Mise à jour 0.9 beta 05

Bravo Nicolas pour l’intégration du MQTT, le WES s’offre une nouvelle jeunesse !

Ca fait des années que je l’utilise et j’admire votre ténacité à le faire évoluer.

Pour la partie routage du surplus de production photo-voltaique j’utilise un circuit dévellopé par F1ATB et je constate que ce principe à été repris sur cette mise à jour.

Le module WEX qui figure sur le tableau de bord doit certainement piloter des relais statique, pouvez vous nous en dire un peu plus sur le matériel à acquérir, sa disponibilité, …

Je suis intérressé pour  tout centraliser sur le WES.

Merci.

• Cette réponse a été modifiée le il y a 3 mois par Franky77.

Super

je test MQTT vir le post dédié

A+

DynDns OK testé ce jour , enfin un accès externe secure simple et efficace

j’ai désactivé mes bidouilles secures.

Bonjour Nicolas,
Merci pour cette mise à jour. Je reviens sur le MODBUS ;
– Problème d’affichage des graphes : j’ai l’impression que le fichier MBGRAPH.HTM ne serait pas le bon ? (voir copie d’écran)
– Problème d’enregistrement des MB.CSV : Les enregistrements n’ont fonctionné que 4 minutes après la mise à jour (voir copie du fichier)
J’ai du faire une erreur ou un oubli quelque part !
Pouvez-vous m’aider pour résoudre ces problèmes ?
Cdt
Gaby-69

Nicolas,

je ne sais si vrai dysfonctionnement ou non, mais a 11h55 ce jour recu mail comme quoi demain Blanc sur le predict WES toujours inconnu alors que normalement si je ne me trompe vous updaté a 11h30! Pas eu de reset du wes donc On continu.

A+

sauf erreur de ma part, je pense qu’il y a quelques liens à revoir sur la partie pince de courant pour avoir les bonnes informations.

Sur HA, on retrouve bien les 4 pinces.

Si on va sur chaque pinces on se retrouve sur la fenetre capteurs avec les informations suivantes :

• Cos phi
• courant A
• puissance W
• Puissance apparente VA

Sauf pour la pince n°4, il manque les valeurs pour le Courant A et la Puissance W.

Aussi mes pinces sont affectées respectivement sous les noms suivants :

1. Panneaux Photovoltaique
2. PAC maison
3. Piscine
4. Réseau EDF

Les  noms d’affectations de chaque pinces sont décalés de +1 dans HA mais les valeurs lues correspondent bien à la bonne pince, par exemple pour la fenetre capteur de Panneaux Photovoltaique (pince n°1) on peut lire :

• Cos Phi
• Courant PAC maison
• Puissance PAC maison
• Puissance apparente

Voila ce que je peux vous remonter, à voir si cela est général ou localisé sur mon cas.

Bon week end

• Cette réponse a été modifiée le il y a 3 mois par Franky77.

Nicolas,

La partie MQTT est géniale, mais il y a quelques correction à faire

Je confirme les remarques de Francky77, sur l’absence de la pince 4 et le décalage des noms.

Est il possible que les pinces remontent les index?

Merci

Laurent32 et Francky77,

Vous avez quelle version de HA  (valable aussi pour Nicolas)

Moi la dernière
Core2026.3.1

• Supervisor2026.03.0
• Operating System17.1
• Interface utilisateur20260304.0

Vous avez intégré quoi et comment , perso pas tout vraiment idem à Nicolas mais je pense qu’il a une ancienne version!

Perso j’ai intégré sous application (icone jaune APPS) Mosquitto broker en Version actuelle : 6.5.2 qui est le broker MQTT . C’est avec lui que le cilent MQQT du Wes se connecte. KJ’ai aussi MQTT explorer en intégration sous HA qui est idem a la version exe sous windows que j’ai aussi.

Coté clien MQTT sous HA j’ai dans appareils et services (icone bleu) ajouter le service MQTT client qui me donne bien mais en parti seulement des retours du WES . Il ne remonte pas toutes les informations que certaines et sans valeurs!

MQTT wes ne me parait pas encore pleinement full opérationnel mais c’est un bon début

En attendant je reste sur RestFull

A+

• Cette réponse a été modifiée le il y a 3 mois par nicolas_cartelec.

Bonjour Nicolas,
Avec cette mise à jour 0.9b05 les fichiers MB-xx-xx.csv ne sont plus enregistrés !
Avec la version 0.9b02 cela fonctionnait ?
A la mise à jour, du 12 mars, les enregistrements ont bien commencé pendant 4 minutes, puis plus rien (copie du fichier .csv du 12 mars)
Merci de voir ce problème
Cdt
Gaby-69

• Cette réponse a été modifiée le il y a 3 mois par Gaby-69.

Ok je modifie les noms pour supprimer les accents.

Concernant la box HA, green de chez Nabu Casa et toutes les versions logiciels identiques à vous.

