Fonctionnement du booleen "cycle ok" et remise à ok

[Michel_F]

Le fichier ne contient que 500 lignes et pile 500 lignes, je trouve ça étrange surtout qu’il s’agit de la taille max des log par défaut sur Jeedom.

[monaghan]

Hello breaking news
conf suivant proposition sans les 2 registres « louches » .
Résultat: 2 ème nuits avec chute du booleen à 2h13 puis remonté ok « naturelle » à 2h15.
Pas de log dispo–> après analyse j’avais supprimé au lieu de vider le log. Ayant fait au plus simple le code, le copy ne trouvant pas de fichier source … ben pas de copie. Je pensais que le fichier mymodbus_deamon se régénérait automatiquement dès le passage en mode debug mais ce n’est pas le cas.

L’hypothèse précédente semble donc se vérifier:
*A 2hxx l’ECU coupe la comm Modbus. → cycle_ok passe à 0 (conforme à l’attendu)
*Quand celle ci repart les registres peuvent être dans des situations incertaines car les onduleurs sont à l’arrêt (nuit). → cycle_ok reste à 0 (conforme à l’attendu)
*Lorsque les onduleurs redémarrent les registres sont à nouveau conformes et sont collectés correctement par le dialogue Modbus. → cycle_ok reste à 0 (inattendu).

A noter que les 2 registres concernés sont ceux de la mesure de courant. Seules grandeurs dépendant directement de l’onduleur. Tension/fréquence sont des data exogènes à l’onduleur et puissance est une data calculée. Ca pourrait expliquer la différence d’état de ces 2 registres par rapport aux autres.

Conclusion possible pour mon usage et si l’appli continue à laisser cycle_ok conforme à l’attendu grâce à la suppression de collecte des registres « courant »:
Ne pas collecter les data « courant » qui ne me servent objectivement à rien. C’est la puissance surtout qui m’intéresse. Du coup pas de scénario consommateur de ressources et utilisation du booléen pour les cas de figure prévues (arrêt de dialogue et redémarrage avec des registres conformes).

Tout ceci n’explique toujours pas pourquoi cycle_ok n’arrive à remonter ok sur ce cas de figure mais on peut se dire que ça n’intéresse que les utilisateurs d’ECU APS qui souhaitent collecter la data courant… Ca doit restreindre le nb de personnes concernées…à …

[freeddoo]

Salut

Petite demande d’information à @Michel_F et à @monaghan.
J’ai lu l’ensemble de vos échange et j’aimerais également récupérer les infos de mon ECU-C.
Je me suis amuse à faire des testes mais j’ai un soucis.
Je crée un équipement avec plusieurs info, je l’enregistre et je teste. C’est ok.
Dès que je rajoute une info dans l’équipement j’ai plus de remonte.
Le démon est ok et rien dans les logs.
Une idée ?
un exemple

Je voulais pas créer un autre fil, celui la j’y trouve plein de ressource pour mon besoin.
Merci de vos retours

Ps ma config

[monaghan]

Perso j’essaye d’appliquer des règles d’hygiène informatique de base
N°1 ne pas emmener le soft dans des situations non nominales. Les développeurs ne peuvent pas passer du temps/du code à couvrir toutes les situations/combinaisons imaginables voire inimaginables…
Regarde la spec modbus APS (cf plus haut dans le fil). Certains registres que tu adresses sont réputés « unimplemented ».
Evitons.
N°2 utiliser des outils dédiés au test pour vérifier le bon fonctionnement du dialogue.
Dans ce cas Modbusdoctor de Kscada est bien adapté et permet de tester les registres.

Autre remarque: il y a un plugin tout fait APS pas cher, plutôt joli au niveau dashboard.
Dans mon cas j’en suis sorti car son utilisation me plantait définitivement (OffOn ECU obligatoire) le dialogue modbus de l’ECU, statistiquement une fois tous les 30 jours.

Par contre je te propose d’ouvrir un autre fil , car mon sujet est désormais traité et je vais donc le clore car 3eme jour consécutif de remontée ok du booleen cycle_ok.
Un grand merci à Michel pour le support et la résolution.