Petit partage d'experience recent avec du gen7, mqtt, zigbee, zwave etc

Bonjour a tous,

Cela fait un moment que je me demande quand ou comment prendre le temps de partager un peu mes dernières réflexions quant ’à Jeedom et ses directions.
D’abord je souhaite faire un point sur mon utilisation et mon profil qui peut etre, ou peut etre pas typique de la communauté d’utilisateurs Jeedom.
D’abord me premiers pas dans la Domo remonte au X10, avec homeseer, et il faut bien le dire, des outils un peu limités en termes d’accessibilité et de fiabilité. J’ai mis tout ça un peu de cote, pour ensuite basculer vers une solution de type semi Cloud. J’ai beaucoup de plaisir à aller chercher au plus loin les capacités des systèmes en question, et vois parfois tout ça comme un puzzle et des énigmes à résoudre.
Lors de l’achat et rénovation de ma maison actuelle, j’en a profité pour tout remettre à plat, et suis tombé sur cette petite solution à l’époque : Jeedom.
Depuis, j’ai essayé d’autre plateformes, mais suis systématiquement revenu sur Jeedom. Et ce pour Deux raison : l’architecture qui offre beaucoup de flexibilité (on peut faire n’importe quoi avec) et son interface qui offre une prise en main simple et rapide.
Je ne suis ni expert ni développeur, mais suis toutefois capable de lire et comprendre un script, les intrications de dépendances etc… Je n’ia pas peur de tester, trafiquer et de prendre le risque de tout casser, car j’ai toujours un backup à portée de main. Et les backups ne m’ont jamais fait défaut : c’est la résilience de Jeedom. Jeedom est pour moi une solution simple à aborder, mais compliquée à maitriser.
L’histoire :
Mon réseau est constitué principalement de Zwave (environ 60 modules) Ainsi que des tablettes que j’ai fait customiser via alibaba, disséminés dans la maison. (env 350M²) avec des design Custom qui fonctionnent tres bien est qui ont beaucoup profité des dernières améliorations.
Il y a quelques mois… Les point que je vais aborder
L’hiver arrive, est je constate que certain de mes Spiritz sont HS (le moteur tourne dans le vide.) Je constate aussi des latences sur le réseau et une fiabilité parfois discutable.
Pour commencer, Je décide de remplacer les Thermostats et je retrouve 1/ des dipsos limitées et des prix prohibitifs. Et quand je cherche une alternative au Spiritz zwave, je me rends a l’évidence : le Zigbee est de plsu en plus prépondérant. En outre, j’ai besoin de mettre un carillon couplé à un doorbird en Zwave. Je tombe bien sur la Sirèn6 d’Aeotec. Misère c’est du gen 7 et c’est le bazar à intégrer. Enfin on peut mais c’est un peu du bidouillage.
C’est ainsi que je challenge toute l’installation : le Zigbee, le Zwave et il s’agira de 2 chantiers simultanés. Au diable l’avarice !
Je découvre le nouveau contrôleur Gen 7 qui est dispo. Alors je fonce, et la …. Ça ne marche pas. Normal, la version OpenZWave ne le prend pas en charge. Et c’est à ce moment que je me rends compte que le chantier de l’EPR à cote, ce n’est rien en termes de sous-estimation de travail…
Je me lance donc dans la recherche de solution, en espérant que la nouvel génération 7 de Zwave saure résoudre certains de mes soucis de latence… Spoiler, ça n’a rien changé à ce niveau-là.
A ce jour, y’a pas a tortiller, si tu veux de last gen, la seule façon d’y arriver c’est de faire du Zwave JS, a la place de d’Open -Zwave que ce soit d’ailleurs 1.4 ou 1.6…
Et en suivant Alice dans son terrier, je découvre ZwaveJS2MQTT (prérequis), qui passe par un broker MQTT, et qui ensuite s’interface avec un JMQTT( plugin Jeedom au passage qui fonctionne vraiment bien – sauf pour les icones a l’heure ou j’écris ces lignes.)
En realité, cette approche est pas si mal pour la raison suivante :
Il faut voir Jeedom comme une fondation sur laquelle vont venir s’intercaler des briques. L’engine Jeedom va s’appuyer sur nombre de briques (ou plugins) qui auront chacun leur rôle. Toutefois, le ciment entre les briques(plugins) Jeedom est Jeedom est spécial. En gros la brique tu mets, elle est faite pour Jeedom, est c’est parfois la seule brique qui existe (cf open zwave.) Or la brique en question, mais c’est un dev tout aussi important si ce n’est plus que la partie fondation. Et c’est la le premier reproche que je ferais a Jeedom. Leur savoir-faire et leur qualité est dans le développement de l’engine… Ils ne font pas du développement de protocoles. Tout au plus, ils l’intègrent, est ca c’est juste trop de taf, tu cours toujours derrière un truc dont on ne maitrise pas le développement et du coup c’est jamais a jour. C’est comme une voiture, qui devrait s’adapter a des roues qui changent de formes de tailles etc… sans arrêt. Là-dessus, ils ne sont pas bons. L’avantage d’une couche intermédiaire, comme JMQTT, c’est de pouvoir s’appuyer sur un broker (qui va servir de passerelle universelle) est de pouvoir y connecter se que l’on veut derrière. Et la c’est magique car… on peut du coup séparer les composant, est les faire évoluer séparément. Et même les faire tourner sur des machines distinctes. Aujourd’hui, j’ai du coup un Jeedom sur un docker, un mqtt sur un autre docker, et un zwaveJS2 mqtt sur un PI3, avec sa clé en gen7, que je peux positionnée au je veux dans la maison câblée en ETH. (faite pas ca avec du wifi hein !?)
Du coup j’ai pu intégrer sans problème ma siren6 sur un Gen7, avec tout ce qui va bien, et en plus en secu S2. Du coté » de Jeedom ? rien a changer…… Et si je voulais mettrre du ozwave1.6… facile, il suffir de lancer zwave2mqtt1.6 est ca marche tout aussi bien (avec les limites de l’ozwave qu’on lui connait auj.)
L’autre avantage, c’est que j’ai pu sereinement envisager l’ajout du zigbee. Avec une Zigbee2mqtt. J’utilise le même broker MQTT évoqué précédemment, et enfin, zigbeelinker qui marche lui aussi tres bien. Et si je dois redémarrer un truc, je ne redémarre que ce truc. Et rien d’autre.
La réalité, c’est que l’histoire nous tout simplement que les protocoles évoluent, celui qui avance aujourd’hui ne sera pas celui de demain. Que leur version évolue aussi, leur distribution etc… et que s’enfermer structurellement dans un protocole alors que ce n’est pas leur cœur de métier, est a mon sens un erreur stratégique. Il faut que Jeedom se pérennise and permettant aux utilisateurs de choisir à tort ou a raison leur protocole de prédilection.
Du coup, pour ceux qui ont suivi tout ce pâté :
Jeedom est à ce jour la meilleure solution (pour moi) mais souffre de 3 défaut majeur.
• L’intégration native de module de communication dont la techno n’est pas maitrisée et qui ne va pas forcement dans le sens de l’histoire.
• Ne pas avoir réussi à ce jour de véritablement internationaliser la solution, et de pouvoir ainsi s’appuyer sur une communauté de dev globale (la ou Hass est tres fort.)
• Le hardware, même s’il augment l’adoption de la solution en abordant de nouveaux utilisateurs potentiels, ne me semble pas etre un élément clé dans le cœur de Jeedom.
Quelques retours sur les dernières technos et choix :
Siren6 est superbe. Marche tres bien.
Gen7 fonctionne bien et vite, mais je regrette qu’il n’y a plus la batterie et le bouton d’inclusion/exclusion, tres pratique pour réintégrer des modules dans les plâtres.
Mes ralentissements, qui sont devenu plus facile a identifier sur zwaveJS mon permit de voir que des modules se mettaient parfois a vomir toute les datas qu’ils pouvaient et inonder le réseaux. Genre 60 fois en l’espace de 2 sec, la même valeur remontée. J’ai l’impression que les modules qubinos étaient souvent la source du vomi. J’ai remplacé les Qubinon par des fibaros, ou des zigbee dans certains cas.
Le zigbee parlons en rapidement :
Contrairement a Zwave, le zigbee c’est du 2.4 ghz. En plein sur les fréquences Wifi. Et ça, ça pue. Car j’ai une belle installation Ubiquity, avec 5 accès point qui balancent un signal au plus fort.
I’l m’a fallu, basculer tout le réseau Wifi en Channel 1 pour le 2.4ghz et en low power. Et le zigbee en 25. Mais si vous avez des voisins qui saturent la fréquence du zigbee, ça peut poser des problèmes si le maillage n’est pas assez dense.
J’ai commencé avec une clé deconz…. Et je n’ai pas une tres bonne expérience… Le positionnement de la clé est critique. Sinon ça ne cause pas. Des soucis avec les Hues, des RQI qui ne remontent pas correctement etc… bref je l’ai échangé pour une Zigstar qui balance du 20db d’atténuation. Et là, ça passe beaucoup mieux…. Il faut toutefois noter que la réactivité du zigbee est impressionnante. Par contre, il faut du zigbee 3.0 est ça ce n’est pas toujours explicite sur les produits.
Le prix du zigbee aussi est beaucoup moins cher.
Voilà quelques impressions et retours d’expérience. Il y a beaucoup d’autre choses à dire, mais l’essentiel est là. Si je devais passer un message à l’équipe Jeedom, c’est vraiment un gros bravo, et merci pour toutes ces évolutions qui en font un beau produit (même s’ils sont un peu ronchons parfois).