J’ai bien la tension présente sur le WES via le transfo 9v.

La pince 4 est bien présente mais que 2 entités disponible, cos phi et VA.

Si tout est ok chez vous, le PB demeure donc sur mon HA (je ne maitrise pas encore parfaitement le HA)

Hello,

Perso Raspy 4 avec SDCARD boitier Argon One avec ventilateur.

Seul le hard diffère mais pas le soft.

A+

Nicolas, espaces caractères spéciaux j’imagine que cela pose aussi souci!

Nicolas, pour le predict demain toujours inconnu, depuis la dernière version!

Bonjour Nicolas,

Afin d’etre sur, j’ai refait entierement une µSD depuis un PC en recopiant toute l’archive !

J’ai toujours le non enregistrement des fichiers CSV en Modbus (voir copie du répertoir MB ci-jointe)

Si cela peut vous aider, je peux vous donner l’IP pour vous connecter sur le site ?

Cdt

Gaby-69

Pour complèter, au démarage de la nouvelle µSD il n’y a pas été créé de répertoires MB, PCE et TELEINFO Pourquoi ?

Pouvez-vous donner des exeplications sur ce que fait le systeme lors de son chargement ?

Merci

Pour cette mise à jour quelle est le BINAIRE à utiliser ?

Je reviens sur le fonctionnement du MODBUS :

• 1 /GRAPH/MB/2026/WNOMx.DAT Les entetes sont bien crées mais pas d’enregistrements
• 2 /GRAPH/MB/2026/03/WNOMx.DAT Les entetes sont bien crées mais pas d’enregistrement
• 3 /MB/2026/ Enregistrements OK avec le binaire V0.b02 Pas d’enregistrement avec le binaire V0.b05
• 4 Le fichier MBGRAPH.HTM me parait erroné car l’on affiche : Temperature en °C et Humidité en % !!! nous somme en Kwh, A. et V. !!!

Je pense qu’il y a un problème avec le binaire ?

Merci pour votre réponse

Cdt

Gaby-69

moi j’ai le 05 pour le bin et le O6 pour le web

Coté MQTT pour le moment pas vu grand chose, mais regardé rapidement

Merci pour votre réponse

J’ai toujours la même chose quelque soit les binaires V0.9b05 ou V0.9b06 pas d’enregistrement de CSV en MB !

Si je reviens au binaire V0.9b02 les enregistrement CSV en MB fonctionnent.

Il faut déjà régler ce problème avant d’aller plus loin…

Gaby-69

Pour moi pas vu de différence tant coté Prédict que MQTT…

Voici le fichier de ce jour MB-03-17.csv

Merci pour cette information

J’ai donc supprimé tous ces « SILENCE » Les différents fichiers sont bien enregistrés. On dirait que le MB fonctionne correctement du coté enregistrement ! Reste à tester le dialogue « maitre/esclave » !

Je ferais le point demain… après une nuit de teste en V0.9b06…

Bonne soirée

Gaby-69

Fra,cky 77,

Tu as mis quoi comme app, appareils et service coté HA car moi avec Mqtt brooker en APP et l’aplli/service Mqtt je n’ai rien de remonté et toujours qu’une partie des données du WES comme modèle entité remonté par le discovery!

Nicola, j’ai bien On les pinces , les capteurs , les relais y compris extension….

Bon je verrais pour tout supprimer, nettoyer HA puis réinstaller

A+

Nicolas,

J’ai regardé les logs de Mosquitto broker, voir extrait ci dessous (app: MQTT entité MQTT Broker mosquito, option télécharger les diagnostiques)

dans le discovery data deux « champs me paraissent troublant: Message [] et Transmitted[] qui sont vide !

EXTRAIT:

{
« entity_id »: « sensor.cuisine_lingerie_courant »,
« subscriptions »: [
{
« topic »: « WES/wes_36842f/clamps »,
« messages »: []
}
],
« discovery_data »: {
« topic »: « homeassistant/sensor/wes_36842f_clamp1/clamp1_current/config »,
« payload »: {
« value_template »: « {{ value_json.c1 }} »,
« state_topic »: « WES/wes_36842f/clamps »,
« device_class »: « current »,
« name »: « Cuisine Courant »,
« state_class »: « measurement »,
« unit_of_measurement »: « A »,
« device »: {
« via_device »: « wes_36842f »,
« model »: « WES Current Clamp »,
« identifiers »: [
« wes_36842f_clamp1 »
],
« manufacturer »: « WES »,
« name »: « Cuisine »
},
« unique_id »: « wes_36842f_clamp1_current »
}
},
« transmitted »: []
},

@Nicolas, Predict a priori Ok j’ai bien Rouge Rouge et les bonnes valeurs .

Pour info ceux qui suivent mon anomalie tempo : Changement Cpt pas mieux je suis Bleu alors que rouge (tant mieux pour la facture) et devinez ENEDIS 3 mois plus tard par mail m’indique « On a vu que dans votre coin il y a des pertubations sur le reseau qui genes le concentrateur on ne peut donner de date de rétablissement »

