Mise à jour 0.91 BETA 04 pour béta testeur chargeur VE et batteries

Bonjour,
Merci pour la MAJ,

Comme d’habitude, zéro soucis pour l’installation.

Comme déjà discuté, je suis intéressé pour une carte bêta-testeur.

Cordialement

• Cette réponse a été modifiée le il y a 4 mois et 1 semaine par Max33.

bonjour Nicolas,

j’ai bien respecté la procédure de sauvegarde de l’ancienne carte SD.

j’ai acheté une nouvelle carte SD 16Go classe 10 pour faire la mise à jour en 0.91 beta 05. gros problème de reboot du serveur WES lorsque je consulte les pages Index et Program (section actions): les pages sont soient grisées ou fond rouge et aucunes données visibles, cf pièces jointes

j’ai la surprise de m’apercevoir que le serveur WES voit la nouvelle carte SD de 16Go à 8Go seulement, est-ce normal? j’ai testé en mettant l’ancienne carte SD, cela fait désormais la même problématique de reboot du serveur wes en consultant la page Index et Program.

est-il possible de revenir sur la version précédente du firmware?

là pour le coup, je ne peux plus utiliser le serveur wes pour gérer à distance ma pompe de forage.

en espérant que vous avez une solution à me proposer.

bonne journée. Sébastien

Bonjour,

j ai le meme probleme pour l onglet Action.

version  micro 0.91b6

version web 0.91b5

cdlt

Bonjour,

MAJ 0.91b7

Idem:

version  micro 0.91b607

version web 0.91b06

De plus, serveur très très lent, et  fond rouge

Caches vide+ test de deux navigateurs.

Cordialement,

Je viens d’essayer, mais cela ne fonctionne pas.

J’ai supprimé l’intégralité des fichiers de la carte SD (à l’exception des dossiers cfg et graph) et j’ai recopié l’ensemble des fichiers présents sur le site.

J’ai également essayé après avoir vidé le cache et avec un autre navigateur, mais le problème est le même.

Merci à vous.

Bonjour,

Mise à jour d’un 2nd WES, le problème est idem.

Pouvez-vous me rappeler la procédure de MAJ? je dois avoir un problème a ce niveau là ….

Cordialement,

Bonjour,
J’ai également les mêmes problèmes, serveur acheté semaine dernière.
Avez-vous résolu le problème ?
Merci

Bonjour,

Oui, j’ai enfin la page principale ! Merci

Par contre, le bouton sauvegarde ne fonctionne toujours pas.

Et j’ai également un problème avec la mesure de tension, j’ai acheté l’alimentations WES 12VDC & 9VAC. PAs de retour de tension.

Je vais contrôler ce soir, mais entre le visuel et le miens, le 9 V AC est à gauche et le miens à droite

OK pour la mesure de tension, petit faux contact.

Pour la sauvegarde, avec EDGE, cela fonctionne à priori. BUG avec Chrome ?

Au niveau de JEEDOM, pas possible de récupérer les valeurs « puissances instantanées » des pinces ?

Merci pour les réponses rapide

Non, l application WES

Bonjour,

Parfait, plus de soucis, je mets en route le WEX ce weekend.

Avez-vous prévu une interface pour programmer des chauffes ( ex: pas assez de surplus solaire pour chauffer le CE)

Cordialement

Bonjour,

Toutes mes condoléances.

Le wex est branché, pilotage en manuel ok, par contre pas de routage en auto, des idées ce qui ne vas pas ?

J’ai remarqué que dans la cinématique, la conso réseau ne s’incremente pas, un rapport ?

Cordialement

Bonjour,

A ce que j’ai lu , j’imagine que le predict dans le MQTT n’est pas encore actif, que les variables n’ont pas augmentées… et que les évolutions sont majoritairement autour de la production.

Je reste donc en V091b02 qui est stable

A bientot

Pascal

Bonjour,

Ssr paramétré et activé.

Ordres des priorités, c’est bien le ssr1. J’ai que ça vu que j’ai pas de marstek ou borne de charge.

