Commandes en FC06 non envoyée, Démon KO au réveil d'un équipement

Bonjour,

Je ne sais pas si c’est l’endroit approprié pour remonter les problèmes que je rencontre avec la version bêta du plugin.
Je rencontre donc les problèmes suivants :

  • non fonctionnement de l’envoi de commandes en FC06 (que se soit via slider, liste, valeur …) :
[2024-02-10 23:22:54] DEBUG  : PyModbusClient: *PAC Modbus* write_request {'last_value': None, 'name': 'Commande de marche ECS', 'type': 'action', 'slave': 10, 'fct_modbus': '6', 'data_type': 'int16', 'addr': 12, 'byteorder': '>', 'wordorder': '>', 'repeat': False}
[2024-02-10 23:22:54] ERROR  : PyModbusClient: *PAC Modbus* Something went wrong while building the write request for Commande de marche ECS (command id 6577): ValueError("invalid literal for int() with base 10: ''")

Je demande d’écrire un entier, 0 ou 1, en l’occurrence - il s’agit bien d’une requête FC06.

  • J’ai deux appareils sur la même ligne modbus, une passerelle vers PAC Daikin et un onduleur solaire qui est donc éteint la nuit. Le tout est branché sur une seule interface USB (même paramètres de communication sur les deux appareils : vitesse 9600, 8 bits, pas de parité, stop bit :1, slave address 1 pour l’onduleur, 10 pour la PAC).Je constate que la communication n’est pas « rétablie » vers l’onduleur, lorsque celui-ci se « réveille ».

J’ai une configuration peut-être un peu trop « en avance » : Jeedom 4.4.1, debian 12 bookworm.
Je peux mettre en place un raspberry pour test.
Quoiqu’il en soit, merci pour votre plugin.
mymodbus.txt (390,5 Ko)

Bonjour,

Justement non vous ne l’étiez pas, post déplacé.

1 « J'aime »

Bonjour,

Ce serait bien de mettre une capture de la config de la commande action (id=6577 chez vous) qui ne fonctionne pas parce que d’après ce que je vois dans les log :

[2024-02-10 23:22:52][DEBUG] : PyModbusClient: *PAC Modbus* check_queue - daemon_cmd: {"write_cmd": {"eqId": "221", "cmdWriteValue": "", "cmdId": "6577"}}

"cmdWriteValue": "" n’est pas normal, normalement on cherche à envoyer une valeur.

Comme la valeur n’est pas définie, la trame n’est pas construite normalement et génère une erreur.

Je peux voir pour filtrer ce cas du coté du plugin pour que la commande génère une erreur sans l’envoyer vers le démon.

A+
Michel

Bonjour,
Que ce soit une liste,


ou bien un slider,

je constate effectivement qu’aucune valeur n’est envoyée.

Dans le champ valeur, il faut rentrer la valeur que vous voulez écrire.

Si c’est une constante (par exemple 7), il faut écrire la valeur.
Si c’est la valeur de la liste, il faut écrire #select#.
Si c’est la valeur d’un slider, il faut écrire #slider#.
Si c’est une couleur, il faut écrire #color#.
Si c’est la valeur d’une autre commande, il faut écrire son nom de la forme #[objet][équipement][commande]#

C’est quasi standard à Jeedom tout ça.

Ce n’est pas directement la valeur du slider ou de la liste par ce qu’on peut vouloir faire un calcul, par exemple (7 - #slider#) * 2 avant d’envoyer la valeur.
C’est vrai que je pourrais rendre le plugin intelligent en écrivant ce qu’il faut au moment de l’enregistrement si le champ valeur est vide.

Merci pour votre réponse, les commandes FC06 sont maintenant fonctionnelles.
Peut-être serait-il possible de détailler la documentation sur ce point, chaque plugin a un fonctionnement différent à ce sujet.

Par contre, le démon le démon semble ne pas fonctionner quand les deux équipements sont actifs :

[2024-02-11 18:03:55][INFO] : Serial lost connection.
[2024-02-11 18:03:55][DEBUG] : Client disconnected from modbus server: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
...
[2024-02-11 18:03:55][ERROR] : PyModbusClient: *PAC Modbus* Something went wrong while reading Requête FC04 (command id 6545): <class 'pymodbus.exceptions.ConnectionException'>  = Modbus Error: [Connection] Connection lost during request. Traceback: <traceback object at 0x7fc2718ba0c0>

J’ai essayé de décocher l’option « garder la connexion ouverte », plus rien ne fonctionne.
Je transmets le log complet : mymodbus(1).txt (1020,2 Ko)

Sans doute s’agit-il de 2 équipements en liaison série ? Chaque équipement fonctionne seul, mais pas les 2 activés en même temps ?
→ C’est dans ma todo liste.

En attendant, il faut mettre toutes les commandes dans un seul équipement (à ne pas afficher) et utiliser 2 équipements virtuels pour chaque appareil.

edit : je n’ai pas regardé le contenu du fichier log. Il y a plus de 12000 lignes de log, je ne sais pas quoi chercher ni où. Une indication sur quand est fait quoi serait utile pour la prochaine fois. :wink:

Effectivement, il s’agit de deux équipements sur la liaison série (fonctionnement standard de mobdbus, d’ailleurs).
D’après le fichier log, il semble qu’effectivement, les deux équipements cherchent à accéder simultanément au port USB, cf "multiple access on port?".
Je vais donc attendre l’évolution du plugin, lire les changelog et tout regrouper dans un seul équipement.
Merci.

Bonjour,

J’ai testé aujourd’hui, avec toutes les commandes dans un seul équipement, ça ne se passe pas bien.

Visiblement, la communication vers le port USB se coupe, le démon ne semble pas apprécier deux adresses esclaves différentes.
J’ai ce type de message :

3423|[2024-02-15 17:48:04] DEBUG : Client disconnected from modbus server: trying to send
3424|[2024-02-15 17:48:04] DEBUG : Getting transaction 10
3425|[2024-02-15 17:48:04] ERROR : PyModbusClient: PAC Modbus Something went wrong while reading Requête FC04 (command id 6545): <class ‹ TimeoutError ›> = . Traceback: <traceback object at 0x7faf87f1ab80>
3426|[2024-02-15 17:48:04] INFO : Serial lost connection.

Est-ce qu’il ne serait pas plus simple d’utiliser une passerelle RS485->Ethernet ?
Merci

Bonjour,

C’est effectivement une option.

D’autre part, j’ai pu constater que le polling court et le fait de garder la connexion ouverte étaient souvent liés à un disfonctionnement.
Je ne sais pas à quoi c’est dû.

Peut-être que le passage prochain à la dernière version du module pymodbus arrangera cet état de fait.

A+
Michel