Ce que je disais le CPL ENEDIS (Ex EDF) pourri par des clients qui injecte plein de parasites. Un point a approfondir il y a ces derniers temps beaucoup de solaire qui c’est intallé…les Onduleurs Solaire (surtout ceux pas cher) ont la facheuse tendance a faire de la « Merde ».

A+

Bonjour Nicolas,

Pour faire le bilan sur MODBUS aprés une nuit sans avoir de SILENCE ! Bravo, vous avez mis le doigt sur le bug !

Il en resort que la première ligne de BMVAR (Idx 1) s’enregistre à « 0 » (copie d’écran ci-jointe)

Dans le fichier MB-03-18(2).csv on a bien la valeur pour tous les registres interrogés sauf pour le premier =0 ?

Quel est votre avis ?

Cet un compteur d’énergie triphasé « Schneider iEM3255 » (ci-joint la doc « Communication via Modbus »)

J’attendrai votre mise à jour pour refaire des essais avec ou sans silence.

Merci

La doc ne passe pas, si vous en avez besoin je peux vous l’envoyer par mail ?

Bonjour

j’essaye d’integrer le WES dans HA via le MQTT, mais je ne sais pas comment formater mon configuration.yaml.

J’ai bien les donnees qui arrivent via MQTT ( ca donne un serieux coup de jeune au WES , merci )

Quelqu’un peut me poster un exemple svp ?

Je debute dans Home Assistant, merci

Petit complement a mon message precedent.

Je cherche a utiliser les donnees de 3 compteurs impulsion, 4 pinces amperemetriques et 2 sondes de temperatures ( temp, humidite, lux ) en 1 wire.

Merci d’avance

Bonjour Nicolas,

Aprés plusieurs semaines d’utilisation du MODBUS sur le WES, soit en V0.9b02 ou V0.9b06, j’ai constaté les points suivants :

• L’interrogation en 32 bits fonctionne (avec les parametres ci-joint Doc page 65)
• L’interrogation en 64 bits ne fonctionne pas (avec les parametres ci-joint Doc page 66)

Pour avoir les bonnes valeurs du 64 bits, j’ai du me mettre en 32 bits, Type = 32 bits (registres 3204 et 3256)

• Le registre interrogé en premiere position est enregisté à zero (0) (fichier MB-03-22.csv ci-joint)
• Avec ce même registre dans une autre position est lu et enregisté !!!

Merci pour votre avis

Cdt

Gaby-69

• Cette réponse a été modifiée le il y a 2 mois et 3 semaines par Gaby-69.

Oui, j’ai essayé tous les ordres des bits en 64 bits, aucune valeur est coherante. Seul le 32 bits donne les bonnes valeurs ?

Comment peut on savoir ce que répond l’esclave ???

Après relecture de la documentation de Schneider, il ne faut pas utiliser les adresses des registres en DECIMALE car il y a un décalage de « 1″ avec l’adresse HEX !

J’ai donc utilisé les adresses en hexadecimale, pour l’instant tout tourne…

Je ferais un bilan aprés cette nuit avec le fichier csv complet !

Bonjour Nicolas,

Aprés une journée de fonctionnement avec les bonnes adresses des registres, la fonction lecture des registres fonctionne !

Un seul problème reste à regler : la lecture et l’enregistrement des deux premières lignes MB CPT1 et MB CPT2 (voir fichier CSV ci-joint)

Lors de l’interrogation de MB CPT1 la réponse n’ai pas reçu (voyant à rouge) puis avec un retard la valeur est affichée (voyant à vert) mais dans le fichier la valeur est enregistrée à zéro (0)

Même chose pour MB CPT2 mais que toutes les 10 minutes à 30 minutes

Pour toutes les autres lignes pas de problème. J’ai donc oublié ces deux premieres lignes…

Merci de voir ce bug !!!

Cdt

Le compteur n’est pas en cause, car l’interrogation de ces registres a ete faite a l’identique en Idx 1 = Idx 12 et Idx 2 = Idx 13

Les resultats sont correctes en Idx 12 et Idx 13

Merci pour votre réponse et vos conseils

Je n’ai plus qu’a attendre la nouvelle version !  une date ?

Cdt

Bonjour Nicolas

J’ai testé le fonctionnement des 2 relais intégrés au WES avec la fonction Tempo, et ils fonctionnent parfaitement avec la 0.9 beta 06 (problème remonté par Bernard sur la beta 05).

J’ai pour ma part constaté une anomalie avec les fichiers csv des sous-compteurs (PLS) : Les deux premiers groupes correspondant au mois et au jour sont toujours à zéro. En revanche les autres groupes donnant les index des différents compteurs fonctionnent bien et incrémentent normalement d’un jour sur l’autre. Cette anomalie n’est pas présente sur les csv de la TELEINFO et des pinces (PCE).

