Avant de solliciter la communauté, j’ai essayé d’avancer au maximum par moi-même et suis arrivé à de bons résultats alors que ne connaissais modbus que de nom.
Config : Logo! 8.3
Jeedom sur RPI4, 4.2.18.
Mod en beta 2022-07-24 01:01:47
Côté Jeedom : équipement créé en mode « tcpip », port 502, unit ID 1, polling 2s
le Logo! est serveur, Jeedom est client.
Je parviens à :
Lire l’état de sorties Q et NQ (donc la partie réseau est OK).
(J’ai compris l’adressage des coils / bobines)
Je parviens à écrire une fois sur une NI, mais les tentatives suivantes, malgré le retour réussi côté Jeedom, ne changent plus côté Logo!.
J’ai ajouté une connexion avec un Modbus doctor ensuite pour déterminer si cela venait de Jeedom ou de l’automate. Tout va bien avec Modbus Doctor, j’active et désactive la NI à volonté ==> C’est donc Jeedom qui sait faire une fois mais pas 2. Si je veux une nouvelle réussite, je crois qu’il faut que je repousse le programme !
root@XXXXX02:/var/www/html/plugins/mymodbus/ressources# /usr/bin/python3 /var/www/html/plugins/mymodbus/ressources/mymodbus_write.py --host=999.999.999.163 --protocol=tcpip --port=502 --baudrate=0 --unid=1 --wsc=2412 --value=0
Version de python ok
Traceback (most recent call last):
File "/var/www/html/plugins/mymodbus/ressources/mymodbus_write.py", line 82, in <module>
assert(not rq.isError()) # test that we are not an error
AssertionError
root@XXXXX02:/var/www/html/plugins/mymodbus/ressources#
merci pour ta réponse, j’ai trouvé cette nuit, mais je me suis endormi devant les écrans…
Oui, c’est ce que je faisais, dans mes premiers tests j’utilisais la même commande en changeant le paramètre.
ça venait du fait que j’avais paramétré le fait de garder la session ouverte. Et le pauvre automate, visiblement, ne gère qu’une session modbus par client à la fois, ce qui est déjà bien pour un petit hardware sans OS (et ce qui est peut-être normal dans le protocole Modbus, ça, j’en sais rien)
Pourquoi n’y ai-je pas pensé avant…
Ce qui m’a permis d’arriver à cette conclusion, c’est :
contrairement à ce que j’ai dit, ça ne marchait plus du tout, malgré avoir vérifié maintes fois les adressages.
j’avais le même comportement en ligne de commande.
en regardant le code du script « write », je vois qu’il fait 3 retries. Quelques netstat plus loin… Je passe ce nombre à 10 pour voir si ça met plus de temps à échouer ==> OUI. Il faisait donc des retries de connexion. Et là, ça a fait tilt.
j’ai arrêté le démon et là, paf, en CLI comme depuis Jeedom, ça s’est mis à fonctionner correctement.
tout de suite, contretest, je rallume le démon, et paf, ça marche plus.
J’ai viré le maintien de session ouverte, re testé, content, déjà crevé par le boulot ==> dodo.
Il eu fallu, pour pouvoir garder la session ouverte, que le write soit fait par le même processus que le démon, sur le même socket TCP, même session Modbus.
Au passage, un grand merci à l’auteur de ce plugin qui ouvre encore plus le champ des possibles !
Je suis tombé par hazard sur ton poste, merci pour ton message de remerciement. Faut surtout dire merci à tout les utilisateurs qui viennent ici partager des solutions et qui proposent leurs l’aide.