12 « J'aime »

Merci pour cette analyse fouillée et pertinente je trouve. Je pense la même chose.
Je tourne autour de la bascule de ozw vers mqttt.

1 « J'aime »

Belle anayse.
Une question qui reste ( du moins je crois) sans réponse à ce jour. Ou en est l’équipe de jeedom sur la mise à jour de openzwave vers une éventuelle 1.6 et/où sur le passage à la gen 7 et zwaveJs.
Je crois avoir compris à travers mes lectures que le passage en 1.6 obligerait à refaire certaines des inclusions matériel… Et la gen7 elle à tout reinclure.
Une ligne directrice serait la bienvenue. Un délai encore mieux

4 « J'aime »

Bonjour,

Merci pour ce retour très intéressant ça confirme certain axe de réflexion que j’ai en ce moment.

3 « J'aime »

Je pense que c’est la toute la Question : Il y a 2 approches

  • Soit tu attends que Jeedom rattrape le train pour intégrer un truc dont il ne sont pas dépositaires
  • Soit tu normalise la couche entre ton Jeedom et ton stack Zwave zigbee ou n’importe quoi d’autre… mais c’est plus compliqué a entreprendre.

Sur la premier option, je n’y crois pas, sachant que de facto, il y aura toujours un train de retard, et qu’en plus sincèrement, Je pense qu’ Open Zwave 1.6 (écrit en C+) est en train de mourir au profit de zwaveJS (écrit en … JS !! qui est un langage aujourd’hui plus couramment maitrisé par la communauté). Et la c’est le dilemme. quelle position doit prendre l’équipe JD ? Maintenir ce qui fonctionne ? upgrader ce qui fonctionne avec quelques risque de plantage et de support - sans pérennité? Changer de stratégie pour une approche plus « inclusive » ( qui existe deja plus ou moins a travers mon expérience) mais au risque de dire a tt le monde… "hé les gars, le truc que vous avez fait est totalement obsolète et on va vers une autre direction, mais faut tout refaire… glhf. ) C’est une décision difficile… et franchement je ne leur jette pas la pierre.
CE que je tiens a faire remarquer, c’est le bignou au debut a été suffisemment bien developper pour que ces options existent et ca c’est fort. A chacun de prendre son chemin tout en conservant toutce que fait le benefice de Jeedom.