Après recherche dans mes fichiers, le problème est apparu chez moi à l’installation de la beta 05 et sur mes deux WES. S’agit-il d’un bug ou d’un problème de configuration ?

Merci pour votre aide.

Bonjour,

J’ai essayé avec différent réglage c’est pareil

Bonjour,

Oui j’ai bien les équipements sous home assistant

Bonjour Nicolas,

J’ai un problème avec les graphes en Modbus.

Après avoir changé les libelles des courbes « puissance » deux de ces courbes ont pris un coéficiant de 1000 ?

17.00 devient 17000.00 ou 52.00 devient 52000.00

Ci-joint le fichier : GRAPH/MB/2026/04/020.DAT à partir de la ligne 12h20 on peut voir le problème !

J’ai fait des « reboot » recharger le « binaire » rien ne change ???

Que faire ?

Cdt

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

Ci-joint des copies d’écran Modbus

Toutes les lignes « puissance » ont les mêmes parametres

Non rien n’a été changé, sauf les noms des courbes !

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

Non, je n’ai rien changé. Toutes les 4 lignes « puissance » ont les mêmes parametres !

Sur la page « Valeurs Modbus » les valeurs affichées sont bonnes et en Kw.

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

Fichiers envoyés !

Super maj ! Merci 🙂

Question pour la prochaine mise a jour.

Niveau gestion batterie marstek. Une gestion de plusieurs batterie est elle envisagée ?

Merci encore pour toute ces mise a jours et mise a niveau. Wes reste a la page grace a vous !

Bonjour Nicolas,

depuis l’installation de la mise à jour de cette version le 11/03, je constate qu’il me manque des données sur les fichiers csv annuel et plus précisement :

teleinfo –>RAS

Pinces ampèremétrique –> pas de synthèse avant le 11/03 mais j’ai les fichiers csv journaliers

Compteurs d’impulsions –> pas de synthèse après le 11/03 mais j’ai toujours les fichiers journaliers

J’ai transféré l mise à jour via filezilla donc théoriquement les dossiers contenant ces données ne sont pas touchés.

Est ce un bug ?

Merci.

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

Bonjour Nicolas,

J’espère qu’il n’est pas trop tard, mais serait-il possible d’intégrer dans la prochaine mise à jour : l’unité « Puissance » en W, dans la liste déroulante  » Unités  » de la « Programmation des registres MB ».

Pour info, je me bats depuis longtemps avec la programmation pour gérer intelligemment mon installation triphasée (consommation et production PV). Le TIC ne fournissant que des puissances apparentes individuelles par phase et globale, il est difficile de savoir rapidement et de manière automatique la puissance active que l’on consomme réellement (qui est celle que l’on paie) et donc celle disponible, lorsqu’on produit en PV. C’est encore pire lorsque le réseau est déséquilibré et lorsque les 3 phases ne sont pas dans le même sens. Pour avoir une idée plus précise, j’utilisais un Shelly 3EM avec une pince sur chaque phase et qui fournit en quasi instantané, pour chaque phase, et au global:  la puissance active et son sens (- pour injection et + pour soutirage). Malheureusement à part consulter les informations sur mon PC ou mon smartphone, il ne servait pas à grand chose. Avec l’implémentation du Modbus sur le WES, il va être possible d’utiliser la mesure de puissance active du Shelly ( ou d’un autre compteur 4 cadrans plus industriel). Seul petit problème, le shelly est en modbus TCP et le WES en RTU. J’ai commandé une passerelle Modbus TCP <> RTU, j’espère que cela va fonctionner, car je ne suis pas super à l’aise avec la programmation Modbus. Cela explique néanmoins ma demande concernant l’intégration de l’unité puissance dans la programmation. Il sera alors possible au WES de déclencher des actions conditionnées à la puissance active instantanée ou moyennée soit en Modbus, soit sur le réseau 1 Wire, et ce de manière simple. J’ai bien conscience que disposer d’une unité « Puissance » n’est pas indispensable au fonctionnement du Modbus. Mais ce sera plus propre…

Merci par avance.

Bonjour à Tous,

Bonjour Nicolas,

La page MBGRAPH.HTM est rouge depuis quelques jours sans aucune modification du WES

J’ai rechargé tous les fichiers .HTM, Reset, Ctl-F5 : rien ne change ????

Dans quelle direction faut-il chercher ?

Merci pour vos aides

Cdt

Gaby-69

Merci Nicolas pour toutes ces précisions.

Ce serveur WEB devient de plus en plus performant ! Bravo, on attend la suite avec impatience.

Pouvez-vous nous donner une date pour cette nouvelle version ?

Cdt

Gaby-69

Merci, vous êtes super !

Merci pour la MAJ.

Pas de problème particulier à l’installation.

Le WEX arrive à la vente en suivant ?

Cordialement

Bonjour,

