Bonjour Michel,
Ci-après les résultats de mes tests dominicaux:
La bonne nouvelle est que j’ai réussi à retranscrire les équipements et leurs commandes en version béta et que tout fonctionne.
A signaler quelques sauvegardes d’équipement qui bloquent sur une erreur 500 puis qui passent après un deuxième clic ???
Pour mémoire le réseau Modbus comporte à ce jour 3 équipements (2 en RTU: carte entrées et carte relais; 1 en TCP/IP: VMC).
Dans ma configuration, le démon refuse de démarrer si tous les équipements sont actifs. Donc je le démarre avec seulement la carte entrées puis j’active les deux autres équipements. Je peux reproduire cette anomalie sans problème. Je n’ai pas encore compris l’origine du problème.
De plus, le log contient beaucoup de message d’erreur qui ne semblent pas bloquants ?? J’ai fait de multiples tests de modification des paramètres sans pour autant arriver à supprimer ces erreurs
Ci-joint les configurations des équipements et le log du plugin
Il serait intéressant pour moi d’avoir le log en debug du plugin qui contient ce moment-là ET le log http.error pour comprendre ce qu’il se passe et le corriger.
De la même manière, le log du plugin et debug au moment du lancement du démon sans succès serait utile.
En mode série (RTU ou non) le fait de garder la connexion ouverte alors que le polling est long (> 5 secondes) peut causer des problèmes.
Par ailleurs, sur la carte de sortie, si l’option « inverser les octets » est cochée, il est possible de remplacer 256 par 1 et 512 par 2.
Est-ce que vous pourriez détailler les configurations des 3 équipements histoire que j’ai un aperçu complet SVP.
Bonsoir Michel,
J’ai appliqué vos recommandations sur l’inversion d’octets et le fait de ne pas garder la connexion ouverte. J’ai beaucoup moins de messages effectivement. Voir la log ci-après: mymodbus.txt (35,5 Ko)
Vous trouverez ci-après les logs de démarrage avec 1 ou 2 équipements. Avec 2 le démon ne redémarre pas. mymodbus-démarrage-1-equipements.txt (35,6 Ko) mymodbus-démarrage-2-equipements.txt (34,4 Ko)
J’ai reproduit l’erreur 500 en créant « from scratch » un nouvel équipement. Le log ci-après. http.error.txt (614 Octets)
Enfin les configurations des 3 équipements:
Que ce soit avec un ou 2 équipements série, l’exception de pymodbus ne me plait pas.
[2023-11-05 20:47:27][INFO] : Serial lost connection.
[2023-11-05 20:47:27][DEBUG] : Client disconnected from modbus server: None
[2023-11-05 20:47:27][ERROR] : Exception in callback SerialTransport._call_connection_lost(None)
handle: <Handle SerialTransport._call_connection_lost(None)>
Traceback (most recent call last):
File "/var/www/html/plugins/mymodbus/ressources/_pyenv/versions/3.9.16/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/var/www/html/plugins/mymodbus/ressources/_pyenv/versions/3.9.16/lib/python3.9/site-packages/pymodbus/client/serial_asyncio/__init__.py", line 427, in _call_connection_lost
self._serial.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Je ne suis pas sûr de la source de cette exception.
Merci, il va y avoir un correctif.
C’est ce dont je me doutais, c’est la même interface série utilisée par MyModbus. Le démon démarre donc les lectures sur les 2 exclaves Modbus en même temps et ça ne fonctionne de toute évidence pas. Comme les log ne montre pas le moment du démarrage du démon, je ne sais pas.
Pourriez-vous désactiver le plugin MyModbus puis l’activer et garder les messages log du démarrage SVP ?
Un bon essai serait de modifier le paramètre « Temps entre la connexion et la première requête » sur un équipement série et le passer à 10 secondes pour induire un décalage entre le polling des l’équipements.
Suite à la mise à jour de cette beta 24 je n’arrive plus à redémarrer mon demon. Je ne sais pas si c’est spécifique à ma config où plus général, mais un conseil, attendez d’avoir une confirmation de Michel avant d’appliquer cette mise jour.
Bonjour, j’ai appliqué cette mise à jour sur une install. (Modbus RTU) Après la mise à jour du plugin. J’ai voulu relancer le daemon … KO.J’ai relancé l’installation des dépendances puis tenter de redémarrer le daemon KO. Je n’avais pas le temps d’approfondir le disfonctionnement. (Désolé)
J’ai donc fait « machine arrière » en restaurant un backup. qui a redémarré sans problème avec une version V2.0 beta 20.
Je conseille de temporiser l’installation de cette dernière version. @Michel_F saura certainement nous orienter au mieux.
Merci !
Le correctif vient d’être trouvé et est sur github. La mise à jour auto du market de ce soir va corriger le problème à moins que Bebel27 ne pousse manuellement plus tôt. Je vais lui envoyer une demande dans ce sens.
Solution : plugin / mymodbus / core / class / mymodbus.class.php ligne 528 à 537 à remplacer par ces lignes (une ligne est supprimée)
Ancien code :
Bonjour Michel,
Je viens de mettre en préproduction la dernière version. J’ai pu vérifié qu’elle intégrait bien le correctif ci-dessus. J’ai relancé l’installation des dépendances pour faire bonne mesure
Je n’ai pas modifié les paramétrages des équipements indiqués lors des tests précédents.
Les constats:
le démon démarre maintenant sans problème quelque soit le nombre d’équipement sur le réseau RTU.
Par contre, je ne peux plus piloter la carte relais (à noter: la carte entrées fonctionne toujours).
J’ai fait le test suivant: j’ai désactivé tous les équipements hormis la carte relais et j’obtiens le log ci-après lorsque j’essaie d’activer un relais. Curieusement des messages d’erreur concernant la carte d’entrées apparaissent aussi dans ce log alors que l’équipement n’est pas actif. mymodbus-2.txt (9,4 Ko)
Globalement, il y a toujours beaucoup de message d’erreur dans le log en debug, notamment sur PyModbusClient (voir ci-après). mymodbus.txt (33,8 Ko)
J’ai aussi des erreurs dans le log des packages, suite à l’installation. mymodbus_packages.txt (1,6 Ko)
Je ne sais pas comment pymodbus réagit avec des tentatives d’ouverture de connexion sur différents esclaves modbus mais avec la même interface série et en plus en même temps. Je n’ai pas la possibilité de tester ça chez moi et je ne sais donc pas si 2 équipements MyModbus distincts utilisant la même interface série fonctionnent.
Vous est-il possible de tester avec un seul équipement qui regroupe les commandes des équipements actuels ?
C’est parce que j’ai supprimé le test qui empêchait le démon de démarrer si 2 équipements utilisent la même interface série. Mais en réalité, je ne sais pas si ça peut fonctionner…
Oui, ça n’a pas l’air de fonctionner franchement bien chez vous…
Vraiment très étrange ces messages :
pyenv: no such command `init'
pyenv: no such command `local'
pyenv: no such command `exec'
pyenv: no such command `exec'
pyenv: no such command `exec'
Pour réinstaller pyenv, il faut :
désactiver le plugin
supprimer le répertoire plugins/mymodbus/ressources/_pyenv
réactiver le plugin ce qui devrait réinstaller les dépendances (ça prend du temps) sinon, les réinstaller "manuellement’’
Par ailleurs, je vais me repencher sur le plugin, notamment les paquets à installer et ferai sans doute une autre mise à jour prochainement
Bonjour Michel,
Je viens de faire le test avec un équipement unique comprenant un échantillon de commandes de mes équipements physiques. Cela fonctionne sans problème et je n’ai plus de message d’erreur.
A noter: un équipement désactivé continue de générer des erreurs
Si vous avez besoin d’infos, de log n’hésitez pas.
Cela tendrait à prouver qu’effectivement avec le plugin actuel une même interface série ne peut piloter plusieurs équipements. Je comprends mieux pourquoi ID de l’esclave est maintenant au niveau de la commande alors qu’il était précédemment au niveau de l’équipement.
Cela dit, dans mon cas (qui n’est probablement pas celui de tout le monde) j’ai actuellement 3 esclaves sur mon réseau et je vais bientôt passer à 6. Si je mets toutes les commandes dans un même équipement j’aurai de l’ordre de 200 commandes, ce qui n’est pas très pratique en terme de maintenance et qui limite rapidement l’usage de MyModbus sur un réseau unique, alors que c’est un protocole industriel très fiable.
De plus, les paramètres de connexion (vitesse, parité, etc.) ne sont pas toujours les mêmes et dépendent des esclaves avec parfois l’impossibilité de les modifier.
Certes, il est aussi possible de multiplier les réseaux physiques avec des convertisseurs différents, mais je n’ai pas fait de test en ce sens.
Enfin, concernant pyenv, je l’ai réinstaller à la main, sans difficulté.
En conclusion, s’il existait une solution pour piloter plusieurs équipements sur une même interface série, ça serait vraiment super.
Si vous analysez la faisabilité de cette solution, faites m’en part car cela orientera mes choix à l’étape de mise en œuvre suivante.
Encore merci pour votre aide et vos précieux conseils
K’sin
C’est logique quand on sait comment est gérée une communication série. Merci d’avoir fait le test.
Voilà qui est très curieux. Me serait-il possible d’accéder à votre Jeedom afin de tester ça ? Si oui, envoyez moi un MP SVP.
Je vais devoir me creuser la tête pour verrouiller cela au niveau du démon. Je vais trouver quelque chose, j’ai déjà des pistes.
Ce sera très certainement quand même dans un seul équipement pour que la configuration soit au même endroit. Il le faut pour éviter des requêtes simultanées sur 2 esclaves distincts avec des configurations de communication différentes.
→ Pour ne regrouper que les commandes d’un même appareil, je pense qu’il sera nécessaire de passer par un virtuel par appareil qui reprend les commandes correspondantes. Ce qui est le cas aujourd’hui aussi.
Bonjour Michel,
J’ai des difficultés à faire fonctionner le plugin en production qui est en Debian 11.
Est-ce que le plugin a déjà fonctionné dans cet environnement car j’ai l’impression qu’il y a des pb avec PHP 3.7 vs 3.9 ?
Si oui, est-ce qu’il y a des précautions en terme d’installation ?
Merci pour vos retours
K’sin
MyModbus utilise un pyenv en python 3.9.16 qui est indépendant du système.
Il n’y a rien à faire de particulier pour la gestion de la version python, c’est moi MyModbus qui gère.
J’ai testé MyModbus sous debian 10 et 11 sans différence. Ma machine de développement est en debian 11.
Avec la prochaine mise à jour en cours, la version de python dans pyenv va évoluer en 3.11.6, soit la dernière version stable.
Il semblerait que pymodbus ne soit pas installé correctement.
Il faudrait supprimer le répertoire plugins/mymodbus/ressources/_pyenv et relancer l’installation des dépendances.