petit NB 1 : Il y a beaucoup d’extrapolation dans mes reflexion et elles n’engagent que moi. Surout quand je mets a la place de l’equipe.
NB 2 : a voir le dev de openzwave, OpenZWave · GitHub on peut voir que l’ECG est en quasi mort cerebrale. et ca c’est pas bon signecomparé a la version JS Z-Wave JS · GitHub

1 « J'aime »

Salut,

En ce qui concerne les trucs2mqtt, depuis quelques temps, je vais plus loin en privilégiant les modules intégrant nativement le protocole MQTT comme les shelly ou ce type de cartes :

1 « J'aime »

Bonjour,

Merci pour le partage de l’analyse.
On voit en effet que MQTT prend une ampleur importante en domotique…cela l’était depuis un moment pour tout l’IOT/OT

Si je ne dis pas de betise (je regarde de très loin), HA semble prendre le partie de passer pas mal de chose par MQTT. Ainsi il est plus simple de collecter/transmettre de l’information de façon standardisée.
Peut-être que Jeedom devrait étudier cette trajectoire…Je pense que cela simplifierais des choses et donc leur ferais gagner du temps.

Oui, et le plugin-jmqtt va devenir incontournable.

Il serait préférable pour la pleine démocratisation du MQTT que ce soit des plugins type ZigbeeLinker plutôt que jMQTT où il y a une masse de travail et de connaissance à avoir qui n’est pas à la porté de tous.
Le travail sur le plugin jMQTT est remarquable mais peu accessible pour ceux qui n’y connaisse rien ou presque. un peu comme android et iOS en fait au début 2 très bons produits mais pour des publics différents

Ou alors que la base de templates dans jMQTT se développe de façon plus importante.

Antoine

Salut,

Merci de ton retour…
J’ai une grosse config zwave (80 modules dont 60 elec et 20 sur batteries en non sécurisés) avec la gen5 sur une VM promox i7 et ssd et j’en ai plus que marre du très vieux plugin zwave…impossible d’avoir une fiabilité

J’attends de passer en zwaveJS2 mqtt , mais je constate que ce n’est pas exempt de ralentissement en cas de module « bavard »…pourtant ça devrait être géré avec le zwave officiel, j’imagine ?

merci pour l’info sur le zigbee, j’ai déjà pas mal de modules en wifi aussi, donc c’est pas un bon choix…

1 « J'aime »

