C’est bien ce que je pensais.
C’est pourquoi je cherche à trouver ce qui ne fonctionne pas chez monaghan.
edit: chez moi aussi, j’ai un onduleur capricieux et certaines requêtes sont en erreur assez souvent. Cycle_ok se comporte comme il doit.
Donc je ne doute pas du fonctionnement du plugin mais de la configuration chez lui.
Hello
De retour sur le sujet après un petit déplacement sans accès Jeedom.
Alors situation
Conf retenue:
*Désactivation de tous les équipements
*Création d’un seul équipement avec avec 2 @esclaves reflétant 2 onduleurs.
{
"ECU2onduleurs": {
"name": "ECU2onduleurs",
"eqType_name": "mymodbus",
"configuration": {
"createtime": "2025-01-28 11:19:08",
"eqProtocol": "tcp",
"eqRefreshMode": "polling",
"eqPolling": "10",
"eqTimeout": "5",
"eqRetries": "3",
"eqWriteCmdCheckTimeout": "0.01",
"eqFirstDelay": "0",
"eqErrorDelay": "1",
"eqPortNetwork": "502",
"updatetime": "2025-02-03 17:59:51",
"eqAddr": ""
},
"category": {
"heating": "0",
"security": "0",
"energy": "1",
"light": "0",
"opening": "0",
"automatism": "0",
"multimedia": "0",
"default": "0"
},
"display": {
"width": "786px",
"height": "216px"
},
"status": {
"lastCommunication": "2025-01-20 18:31:05",
"enableDatime": "2025-01-20 18:31:05"
},
"cache": [],
"commands": [
{
"logicalId": "polling",
"eqType": "mymodbus",
"name": "Polling",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"unite": "s",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "1",
"cmdFormat": "bit",
"cmdInvertBytes": "0",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"logicalId": "polling"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "0",
"alert": []
},
{
"logicalId": "refresh",
"eqType": "mymodbus",
"name": "Rafraîchir",
"type": "action",
"subType": "other",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "1",
"cmdFormat": "bit",
"cmdInvertBytes": "0",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"logicalId": "refresh"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "SN",
"type": "info",
"subType": "string",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "s",
"cmdAddress": "40052[16]",
"cmdInvertBytes": "1",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"logicalId": "cycle ok",
"eqType": "mymodbus",
"name": "Cycle OK",
"type": "info",
"subType": "binary",
"isHistorized": "1",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "1",
"cmdFormat": "bit",
"cmdInvertBytes": "0",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"logicalId": "cycle ok"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"logicalId": "refresh time",
"eqType": "mymodbus",
"name": "Temps de rafraîchissement",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"unite": "s",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "1",
"cmdFormat": "bit",
"cmdInvertBytes": "0",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"logicalId": "refresh time"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "0",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Tension",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40138",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Puissance",
"type": "info",
"subType": "numeric",
"isHistorized": "1",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40144",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Courant",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40124",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "1",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Frequence",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40146",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "1",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Temperature",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40162",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Energie",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "1",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40154",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "0",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "SN2",
"type": "info",
"subType": "string",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "s",
"cmdAddress": "40052[16]",
"cmdInvertBytes": "1",
"cmdInvertWords": "0",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Tension2",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40138",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Puissance2",
"type": "info",
"subType": "numeric",
"isHistorized": "1",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40144",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"graphStep": "1"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Courant2",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40124",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "2",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Frequence2",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40146",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "1",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Temperature2",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40162",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1"
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"isVisible": "1",
"alert": []
},
{
"eqType": "mymodbus",
"name": "Energie2",
"type": "info",
"subType": "numeric",
"isHistorized": "0",
"configuration": {
"cmdSlave": "2",
"cmdFctModbus": "3",
"cmdFormat": "f",
"cmdAddress": "40154",
"cmdInvertBytes": "0",
"cmdInvertWords": "1",
"cmdInvertDWords": "0",
"cmdFrequency": "1",
"timeline::enable": "0",
"influx::enable": "0",
"interact::auto::disable": "0",
"historizeRound": "0",
"jeedomCheckCmdOperator": "==",
"historizeMode": "avg",
"repeatEventManagement": "never",
"alert::messageReturnBack": "0",
"actionCheckCmd": [],
"jeedomPreExecCmd": [],
"jeedomPostExecCmd": []
},
"template": {
"dashboard": "core::default",
"mobile": "core::default"
},
"display": {
"showNameOndashboard": "1",
"showNameOnmobile": "1",
"showIconAndNamedashboard": "0",
"showIconAndNamemobile": "0",
"forceReturnLineBefore": "0",
"forceReturnLineAfter": "0",
"parameters": []
},
"isVisible": "1",
"alert": []
}
]
}
}
*Aprés activation le cycle_ok est à 1. ok
Ci dessous l’historique.
A nouveau on voit que le booleen tombe vers 2h13 ne revient jamais à 1 alors que les mesures se font correctement (identiques à celles collectées par NodeRed sur l’id 1). Le tout sur 2jours consécutifs. Toujours ce décalage entre la logique du booleen et la réelle possiblité d’acquisition.
Conclusion le fait d’être sur un seul équipement ne change donc rien au pb de cohérence cycle_ok vs acquisitions correctes.
Encore une fois le booleen est à 0 alors que je peux acquerir des donnés également avec modbusdoctor.
resumé:
cycly_ok =0 alors que
acquisitions par MyModbus ok
acquisitions par Nodered ok
acquisitions par Modbusdoctor ok
Sur cette configuration ECU-C APS en Modbus TCP, le booleen n’arrive pas à remonter à 1 par la logique codée.
Le redemarrage du demon dans conf +refresh a permis de remonter à 1.
zone utilisée pour redémarrage demon.
Si j’ai un peu de temps, je vais essayé d’instrumenter une détection comm ko dans nodeRed pour voir comment ca se passe.
Au fait je suis en version beta (2025-01-24 11:07:19) car la version stable avant la maj ne fonctionnait pas pour moi.
les logs
mymodbus(3).txt (218,2 Ko)
mymodbus_daemon(1).txt (8,2 Mo)
erreur de ma part sur le log demon comme il était trop gros je l’ai raccourci mais a priori de trop…
si besoin j’en referai un nouveau couvrant cette nuit.
Les solutions possibles si on en reste là:
1Scénario d’arrêt acquisition pendant la période de « maintenance ECU » vers 2h13. mais rien ne prouve que sur un vrai pb de comm le booleen remontera pour ma configuration. → de la charge cpu inutile puisque fonctionnalité non certaine.
2Puisque mes acquisitions peuvent se faire correctement quelque soit l’etat du booléen, on oublie carrément le booléen qui n’est pas complètement pertinent sur mon installation.
3*Je reste sur nodered/Mqtt avec mes 3 machines impliqués (Box pour nodered Modbus et transfert MQTT sous debian / Syno pour mosquitto/ Jeedom pour recup MQTT). Ce qui revient en l’état à ne pas avoir de booleen de bon fonctionnement (identique à solution 2).
A noter que si d’autres lecteurs ont un ECU-C APSystem ce serait probablement intéressant de faire un essai. Le template de conf equipement est dispo dans le fil de discussion. Cela permettrait de confirmer ou non que la logique de remontée du booleen n’est pas compatible avec une conf Modbus TCP sur ECU-C APS ou l’inverse peut importe ou s’il s’agit d’un cas de figure local.
Pour éviter toute éventuelle incompréhension avec des lecteurs de ce fil, le but de cet échange n’est pas de mettre un quelconque doute sur ce plugin.
En dehors de ce pb que j’ai sur ma conf, ce plugin fait le job est représente une excellente solution qui plus est gratos. La configuration d’un équipement est vraiment rapide, conviviale et bien pensée. (comparé à ce que j’ai sur NodeRed c’est du bonheur)+ gros travail de doc.
Bravo et merci beaucoup au créateur et contributeurs pour la somme colossale de boulot qu’il y a derriere ce genre de plugin.
A+
Bonjour,
Petite précision sur cyle_ok :
Dans les log mymodbus_daemon, il n’y a malheureusement pas le moment du passage à 0 de cycle_ok à 2h13 puisqu’il commence à 2h21. C’est dommage…
MAIS…
Dans mymodbus.log, on voit que l’info clycle_ok = 0 a été reçue à 2h13
Dans les log mymodbus_daemon, on voit que toutes les 20 secondes, cycle_ok = 1 (oui, oui 1) est envoyé vers Jeedom. Pas une seule fois, à partir de 2h21 en tout cas, cycle_ok = 0 n’a été envoyé par le démon.
Donc toutes les requêtes Modbus sont effectivement OK et s’exécutent sans erreur.
On avance…
Pour éviter de surcharger la communication interne et donc pour économiser des ressources sur la machine Jeedom j’ai fait en sorte qu’une valeur ne soit pas transmise dans certaines conditions pour les commandes info (il y a une case à cocher dans la config des commandes de Jeedom pour éviter d’enregistrer un point s’il n’y a pas de modification) et peut-être que cette condition n’est pas toujours la bonne, notamment pour ces remontées d’info (cycle_ok, polling, cycle_time).
Je regarderai ça ce soir.
Dans les log mymodbus_daemon on voit bien ce qui est fait :
[2025-02-06 02:21:29][DEBUG] : ECU1_PVsud: 'add_change' launched with payload = {'values::cycle_ok': {'value': 1, 'eqId': '756'}}
[2025-02-06 02:21:29][DEBUG] : ECU1_PVsud: 'add_change' No modification to send
La fonction add_change est appelée avec cycle_ok = 1, mais plus loin le test ne détecte pas de modification et donc cycle_ok n’est pas envoyé. Le test n’est peut-être pas le bon ou alors, cycle_ok = 1 a effectivement déjà été envoyé (mais je ne le vois pas dans les log puisqu’ils sont à partir de 2h21).
Un autre cas :
[2025-02-06 05:14:41][DEBUG] : ECU1_PVsud: 'add_change' launched with payload = {'values::cycle_ok': {'value': 1, 'eqId': '756'}, 'values::cycle_time': {'value': 0.35880967520643026, 'eqId': '756'}}
[2025-02-06 05:14:41][DEBUG] : MyModbusd: Message received from MyModbusClient ECU1_PVsud: {'add_change': {'values::cycle_time': {'value': 0.35880967520643026, 'eqId': '756'}}}
Explications simplifiées :
cycle_ok et cycle_time sont envoyés par le démon dédié à l’équipement (fonction appelée avec les infos) . Le dispatcher (MyModbusd) ne reçoit que cycle_time, donc le filtre a supprimé cycle_ok des infos envoyées.
C’est le vrai démon (ou dispatcher) MyModbusd qui communique en direct avec Jeedom, les démons de chaque équipement (MyModbusClient) communiquent avec le dispatcher. Il y a autant d’instances de MyModbusClient qu’il y a d’équipements communiquant actifs.
Il serait TRES interessant pour moi de voir vos log mymodbus_daemon autour de 2h13 (5 minutes avant jusqu’à 5 minutes après), pour savoir ce qui est fait et si cycle_ok = 1 est au moins envoyé une fois. De cette manière je saurai si la condition doit être revue.
Vous êtes en version bêta. Vous pouvez tester avec la stable ? Il suffit d’installer la version stable sans rien supprimer.
Les fonctions add_change sont différentes
A+
Michel
Remarque en passant : des valeurs nan sont lues systématiquement pour les commandes ID 7965 et 7971. Je ne crois pas en avoir vu d’autres.
nan = Not A Number
Il faut sans doute vérifier la configuration de ces commandes
Hello et merci du retour
ci joint la doc sunspec Modbus de l’ECU-C APS pour info.
SunSpec Modbus.pdf (1,4 Mo)
Curieux… les seuls type string sont les SN qui dans l’équipement ECU2onduleurs créé pour les tests et dont le détail .json a été fourni ce matin , sont les ID 7960 et 7975. @MB:40052[16] et 40052[16].
snapshot pour vision jeedom du parametrage @esclave2
Si les commandes id 7965 et 7971 remontent comme des NAN alors quelles sont cablées en float32b… Bizarre… vous avez dit bizarre?
Surtout qu’elles remontent bien comme un chiffre. ex:Je fait un trunc 2 de dessus pour limiter les décimales.
Je viens de vider les log pour avoir un relevé propre demain.
Je suis toujours sur l’équipement d’essai à double esclave et beta « ancienne ».
Je repasserai demain en stable. (qui doit être identique à la beta utilisée).
A+
NaN c’est quand une valeur réelle ne peut pas être décodée, ça ne veut pas forcément dire qu’il s’agit d’autre chose que d’un chiffre.
Peut-être que la nuit la valeur n’est pas lisible, out simplement.
En journée, donc ?
Je viens de publier une mise à jour de la bêta, vous pouvez tester cette version bêta et ignorer ma demande de repasser en stable ?
Rappel :
Hello
situation ce matin
Passage ko 2h13 et y reste malgré les acquisitions corrects à partir de 8heures quand le soleil a bien voulu fournir du jus. As usual
Relance demon sans rafraîchissement – > passage à 1.
Historique permettant de voir ces points
logs
mymodbus(5).txt (414,1 Ko)
mymodbus_daemon(5)b.txt (7,9 Mo)
J’ai tronqué le fichier logdemon car 40Mo ne passe pas. De plus il ne commençait qu’à 2h20…Pour avoir la zone autour de 2h13 il faudra que je fasse le téléchargement +tôt la prochaine fois (dommage à 7mn pres…)
ToDolist pour ce soir
*Je reste sur l’équipement test à 2 @esclaves simultanées.
*Je passe en beta new.
*Je n’oublie pas de telecharger le log dès le reveil…
A+
Bonjour,
En effet. Pour utiliser solcast, c’est pénible aussi j’imagine.
à 12 minutes près… J’aimerais avoir l’état quelques minutes avant aussi, pour mémoire.
A+
Michel
*passage en beta new ok
*telechargement ce matin ok
…mais oubli de passage en debug des log… 
sinon comportement classique.
ko 2h13
ok sur redémarrage demon manuel.
mymodbus_daemon (2).txt (43,2 Ko)
Au fait utiliser heartbeat et l’option redémarrer demon permettrait il de traiter le sujet, en mode traitement du symptome?
Ce WE pas d’acces jeedom.
Je relancerai ca la semaine prochaine.
Bon WE
Non, l’option heartbeat vérifie l’état du démon régulièrement et le relance si le statut est NOK.
Le démon tourne dans ton cas, mais ne remonte pas cycle_ok vers Jeedom. Cycle_ok est une commande de MyModbus absolument pas standard, donc Jeedom ne va pas checker cette commande.
Bon week-end
Petit test avant le blackout:
*cycleok=1
*changement de l@esclave1 1 -->10 fait dans l’administration de l’appliI APS
*cycleok passe à 0 → conforme puisque @ 10 n’est pas utilisée
*arrêt des acquisition sur @esclave1 -->conforme
*acquisitions correctes sur l@esclave2 -->conforme
*retour à l@esclave1 = 1 fait dans l’appli APS
*cycleok repasse à 1 tout seul -->conforme
*acquisitions 1 et 2 ok -->conformes
Dans ce cas de figure la logique de test fonctionne bien.
La config/sequence de com APS à 2h 13 doit donc être différente du fonctionnement ci dessus et ne permet pas
soit de repasser dans la boucle de test permettant cycleok=1
soit berne le test lui même.
et ce de façon permanente jusqu’à relance du demon manuelle.
mymodbus_daemon (3).txt (460,4 Ko)
mymodbus(4).txt (27,4 Ko)
A+
Excellent test. Bien vu pour simuler une coupure de communication.
Hâte de voir les log débug autour de 2h13.
Du nouveau ?
Hello
plusieurs jours que j’essaye d’avoir un log debug correct…
conf: mymodbus beta du 15/02/25
Résultats:
Par 2 fois le booleen cycle_ok est remonté tout seul aprés la situation APS 2h12.
Le reste du temps le booleen ne remonte que par activation manuelle de relance.
Quand nous sommes dans ce cas les logdemon effacent toute activité avant 2h21 quelque soit l’heure de collecte.pourquoi???
Il n’y a donc aucune trace du 2h12 de plus ces log font plus de 40Mo.
le logdemon ci dessous est tronqué.
Perso je ne vois pas comment sortir de cette impasse. La qualité de collecte de données est bonne et j’ai autant d’info par MyModbus que par mon précédent système plus compliqué de plus je gagne de l’ordre de 20secondes à l’avantage de MyModbus.
Je vais probablement en rester là et supprimer l’affichage de cycle_ok qui ne me sert pas puisque non certain dans cette conf. (info que je n’avais de toute façon pas non plus précédemment)
J’ai regardé si je pouvais faire un scenario de relance demon auto à 2h12+ mais rien d’évident pour mon niveau de programmation.
Voilà sauf si tu as d’autres idées…
Merci pour ton soutien
A+
mymodbus(7).txt (366,0 Ko)
mymodbus_daemon(5).txt (3,4 Mo)
flèches verte correspondent aux 2 cas de remontée cycle_ok spontanée.
Bonjour,
Pas sûr de comprendre ce que tu écris…
Les log sont tronqués automatiquement par Jeedom à un moment de la journée qui est déterminé automatiquement en fonction de la charge de la machine (de mémoire). Ca se trouve, c’est tronqué à 2h20 ?
Pour contourner ça, un script qui copie les fichiers log à 2h19 pourrait aider. Tu saurais faire ?
Dans un scénario, il est possible de désactiver un équipement, me semble-t-il, tu pourrais faire ça en paliatif dans le même scénario qui copie les fichiers log (ordre : désactivation/réactivation puis copie des fichiers log de préférence).
Pour info : les commandes 7965 et 7971 ne lisent que nan (not a number), tu devrais contrôler ces commandes.
A+
Michel
Hello , je reprends le sujet…
Pas sur de comprendre ce qu’il y a a contrôler ou comment le contrôler. L’ensemble des acquisitions est correct j’en déduis donc que le paramétrage est correct. Paramétrage visible sur hard copie d’écran plus haut dans le fil de discussion. De plus le paramétrage est conforme à la spec Modbus de l’ECU APS.
Je ne sais pas comment identifier que les commandes lisent « nan » sur le log. Peux tu me donner un exemple?
Pour ce qui est des logs, script/scenario faits et testés, nous aurons alors je l’espère des info sur le moment fatidique entre 2h10 et 2h22 demain.
A+
ok Vu
Reflexion/hypothese:
Vers 2h12 l’ECU fait des opérations qui nécessitent l’arrêt du dialogue Modbus. (a minima je sais que les valeurs de cumul Wh/Jour est remis à zéro).
Quand celui ci reprend, les onduleurs sont à l’arrêt (il fait nuit) et n’ont donc aucune data à fournir à l’ECU. Les registres concernés pourraient se trouver dans une situation non fiable dans cette période. Celui ci n’a rien à fournir lors d’une requête jeedom jusqu’à ce qu’il fasse jour. d’où peut être le nan sur certain registre.
Ceci dit ça n’explique pas pourquoi le test cycle ok est mis en carafe tant que le demon n’est pas relancé…
Bonjour,
Ca se tient…
Il serait intéressant de faire un équipement de test identique sauf ces 2 commandes (à supprimer, donc) pour voir si Cycle_ok = 0 vient de là.
A+
Michel
oui bonne idée.
Pour ce qui est des log c’est la misère . Le log a bien été sauvegardé à 2h19 mais neremonte des données que jusqu’à 2h18… je vais mettre une copie toutes les minutes dans la zone 2h10/ 2h19.
mymodbus_daemon.old.txt (49,7 Ko)
