Paramétrage Mymodbus Chaudière De Dietrich Diematic

reyur · Janvier 29, 2025, 10:07

Bonjour,

Comme expliqué ici Evolutions du plugin MyModbus version stable - #21 par reyur, j’utilise jusque maintenant l’ancienne version stable du plugin et ça fonctionne parfaitement. Je souhaiterai si possible migrer vers la dernière version pour éviter d’être bloqué un jour avec les mises à jour du core jeedom qui ne seront plus compatibles.

J’ai fait quelques tests non concluants sur la dernière version, je récupère des données totalement erronées, et je crée donc ce post pour essayer de comprendre ce qui coince.

Modèle de la chaudière : De Dietrich AGC 35 MODULENS - Régulation : Diematic iSystem
Type de passerelle : USR-W610
Paramétrage côté USR-W610 :

Config ancienne version mymodbus :

Exemple conf lecture et écriture :

Plusieurs questions pour commencer :
Est-ce que le protocole de connexion doit bien être « tcuovertcp » ?
Je ne comprends pas à quoi correspond l’adresse esclave (unit ID), il faut laisser 1 ?

Avec les paramètres que je teste actuellement

j’obtiens des données erronées et qui repassent régulièrement à 0.

reyur · Janvier 29, 2025, 11:05

Pour le num d’esclave, je viens de comprendre, j’ai indiqué 10.

Exemple sur ce champ 652 :

→ 2 commandes identiques, 2 valeurs différentes!

Et côté logs :

0033|[2025-01-30 00:00:54] ERROR  : Fatal error: protocol.data_received() call failed.
0034|protocol: <pymodbus.client.modbusclientprotocol.ModbusClientProtocol object at 0x7fd3399a3f10>
0035|transport: <_SelectorSocketTransport fd=8 read=polling write=<idle, bufsize=0>>
0036|Traceback (most recent call last):
0037|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/pdu/mei_message.py", line 127, in calculateRtuFrameSize
0038|_, object_length = struct.unpack(">BB", buffer[size : size + 2])
0039|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0040|struct.error: unpack requires a buffer of 2 bytes
0041|The above exception was the direct cause of the following exception:
0042|Traceback (most recent call last):
0043|File "/opt/pyenv/versions/3.11.11/lib/python3.11/asyncio/selector_events.py", line 1013, in _read_ready__data_received
0044|self._protocol.data_received(data)
0045|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 297, in data_received
0046|self.datagram_received(data, None)
0047|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 331, in datagram_received
0048|cut = self.callback_data(self.recv_buffer, addr=addr)
0049|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0050|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/client/modbusclientprotocol.py", line 71, in callback_data
0051|used_len, pdu = self.framer.processIncomingFrame(data)
0052|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0053|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 77, in processIncomingFrame
0054|data_len, pdu = self._processIncomingFrame(data[used_len:])
0055|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0056|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 95, in _processIncomingFrame
0057|used_len, dev_id, tid, frame_data = self.decode(data)
0058|^^^^^^^^^^^^^^^^^
0059|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/rtu.py", line 112, in decode
0060|if not (size := pdu_class.calculateRtuFrameSize(data[used_len:])):
0061|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0062|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/pdu/mei_message.py", line 132, in calculateRtuFrameSize
0063|raise IndexError from exc
0064|IndexError
0065|[2025-01-30 00:01:19] ERROR  : No response received after 3.0 retries, continue with next request
0066|[2025-01-30 00:01:19] ERROR  : Chaudiere/652_T_Hors_Gel1: error during read request on slave id 10, address 652 -> Exception Response(131, 3, None)
0067|[2025-01-30 00:02:41] ERROR  : Chaudiere: 'process_read_response' 'cmd_decode' for command id = 10 raised an exception: 'WriteMultipleRegistersResponse' object has no attribute 'values'

Edit :
A force de faire des tests, je crois que je commence à comprendre le problème.
Si je lance plusieurs lectures de suite via Modbus Doctor, j’ai effectivement plusieurs valeurs possibles. Par exemple, je vais avoir :

80% du temps la bonne valeur qui est 50.
15% du temps des valeurs erronées (0, 110…) mais avec un Request OK.
5% du temps, une erreur Illegal Data Value.

Je ne sais pas comment l’ancienne version du plugin arrivait à gérer ça, mais elle prenait en compte uniquement la bonne valeur.