:+1: et si tout le matériel pouvait communiquer nativement en MQTT, ce serait merveilleux.
On ne serait pas en train de se prendre la tête à faire des interfaces trucs2mqtt.

C’est limite si le plugin jmqtt ne devrait pas être intégré au core de Jeedom.

4 « J'aime »

En fait jMQTT a évolué récemment pour permettre à des développeurs tiers de d’interfacer avec jMQTT pour simplifier l’interaction Mqtt.

Ainsi on peut imaginer un plugin Zwave en satelitte de jMQTT pour faire le même principe que le très bon ZigbeeLinker

6 « J'aime »

En fait, j’ai trouvé l’approche de zigbeelinker tres interessante car elle presente la possibilité de dépoyer le mode client, ou le client + MQTT, ou le client et/ou Mosquitto, et ou le zigbee2 mqtt. Du coup, meme s’il s’agit d’installer 3 boudins séparer, ca ce fait dans un approche « plug and play », ideal pour ceux qui ne savent pas trope dans quoi ils mettent les pieds. Au fond c’est un peu ce que fait deja le plugin Ozave avec une couche en moins, et de façon plus discrète. Ce qui est formidable c’est que l’archi de Jeedom permette de faire ce genre de choses.
@ [Domatizer] MQTT est certainement le truc en vogue auj et tres puissant. Après rien ne dit dans quelle direction ca va aller. I Croisons les doigts pour que ca dure… Toutefois, il faut toujours garder une strategie de sortie. Au moins c’est pas une solution cloud
Enfin, c’est peut etre une question de terminologie, mais ce n’est pas le matos qui parle en MQTT. le zwave parle toujours en Zwave, le zigbee en zigbee etc… il y juste une couche intermediaire d’interpretation qui permet de « traduire » les commandes zigbee en commande d’ailleurs "en l’occurance, jeedom. Le mqtt c’est un peu la boule de remorquage. Tu peux la mettre sur une moto, une voiture, un camion etc… et apres tu choisi la remorque qui va bien. la boule fera le pivot entre le jeedom et ton protocole. Et du coup changer la remorque n’oblige pas a changer la voiture, et vice versa.

@ Doryphore ZwavJS est le support zwave le plus abouti a ce jour, et d’ailleurs le suel qui porte veritablement la certification Zwave puisqu’il suit le cahier des charges. Il est le seul a gérer le Gen7 et le S2. Du coup, y’a pas grand de plus officiel que ca. Apres ca reste une approche opensource et donc sujet a des contributions. En ce qui concerne le module bavard, je pense qu’i faut l’identifier et le remplacer. Le cahier des charge requière une comptabilité pour les version précédente… du coup, si tu as un module « idiot » il le sera toujours et a moins d’avoir une génération incompatible, il viendra toujours pourrir ton réseau.
Pour le Wifi vs zigbee… c’est clair que le 2.4ghz a ses défaut. il est moins « pénétrant » dans les murs, et fait la course contre le Wifi. du coup il faut les rapprocher. Je ne passe pas les murs de pierre chez moi. mais c’était deja vrai avec les philips hue. Mais la clé du zigbee c’est d’atteindre la taille critique du nombre de module routeurs. Il sont d’ailleurs essentiels pour autoriser des réseaux de grande tailles. L’avantage c’est que ca consomme a priori moins; c’est moins cher, et possiblement plus rapide. Le choix de la clé est essentiel, et l’intégration des modules est un régale comparé au zwave. A voir sur le long terme.

Pour les templates JMQTT, j’utilise MQTT explorer qui fonctionne tres bien, et me permet de faire me propres commande a la demande, et de les organiser comme je le veux. Je n’ai pas senti un vrai besoin la, mais ca c’est moi.C’est vrai qu’il faut un peu plnger dans le Json.
Le vrai prérequis critique c’est que zwaveJS reconnaissent les modules zwave de la même façon que le plugin openzwave doit toujours etre maintenu en famille pour reconnaitre les modules. Mais vu le nombre d’utilisateur de zwJS, ca ne traine jamais tres longtemps.

5 « J'aime »

Je n’ai pas de zwave ( pas le budget et j’aime bien rester sur le filaire) mais acquiesce sur l’idée d’intégrer mqtt à Jeedom.
Je suis passé à MQTT pour gérer mon alarme (une centrale d’une boite asiatique achetée il y a 25 ans: Comfort Home Automation Overview).
J’ai ajouté un module soft de vidéo surveillance :BlueIris qui fonctionne sur une VM windows.
Ce module intègre aussi MQTT et permet donc interactions avec Jeedom. Comme la détection par caméras est trop sensible aux bestioles volantes,au soleil… je compte déclencher mes enregistrements vidéo par une cde mQTT envoyé par jeedom ou mon alarme « Cytech ». Ca fonctionne mais reste à mettre en place le tout( la domotique, quel bouffe temps)