Bravo pour cette nouvelle évolution qui va encore nous faciliter la vie…
Comme je l’ai précisé par ailleurs, je possède un compteur Shelly Pro 3 EM compatible Modbus TCP. Je n’ai pas réussi à le connecter au WES à l’aide d’une passerelle Modbus TCP <> RTU (problème de time out ou autre, débuggage impossible pour moi avec 3 appareils connectés en série). Avec l’arrivée du Modbus TCP sur le WES, j’ai de nouveau tenté de venir lire les données du Shelly avec le WES, cette fois en direct. Le WES voit bien le Shelly et semble dialoguer avec lui (led verte), mais impossible d’obtenir autre chose que la valeur zéro pour la puissance active. Il semble que le WES ne parvienne pas à former la valeur de la puissance active à partir de la lecture des deux registres concernés. J’ai testé les différents « types de valeurs », les différents « Bits Orders », rien n’y fait.

Mes compétences en Modbus étant limitées je joins la copie de l’écran comportant la commande que j’ai saisie. Si quelqu’un voit une erreur, merci de me la signaler. Peut-être y a-t-il aussi incompatibilité entre le WES et le Shelly ?

Pour Info le Shelly est correctement lu par QModMaster. Les registres contenant la puissance active sont 1012 et 1013. Le Shelly semble fournir des Float 32 IEEE754 little-endian.

Cela fonctionne avec le multiplicateur 1.

Manifestement je suis sur le registre de l’intensité pas de la puissance, mais en tatonnant un peu je devrais trouver le bon. Je le posterai une fois trouvé, pour éviter à d’autres de le chercher dans la doc Shelly qui n’est donc pas tout à fait à jour…

Merci Nicolas pour votre aide

Au final la Puissance active totale instantanée en triphasé est dans le registre 1014 du Shelly Pro 3EM (Version 1.7.5), et il convient d’y appliquer le multiplicateur 0,001 pour l’afficher en Watt.

Je joins la copie d’écran de programmation.

Pour tous ceux qui rencontrent des problèmes de gestion de puissance active disponible en triphasé avec des panneaux solaires (en monophasé le WES fait le travail de manière autonome), le Shelly Pro 3 EM 3 CT63, avec ses 3 pinces séparées permet de fournir au WES la puissance active totale instantanée (en injection comme en soutirage), et donc d’établir une programmation de démarrage des divers consommateurs. Il n’a bien évidemment pas la robustesse ni le côté industriel d’un Schneider A9MEM3255 nativement en Modbus RTU, mais il coûte environ 2,5 fois moins cher….

Ayant fini mes essais un peu tard hier soir, je n’ai pas testé la mesure en injection. Mauvaise surprise aujourd’hui dès que Shelly envoie un nombre négatif pour la puissance active instantanée (cad lorsque l’on injecte sur le réseau), le WES affiche zéro. Il semble donc ne pas pouvoir lire les valeurs négatives.  Avez -vous un avis sur le sujet Nicolas ?

Voilà les deux copies de qModmaster une en Hex et l’autre en Dec.

Les valeurs de puissance données par le Shelly au moment des captures étaient comprises entre -450 et -650 W ( donc en injection). Le WES affichait zéro.

Pour info dès que la valeur de puissance redevient positive le WES l’affiche de nouveau sans intervention

Bonjour,

J’ai regardé dans le menu WEX,

Je ne comprends pas bien la cinématique.

En injection solaire, la valeur est bien affichée avec la cinématique qui va bien Panneaux vers Maison

Si je rajoute une charge de 3000W, ça n’affiche pas correctement (voir capture)

Du panneau a la maison, j’ai le delta de ma conso-  prod solaire

et ma charge apparait entre les panneaux et le réseau (et non pas entre réseau et maison)

As-tu une explication? (mauvaise config des pinces? )

Merci a toi

La pince général sur la phase entre le AGPC et le tableau général

Et la pince de production entre le coffret AC et le tableau général ( micro-onduleur).

Les pinces sont situé sur les mêmes câbles que mon routeur actuel (j’ai bien les même mesures de valeurs que celui-ci ).

d’ailleurs est-il possible que la pince général affiche du négatif quand il y a injection sur réseaux?

Bonjour Nicolas, merci pour cette future modif du Modif TCP . Je testerai dès réception le fonctionnement.

Par ailleurs, je travaille en parallèle sur du Modbus RTU pour piloter une wallbox. J’ai donc acquis, malgré son prix, un compteur Schneider iEM3255 pour alimenter ma chaîne Modbus RTU avec des données Modbus directement utilisables (en fait un WES en Modbus TCP pour l’affichage temps réel de la production et de la consommation, et un deuxième WES en Modbus RTU, pour le pilotage, toujours temps réel, des automatismes).