Je ne sais pas si tu as un avis @Michel_F stp ?

Michel_F · Janvier 30, 2025, 8:40

Bonjour,

Je n’ai même pas l’ombre d’une piste…

Ce que je sais :

l’ancienne version de MyModbus écrite par Bebel n’était pas vraiment un démon, c’était construit de sorte que jeedom lance une commande python pour chaque requête. Chaque commande était indépendante. C’est comme ça dans mon souvenir mais je n’ai plus de trace de cette version.
l’ancienne version était basée sur une ancienne version de pymodbus (V2.5.? quelque chose alors qu’on est en 3.8.4 aujourd’hui)

Dans les erreurs que tu envoies, je vois :

IndexError: erreur sur un index lors du calcul de la taille du PDU
un timeout
une exception
une autre exception parce que la réponse Modbus n’a pas de propriété values. Mais sur une requêtes d’écriture, je ne comprends pas le problème…

Bref, je n’ai pas de piste.

reyur · Février 9, 2025, 6:09

J’ai refait quelques tests, et j’ai remarqué plusieurs choses :
pour les valeurs étranges que je reçois, ça semble lié au daemon mymodbus de mon vrai jeedom. Je l’ai coupé pour la suite des tests.

Suite à ça, les valeurs ne s’actualisent plus toutes seules, mais j’obtiens une nouvelle chose bizarre.

Si j’ouvre Modbus Doctor et que lis un registre, ça va forcer l’actualisation d’une des commandes dans jeedom. Si je lis une seconde fois, ça met à jour la commande suivante…

La conf actuelle utilisée

Michel_F · Février 9, 2025, 6:50

Es-tu certain que plus aucun process MyModbus ne tourne ? Pour actualiser les valeurs dans Jeedom il faut un process qui envoie les Infos au core du plugin.
ps ax | grep -v grep | grep mymodbus pour s’en assurer.

reyur · Février 12, 2025, 10:33

Plus aucun process mymodbus ne tourne sur le jeedom de prod, je confirme.
Et oui, on a bien un résultat à cette commande sur le jeedom de test :

Je ne comprends vraiment rien.

En espérant qu’un autre utilisateur de myModBus ayant une chaudière similaire passe par ici…!

Merci pour ton support en tout cas Michel_F.

echo · Février 12, 2025, 11:23

Bonjour

Je ne connais pas le plugin, n’y la chaudière.

Avez vous essayez d’augmenter le temps entre 2 lectures, 0,01 s me semble peu. Le rôle de la chaudière c’est de gérer le chauffage, en plus vous passez par une passerelle, la liaison Modbus n’est pas prioritaire dans le process. Si les valeurs varient, il se peut que la passerelle vous envoie un code erreur.
Avez vous la documentation de la passerelle et les chronogrammes?

Cordialement

Michel_F · Février 12, 2025, 11:27

Ce phénomène n’est pas du tout logique.

Si je reprends :

le démon est stoppé sur ton Jeedom de prod,
tu as un Jeedom de test avec le démon lancé
quand tu lances des requêtes Modbus, ça actualise les valeurs sur le Jeedom de prod où le démon est à l’arrêt

C’est bien ça ?
Si c’est bien ça, alors il faut vérifier que ça ne vient pas d’un script ou d’un scénario. Si le démon ne tourne pas, il n’est pas possible d’actualiser les valeurs des commandes info.
Que contient le log event ?

Ca veut dire que je ne dois plus intervenir ?

Il s’agit de Modbus TCP, ce temps est correct.

Dans quel process ?

Si la passerelle retourne un code d’erreur, c’est intercepté par le démon et mis dans les log.

Tonio16 · Février 13, 2025, 12:07

Salut

Sur ma vmc modbus-rtu sur port 232, je dois définir un interval de 0.1s au moins, entre chaque demande. C’est le temps nécessaire pour recevoir, analyser la demande modbus 0.040ms selon la doc, et envoyer la reponse, 0.1 s pour repasser en mode reception.
On voit bien sur la doc fabriquant jointe que pour mon appareil, un temps de 0.01s entre chaque lecture ne peut pas fonctionner.

Antoine

Michel_F · Février 13, 2025, 12:23

Dans le cas de reyur, c’est une connexion TCP.
Rappel de documentation :

