Trouver des équipements Modbus adéquats

Bonjour,

Dans le cadre d’une rénovation complète je souhaiterais passer en Modbus-RS485, j’ai vu qu’il y a un greffon Jeedom adéquat pour cela, ainsi que quantité de clés, passerelles, relais, pilotes d’entrées/sorties analogiques ou numériques gérables ainsi ; en revanche j’ai le plus grand mal à identifier des équipements terminaux (par exemple des capteurs ou des vannes de radiateurs), qui semblent standards, fiables et intégrables facilement dans un contexte de domotique résidentielle.

Par exemple dans les mondes sans-fil genre Enocean ou Z-Wave, on trouve facilement des « multi-capteurs » (ex : thermo, hygro, lumière) sur étagère, leur esthétique est acceptable dans une maison, ils ne sont pas chers, et sont standards.

Comment peut-on faire dans le monde Modbus pour disposer d’équipements équivalents ?

Merci d’avance pour tout conseil !

Olivier

Salut,

Alors tout d’abord je n’y connais strictement rien en modbus :sweat_smile:

Tout ce que je voulais dire c’est que justement la force d’un outil tel que jeedom c’est que c’est totalement multi protocoles : dans l’absolu tu pourrais très bien avoir un capteur de température zigbee et agir sur une vanne thermostatique modbus.

Il y a des cas ou c’est plus simple que de trouver pile poil ce que tu veux dans le protocole que tu utilises le plus

Bonjour

Le protocole Modbus RS485 est un vieux protocole des années 80. Voir modbus.org
Aujourd’hui il est préférable d’utiliser le modbus sur IP.

L’avantage du Modus RS485 est de pouvoir connecter 32 esclaves sur un câble téléphonique sur des distances supérieures à 1000 mètres.
Ses inconvénients sont une communication half duplex, vitesse de communication lente, les esclaves ne peuvent pas communiquer entre eux. Il y a un maitre et des esclaves. Le câblage doit être soigné et le blindage du câble doit être relié à la terre. Les esclaves sont câblés en série, le câblage en étoile n’est pas recommandé.

Le domaine de prédilection du modbus dans le bâtiment est l’électricité: relevé de compteurs, automates, onduleur, etc… Mais il peut être utilisé aussi en CVC sur des climatiseurs.

Son paramétrage est assez lourd, il faut étudier en premier sur ce que l’on appelle la table Modbus de l’équipement. Il faut être à l’aise avec les différents type de mots 16, 32, 64 bits, virgule flottante. Des pièges existent comme l’inversion des mots. Je ne le conseille pas pour un débutant.

Son application en domotique est plutôt restreinte, VMC, automate, comptage. Ce sont des équipements coûteux.

Dans le cadre d’une rénovation complète d’une habitation il est préférable de créer un réseau IP, un switch centralisé avec des câbles qui partent en étoile sur une distance inférieure à 100 mètres. Ce réseau pourra vous servir pour le multimédia, internet et la domotique. Si vous avez des dépendances vous pouvez tirer une fibre.

Concernant les capteurs, les plus utilisés sont en protocole Zigbee. Le wifi peut être utilisé mais il faut limiter le nombre d’équipements au risque de saturer le réseau. il n’est pas rare de dépasser la centaine de capteurs.
Après vous pouvez vous diriger sur des protocoles spécifiques à la domotique comme le KNX.

En cas de revente de votre habitation, la personne qui se retrouve avec une installation en modbus RS485 sera complètement perdue, les automaticiens pour les particuliers ne courent pas les rues.

Bonjour,

Un vieux protocole ne signifie pas qu’il est obsolète.

TCP a été développé en 1973 puis adopté pour Arpanet en 1983, remplaçant NCP (RFC 801).

Source : Transmission Control Protocol (TCP) — Wikipédia
TCP est donc 9 ans plus vieux que Modbus qui a été développé en 1979.


A vrai dire on peut adresser 247 appareils sur un bus Modbus.


Rien que chez moi :

  • onduleur
  • chaudière
  • VMC
  • PAC piscine
  • automate

C’est pas très « restreint ».


Une fois qu’on a compris le truc, il n’y a plus de difficulté, c’est comme tout.

Alors oui, mais pas pour la domotique, selon moi. Uniquement pour la mise en réseau.
Des protocoles tels que KNX sont plus indiqués (mais sans doute un peu plus coûteux) que de tout faire sur un réseau IP. Ou alors il faut bien définir les séparations physiques et logiques (VLAN). KNX fonctionne sur IP également. Tout comme Modbus.


:+1:


Par contre je déconseille de tout passer en Modbus série, c’est vrai que ce n’est pas au goût du jour. Tant qu’à utiliser un bus, je conseillerais plutôt le KNX. C’est robuste, fiable, on est assez libre de l’installer comme on veut (on peut partir avec une arborescence comme ça nous arrange, il faut juste ne pas depasser les 100m entre l’alimentation et un appareil), c’est répendu. Par contre c’est cher… on ne peut pas tout avoir.
KNX fonctionne sur bus et en IP. En filaire et sans fil.

A+
Michel

Je n’est pas dit cela, je l’ai utilisé pendant plus de 30 ans.

Pas sur le même câble en direct voir spécification du RS485.