J’ai des difficultés à communiquer avec le Schneider ( comme je l’ai déjà dit, je ne ne suis pas un crack du Modbus). La Led verte s’allume, mais les infos sont incohérentes. Je n’arrive pas en outre à chercher le bon registre (contenant la puissance active instantanée globale) car je ne suis pas sûr de mon paramétrage et je n’arrive pas à déterminer si je ne suis pas au bon endroit ou si je ne choisis pas les bons paramètres. Si quelqu’un utilise déjà ce compteur Schneider, merci de me communiquer l’ensemble des paramètres utilisés, ça m’aiderait beaucoup.

Mes réglages sont les suivants :

1 – Schneider en parité Even (parité paire sur le WES) . Faut-il plutôt None sur le Schneider et pas de parité sur le WES ?

2 – Vitesse réglée à 9600 bauds sur le Schneider et le WES

3 – Adresse esclave : 1

4 – Registre : ? – j’en ai testé des tas mais comme je ne suis pas sûr des autres paramètres…

5 – Fonction 3 ( Read Holding Register)

6 – Type valeur : Float 32 bits

7 – Bit Ordre : ABCD

8 – Multiplicateur : 0,001

9 – Interval Lecture : 10 s

10 – Silence x 10 ms : 5

Bonjour Nano42,

Voici mes parametres de la page MBPROG.HTM :

Description = Energie active totale

Modbus = RTU

Adresse = 1

Registre = 3203

Fonction = Read Holding Register

Type valeur = 64 bits

Bit ordre = 64 bits HGFEDCBA

Multiplicateur = 0.0010

Variables Modbus = MB CPT1

Unité = KWh

Interval lecture = 10 s.

Silence = 0

Cdt

Gaby-69

Merci pour ces infos qui m’aident à avancer.

J’ai dans un premier temps appliqué les paramètres conseillés par Nicolas, notamment la vitesse et l’absence de parité sur le schneider et sur le WES ( par ailleurs c’est bien « Read Holding Register qu’il faut appliquer, « Read Input Register » provoque une led rouge immédiate). J’ai ensuite testé la configuration de Gaby-69. Cela fonctionne parfaitement chez moi aussi. Rapporté à la doc Schneider on voit bien l’offset de 1 puisque la doc donne le registre 3204 pour l’énergie totale importée et qu’il faut taper 3203 dans le WES (3204 ne fonctionne pas). J’ai testé avec succès d’autres registres en Int64.

En revanche je ne parviens pas à lire les registres en Float32. La puissance active totale instantanée est dans le registre 3060 (doc Schneider). Que ce soit en 3060 ou 3059, j’obtiens des valeurs instables parfois très grandes et parfois zéro, qui alternent au cours des lectures successives toutes les 10 S. La led demeure verte. J’ai testé également sans succès tous les ordres de bits.

L’un de vous est-il déjà parvenu à lire un Float 32 Schneider ?

Je soumets ce nouveau problème à la sagacité de Nicolas.

Je n’ai pas de probleme pour litre du Float 32 bits ! avec DCBA pour l’ordre des bits.

Courant Ph 1 = 2999

Courant Ph 2 = 3001

Couranr Ph 3 = 3003

Tension L1-L2 = 3019

Tension L2-L3 = 3021

Tension L3-L1 = 3023

Bonne soirée

Gaby-69

J’ai oublié les puissances !

Puissance Ph 1 = 3053

Puissance Ph 2 = 3055

Puissance Ph 3 = 3057

Puissance totale = 3059

Cdt

Encore merci pour votre aide

En utilisant les paramètres de Gaby-69, et notamment les puissances actives par phase, j’ai pu déterminer que le WES ne lit pas les valeurs négatives en MTU (même comportement qu’en TCP).

Je ne m’en suis pas aperçu tout de suite car je ne cherchais à obtenir que la puissance active totale, or dès qu’une des 3 phases est en injection la puissance active totale passe à zéro, ce qui me laissait penser à un problème de lecture. En revanche lorsque les 3 phases sont en soutirage, une puissance totale s’affiche.

Par ailleurs,  toutes les valeurs en Float 32 sont tronquées après la virgule (tension, intensité, puissance) ce qui donne des valeurs très approximatives. En revanche les valeurs en Int64  (compteurs totalisateurs) sont elles affichées avec les 3 décimales actives.

Il s’agit probablement d’un problème de remontée des données, car sur l’écran LCD du Schneider, la puissance active en injection est affichée correctement avec le sens (+ ou -) et la précision normale.

Merci Nicolas de bien vouloir regarder s’il est possible de traiter ces problèmes avec celui du TCP pour la prochaine version.

Formidable !

Est-ce que cette maj traite également le problème de troncage des décimales ?

Une petite information complémentaire. Je ne sais pas si ça peut aider, mais j’ai remarqué que l’export de la puissance active active issue du Shelly (TCP) vers une Variable virtuelle fonctionne parfaitement : valeur exacte avec le bon signe. Ce n’est pas le cas en RTU.

J’ai en outre une question concernant l’usage des valeurs récupérées. Comment peut on utiliser soit une variable Modbus, soit une variable virtuelle dans la programmation des actions, puisque ni les variables Modbus, ni les variables virtuelles n’apparaissent dans la liste déroulante des sources possibles pour la programmation. Faut-il passer par une étape intermédiaire, si oui laquelle ?