“Temps entre 2 requêtes de lecture” est le temps d’attente entre la réception d’une réponse et l’envoie d’une nouvelle requête. Ce temps peut être mis à 0 dans la plupart des cas, il est surtout utile pour des connexions lentes, typiquement des connexions série. Il faut savoir qu’un temps d’attente de 0.03 s est mis en place par le module pymodbus pour les connexions série. Ce temps se rajoute au temps d’attente du plugin.

La documentation que tu postes est bien faite et parle de 3 caractères de temps d’attente ce qui est bizarre à comprendre mais c’est la particularité du RTU. pymodbus attend 3.5 caractères par défaut en RTU. Donc, en théorie, sans rien préciser, ça devrait fonctionner chez toi avec un temps réduit puisque ce temps est rajouté à ce que fait pymodbus.

Mais c’est hors sujet ici.

edit: j’ai précisé Modbus TCP pour être plus précis

echo · Février 13, 2025, 12:22

Bonjour

J’ai fait quelques recherches et je suis tombé sur cela:

Je ne veux froisser personne, je veux simplement aider. J’ai regarder la documentation de la passerelle qui n’est pas de marque De Dietrich. Si j’ai bien compris la liaison entre la passerelle et la chaudière est une liaison série RS485 ou RS232. On est donc dans la même configuration que si la box Jeedom était connectée directement sur la chaudière en liaison série, les contraintes de timing s’appliquent dans ce cas. Si on envoie les requêtes ip trop rapidement la chaudière risque de ne pas pouvoir suivre. Je me trompe peut être, mais j’aimerais comprendre.

Tonio16 · Février 13, 2025, 12:34

Pourquoi ne pas partir sur une solution de ce type ?

Des infos sur la communciation:

Cette partie est surprenante:

One specifity of the De Dietrich implementation is the dual-master : The boiler transmit ModBus command during 5s as a ModBus master and then remain silent during 5 next seconds waiting for possible ModBus commandas slave (address: 0x0A).

This particularty will have some impact on the behviour of our system : reponse time will be between 5 and 10 s (5s waiting for boiler slave mode followed by the data transmission).

Avec le mqttdiscovery l’intégration à jeedom est facile avec le plugin-mqttdiscovery et pwut etre mqtt.manager (je connais pas).

Antoine

reyur · Février 13, 2025, 4:22

Non pas du tout, ça veut juste dire que j’ai peur d’embêter avec mon sujet bizarre

Non, pas tout à fait.

le démon est stoppé sur ton Jeedom de prod, → Oui
tu as un Jeedom de test avec le démon lancé → Oui
quand tu lances des requêtes Modbus, ça actualise les valeurs sur le Jeedom de TEST.
Mais ça actualise n’importe quel champ avec la valeur qui vient d’être lue!

Pour la documentation de la passerelle que j’utilise, tout est trouvable ici : RS485 to WiFi Converters | RS232 to WiFi Converters | Serial WiFi Converters

Michel_F · Février 13, 2025, 7:51

Ouf, parce que j’en avais pas envie. Par contre a partir de samedi je suis en vacances durant 1 semaine avec un accès internet très limité.

C’est déjà plus (+) probable, il suffit que la passerelle ignore l’id de transaction dans la trame et c’est le mélange assuré.

Michel_F · Février 13, 2025, 8:05

Je pense que ce problème est le même.

Il ne faudrait qu’un seul appareil qui envoie des requêtes. Disons que tu ne fais plus d’essais de requête simultanées, seulement Jeedom avec une pause entre lecture de 0,1 seconde au moins.
Ça va être lent, mais tu peux optimiser avec des plages de registres.

Concernant le mode, si j’ai bien compris, côté bus série, tu ne dois rien changer parce que ça fonctionne.
Côté Ethernet, tu peux choisir une des solutions suivantes. Je te conseille de tester pour voir si je ne raconte pas de bêtises et me le faire savoir :

MyModbus en tcp avec la passerelle configurée en « Modbus TCP <=> Modbus RTU »
MyModbus en rtuovertcp avec la passerelle en mode « transparent »

Je pense que les 2 fonctionnent, il faudrait tester quelle configuration donne les meilleurs résultats en terme de stabilité et de justesse. N’hésite pas à tester longtemps et à noter le temps entre lecture configuré et les résultats ainsi que tes impressions.

sim140680 · Février 14, 2025, 9:42

Hello,

