edit : en fonction de ta config, ça va durer plus ou moins longtemps
Un utilisateur a même eu des reboot de son RPI parce que l’alim était trop faible et il s’est retrouvé dans le même cas que toi : commande bloquante enregistrée mais pas terminée puisque son RPI avait rebooté en plein milieu
De mon coté, je n’arrive toujours pas a obtenir quoi que ce soit de mon onduleur Huawei.
J’ai appliqué plusieurs configs supposées fonctionnelles dans ce forum et j’ai toujours la même erreur de Timeout à la lecture
[2024-04-02 15:00:16]INFO : mymodbus::deamon_stop * Arrêt du démon...
[2024-04-02 15:00:16]INFO : mymodbusd: Command 'quit' received from jeedom: exiting
[2024-04-02 15:00:19]INFO : mymodbus::deamon_stop * Démon arrêté
[2024-04-02 15:00:22]INFO : Protocol lost connection.
[2024-04-02 15:00:22]ERROR : PyModbusClient: *Onduleur* Something went wrong while reading Time (command id 3459): <class 'TimeoutError'> = . Traceback: <traceback object at 0x7f9ba9b100>
[2024-04-02 15:00:22]INFO : Send to jeedom : {'eqId': '519', 'values': {'cycle_time': 60.0226984500885}}
[2024-04-02 15:00:22]INFO : Protocol lost connection.
[2024-04-02 15:00:22]INFO : PyModbusClient: *Onduleur* shutdown called
[2024-04-02 15:00:22]INFO : jeemodbus.php: Mise à jour des commandes info : 'Temps de rafraîchissement'
[2024-04-02 15:00:43]INFO : mymodbus::deamon_start * Lancement du démon mymodbus : /var/www/html/plugins/mymodbus/ressources/mymodbusd/mymodbusd.py
[2024-04-02 15:00:49]INFO : mymodbusd: Start daemon mymodbusd
[2024-04-02 15:00:49]INFO : mymodbusd: Log level: info
[2024-04-02 15:00:49]INFO : Writing PID 30379 to /tmp/mymodbusd.pid
[2024-04-02 15:00:49]INFO : Init request module v2.31.0
[2024-04-02 15:00:49]INFO : Protocol made connection.
[2024-04-02 15:00:49]INFO : Connected to 192.168.0.13:502.
[2024-04-02 15:00:53]INFO : Protocol lost connection.
[2024-04-02 15:00:53]ERROR : PyModbusClient: *Onduleur* Something went wrong while reading Time (command id 3459): <class 'TimeoutError'> = . Traceback: <traceback object at 0x7fa66b9e80>
[2024-04-02 15:01:19]INFO : Protocol lost connection.
[2024-04-02 15:01:19]INFO : Protocol made connection.
[2024-04-02 15:01:19]INFO : Connected to 192.168.0.13:502.
[2024-04-02 15:01:23]INFO : Protocol lost connection.
[2024-04-02 15:01:23]ERROR : PyModbusClient: *Onduleur* Something went wrong while reading Time (command id 3459): <class 'TimeoutError'> = . Traceback: <traceback object at 0x7fa66ba300>
pour corriger le problème de FrtHIB et de Bison, la prochaine mise à jour de pyenv4Jeedom permettra de réinitialiser manuellement le verrou sur les commandes bloquantes.
La prochaine mise à jour sera faite pour s’accorder avec TiTidom (et d’autres ?) notamment pour le plugin-ttscast avec un chemin d’installation dans /opt/pyenv et plus dans un sous-répertoire du plugin.
Je me permets de poser une question car, après plus d’un an sans aucun souci avec le plugin MyModbus - beta vers 2025-05-28 10:28:41, tout fonctionnait parfaitement au point que j’en avais presque oublié les soucis initiaux.
Cependant, depuis deux jours, je rencontre à nouveau des problèmes uniquement avec les équipements utilisant une connexion en série (serial). Les équipements en TCP, quant à eux, continuent de fonctionner normalement.
Je voulais savoir s’il y avait eu des changements récents dans le plugin (mise à jour, modification du fonctionnement, dépendances, etc.) que j’aurais pu manquer et qui pourraient expliquer ce dysfonctionnement ?
Pour information, voici quelques éléments :
Le plugin MyModbus vers 2025-05-28 10:28:41
La version de pyenv vers 2024-04-03 00:50:26
Voici le détail de la configuration Python utilisée par le plugin :
mymodbus 3.11.8 pymodbus3.2.2
Je joins également une partie des logs : mymodbus_daemon (1).log (8,9 Mo)
Pour info : j’ai fait quelques relance, arrêt, mise en service d’équipmenté c’est la même chose plus de lecture sur la partie serial
Merci d’avance pour votre aide ou vos retours si d’autres ont observé un comportement similaire
Les modifications apportées au plugin sont listées dans le changelog.
Il m’a fallu quelques secondes avant de comprendre que « vers » signifiait en réalité « version ». Je mets en doute l’utilisation de ce raccourcis.
Ca fait depuis la version 17/09/2024 bêta42 que MyModbus n’utilise plus le plugin pyenv4Jeedom. Le plugin pyenv4Jeedom peut être désinstallé, il ne sert plus à rien.
Que s’est-il passé il y a 2 jours ?
Les équipements ? Dans les log, seul l’équipement « ISM » génère des erreurs et toujours la même sur les 8 commandes de lectures :
ISM: 'process_read_response' 'cmd_decode' for command id = 1230 raised an exception: unpack requires a buffer of 2 bytes
Avez-vous essayé de faire redémarrer cet appareil (mise hors tension, mise sous tension) ? A priori les réponses aux requêtes ne sont pas assez longues, il est peut-être planté.
Tous les traitements sont identiques que ce soit du TCP, de l’UDP ou du série. Si tout fonctionne sauf un équipement, je mets l’appareil interrogé par l’équipement en doute.
Ca contient 6548 erreurs identiques + 1 erreur de la même cause mais sans traceback (ligne 79493 du fichier).
Malheureusement, ça ne me sert pas.
Aucune trace de ces manipulations dans les logs.
Si le résultat est le même avec la version stable, c’est que ça vient de votre appareil.
Je pense que l’appareil a un soucis. Si vous avez la possibilité de le tester avec Modbus Doctor ou tout autre outil, ça pourrait confirmer (ou pas) ce que je pense.
Si pour tester l’appareil avec Modbus Doctor il faut le mettre hors tension, alors ne testez que la mise hors tension / mise sous tension et testez avec MyModbus.
Bonjour
Oui uniquement Ism en rs232 ne fonctionne plus ( une dizaine de valeurs numériques et analogiques sont concernées ) . Le problème est apparu sans raison particulière perte d’informations + défaut de lecture.
Oui j’ai fait plusieurs démarrage des différents équipements sans résultat, même si il me semble bon je vais remplacer le module de communication pour voir si c’est lui le coupable je ferai cela dans la journée. Je ferai dans la foulé des tests avec Modbus Doctor
C’est vrai pour les logs j’ai fait plusieurs manipulations avec effacement des logs à plusieurs reprises.
Sinon je vais réinvestiguer sur mon système soft et hard .
Je vous tiendrai informé
Bonjour à Tous
malheureusement après une demi-journée de tests et vérifications je ne pourrai pas vous donner d’explication car l’ensemble des mes composants étaient bons ( Vérification de toute la chaine de mesures sur mon pc Windows et Modbus doctor, OK . Après reconnexion toujours en défaut, j’ai abandonné le Beta , j’ai mis à jour mon raspberry pi j’ai contrôlé mon interface USB/Rs232 car le module est ancien (ATEN UC232A ) et j’ai cru qu’il n’était plus accepté par les mises à jours du raspberry .
Puis ce soir l’ensemble c’est remis en marche sans explications particulières, c’est frustrant car cela reviendra surement .
Concrètement j’ai uniquement fait les mises à jour Raspberry et passage en stable pour le module Mymodbus. et une multitude de démarrage Raspberry et demon du plugin .
Cordialement
Dès le début je pensais que ça allait se comporter de cette manière, il n’y a pas eu de modification du démon qui touche seulement les liaisons série.
Les liaisons série sont sensibles et souvent capricieuses. Elles sont parfois difficiles à mettre en service. Ça peut être le câble qui est trop long (15m maxi en rs232) ou de mauvaise facture, les résistances de terminaison, la montée en température du convertisseur, les connexions imparfaites, …
En tous cas, vous avez remis en marche tout ça et c’est tant mieux.
Bonjour,
Je modifie rarement mon système, la dernière intervention remonte au début de l’année 2024, en dehors des mises à jour de Raspberry Pi, Jeedom et des plugins. Cela dit, il faut reconnaître que le matériel « industriel » actuellement connecté à mon Raspberry Pi 4 commence à dater (ISM110 Gantner, interface ACKSYS RD400 et convertisseur ATEN UC232A).
Je commence donc à envisager de remplacer l’ensemble de la chaîne de mesure par une carte E/S numériques et analogiques sur Ethernet. Ce serait une solution plus simple, plus fiable, et plus facile à maintenir à long terme. Il me reste encore à faire un peu de prospection à ce sujet.