Concernant le paramétrage, tu es un expert Michel, tu as même créé un plugin sur le modbus.

En effet, électriquement il est recommandé d’utiliser un répéteur par groupe de 32 appareils sur une même ligne, mais 247 équipements sont adressables sur le même bus.

Analogie maladroite avec IP filaire : sur un même réseau dont le masque est 255.255.255.0, 254 appareils sont adressables, mais il est conseillé d’utiliser plusieurs switch pour connecter tout ce beau monde.

1 « J'aime »

Merci pour vos réponses ; j’ai dit RS485 mais j’aurais mieux fait en effet de mentionner plutôt Modbus en général.
C’est vrai qu’être multi-protocoles est une option, mais je préfère les minimiser quand même, cela me paraît plus simple, robuste et satisfaisant.
Je préfère nettement les solutions filaires ; Enocean m’avait bien plu, mais j’ai envie d’une plus grande fiabilité, et le filaire cadre avec une rénovation importante.
Je ne connais pas KNX mais je n’en ai pas une très bonne image (ancien, propriétaire, cher), j’ai l’impression que Modbus est plus ouvert, et avec tout type de prix (ex : les équipements Waveshare me semblent séduisants) ; me pencher sur des spécs (si les paramétrages sont disponibles) et des sujets plus informatiques me va. Pour la revente, tant pis.
En revanche, à part piloter des « gros appareils » comme des VMC ou des chaudières, si trouver des multi-capteurs est difficile avec Modbus, je peine un peu à voir quels usages lui restent : les détecteurs d’ouverture se font sur paire torsadée, les relais peuvent être pilotés par Modbus mais juste après se font par commande directe depuis le tableau… Pourtant des capteurs pourraient bien envoyer leurs données sur le bus…
Bon, merci pour vos conseils, je commence par regarder au moins un peu KNX aussi.

A vrai dire je m’attendais à trouver (peut-être l’ai-je loupée) une liste des équipements supportés via Jeedom, préférablement classable par protocole (ex : Modbus), avec pour chaque entrée de cette liste le nom du fabricant, celui du modèle précis d’équipement, et son niveau de support par Jeedom. Alors les utilisateurs auraient pu trouver des offres (avec des prix transparents) dans les magasins de domotique concernant les équipements de leur choix, en ayant l’assurance de bâtir un système fonctionnel simplement et sans surprise. J’ai l’impression qu’on est un peu loin de cette vision idéale !

Comme de plugins proposent d’apporter la compatibilité à un protocole à Jeedom, tous les appareils utilisant ce protocole sont utilisables. Il y aura peut-être une liste d’appareils non compatibles ou dont certaines fonctions spéciales ne sont pas implémentées, mais faire et maintenir la liste des appareils compatibles est une tâches trop ardue.

Tel que je le comprends un greffon (ici Modbus) est nécessaire pour autoriser de manière générique l’utilisation d’un protocole, mais il reste encore expliquer à Jeedom comment, sur la base de ce protocole, décoder la façon toute spécifique qu’un appareil (ici Modbus) a de communiquer (la « carte » de quelles données lire/écrire, selon quel format/type, dans quels coils/registers, tel que choisi arbitrairement par son fabricant), non, à chaque fois avec pas mal de conventions à respecter ? (fréquence, bit de parité, etc.)

Pourtant, pour un équipement donné, dès lors qu’au moins une personne aura fait ce travail d’application/traduction des spécifications, il suffirait d’agréger dans un tableau (ici pour Modbus) ces informations (pour tel modèle de tel constructeur, utiliser telle « carte ») dans un fichier quelconque (selon un format adéquat) pour qu’après les utilisateurs de Jeedom puissent réutiliser/enrichir/améliorer collectivement ces éléments, et définir une fois pour toutes un support parfait et complet.

Je comprends que cela soit une tâche ardue, notamment car il ne semble pas exister un ensemble réduit d’équipement Modbus qui seraient standard de fait, et pour lesquels dès lors les cartes pourraient être facilement disponibles.

Quel dommage : ce serait super si, comme par exemple en ZWave, on disposait de détecteurs multifonctions 6 en 1 proposés en tant que modèle connu d’un constructeur connu, cela aiderait considérablement !

Pour MyModbus il est possible de générer un template de l’équipement et de partager ce template. Si les utilisateurs souhaitent partager leur configuration, c’est avec plaisir que je l’intégrerai dans la bibliothèque intégrée à MyModbus.
Le fait de récupérer automatiquement des informations sur ce qui est utilisé dans un plugin est contraire à la loi (RGPD) et ne peut donc pas être mis en place.

Il y a donc un moyen mais il n’est pas automatique. Il faut que l’utilisateur veuille partager sa configuration. Ça a déjà été fait pour quelques équipements mais pas beaucoup. Je ne peux pas obliger les gens à partager leur travail.

Tout à fait, cela se comprend bien, il faudrait un grand nombre d’utilisateurs pour faire émerger des configurations standard.
Merci pour les réponses de chacun !

1 « J'aime »

Bonjour

Les templates sont une très bonne solution pour gagner du temps et surtout peuvent servir de référence lorsque l’on a des difficultés pour accéder aux valeurs. Par contre les tables modbus peuvent contenir des centaines de paramètres et chacun a des besoins différents.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.