Bonjour à tous
Le contexte. Depuis un an j’utilisais le plugin APS pour faire le suivi de mes panneaux solaires. Le constat un crash de la communication de l’ECU aléatoirement à fréquence moyenne 1fois/mois mais toujours entre environ minuit et 2 heures du mat. Un OffOn de l’ECU est alors nécessaire.
Changement de stratégie: Désactivation du plugin et passage sous Nodered en VM sous FreeboxDelta :reception ModBus emission MQTT. Nickel ça baigne.
Mais je trouve que cette solution n’est pas la plus simple dans son circuit de data et de qté d’appareil et de software utilisés. Donc je viens de faire un tour sur le plugin MyModBus pour avoir directement les data des DS3 dans Jeedom.
Installation etc… ça baigne.
Par contre je me retrouve avec une erreur communication toutes les nuits vers 2h du mat.
Probablement le même pb de com qui aléatoirement plantait la comm de l’ECU avec le plugInAPS et donc probablement un bug APS.
Mes questions:
Quelle est la logique dans le plugin de remise à 1 de ce booléen?
Est il possible de le remettre à 1 par commande? une fois que la cause a été identifiée bien sur…
Merci d’avance de vos éclairages
A+
Informations Jeedom
Core : 4.4.19 (master)
DNS Jeedom : non
Plugin : MyModbus
Version : 2025-01-24 11:07:19 (beta)
Statut Démon : Démarré - (2025-01-28 11:22:10)
Les log en texte préformaté (icône </>), c’est plus pratique pour voir la fin des lignes qui contient souvent des info importantes.
Effectivement, bien supposé, mais c’est aussi dans la documentation.
“Timeout” est le temps en secondes durant lequel une réponse à la requête est attendue par le module pymodbus. Si ce temps est dépassé sans réponse, la requêtes est renvoyée. Ceci se produit autant de fois que configuré dans “Nombre de tentatives en cas d’erreur”. Si après ce nombre de fois l’appareil n’envoie toujours pas de réponse à la requêtes, la commande info “Cycle OK” est passée à 0 et la prochaine requête est envoyée.
Effectivement, je ne décris pas dans la doc qu’est-ce qui remet cette info à 1. Je vais rajouter ça quelque part.
→ Merci d’avoir pointé ce fait
Dès qu’un cycle de lecture complet (toutes les lectures définies dans l’équipement et ceux qui utilisent sont interface, le cas échéant) est fait sans erreur, cette info passe à 1.
Inutile, l’info sera remise à 0 par le plugin.
D’après les log partiels, il semblerait que la connexion soit perdue. Votre appareil doit faire quelque chose la nuit et désactive la communication Modbus Ethernet.
Si vous voulez faire quelque chose pour éviter ce type d’erreurs, le seul moyen est d’arrêter la communication durant les plage de maintenance. Un scénario qui désactive l’équipement devrait solutionner le problème.
Ok mais alors quelque chose m’échappe.
L’ECU est interrogé toutes les 10s, sachant que l’ECU lui même rafraichit ses data toutes les 5 mn, depuis 2 heures du mat l’ensemble des data a été réinterrogé une tonne de fois avec succés. Les valeurs que l’on peut comparer au flux Nodered/MQTT dans le tableau APS_MQTT nodeRed montrent d’ailleurs bien que les interrogations sont valides. De plus le log ne montre plus aucune erreur depuis les 2h du mat fatidique.
Ou est l’erreur dans ce raisonnement?
Autre point de reflexion: L’ensemble des commandes adresse la collecte de valeurs numériques fluctuantes sauf une le SerialNumber de l’équipement qui est stable et de type texte.
Dans le log debug ci dessous je vois bien les 6 data numériques Puissance Tension Courant Frequence Temperature Energie mais pas le SN.
Je n’arrive plus à retrouver dans la doc que les data non modifiées avaient un traitement particulier ou bien je confond avec un autre plugin. Néanmoins pourrait il y avoir corrélation entre la non remise à 1 du booleen et l’existence de cette data non variable?
[2025-01-29 17:20:36] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:36] DEBUG : mymodbus::deamon_info * daemon_info = '{"log":"mymodbus","state":"ok","launchable":"ok"}'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: $result *{"values":{"cycle_time":{"value":0.09649345140496735,"eqId":"741"},"7792":7,"7793":233,"7794":0.18274393677711487,"7795":49.970001220703125,"7796":20,"7797":2771.698486328125}}* type: array
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Temps de rafraîchissement' -> new value: '0.096'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Puissance' -> new value: '7'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Tension' -> new value: '233'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Courant' -> new value: '0.18274393677711'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Frequence' -> new value: '49.970001220703'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Temperature' -> new value: '20'
[2025-01-29 17:20:37] DEBUG : jeemymodbus.php: Mise à jour cmd 'Energie' -> new value: '2771.6984863281'
[2025-01-29 17:20:39] DEBUG : jeemymodbus.php: $result *{"values":{"cycle_time":{"value":0.09672044880280736,"eqId":"740"}}}* type: array
[2025-01-29 17:20:39] DEBUG : jeemymodbus.php: Mise à jour cmd 'Temps de rafraîchissement' -> new value: '0.097'
[2025-01-29 17:20:41] DEBUG : mymodbus::deamon_info
[2025-01-29 17:20:41] DEBUG : mymodbus::getDeamonLaunchable
[2025-01-29 17:20:41] DEBUG : mymodbus::getCompleteConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::getEqConfiguration
[2025-01-29 17:20:41] DEBUG : mymodbus::deamon_info * daemon_info = '{"log":"mymodbus","state":"ok","launchable":"ok"}'
[2025-01-29 17:20:46] DEBUG : mymodbus::deamon_info
Pas sûr de comprendre en détail, mais j’imagine que ça veut dire que toutes les lectures lisent des valeurs qui évoluent dans le temps sauf le SN.
C’est le cas si le champ Lecture 1x sur est renseigné avec une valeur supérieure à 1.
C’est une excellente idée, mais ce n’est pas le cas. Le nombre de lecture OK à faire n’est pas comparé aux nombre de lectures totale. Le principe c’est : si sur le cycle il y a une erreur alors Cycle OK passe à 0 sinon il passe à 1.
c’est ça aussi, mais a priori donc aucun rapport avec le sujet…
ok je vais regarder ca puisque je n’ai aucun cycle ok remonté aujourd’hui et le log en mode debug ne remonte pas assez loin dans le temps. Je vais faire qq essais complémentaires avec et sans SN pour essayer de resserrer la nasse.
Je pars donc sur le principe que si toutes les requêtes sur même équipement remontent une info valide le booléen cycle_ok doit repasser a 1. A suivre demain.
Pour info je viens de recréer des équipements sans interrogation SN. Leur cycleOk lors de leur création c’est bien sur collé sur 1.
let’s see
Résultats des courses.
quelque soit la configuration des équipements avec ou sans data statique (SN) le « cycle_ok » ne revient pas à 1 même lorsque l’ensemble des data adressé est ok.
Pour info j’ai vérifié la validité des requêtes Modbus TCP sur l’ensemble des data avec ModbusDoctor et par nodered. Toutes les data sont récupérées sans pb sur plusieurs équipements alors que leur booleen reste sur 0.
Il y a a priori qq chose dans l’algo de remise à 1 qui ne fonctionne pas comme attendu.
Pour ma culture dans quel fichier se trouve cette logique de remise à 1?
A+
En passant l’équipement en ‹ sur événement ›, log en debug, log vidé et en redémarrant le démon et en déclenchant un rafraichissement. Le log résultant m’interesserait pas mal si vous pouviez faire ça.
A noter le mode sur évènement remplit rapidement le log. Ca tronque le log au bout de 10mn. L’evenement indésirable ayant lieu vers 2 h du mat. on aura pas d’info autour de cette heure…je dormirais
Non un équipement correspond a un seul onduleur qui a une adresse esclave spécifique.
Toutes les commandes info d’un equipement sont faites sur cette @esclave unique.
Pour etre sur de la logique attendue sur l’etat de cycle_ok.
Est ce qq chose comme;
Réalisation d’un cycle de commandes (lectures dans mon cas)
Dans ce cycle si au moins une des commandes ne se fait pas correctement alors cycle_ok=0
Sinon cycle_ok=1.
Le défaut détecté par le test n’est pas mémorisé et le but recherché est donc de détecter uniquement un défaut de comm permanent.
Est ce bien ce qui est recherché?
Si c’est le cas, à l’analyse du code, et meme si je ne comprends absolument rien au détail du code, on voit que le passage à 0 et 1 semble dépendre de 2 tests sur des objets de nature différente et à des moments différents.
En ligne 288
if not cycle_with_error:
alors cycle_ok=1
puis en ligne 595
if cmd[« cmdFormat »] == ‹ blob ›:
alors cycle_ok=0
Probable analyse de beotien…mais n’y aurait il pas qq chose à regarder?
Hello
Ci joint les resultats et info demandées:
Statut ce matin: cycle_ok est resté à 1 malgres l’arret habituel vers 2h.
3 rafraichissements manuels faits cf timeline pour heure de réalisation
L275: la fonction one_cycle_read fait une lecture de toutes es commandes info et retourne s’il y a eu une erreur ou pas
L277 à 285: gestion du mode polling
L288 à 294 : s’il n’y a pas eu d’erreur, cycle_ok=1 est envoyé à Jeedom pour actualiser la commande correspondante
-L595 dans la fonction set_error envoi de cycle_ok=0 puisque cette fonction est appelée en cas d’erreur à la ligne 370 :
Désolé de confirmer la première partie de cette phrase et de nier la seconde
Petite précision sur cette partie du plugin : durant la phase bêta, un utilisateur qui a fait énormément de tests et qui utilise beaucoup MyModbus a tester en détail l’info cycle_ok : son onduleur se met en mode maintenance tous les jours durant une certaine plage horaire. Ccle_ok passe à 0 et revient bien à 1 une fois que les lectures sont à nouveau bonnes. Et ce depuis plusieurs semaines, tous les jours.
Le but serait de repasser en polling ou en cyclique afin d’avoir un fonctionnement comme vous le souhaitez. Je ne pense pas qu’il soit pratique de rafraichir manuellement.
Si vous repassez en polling, pourriez-vous me faire parvenir les log mymodbus_daemon à partir du démarrage du démon et sur quelques cycles de lecture SVP ?
1000|[2025-02-01 15:41:00] INFO : Starting daemon with log level: debug
1001|[2025-02-01 15:41:00] DEBUG : Writing PID 307238 to /tmp/jeedom/mymodbus/daemon.pid
1002|[2025-02-01 15:41:00] INFO : Listening on 127.0.0.1:55502
1003|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' client params for reg test 2: {'name': 'reg test 2', 'timeout': 5.0, 'retries': 3.0, 'trace_connect': <bound method MyModbusBase.trace_connect_callback of <mymodbustest.MyModbusTest object at 0x7fae5d9753d0>>, 'port': 502, 'host': '192.168.1.20', 'framer': <FramerType.SOCKET: 'socket'>}
1004|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' self.eqConfig = {'id': '202', 'name': 'reg test 2', 'eqProtocol': 'tcp', 'eqRefreshMode': 'polling', 'eqPolling': '5', 'eqTimeout': '5', 'eqWriteCmdCheckTimeout': '0.01', 'eqRetries': '3', 'eqFirstDelay': '0', 'eqErrorDelay': '1', 'eqAddr': '192.168.1.20', 'eqPort': '502', 'eqRegTest': '1', 'eqRegTestFirst': '12688', 'eqRegTestLast': '12703', 'eqRegTestSlave': '1', 'eqRegTestFunction': '1', 'eqRegTestFormat': 'bits', 'eqRegTestInvertBytes': '0', 'eqRegTestInvertWords': '0', 'eqRegTestInvertDWords': '0'}
1005|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' request_func = <class 'pymodbus.pdu.bit_message.ReadCoilsRequest'>
1006|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12688: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12688, count=1, bits=[], registers=[], status=1)
1007|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12689: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12689, count=1, bits=[], registers=[], status=1)
1008|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12690: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12690, count=1, bits=[], registers=[], status=1)
1009|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12691: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12691, count=1, bits=[], registers=[], status=1)
1010|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12692: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12692, count=1, bits=[], registers=[], status=1)
1011|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12693: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12693, count=1, bits=[], registers=[], status=1)
1012|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12694: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12694, count=1, bits=[], registers=[], status=1)
1013|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12695: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12695, count=1, bits=[], registers=[], status=1)
1014|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12696: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12696, count=1, bits=[], registers=[], status=1)
1015|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12697: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12697, count=1, bits=[], registers=[], status=1)
1016|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12698: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12698, count=1, bits=[], registers=[], status=1)
1017|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12699: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12699, count=1, bits=[], registers=[], status=1)
1018|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12700: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12700, count=1, bits=[], registers=[], status=1)
1019|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12701: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12701, count=1, bits=[], registers=[], status=1)
1020|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12702: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12702, count=1, bits=[], registers=[], status=1)
1021|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_eqConfig' Modbus request for address 12703: ReadCoilsRequest(dev_id=1, transaction_id=0, address=12703, count=1, bits=[], registers=[], status=1)
1022|[2025-02-01 15:41:00] DEBUG : reg test 2: 'connect' ModbusClient of reg test 2 = AsyncModbusTcpClient 192.168.1.20:502
1023|[2025-02-01 15:41:00] INFO : MyModbusd: Starting the task to test anthe equipement reg test 2
1024|[2025-02-01 15:41:00] INFO : Send async started with a cycle of 0.5s
1025|[2025-02-01 15:41:00] DEBUG : reg test 2: 'read_downstream' launched
1026|[2025-02-01 15:41:00] DEBUG : MyModbusd: 'read_upstream' run for reg test 2 (id = 202)
1027|[2025-02-01 15:41:00] DEBUG : Connecting to 192.168.1.20:502.
1028|[2025-02-01 15:41:00] DEBUG : Connecting reg test 2
1029|[2025-02-01 15:41:00] DEBUG : Connected to reg test 2
Excellent!
Merci pour la patience et les explications. Toujours autant béotiens mais moins con apres ca
Enfin il me semble
Bon hier j’ai reactivé les 4 equipements (onduleurs) et remis tout ce beau monde en pool bien sur.
Au cas ou: le dialogue modbus TCP ne se fait qu’avec un seul equipement physique; L’ECU APS qui récupère les info des onduleurs DS3 par Zigbee, RF donc. La liaison reseau de l’ECU est par cable ethernet .
J’ai mis en historisé l’equipement onduleur2 sur la data puissance sur mes 2 modes de collecte de data. ainsi que le booleen cycle_ok de l’onduleur2
Les collecteurs
1/ nodeRed (VM debian freeboxdelta) → Mqtt (appli Syno) → Mqtt(plugin Jeedom)
2/ MyModBus(plugin Jeedom)
Resultat ce matin: Les onduleurs ont tous passé le 2h13 ok sauf l’onduleur2
L’historique ci dessous montre que sur l’onduleur le cycle_ok est passé à 0 à 2h13 mais les acquisitions ont continuées à être collecté jusque vers 10h. Pendant ce temps les acquisitions modbus par nodered sur le meme equipement meme data continuaient à ce faire correctement.
A 18h j’ai fait un refresh manuel qui a amené la valeur à l’attendu 0w.
A noter que j’ai beau faire la séquence relance du deamon + refresh. le cycle_ok reste scotché à 0 pour onduleur2.
Relance des dépendances → tout le monde repasse à 1
Même si Cycle_ok est à 0, les lectures se font correctement, puisque vous comparez les lectures avec des lectures faites par node-red.
J’ai bien compris ?
Malheureusement, je n’ai que les logs quand tout va bien, une fois que tout est reparti en polling. Dans les logs il n’y a que des cycle_ok à 1 qui sont envoyés.
Un redémarrage du démon aurait fait la même chose. Les dépendances sont OK, je vous assure à 100% que ça ne vient pas de là.
Faites un essai pour moi : si c’est comme j’ai compris, les 4 équipements ont les mêmes paramètres de communication et sont configurés pour communiquer avec la même IP : l’ECU.
Il s’agirait de faire en sorte de modifier ECU1_MyModBus_02, ECU1_MyModBus_03 et ECU1_MyModBus_04 pour utiliser l’interface de ECU1_MyModBus_01. De cette manière MyModbus ne génèrera pas 4 connexions simultanées mais qu’une seule. Les infos remonteront pareil, peut-être un peu moins rapidement mais en utilisant des plages de registres, vous pourrez optimiser la vitesse (une lecture pour le SN et un plage de registres 40124 [40] s’il n’y a pas de « trou » dans les registres des onduleurs).
Et si vous partagiez les templates des 4 équipements ?
correct , l’ethernet passe bien sur par la box delta
Le log fourni hier soir correspond à la journée du 1 au 2 fev
Le graphique historique fourni sur la meme période montre que cycle_ok passe à zero vers 2h malgré des collectes correctes, puis vers 10h arret reel de comm, donc tout ne va pas bien dans les faits. Le log ne refleterait donc pas la réalité des évenements?
Status au 3 fev:
4 equipements à @esclave différentes meme IP.(ECU)
ci joint template de 2 equipements
onduleur01
*Relance hier soir des dépendances car la relance seul du deamon+refresh ne faisait aucun effet. (fait plusieurs fois)
*Tous les équipements en cycle_ok =1
Ce matin
*Tous les équipements en cycle_ok =0 passage à 2h13
*Tous les registres des 4 equipements fournissent néanmoins des data corrects (identiques au collecteur NodeRed ou ModbusDoctor)
-------> cycle_ok ne reflete donc pas la réalité de comm ok sur ma configuration.
Problème interessant et pour lequel je n’ai pas encore de solution. Mais on avance, parce que je comprends des choses.
Non, les logs couvrent ces périodes :
mymodbus : 2025-02-02 19:34:59 à 2025-02-02 19:52:46 : 518 lignes de log
mymodbus_daemon : 2025-02-02 19:36:10 à 2025-02-02 19:52:36 : 37125 lignes
J’ai donc en gros 20 minutes.
OK, maintenant je comprends enfin votre problème. OK
Oh que si, quand j’ai des logs, ils reflètent toujours la réalité, mais je n’ai pas assez de log (cf plus haut).
Merci pour les templates, je regarderais pour vous proposer une optimisation avec des plages de registres. Si les plages sont contigües, ça ne fera qu’une seule requête pour actualiser toutes les commande info.
Ce n’est pas possible. Comment relancez-vous le démon ?
Ce serait pratique d’avoir les logs mymodbus_daemon au moment du passage cycle_ok à 0 et sur plusieurs heures jusqu’à ce que la comm. soit bonne mais que cycle_ok ne passe pas à 1.
Ce qui fonctionne c’est que cycle_ok passe bien à 0. Par contre il ne passe pas à 1 (ce qui signifie qu’il y a un défaut que j’aimerais retrouver dans les logs).
Le fait que la comm. tombe au bout d’un moment (quand cycle_ok est à 0) est, selon moi, la conséquence de l’erreur de comm. diagnostiquée par le fait que cycle_ok ne repasse pas à 1.
L’utilisateur confirme
7 équipements (solaredge), 2x par jours font des reset de la carte de communication, et cycle ok tombe bien à 0 et remonte dès que les communications reprennent.
Oui, aucun problème, c’est réglé comme une horloge. Je préfèrerais ne pas avoir de coupure de communications, mais c’est malheureusement le fonctionnement de Solaredge.