Dans l’onglet « Actions » lorsque j’ouvre la liste déroulante des sources :

• sur mon serveur en Modbus RTU, les variables Modbus apparaissent entre les relais 1 Wire et les switchs virtuels (voir photo)
• sur mon serveur en Modbus TCP, les variables Modbus n’apparaissent pas (voir photo)

Bonjour Nicolas,

Merci pour cette mise à jour. Pas de probleme, l’opération s’est déroulée prarfaitement !

Attention il faut bien reprendre les multiplicateurs : Float 32 bits = 1.000 et 64 bits = 0.0010 pour avoir les bonnes valeurs.

Question :

Pouvez-vous me donner votre philosophie pour la géstion des « Variables Virtuelles » car elles sont à deux endroits ?

MBPROG.HTM

RELCFG.HTM

et non pas les mêmes fonctions ???

Encore Merci

Cdt

Gaby-69

Merci pour vos explications

Sur la page RELCFG.HTM les valeurs des VAR x de Modbus ne sont pas affichées dans les champs VAR x ?

Cela permettra de savoir ce que l’on fait…

Exemple : La requête $M012 fonction très bien, mais sans savoir la valeur qui sera envoyée !

Bonjour Nicolas,

J’ai testé la V0.91 beta3.

La gestion des valeurs négatives fonctionne parfaitement pour le RTU et le TCP. J’ai importé une série de valeurs de puissance et intensité en TCP sur le WES n°2 (via le Shelly) et en RTU (via le Schneider) sur le WES n°1. Ces valeurs sont cohérentes et les signes suivent bien phase par phase. Il faudra sans doute que j’ajuste les coefficients multiplicateurs pour tenir compte des petits écarts de mesure constatés, mais cela demeure marginal.

En revanche, les variables Modbus n’apparaissent toujours pas dans le menu déroulant des actions en TCP, ce qui ne permet pas d’utiliser ce dernier pour programmer des actions.

Le fonctionnement de la programmation en RTU est satisfaisant.

Bravo pour ces évolutions, on est à deux doigts d’un fonctionnement optimum.

En fouinant, j’ai trouvé le moyen de contourner le problème. Il suffit d’activer le mode RTU (même en n’allant chercher aucune variable en RTU) en plus du mode TCP, pour faire apparaître les variables Modbus dans la liste déroulante. A corriger dans une prochaine version, sans que cela n’ait aucun caractère d’urgence puisque la programmation TCP est devenue possible en l’état.

Même avec le fichier wes-f4.bin rechargé, si je ne sélectionne pas le mode RTU en plus du mode TCP, cela ne fonctionne pas. J’obtiens en outre le message « Une/des ligne(s) a(ont) été enlevée(s) car la source à été désactivée (TIC, pulse, températre…) » en rouge, et mes lignes de programme utilisant les variables Modbus TCP disparaissent.

Désolé, je n’avais pas compris que vous aviez mis en ligne une version beta03 modifiée avec un nouveau wes-f4.bin. Je l’ai testé, et cette fois il est possible d’accéder aux variables Modbus en TCP pur, sans avoir besoin de sélectionner le mode RTU. Nickel !

Encore merci pour ce progrès décisif qui va permettre aux utilisateurs de triphasé de disposer d’un outil de gestion de la puissance active permettant d’exploiter pleinement les possibilités du WES.

Bonjour Nicolas,

Depuis le passage en juin, je n’ai plus de graphe en Modbus : écran rouge ?

je suis en V0.91beta03, page MBGRAPH.HTM,

Merci pour votre aide

Gaby-69

Bonjour Nicolas,

Merci, la nuit portant conseil, j’ai cherché ce qui pouvait bloquer l’affichage !

Dans le répertoire « GRAPH/MB/2026/06/ » il manque les fichiers :WNOM0.dat, WNOM1.dat, WNOM2.dat et WNOM3.dat

Aprés rajout de ces fichiers tout est rentrée dans l’ordre, l’affichage est correcte.

Question :

Pourquoi en debut du mois ces fichiers n’ont pas été créés ?

Je reste à votre écoute pour essai et test…

Cdt

Gaby-69

Bonjour Nicolas,

Avez-vous pu regarder pourquoi les fichiers WNOM0.dat, WNOM1.dat et WNOM2.dat non pas été créés dans le répertoire GRAPH/MB/2026/06/  lors du chagement de mois ?

Merci

Gaby-69

Bonjour Nicolas,

Dans liste des petits correctifs non urgents à apporter aux prochaines versions : les fichiers modbus .csv sont générés en mode RTU mais pas en mode TCP.

Bonjour,

je test le MQTT

Ca n’as été facile a configurer j’ai du me reprendre plusieurs fois pour avoir les informations remontées coté HA avec le discovery et en activant un par un les sujets….

