Bonjour,
J’ai un défaut de lecture de l’état de certain de mes relais.
J’ai une carte I/O de 8 relais. L’état des trois premiers est bien lus mais pas les suivants !
Voici ma config :
Les commandes ON :
Les commandes OFF :
L’états des relais :
Les trois premiers sont bien lus mais pas les suivants ! Bizarre !
D’où cela pourrait venir ?
Merci pour vos suggestions.
Bonjour,
l’étiquette utilisée est la mauvaise, il faudrait utiliser plugin-mymodbus, j’aurais répondu plus rapidement… Là, c’est parce que j’ai recherché sur le community s’il y avait des messages que j’ai loupés que je suis tombé sur votre message, parce que je l’ai loupé et pour cause…
Pouvez-vous mettre un lien vers la documentation constructeur afin que j’étudie la chose SVP ?
edit: j’ai bien retrouvé ce post, mais le lien est mort:
A+
Michel
Bonjour et merci,
Effectivement je n’avais pas vu la mauvaise étiquette !
Depuis que j’ai posté, et afin que ça fonctionne, j’ai changé de « plage de registre » en normal.
Je voulais mettre un mode spy sur la ligne afin de voir les trames passer mais je n’ai pas eu le temps. Alors si vous trouver la solution ça serait cool.
Donc voir la doc ci-jointe. Quand je dis doc, c’est beaucoup dire ! Car c’est une carte Chinoise. Et encore je l’ai bien améliorée !
Ceci dit quand ça marche, ça marche bien ! Voilà plusieurs années que ça roule.
Manual ZUCZUG carte 8 IO.pdf (715,5 Ko)
Pour la carte 7 entrées ana, voici un autre lien : Modbus RTU R4AVA07 Tech, Analogique Mulhouse Ition, 0-5V, 0-10V, 7ch Voltage, RS485, 1Pc - AliExpress
Il suffit de taper R4AVA07 sur Aliexpress.
Ok, c’est « particulier », mais compréhensible.
Si vous avez des log debug d’un cycle d’interrogation (toutes les commandes info) j’aimerais bien voir ça.
My bad : il faudrait les log mymodbus_daemon en mode debug…
D’accord mais c’est où ?
Tout ce que j’ai trouvé c’est dans configuration. Qui est bien en mode debug. Et qui est la même chose dans logs.
Du coup j’ai relancé les dépendances et le daemon.
Voilà ce que j’ai :
mymodbus_update1047.log (1,5 Ko)
mymodbus1047.log (35,7 Ko)
mymodbus_daemon1046.log (63,2 Ko)
C’est inutile, une fois installées, elles sont installées. Je sais que certains plugins en ont besoin mais pas MyModbus sauf montée de version de pymodbus, mais là c’est géré durant la mise à jour du plugin.
Ca permet de prendre le changement de niveau de log.
Tout ce qui me manquait c’était le fichier mymodbus_daemon, donc c’est exactement ça.
Extrait de la doc:
[2025-05-12 10:45:05][DEBUG] : send: 0x3 0x1 0x0 0x0 0x0 0x8 0x3c 0x2e
[2025-05-12 10:45:05][DEBUG] : recv: 0x3 0x1 0x1 0x0 0x50 0x30 old_data: addr=None
Dans votre cas c’est l’adresse 3 mais la requête envoyée est la même (mais correctement formée, la doc est fausse cf. cette page entre autre) :
Dans la doc il y a 2 octets en trop (les bleus) un seul bit est demandé. Donc on ne peut pas avoir l’état des 8 relais… C’est la norme Modbus, c’est comme ça. La doc est fausse.
On voit d’ailleurs que la trame de la fonction 2 (chapitre suivant de la doc) est correctement documentée. Des erreurs, ça arrive, malheureusement.
Pour savoir comment réagit l’appareil, il serait interessant de faire une commande avec lecture d’un bit avec la fonction 1 à l’adresse 0 et d’analyser le retour, pour voir si l’appareil est non standard (auquel ca, il faudrait interroger le relais avec un script dédié à une implémentation fausse du Modbus).
En réponse, on a :
→ Les trames Modbus du plugin sont correctes.
Ce serait interressant de lire plus de bits avec cette commande et d’analyser le retour.
Pour cet essai, il faudrait que des relais soient enclenchés histoire de pouvoir identifier qu’est ce qui correspond à quoi. 64 bits par exemple et diminuer de 8 en 8 si ça fait une erreur.
Bonjour et merci encore pour cette analyse.
Je m’était demandé plusieurs fois comment on faisait pour voir les trames Modbus. Maintenant j’ai la réponse 
J’ai presque compris le principe d’analyse pour pouvoir aller plus loin. Mais jusque là mes essais ne sont pas encore bien probant !
Je reviens dès que ça me parait plus concret …
En faite, pour aller plus loin j’aimerai comprendre ce que je reçois quand je met à 1 chaque relais un par un mais un seul à la fois.
car pour :
relais 1 j’obtiens : 0x1
relais 2 j’obtiens : 0x2
relais 3 j’obtiens : 0x4
relais 4 j’obtiens : 0x8
relais 5 j’obtiens : 0xf0
relais 6 j’obtiens : 0xa0
relais 7 j’obtiens : 0xc0
relais 8 j’obtiens : 0x80
Du relais 1 à 4 je comprends mais de 5 à 8 pas bien ! Même si j’entrevois une logique.
C’est peu être une histoire de LSB/MSB ?
En utilisant la calculatrice Windows (ou une autre) en mode programmeur, pour comprendre il faut saisir 1 en binaire, contrôler la valeur hexadécimale et rajouter des 0 à la valeur binaire.
Un bit correspond à un relais.
Par contre les valeurs A, C et F ne sont pas logiques :
Jusqu’ à 0x8, le 1 est décallé du bit de poids faible vers le bi de poids fort, du relais 1 vers le relais 4, un bit correspond à un relais. Après ça se gâte…Le relais 8 est de nouveau OK.
Vous êtes certain que les relais 8 n’était pas enclanché pour tester les relais 6 et 7 ? Idem lors du test du relais 5, les relais 6, 7 et 8 n’étaient pas enclanchés ?
Plus loin dans le log, il y a une ligne qui montre comment les bits sont interprétés :
[2025-05-12 10:45:05][DEBUG] : decoded PDU function_code(1 sub -1) -> ReadCoilsResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[False, False, False, False, False, False, False, False], registers=[], status=1)
Cette ligne est utile pour être sûr que ce soit bien interprété. Ici il n’y a que des False, ce ne sont donc que des 0, par contre l’ordre est inversé (normalement, mais j’ai vu passé un changelog qui parlait de corriger ce point erroné) 0001 0000 correspond à bits=[False, False, False, False, True, False, False, False],. C’est une histoire d’interprétation, mais c’est juste.
Bonjour,
Voici le résultat de mes nouvelles investigations :
Oui. J’ai refait des tests et vérifié avec les false et true.
La séquence pour un seul relais monté est bien : 0x1 0x2 0x4 0x8 0xf0 0xa0 0xc0 0x80
Ensuite j’ai fait un équipement qui n’a que les 8 relais.
Et là ça fonctionne : 0x1 0x2 0x4 0x8 0x10 0x20 0x40 0x80
Par contre les widgets d’état des relais ne changent toujours pas. Sauf pour les relais 1, 2 et 3.
Dans l’équipement où il y a tout j’ai :
1 carte 8 relais
1 carte 7 ana
2 compteurs d’énergie.
En faisant un équipement avec carte 8 relais + 7 ana ça fonctionne ainsi qu’un équipement avec carte 8 relais + 2 compteurs d’énergie.
Mais pas avec l’ensemble !
On dirait qu’on a un cas d’école 
… pour lequel j’ai besoin de détails pour chaque cas :
Le mieux étant d’avoir le cas où seul le relais 5, 6, 7 et 8 est enclenché.
Les log vont être longs…
Il faut vous rendre compte que je ne sais que ce que vous indiquez ici et qu’il y a une place énorme à l’interprétation. Et peut-être n’interprétez-vous pas la trame Modbus correctement.
Alors oui, ça va vous prendre du temps, mais ça va m’en prendre encore plus si mes interprétations successives sont fausses.
Avez-vous essayé avec une plage de lecture de plusieurs octets ? Elle peut être plus longue que ce que vous avez besoin. Les « bons » bits sont peut-être plus loin ?
Je suis en pleine saison de répétition de théâtre et du temps, j’en ai très peu. J’essaie d’optimiser, comprenez-moi.
Pas de problème. Aucune urgence. Même si ça n’est pas optimisé, actuellement ça fonctionne. Et moi qui ai connu l’ancien plugin, le votre est vraiment, et de loin, le plus abouti.
Export templates :
MODSBUSRTU_PDR_8IO_ANA_CE.txt (101,2 Ko)
MODBUSRTU_PDR_8IO.txt (72,1 Ko)
MODBUSRTU_PDR_8IO_ANA.txt (85,6 Ko)
MODBUSRTU_PDR_8IO_CE.txt (93,9 Ko)
Je suis en mode « Sur évènement ».
Pour chaque log, j’ai :
redémarré le daemon,
enclenché le relais 5, rafraichi, puis arrêté,
enclenché le relais 6, rafraichi, puis arrêté,
enclenché le relais 7, rafraichi, puis arrêté,
enclenché le relais 8, rafraichi, puis arrêté.
mymodbus_daemon_MODBUSRTU PDR 8IO.log (43,7 Ko)
mymodbus_daemon_MODBUSRTU PDR 8IO ANA.log (55,3 Ko)
mymodbus_daemon_MODBUSRTU PDR 8IO CE.log (59,7 Ko)
mymodbus_daemon_MODBUSRTU PDR 8IO ANA CE.log (97,8 Ko)
Pour les compteurs d’énergie, j’ai fait une plage de registre de 44 registres car les infos sont majoritairement concentrés. Puis j’ai une commande à part pour un registre qui est trop loin car situé à 256.
Ce qui est étonnant, dans cette affaire, c’est que même avec l’équipement 8IO seul, les lectures de l’état des relais sont correctes, mais que les widgets ne changent pas !
Bon courage et encore merci.
P.S. : un pis-aller serait de faire deux équipements distincts, un avec seulement les 8IO et un autre avec le reste. Mais je crois comprendre que l’on ne peut faire fonctionner qu’un seul à la fois. C’est bien ça ?
Il est possible de faire 2 équipements dont un qui utilise l’interface de l’autre. Il est possible de multiplier les équipements (3, 4 et plus si affinité).
Certains appareils supportent les connexions multiples, mais uniquement en TCP ou UDP, pour ceux-là ce n’est pas la peine de partager la connexion, un nouvel équipement avec la même configuration de communication fonctionnera.
Le démon ne voit qu’un seul équipement (une seule connexion) pour les équipements avec une interface partagée.
Ce sont les widgets Jeedom de base (croix ou check) ?
Je voulais dire 0 [64] pour la plage de lecture des relais, histoire de voir ce qu’il y a après.