Pour avoir gratté par mal sur le sujet, seul le mode transparent est stable dans notre cas avec cette paserelle (mais cela casse le fonctionnement ‹ standard › que l’ont peut obtenir avec ModBusDoctor avec la passerelle configurée en Modbus TCP<=> Modbus RTU)

Michel_F · Février 14, 2025, 11:08

C’est parce que Modbus doctor ne sait pas faire de rtuovertcp. Mais comme ce n’est pas avec Modbus doctor que tu veux communiquer mais avec MyModbus, fais les essais de sorte d’optenir le meilleur fonctionnement possible avec MyModbus.

Parenthèse

Le paramètre Baudrate adaptative (RFC2117) a déjà posé problèmeà un utilisateur un jour (je ne sais plus qui et ne sais plus quand) mais en communication standard, pas en RTU.

sim140680 · Février 14, 2025, 5:40

Hi Hi!

C’est moi!

reyur · Février 14, 2025, 8:03

Bonsoir @sim140680 et @Michel_F,

J’ai modifié la conf côté passerelle pour passer en « Transparent Mode », le reste des confs était déjà OK.
ça a l’air beaucoup mieux déjà !

J’ai (pour la première fois) des valeurs correctes (elles paraissent bizarres, mais parce qu’il faut les diviser par 10) :

Par contre, ça a récupéré les valeurs à 20h49

Et depuis, j’ai l’impression que ça ne bouge plus, et j’ai de nombreuses erreurs dans les logs

0091|[2025-02-14 20:56:37] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0092|[2025-02-14 20:56:42] ERROR  : No response received after 3.0 retries, continue with next request
0093|[2025-02-14 20:56:42] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0094|[2025-02-14 20:56:50] ERROR  : No response received after 3.0 retries, continue with next request
0095|[2025-02-14 20:56:50] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0096|[2025-02-14 20:56:55] ERROR  : No response received after 3.0 retries, continue with next request
0097|[2025-02-14 20:56:55] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0098|[2025-02-14 20:57:03] ERROR  : No response received after 3.0 retries, continue with next request
0099|[2025-02-14 20:57:03] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0100|[2025-02-14 20:57:08] ERROR  : No response received after 3.0 retries, continue with next request
0101|[2025-02-14 20:57:08] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0102|[2025-02-14 20:57:17] ERROR  : No response received after 3.0 retries, continue with next request
0103|[2025-02-14 20:57:17] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0104|[2025-02-14 20:57:22] ERROR  : No response received after 3.0 retries, continue with next request
0105|[2025-02-14 20:57:22] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0106|[2025-02-14 20:57:30] ERROR  : No response received after 3.0 retries, continue with next request
0107|[2025-02-14 20:57:30] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0108|[2025-02-14 20:57:35] ERROR  : No response received after 3.0 retries, continue with next request
0109|[2025-02-14 20:57:35] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0110|[2025-02-14 20:57:44] ERROR  : No response received after 3.0 retries, continue with next request
0111|[2025-02-14 20:57:44] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0112|[2025-02-14 20:57:49] ERROR  : No response received after 3.0 retries, continue with next request
0113|[2025-02-14 20:57:49] ERROR  : Chaudiere/608_Ionization_current: error during read request on slave id 100, address 608 -> Exception Response(131, 3, None)
0114|[2025-02-14 20:57:57] ERROR  : No response received after 3.0 retries, continue with next request
0115|[2025-02-14 20:57:57] ERROR  : Chaudiere/602_Temp_chaudiere: error during read request on slave id 100, address 602 -> Exception Response(131, 3, None)
0116|[2025-02-14 20:58:02] ERROR  : No response received after 3.0 retries, continue with next request

Il ne doit plus manquer grand chose!

@sim140680
C’est étrange sur tes captures :

On voit Mode de rafraichissement = Cyclique, et en dessous une valeur de pooling.
J’ai mis Polling, je ne sais pas si c’est le bon choix.

reyur · Février 14, 2025, 8:13

J’ai trouvé le problème, à force de faire des tests pour trouver une configuration valide, j’avais laissé une commande avec une mauvaise adresse esclave.
Apparemment, Mymodbus n’aimait pas et ne remontait plus rien.

Plus aucune erreur dans les logs depuis 5 bonnes minutes
Je vais faire un test d’écriture aussi, et si ça marche, je pourrai suivre la doc pour pouvoir mettre à jour mymodbus sur mon vrai jeedom.

Edit : Test d’écriture OK aussi

Merci beaucoup !