En manu, je peux bien piloter avec la charge que je règle.

Voici les captures.

Il faudrait aussi ajouter si possibles  7 plages horaires de programmation (idem batteries ( jour/puissance / périodes horaires/ on off) pour pouvoir chauffer le cumulus s’il n’y a pas eu assez de surplus solaire la journée.

Cordialement,

• Cette réponse a été modifiée le il y a 2 mois et 2 semaines par Max33.

Bonjour

Je ne sais pas si la question a déjà été posée donc je tente. Tout d’abord bravo pour les évolutions sur le WES. Depuis longtemps j’attendais mqtt pour vraiment tout avoir via ce système sur mon jeedom. C’est chose faite et cela fonctionne très bien. Voire même trop 😉 Avant je m’étais fait un petit scénario qui interrogeait périodiquement le serveur WES (toutes les 1 à 2 minutes en gros) pour récupérer l’intégralité des données de téléinfo et des pinces. Ce n’était pas du temps réel mais déjà très très bien. Avec le Mqtt passage au temps réel mais presque trop : je vois que le WES envoie des messages à chaque changement de valeur même minime des pinces ou du linky au global. C’est conforme et logique. toutefois, ma Smart Jeedom et un de mes rpi qui écoutent le WES ont leur charge CPU qui a doublé et de ce que j’ai vu c’est à partir du moment où j’ai activé/basculé vers mqtt mes informations (passa ge de en moyenne 0.8 à 0.9 de load à 1.6 à 2 en moyenne).

Savez vous si on peut indiquer quelque part de ne pas envoyer plus de x infos par minute par exemple ou pas (côté WES ou côté Mqtt) ? Ou mieux pour des variations inférieures à une valeur de ne rien envoyer ? car lorsque ma pince varie de 80 à 81 ou 82 VA puis retour 80 etc ou de 0.36 à 0.38 en intensité, la récupération de l’information ne m’est pas vitale.

Et encore une fois c’est vraiment extra d’avoir mqtt ce qui me permet de faire entrer le WES dans ma logique globale.

Merci à vous

Bonjour,

Ds5 malheureusement non simplement.

C’est vrai que la charge MQTT du Wes grimpe allègrement (j’ai espionné avec Mqtt explorer). Cela est intrinsèque aux données du Wes que nous surveillons et transmettons en MQTT, par nature elles sont loin d’être des constantes (ex simplement l’index de conso….)

En MQTT, le protocole lui-même ne possède pas de paramètre pour définir la fréquence d’envoi des messages. MQTT est un protocole de transport de messages de type Pub/Sub (Publication/Abonnement) agnostique au contenu et au rythme des données.La fréquence de publication dépend entièrement de la configuration de votre code client (le script ou l’appareil qui envoie les données) ou du matériel (les capteurs).

Dans notre cas je ne trouve pas de parametre dans le WES qui déterminerait la periode de mise a jour et d’envoi des données ni le comment (sur spolling tout les X times ticket ou sur changement…) .
Il est  fort probable que dans le code du firmware Nicolas a mis quelques chose de la sorte il faudrait alors qu’eil le rende accessible.

Pascal

• Cette réponse a été modifiée le il y a 2 mois et 1 semaine par plruffin.

A vous deux (DS5 et Nicolas)

Le tempo predict c’est for me, il exist une donnée qui indique la couleur de demain en tempo actuellement pas remontée en MQTT . Pour la cadence 24 fois par jour (toute les heures) dès que connu vers 11h00 si je me souvient…Comme ca si restart au max une heure avant de connaitre c’est largement suffisant.

Coté timing du spolling des remontées MQTT oui le top ce serait de permettre de configurer la valeur par exemple dans la config MQTT a coté (droite des buttons on/off) de selection des des groupes de variables ajouter le temps de spolling (WARNING mettre des sécurités min max car certain tenteront de tout mettre au mini et la risque d’éffrondement CPU du WES!!!!!)

@nico voir ce qui est réalisable simplement, judicieusement ….

Slt

• Cette réponse a été modifiée le il y a 2 mois et 1 semaine par plruffin.

c’est un peu hors sujet ici, mais voici ce qui m’a fortement gêné cette année côté tempo : réduction à pas grand chose de l’écart entre offre HC/HP normale et tempo (l’offre normale a bien évolué mais pas tempo), les jours rouges oui 22 c’est pas tant que cela mais cette année contrairement à 2025 les jours rouges ont tous été mis sur de longues périodes non stop, notamment pendant les vacances de Noel et donc quand on est absent et qu’on doit rentrer avec -2° dehors et une cheminée qui ne s’allume pas à distance, on doit bien mettre le chauffage électrique et en 1 semaine de congés j’ai quasi brulé toute ma marge d’économie tempo. Par ailleurs ne pas utiliser le four en jour rouge, limiter les plaques de cuisson devient un peu complexe pour gagner peu sur l’année : je ne gagne plus que 150€ maxi sur l’année versus 600 il y a 2 ans. Bref je ne vais pas continuer à chauffer moins les jours rouges etc pour si peu. Sans parler que meme en mode éco 15° les radiateurs ont tourné dans la maison quand on était absent en jour rouge. Donc c’est bien si on a un autre mode de chauffage en journée et qu’on reste tout le tmps à la maison ou qu’on accepte de rentrer le soir avec 10 ou 12° dans la maison pour allumer la cheminée et coucher les enfants avec 3 couvertures 😉 Après voila c’est très fonction de nos usages individuels tempo etc donc ca doit rester intéressant pour certains, pour moi ca ne l’est plus. Et je ne prétends convaincre personne, chacun voit son gain.

Bref tout cela nous éloigne de Mqtt pour lequel en revanche je continue à souscrire à l’offre car c’est vraiment un très bon concept avec l’avantage de partager les infos entre plusieurs serveurs domotiques (ce qui est mon cas avec 4 jeedoms). Si on parvient à alléger un peu la charge de traitement des events mqtt sur mes deux jeedom connectés au WES, ce sera top

Bonjour,

J’ai installé une batterie Marstek, .

Je pense l’avoir configurée correctement dans le wes, mais pas de charge ou décharge, le statut reste en attente et réseaux à 0w.

Voir capture

Une idée?

Cordialement,

Bonjour,

Avez-vous une date approximative pour la prochaine MAJ?

Cordialement

Bonjour

Est-ce que la maj proposera de moduler les envois MQTT ?

Merci

Bonjour,

Update fait , merci pour le predict on verra demain si il donne la bonne couleur, ce soir après forcage du predict ce serait Ok

A+

• Cette réponse a été modifiée le il y a 1 mois par plruffin.

Bonjour,

Merci pour la MAJ,

J’ai plusieurs questions,

-Comment programmer la chauffe du CE  via le WES la nuit (pas assez de surplus), je ne trouve pas comment faire dans le menu action.

-Y a t-il un moyen soft, pour éviter la décharge de la batterie si pilotage du WEX en manu la nuit ( soustraire la pince CE à la pince général)

Merci d’avance

Super, si vous pouvez aussi intégrer une détection fin de chauffe, qui permet de désactiver la programmation de la nuit si une charge complète à été effectuée dans la journée.

La Marstek c’est mieux, mais ce n’est pas encore ok de mon côté.

Je peux piloter une charge décharge en manuel, mais en wes pilote, rien de se passe, statut « en attente ». Et la batterie se déconnecte très régulièrement.

Une idée ?

Merci d’avance.

Cordialement

La batterie est branchée en RJ sur le port LAN de la batterie.

Après quelques essais,

La batterie se déconnecte très régulièrement du wes, presque toute les minutes.

J’ai bien monitoré des phases de décharge, mesuré a 370w et affiché 70w sur l’interface WES.

Et les décharges ont durées quelques secondes.

Mes panneaux et la batterie sont sur un tableau divisionnaire, et je mesure la production solaire avec le wes sur la phase dans le principal, pensez vous que la mesure de cette phase où transit batterie et production peut poser problème ?

Aucune idée pour la version soft, il y a moyen de la voir via le wes?

Je n’ai pas de ct002, j’ai acheté la batterie exclusivement pour un pilotage avec le wes.

Si je débranche le LAN, la batterie ne reboot plus d’elle même.

Bonjour,

J’ai fw: e147 v18 b117

L’application est bien en manuel, du moment que je branche le rj sur lan, la batterie reboot toute les minutes environ.

Merci de l’aide.

Bonjour,

Avec la V150, plus aucun problème, merci !

En attendant la prochaine mise à jour qui permettra de gérer les chauffes programmées des SSR, je suis obligé d’utiliser mon ancien routeur pour avoir de l’eau chaude.

Le routeur prend le dessus et la batterie se décharge à travers celui-ci, alors que ce phénomène ne se produisait pas avec l’ancienne batterie Zendure.

Mais ce n’est pas bien grave, le WEX devrait corriger ça !

Merci pour les évolutions !

Bonjour,

Pour info, le WES avec le MQTT a explosé m’a base de donnée Home Assistant (20 Go pour 3 semaines). J’essaie de la réduire depuis plusieurs jours, mais c’est pas simple.

Un enregistrement par minute serait suffisant pour moi.

En fait, ca fonctionne trop bien, c’est super pratique.

Merci,

Bonjour,

Pour la prochaine mise à jour, serait-il possible d’ajouter « Wes pilote » aux conditions de programmation de la batterie ?

Les jours rouges approchent, et l’idée serait de pouvoir charger la batterie la nuit afin de la décharger en mode zéro injection pendant la journée.

À terme, l’idéal serait d’automatiser ce fonctionnement à l’aide des actions et de Tempo Predict.

Cordialement,

• Cette réponse a été modifiée le il y a 3 semaines et 1 jour par Max33.

J-1 : dès que le lendemain rouge est annoncé, activer la recharge réseau pendant les heures creuses(22h-6h) jusqu’à environ 90-95%.

Jour rouge, 6 h–22 h : priorité au solaire, puis à la batterie. Le mode WES pilote me paraît cohérent car on colle au 0 injection/ soutirage

22 h–6 h : recharger au tarif heures creuses rouges uniquement si un nouveau cycle est utile le lendemain (jour rouge) sinon, charge désactivé

Je pilote tout en tempo avec le wes pour delester conso les jours rouges les regles permetent cela facilement avec les info TIC/predict comme premisse des regles

Bonjour, est-ce que un firmware update est necessaire par rapport au Leak PHP si cette techno est utilié? Si oui, quand est-ce qu’il sera dispo ?

Bonjour,

Quelques questions après plusieurs jours d’utilisation.

-Serait-il possible d’ajouter la puissance de charge maximale à la configuration ?

– Pour le mode WES pilote, le WES calcule juste avec la pince générale ou aussi la production ?

J’ai remarqué un yoyo permanent charge/décharge, malgré du surplus présent.

Merci d’avance

Cordialement

• Cette réponse a été modifiée le il y a 1 semaine et 2 jours par Max33.
• Cette réponse a été modifiée le il y a 1 semaine et 2 jours par Max33.

Un parametre pour limiter la puissance de charge de la batterie à une valeur maximale, par exemple 1 200 W (voir capture en pièce jointe) ?

Le problème survient essentiellement lorsqu’il n’y a plus de production solaire.

Par exemple, la maison consomme 500 W. La batterie compense progressivement cette consommation. Une fois l’équilibre atteint, lorsque la puissance arrive à 0 W, la batterie passe en mode charge, puis le cycle se reproduit.

Par ailleurs, ma batterie est raccordée sur un tableau divisionnaire avec mes panneaux solaires. Le WES, situé sur le tableau électrique principal, voit donc l’injection de la batterie comme de la « production ». Cela pourrait-il avoir une incidence sur son fonctionnement ?

Cordialement,

• Cette réponse a été modifiée le il y a 1 semaine et 2 jours par Max33.
• Cette réponse a été modifiée le il y a 1 semaine et 2 jours par Max33.

Très simple il faut un HYSTERISIS c’est un grand classique de l’automation on met un seuil identique en ON et Off mais voila ca fait le Yoyo  (charge, tempe, debit……).

Il faut que les deux seuils soit diffrérents avec un ecart (Hysteresis) suffisant .

Pour expliquer j’ai par exemple des delestages sur consommation a 12kw  je coupe un gros consommateurs mais si je ne mets qu’un seuil identique des que ce conso sera Off la P va repasser au dessous du seuil et la ca va reneclencher et de nouveau P sup et ainsi de suite . Mon suil coupure et renenclechement sont différents de 3kw mini …

Pour ton cas il faut un seuil pour ON charge et un pour Off charge avec un ecart suffisant pour que ta conso moyenne passe tranquille

Concernant la décharge, il y avait une interférence avec mon routeur.
Pour la charge, il y a toujours un comportement hasardeux. Voici trois captures d’écran prises dans l’ordre, à quelques secondes d’intervalle :

-1:Surplus d’énergie renvoyé vers le réseau.

-2:Affichage de 0 W de production (alors qu’il y a bien une production en temps réel), avec un import depuis le réseau pour charger la batterie.

-3:Retour à la situation n° 1.

Ce comportement se répète ensuite en boucle.
J’ai l’impression que cela pourrait être lié au fait que la batterie est raccordée dans le tableau divisionnaire, avant la pince de mesure. Dès que la batterie commence à se recharger, la mesure passe à 0 W, ce qui provoquerait une injection .
Est-ce que cette hypothèse est plausible ?

• Cette réponse a été modifiée le il y a 1 semaine par Max33.
• Cette réponse a été modifiée le il y a 1 semaine par Max33.

Merci du retour, je m’en doutais.

Impossible pour moi de tirer la pince avec les 25m qui les séparent.

J’attends donc votre module d’extension de pinces.

A titre d’info, pourquoi ne pas avoir utilisé seulement la pince générale pour gérer ça (comme les CT d’origine et divers routeurs)? il y a un gain sur la gestion?

Hello Nicolas,  Un petit retour sur PREDICT en MQTT car ce matin il annonce demain blanc !

Alors pour moi toujours 1 en retour , mais je me pose une serieuse question la « variable instance » que je recupère s’appel Tempo Predict Enable et c’est la je pense le Hic effectivement c’est bien enable mais ce que je veux c’est la couleur de demain . je n’ai pas vu dans mon discovery autre chose.

pour info j’ai relancer les discovery et rien ne change toujours que le valide ou pas

J’ai telecharger le MQTT debug pour voir:

{
« device_class »: null,
« disabled_by »: null,
« disabled »: false,
« entity_category »: null,
« entity_id »: « sensor.local_technique_wes_tempo_predict_enabled »,
« icon »: null,
« original_device_class »: null,
« original_icon »: null,
« state »: {
« entity_id »: « sensor.local_technique_wes_tempo_predict_enabled »,
« state »: « 1 »,
« attributes »: {
« friendly_name »: « WES Tempo Predict Enabled »
},
« last_changed »: « 2026-11-05T12:42:52.158286+00:00 »,
« last_reported »: « 2026-11-05T12:42:52.158286+00:00 »,
« last_updated »: « 2026-11-05T12:42:52.158286+00:00 »
},
« unit_of_measurement »: null
A priori ne construit que le sensor enabled dans les attributs possibles

Une reception

« transmitted »: []
},
{
« entity_id »: « sensor.local_technique_wes_tempo_predict_enabled »,
« subscriptions »: [
{
« topic »: « WES/wes_36842f/tempo_predict »,
« messages »: [
{
« payload »: « {\ »enabled\ »:1,\ »etat\ »:5,\ »aujourd_hui\ »:1,\ »demain\ »:2,\ »bleu\ »:67,\ »blanc\ »:0,\ »rouge\ »:0} »,
« qos »: 0,
« retain »: false,
« time »: « 2026-11-05T12:42:52.156043+00:00 »,
« topic »: « WES/wes_36842f/tempo_predict »
},
{
« payload »: « {\ »enabled\ »:1,\ »etat\ »:5,\ »aujourd_hui\ »:1,\ »demain\ »:2,\ »bleu\ »:67,\ »blanc\ »:0,\ »rouge\ »:0} »,
« qos »: 0,
« retain »: false,
« time »: « 2026-11-05T12:42:55.773884+00:00 »,
« topic »: « WES/wes_36842f/tempo_predict »
}
]
}
],

Les argumenst Payloads ont bien la totale coté datas transmis

et une petit snap sous mqtt explorer qui confirme que ca transmet bien la totale

« discovery_data »: {
« topic »: « homeassistant/sensor/wes_36842f/tempo_enabled/config »,
« payload »: {
« state_topic »: « WES/wes_36842f/tempo_predict »,
« value_template »: « {{ value_json.enabled }} »,
« device »: {
« manufacturer »: « Cartelectronic »,
« model »: « WES V2 »,
« identifiers »: [
« wes_36842f »
],
« name »: « WES »
},
« unique_id »: « wes_36842f_tempo_enabled »,
« name »: « Tempo Predict Enabled »
}
},
« transmitted »: []
},

Nicolas Oui moi aussi j’ai mis la copie idem a toi mais dans le discovery data seul le champs enable est present et traité voir mon dermier message.

De meme dans le discovery recu il n’y a que le champ ENable les autres ne sont pas « construits »

« attributes »: {
« friendly_name »: « WES Tempo Predict Enabled »
}, C’est le seul construit

Si tu a un HA regarde si dans tes sensors si tu as en plus de ENABLE les autres moi non

APrès je peux faire un template ou une creation a la mano mais ca me plait pas je prefere que le WES donne bien le bon discovery

Voila l’extrait de fichier debug MQTT section WES

},
« device »: {
« id »: « 7990efab7f8c00a43bd3878f809b3034 »,
« name »: « WES »,
« name_by_user »: « WES »,
« disabled »: false,
« disabled_by »: null,
« entities »: [

en copie ecran les deux sensors crées pas de demain mais enable

section transmis:

« transmitted »: []
},
{
« entity_id »: « sensor.local_technique_wes_tempo_predict_enabled »,
« subscriptions »: [
{
« topic »: « WES/wes_36842f/tempo_predict »,
« messages »: []
}
],
« discovery_data »: {
« topic »: « homeassistant/sensor/wes_36842f/tempo_enabled/config »,
« payload »: {
« state_topic »: « WES/wes_36842f/tempo_predict »,
« value_template »: « {{ value_json.enabled }} »,
« device »: {
« manufacturer »: « Cartelectronic »,
« model »: « WES V2 »,
« identifiers »: [
« wes_36842f »
],
« name »: « WES »
},
« unique_id »: « wes_36842f_tempo_enabled »,
« name »: « Tempo Predict Enabled »
}
},

Toujours qu’enable

Le snap MQTT explo apres activation du bouton forcage Predict pour avoir la ligne  predict

• Cette réponse a été modifiée le il y a 5 jours et 9 heures par plruffin.
• Cette réponse a été modifiée le il y a 5 jours et 9 heures par plruffin.

Avec des badges et widgets d’annonce de la couleur rouge du lendemain sur les terminaux IHM (ex SOnOff Panel 120) et annonce vocal sur ALEXA pour que les personnes prennent les choix en consequence ex faire la lessive / lave vaisselle repassage

Sinon Ok si tous les sensors…on va pouvoir traiter cela

Coté automatisation par exemple on forcera le chauffe eau pour qu’il accumule avant le rouge journée

• Cette réponse a été modifiée le il y a 5 jours et 4 heures par plruffin.
• Cette réponse a été modifiée le il y a 5 jours et 4 heures par plruffin.

Nicolas , si tu peut déposer avant fin Novembre la version qui corrige le predict ce serait pas mal ….

Jusque la vu les températures on ne devrait pas avoir de rouge en masse