Bon cette fois j’ai bien tout et avec les datas.

par contre je ne suis pas satisfait de la remontée dans le sens Wes vers HA le temps de latence est enorme

Dans le sens HA vers WES c’est ok et rapide je commande bien et sans latence

Bon pour le moment j’ai toujours mon integration « RestFull » qui elle dans le sens WES ==> HA est rapide j’ai mis une minute et c’est Ok

A voir et finaliser pour pouvoir désactiver RestFull

A+

Pascal

Bonjour Nicolas,

Je précise.

En premier il a été necessaire de faire la configuration MQTT plusieurs fois et pour que cela passe correctement j’ai envoyé le discovery non pas global mais entité par entité …

avec la necessité de tout effacer coté HA pour repartir de quelques chose de propre , remarque les parametres coté WES sont strictement les memes depuis le debut et le classique standard par defaut!

Au debut avec MQTT explorer aucune trame de message en dehors de celale de la description! Puis maintenant c’est Ok environs toutes les 10s une trame avec des paquets de datas…

Pour ce qui est de la latence :

sens HA vers Wes , j’active un SW virtuel par exemple , c’est disons quasi instantané (j’ai deux fenetre ouverte une sur le WES l’autre sur le HA ) quand je clique sur l’inter HA il est de suite mis a jour coté WES.

Dans l’autre sens du wes vers le HA la première fois que ca a connecté la latence était horrible , tu change l’état coté wes et plus de 2 minutes après enfin HA est mis a jour (sous explorer MQTT le paquet arrive après ce temps) tandis que sous mon API rest Full il était a jour dans la minute (60s c’est le time update que j’ai mis, pour ne pas surcharger de requete). J’ai tout virere desisntaller les instances MQTT du Wes et recommencer une nouvelle fois et la maintenant disons que c’est correct dans les 15/20s…

Je vais donc laisser quelques jours en doublon et test pour voir si stable . Si ok alors je deconnecterais mon API pour passer sous MQTT . c’est pas mal de boulot car toutes les instances devront etre reprises… Bon après tu coupe l’API et tu cherche celle qui sont inconnues…

une remarque demande je l’avais déja faite me semble t’il: Serait il possible d’augmenter les switchs virtuels par exemple doubler le nombre? je m’explique si on veux faire une programmation avancée évoluée on en utilise forcement pas mal en intermediaire (resultat d’une condition reprise en entrées d’autres conditions) mais aussi si on veux faire communiquer intelligement deux systemes entre eux on devra passer par des « variables intermediaires » et les SW virtuels seront la solution! En effet pour moi le WES en qualite de gestionnaire d’energie c’est lui et uniquement lui qui decide si il commute ou pas une charge ! Donc pas question que HA pilote directement un relais du WES qui lui commande un dispositif . Le HA doit faire une demande au WES par un SWV et c’est le WES qui en lisant dans une regles ce SWV décide en fonction de ces regles de sécurité et de gestion si oui ou non il execute la demande . dans l’autre sens c’est moins critique le HA lit simplement le WES . Donc les 24 sont rapidement FULL. Exemple dans mon cas et pas encore toutes les regles de pilotage coté WES j’ai déja 18 variables intermediaires pour les regles …

Coté MODBUS je vais acheter des modules DIO de Waveshare et je vais tester prochainement des extension surtout pour le cote inputs qui est le point faible actuellement du WES cote output le module extension est parfait et plusieurs possibles donc on a de la marge. Comme dit deja si on veux faire de la gestion avancé il est necessaire d’avoir des retours d’informations des equipements vers le WES et cela ne peut se faire que soit materiellement, soit par connexion virtuelle avec MQTT et Modbus ce coté c’est grandement amélioré pour les équipements complexes. Toutefois pour les equipements simples non connecté du marché electrique l’usage du cablé est encore necessaire.

A+

Pascal

Pour la partie relais, j’utilise les relais de 1 à 5 via l’automatisation HA et pas de problème rencontré.

0 Cartelectronic ,

Sinon félicitation car le produit est vraiment très très fiable cela fait maintenant quelques années que j’ai le mien et aucun soucis , un hard donc bien concu et avec des composants de qualité …

pour moi Zero plantage , soucis reset ou autres en plus de 5 ans On 24/24 – 7/7 – 365j/an…Y compris coté Soft avec les updates qui si tu respect la procédure ce passe a merveille

Coté Soft MAJ  et extension juste un poil difficle a savoir les dates et quand les sorties. Je me permet une remarque en toute « amitié » , pourquoi ne pas prévoir un calendrier avec a date une sortie de ce qu’il y a un peu comme HA , on sait que tous les mois une new version. bon pour vous deux fois par an serait suffisant puis éviter les annonces qui ne viennent jamais si pas sur ou pas au point ne rien annoncé ou juste « commercialement on travail dessus » après avec une toute petite structure c’est pas facile et encore félicitation

A+

Pascal