Mymodbus quoi de neuf?

Bonsoir @tous ,

Cela fait un moment que je n’ai pas trouvé le temps de travailler sur le #plugin-mymodbus , la raison principale est que je suis en plein travaux d’agrandissement ( travaux que je réalise seul ) et c’est long :upside_down_face:.

J’ai été sollicité à plusieurs reprises pour ajouter des fonctions , et aussi finaliser la beta afin de la sortir en stable .

Ne pouvant consacrer du temps au plugin , j’ai accepté de me faire aider par un Jeedomien !

C’est @Michel_F qui va m’aider à enrichir & améliorer le code du plugin , je le remercie pour son aide :clap:.

Pour commencer :

Nous avons besoin de définir les priorités et donc établir une todo list .
Nous souhaitons dans un premier temps, consulter les utilisateurs du plugin afin de connaitre vos points bloquants , vos idées d’améliorations, le matériel que vous utilisez , les choses qui fonctionnent bien et qu’il faut absolument garder .

Nous attendons vos commentaires
ps si vous avez une machine de test et un équipement Modbus , n’hésitez pas à vous signaler en bêta testeur .

@ bientot

3 « J'aime »

Bonjour tout le monde,

je confirme ce que @Bebel27 vient d’annoncer, je l’aide à maintenir le plugin à jour en y mettant un grand coup de neuf :

  • utilisation de la dernière version du module de communication modbus pyModbus,
  • gestion du démon de communication comme il se doit dans Jeedom.

N’hésitez pas à lister vos doléances ici, avec le plus de détail possible pour m’aider un peu.

Mon but est de faire en sorte que ce plugin soit plus généraliste, avec tous les paramètres possibles pour pouvoir presque tout faire de ce que pyModbus permet de faire.
Je peux d’ores et déjà vous rassurer sur le fait que les fonctionnalités existantes seront reprises, sous une forme différente, mais seront bien là.

J’ai déjà commencé à reprogrammer tout ça mais n’ai pas encore une version fonctionnelle. Je programme en parallèle de ce post et rajouterai les fonctionnalités demandées, si elles sont validées par @Bebel27.
Si des beta-testeurs se manifestent, ce sera avec plaisir que je recevrai vos retours, le moment venu.

À bientôt,
Michel

Salut @Bebel27,

Content d’avoir des nouvelles et de savoir que tu ne seras plus seul pour faire évoluer le plugin. Merci par avance à @Michel_F.

Je participe à ce post, même si pour moi ça roule depuis des mois et que je n’ai pas de nouveaux besoins.

Bebel avait ajouté un « Eastron Input » pour prendre en compte la particularité de traitement des informations de cet équipement (inversion de mots sur 32 bits si ma mémoire est bonne).

Une grosse évolution serait donc de permettre une adaptation à l’ensemble des équipements sans avoir à développer un nouveau type E/S donc proposer ce que propose ModbusDoctor et ne garder que les 4 types de base :

image

image

Toutefois, pour faciliter la vie de ceux qui découvre le modbus (univers bien particulier), l’implémentation de template serait un gros plus (basée sur ce que vous connaissez déjà puis ensuite par remontée des utilisateurs comme le fait jMQTT.
Template pour Compteur Eastron : paramétrage automatique de Holding Register, Mot 32 bits, Inversion de Mots, etc…

Enfin voilà, je pense que c’est un peu la direction que vous vouliez prendre mais je préfère le dire puisque c’est demandé :grin:

2 « J'aime »

Merci @Bison pour ton retour :slight_smile:

En effet, quand je dis que je souhaite faire de ce plugin quelque chose de plus généraliste, c’est avec l’idée de paramétrer (entre autre) l’Endianess des équipements (Little ou Big endian) sur les mots et double mots. Selon moi, l’Endianess est lié à l’appareil et donc à l’équipement sous Jeedom.
Dans les commandes, on pourra définir le type de variable (int16, uint16, int32, uint32, …).

Tout ceci sera documenté comme il se doit afin de guider les novices sous forme de tutoriel.

Là où je me pose une question (maintenant que j’ai vu ce que permet Modbus Doctor) c’est si la lecture ou l’écriture d’un octet est utile. Les registres Modbus sont des registres de 16 bits en général, il faudrait donc pouvoir dire si c’est le LSB ou le MSB.

Questions ouvertes :

  • Faut-il pouvoir configurer la taille des registres analogiques ? 8, 16 ou 32 bits.
    Selon mon expérience (je suis automaticien depuis près de 25 ans) les registres sont toujours en 16 bits (1 Word) et je n’en vois pas l’utilité, mais c’est imaginable.
  • Quelqu’un a un appareil qui a des registres analogiques de taille différente ?

Sur un automate Wago, par exemple, les registres modbus sont des mots, un Float32 prend donc 2 « cases de registre ». Le Float32 suivant se trouve donc à 2 adresses plus loin.

Pour les non initiés, Float32 est le format d’une valeur en virgule flottante sur 32 bits.

(Si j’écris quelque chose de faux ou de pas tout à fait juste, vous pouvez me corriger sans problème)
Dans cette réponse je parle des registres analogiques et pas des bits (coil).

1 « J'aime »

Bonjour,

J’ai du matériel Modbus à mettre sur ma domotique (onduleur SMA), si je peux aider aussi à une vrai dev, je veux bien en être.
Il ne faudra pas oublier que certain périf, ne supporte pas la lecture registre par registre, mais que du multiregistre.
Comme dis @Bison, déjà avoir les options de ModbusDoctor, après ce n’est que de la conversion.

Petite question, je viens d’installer le Plugin et j’ai ça (je n’ai pas de port com sur le PC…)

@+

Vince

Salut,
comme c’est une refonte complète, je pense que je vais déjà bosser jusqu’à la première version à peu près utilisable « beta ». A partir de là, quand il s’agira de changer des « petits bouts », pourquoi pas, on va s’organiser. Mais pas avant. Step by step.
En tout cas, c’est sympa de proposer ton aide, je te garantis que j’y penserai :slight_smile:

Pour l’erreur, en effet, j’ai eu le même soucis, cette dépendance sera gérée au même titre que pyudev d’ailleurs. Ce sont tous les deux des modules utilisés dans le module python développé par Jeedom.

J’avance doucement, j’ai 90% de l’interface jeedom, je pense. Il manque le php d’appel du démon et le démon en lui même. pour ces 2 là, j’en suis à environ 15%.

Pour la définition des commandes, il m’est apparu qu’il pouvait y avoir une discordance entre la fonction modbus appelée, par exemple « [0x01] Read input coils » et le type de donnée, par exemple int16 (entier sur 16 bit). J’ai donc doublé les boutons de création de commande :

  • nouvelle commande info binaire
  • nouvelle commande info numérique
  • nouvelle commande action binaire
  • nouvelle commande action numérique

Les commandes sont actuellement toutes visibles au même endroit. Je me demandais si c’était la philosophie jeedom de cette manière ou s’il fallait « ranger » les binaires et les numériques dans 2 « onglets » différents ?

D’autre part, existe-t-il un moyen d’invalider la sauvegarde de la configuration d’un plugin en cas de discordance de ce type ?

1 « J'aime »

Salut,

A mon avis c’est pas la config du plugin dont tu parles mais la config de l’équipement => voir méthode pre[Insert|Update|Save] sur l’eqLogic

Pour ce genre de question c’est mieux de poster dans la section dev car ici ta demande va être perdue parmi les autres.

1 « J'aime »

Salut @Mips,

je viens de trouver la réponse ici. Il suffit de lever une exeption pour empècher la sauvegarde. C’est tout juste ce qu’il me faut, si j’ai bien compris.

Et un grand merci à toi pour la documentation sur le dev d’un plugin :+1:

3 « J'aime »

C’est parce que j’ai vu ton « like » que j’ai retrouvé ce post :wink:

et c’est justement pour ca que je disais:

Absolument !

Bonjour à @Michel_F et @Bebel27,

je trouve ca une super idée de s’associé pour maintenir et améliorer le plugin qui pour moi marche du tonnerre.

je me permet juste ce message car j’utilise la partie RTU du plugin du coup en beta et quand il y aura les mise à jours de ne pas me faire peter cette partie. Je m’en sert pour mon chauffage meme si je peux le gerer sans. Cette partie avait été débuguer par @Bebel27 en direct sur mon install.

Bon courage
A bientot

1 « J'aime »

de mon coté si j’installe la dernière version de Pymodbus, le plugin est HS
J’utilise la version BETA. pour la refaire fonctionner il faut réinstaller les dépendances du plugin en 2.5.3

peut être pareil pour vous?

C’est tout à fait normal, la version beta et la version stable sont écrites pour être compatibles avec la version 2.5.3 de pymodbus.
La prochaine mouture de Mymodbus sera compatible avec la dernière version de pymodbus, à savoir 3.1.2 pour le moment.

Bonjour, en ce qui me concerne j’essaie d’utiliser modbus pour communiquer avec un onduleur Huawei SUN2000 et je crois qu’on est quelques uns sur ce forum.

Il m’était impossible de faire communiquer le plugin avec l’appareil au départ, et en cherchant un peu et en bidouillant j’ai reussi a le faire communiquer en rajoutant la commande « time.sleep(1) » après la commande "client.connect()’ a la ligne 86 de mymodbus_demond.py.

     client.connect()
     time.sleep(1)

Me demandez pas pourquoi, mais ca fonctionne avec ca…

@Michel_F pense tu pouvoir intégrer cette commande dans le nouveau code ?

Sans ca j’ai bien peur que ca ne fonctionne de nouveau pas (comme sur le plugin officiel du reste).

Par ailleurs je n’ai aucun soucis pour lire les valeurs int16 et uint16, par contre impossible de lire les valeur int32 et uint32. Ca me plante le demon.

Ca fera parti de la nouvelle mouture ? Ce sont en fait les valeurs les plus utiles ^^

Si t’as besoin d’un beta testeur, je suis volontaire ^^, du moins pour le seul appareil que je possède.

1 « J'aime »

Bonsoir,

Merci @agadoc pour ton retour, on va surveiller ce point.

Histoire de donner des nouvelles et répondre aux questions, voici des captures de ce que j’ai pour le moment :
Page du plugin :

Configuration d’un équipement TCP :

Configuration des commandes :

Il y a d’autres choses qui fonctionnent, mais je suis en plein milieu d’un truc et j’ai pas envie de commenter du code juste pour des captures. Ca viendra.

En tout cas, on voit les différents types de commande :

  • info binaire
  • info numérique
  • action binaire
  • action numérique

Les fonctions utilisées sont décrites comme dans le protocol modbus, sont prévus :

  • [0x01] Read coils (Binaire / bit)
  • [0x02] Read discrete inputs (Binaire / bit)
  • [0x03] Read holding registers (Numérique)
  • [0x04] Read input registers (Numérique)
  • [0x05] Write single coil (Binaire / bit)
  • [0x0F] Write coils (Binaire / bit)
  • [0x06] Write register (Numérique)
  • [0x10] Write registers (Numérique)

Les commandes avec la remarque (Binaire / bit) ne sont prévues que pour des bits et des bits inversés. Sinon, on voit la liste des types de variable possible.

Pour la première mouture, on va y aller comme ça, ensuite on avisera.

Démon en cours d’écriture…

A+
Michel

1 « J'aime »

Merci @Michel_F de la prise en considération ^^
Je pense qu’il est vraiment important de tenir compte dans le code du fait de laisser le temps aux appareils de répondre.

Sur mon appareil, les 2 plugins modbus avaient le même symptôme, en lisant de plus près le topic sur " [TUTO] - Domotiser une chaudière De Dietrich type DGT130 avec le plugin MyModbus - #52 par gialla)", on se rend compte que c’est plus ou moins la même chose (mais réglé de manière différente).

Si tu peux améliorer d’entrée de jeu la stabilité du plugin en tenant compte de ca, je pense que ca serait top ^^

Bonjour, suite à mon échange avec @Michel_F sur un autre groupe, je confirme que je suis disponible si nécessaire pour faire un test de votre nouvelle version, dans mon cas pour l’interfaçage avec des onduleurs Solaredge (que je commence seulement à utiliser via modbus … utilisation de l’API jusqu’à présent).

1 « J'aime »

@Michel_F , merci beaucoup à toi pour ton implication !
De mon coté, j’ai des soucis avec le plugin dans sa version actuelle, car il ne propose pas la gestion complète des différents types numériques, en particulier signé et non signé.

J’attends avec impatience la premiere version de ton travail, et je serai ravi d’expérimenter et de faire un retour d’expérience concernant la commande de ma chaudière Okofen via Modbus !

Un message a été scindé en un nouveau sujet : Nom sur le dashbord