Dilemme zigbee, bon ou mauvais choix ... l'avenir me le dira

Bonjour,

Jusqu’à début de semaine mon installation tournait comme ceci :

  • Pont Hue + Plugin-Hue pour tout le philips (± 32 ampoules alimentées en permanence et 12 Dimmers switchs)
  • 3 Gateway Xiaomi + plugin-Xiaomi (± 30 périphériques, mini Switch, présence, sondes de T° et capteurs porte/fenêtre)
  • Du zwave pour tout le reste avec ± 30 nœuds en tous genres.
  • Un peu de RFXcom qui traine encore, principalement sur une dizaine de sondes Oregon qui seront a terme remplacées par des capteurs Aquara.
  • Du yeelight (une dizaines de Strip LED)

En fin de semaine dernière j’ai eu la super idée … ou pas, d’uniformiser la partie Zigbee pour plusieurs raisons :

  • Ne plus avoir qu’un seul réseau Zigbee qui serait correctement maillé grâce aux 32 ampoules Hue qui couvrent toute la surface.
  • Supprimer les 3 gateway Xiaomi et donc pouvoir gérer tous les périphériques Aquara en direct sans plus devoir bricoler via les gateways ( passage en mode dev par exemple rendu moins accessible au fil des updates de l’application Mi Home).
  • Pouvoir continuer à faire évoluer à l’avenir mon installation avec tous types de devices zigbee qui ne seront jamais supportés ni par le pont Philips, ni par les Gateway Xiaomi sans devoir encore ajouter un nième réseau Zigbee. C’est pour moi évident qu’il vaut mieux un seul et bon réseaux Zigbee bien maillé qu’une multitude de réseaux qui se marchent dessus.

J’avais un critère qui était de pouvoir continuer à manager les scènes Hue, les groupes d’ampoules et les dimmers switch hors jeedom, car c’est bien plus simple et convivial à faire via une app Hue que sous jeedom, Et aussi j’ai plusieurs groupes d’ampoules qui doivent restées groupées au niveau Zigbee et il était hors de question de les grouper à l’aide de scénarios jeedom ou de virtuels.

Ce critère m’a donc forcément orienté vers la solution deCONZ pour profiter de l’émulation du pont Hue.

J’aurais évidement préféré conserver le vrai pont Hue pour des raisons de stabilité et d’indépendance des éclairages mais la volonté d’avoir un réseau Zigbee unique incluant des périphériques non supportés par Philips comme les Aquara entre autre m’en empêche.
Et je veux aussi surtout profiter des 30 ampoules pour le maillage sans devoir ajouter encore des prises Ikea Tradfri dans tous les coins par exemple pour faire du routage car pour tout ce qui est prises pilotées je suis et veux rester en zwave avec du fibaro.
Les ampoules sont là, déjà alimentées en permanence et elle font un super boulot de routage pour tous les périphériques sur batterie donc ça serait dommage de ne pas les mettre à profit pour la globalité du réseau Zigbee.

Deuxième critère, la clé Zigbee doit être branchée au plus simple, donc en direct sur Jeedom, pas question de mettre ça sur une passerelle déportée sur base de PI ou autre dans un coin et de devoir manager et assurer la maintenance et le backup d’un équipement supplémentaire.
En effet mon Jeedom tourne en VM Esxi sur du hardware performant et de classe professionnelle dans une baie informatique, avec backups journaliers, UPS et compagnie … ce qui me donne une stabilité et une sécurité quasi à toutes épreuves.

Ce critère m’a donc guidé au final sur une instance deCONZ en local sur Jeedom via le plugin officiel et pas un deCONZ déporté sur un nième périphérique.

Donc après avoir passé quelques nuits à découvrir deCONZ et son plugin et à tout migrer, le pont hue est maintenant éteint, les Gateway Xiaomi sont débranchées, mon réseau Zigbee est unifié et tout ou presque remarche exactement comme avant avec presque aucun compromis. Il me reste quelques détails à régler comme l’interconnexion Harmony/Hue entre autre mais pour le reste tout tourne.

J’ai évidement du mettre les mains dans le cambouis plus d’une fois pour ajouter ou modifier des types d’équipement qui étaient mal définis ou comportaient des commandes manquantes dans les json de définition des types du plugin deCONZ, et ajouter aussi quelques visuels pour que ma page équipement du plugin ressemble à quelque chose.

Malgré tout ça plusieurs trucs me dérangent encore :

  • L’évolution du plugin officiel deCONZ quasi au point mort avec le non support des groupes d’ampoules par exemple dans sa version stable et ce depuis des mois, pas d’autre choix que de passer sur la beta pour voir les groupes apparaitre.
  • Le support d’équipements récents dans Phoscon semble relativement lent comme le nouveau Dimmer Switch Hue de 2021 sorti il y a des mois et qui n’est encore accessible que via la Beta de Phoscon et malgré ça assez mal supporté en plus.
  • Pour lancer le GUI deCONZ afin de pouvoir manager et monitorer en détail le réseau Zigbee il faut désactiver le plugin jeedom car le GUI est une instance deCONZ à part entière et évidement c’est incompatible avec l’instance service qui s’exécuterait en parallèle. Dommage qu’ils n’ont pas fait un GUI ou un frontend permettant aussi de manager en détail l’instance du service.

Donc je suis en beta avec le plugin et en beta avec deCONZ et pour un bout de temps vu la relative lenteur d’évolution et ça ne me plait vraiment pas.

De plus maintenant que tout est en route je constate ce matin pendant que je rédige ce post que ± toutes les heures le daemon deCONZ se plante ou en tous cas Jeedom juge qu’il doit le relancer et il n’y arrive en général pas du premier coup … je suis en plein investigation dans les différents logs pour essayer d’en trouver la cause (et si ça tombe c’est les versions beta …), c’est particulièrement gênant vu que du coup pendant ce temps tout le réseau Zigbee est évidement 6 pieds sous terre …

Tout ça pour au final m’interroger maintenant si l’idée était vraiment bonne …
Et si j’aurais pas mieux fait de choisir le plugin officiel Zigbee qui semble plus suivi, que j’ai acheté aussi (Il est en promo en plus) mais pas utilisé vu que je perdais les fonctionnalités d’émulation de pont Hue offertes par deCONZ que j’estime pour l’instant indispensable à mon usage pour la partie éclairage en tous cas …

Et j’ai pour le moment pas trop envie non plus de tout remettre par terre et de repasser quelques nuits à reswitcher sur une alternative …

Donc je vais maintenant passer quelques heures à essayer d’identifier la cause du plantage de mon daemon deCONZ et continuer à me morfondre sur mes peut-être mauvais choix …

Wait and see …

Alors je ne peux pas te dire pour tes problemes, mais pour

Deconz est une application de management zigbee, c’est une grosse application qui ne fonctionne que sous environnement desktop. La partie utilisée par jeedom n’est qu’on plugin, et le fonctionnement en headless n’est qu’un rajout, Sur HA par exemple ils ont accès a la version complète de deconz via VNC.

Pour l’evolution coté jeedom, j’avoue, les utilisateurs font plus de boulot que les devs.

Pour celle coté deconz, ils ont bloqué les nouveaux appareils depuis plusieurs mois pour une transition vers un nouveau mode de fonctionnement, via des fichiers Json, ca va permettre l’utilisation de fichier json via leur éditeur ou des fichiers textes, ça va booster le rajout ou l’édition des nouveaux appareils, par contre je n’ai pas trouvé de dates.

Bonjour,

Mince tu a raté plugin-zigbeelinker / plugin-zigbee2mqtt

avec ses 1796 devices et qui en ajoute plusieurs dizaines chaque mois …

et une procédure pour inclure des devices inconnus

bon Samedi

1 « J'aime »

En effet, j’ai pas trop suivi tout ça ces derniers mois et je suis probablement passé à côté. Je vais me pencher dessus …

Mon deamon Deconz se plante toutes les heures à heure quasi fixe, autour de la 15 ème minute et j’ai pas encore identifié la cause et ça me gonfle. Jeedom n’arrive à le restarter qu’après 2 tentatives donc tout est morts jusqu’à ± la 25 ème minute de l’heure.
Je songe à monter deCONZ sur une VM séparée pour de 1 ne plus être en Headless et profiter plus facilement du GUI (pour le moment je le lance au besoin au travers de putty en SSH avec serveur X11 déporté après avoir stoppé le deamon jeedom …) et de deux rendre mon installation deCONZ plus indépendante de la VM jeedom.

Mais je vais avant tout ça me pencher sur zigbeelinker et zigbee2mqtt pour voir à côté de quoi je suis passé …
Mais quid de l’émulation pont Hue avec ces solutions ?

Je m’auto répond …

La piste serait d’utiliser « diyhue » en complément, il est compatible avec zigbee2mqtt …
Je vais donc continuer à creuser pour la stratégie finale que je pourrais adopter …

Bon après des dizaines de tests et d’essais, je laisse tomber zigbee2mqtt et donc aussi le plugin zigbeelinker …

  • Les groupes d’ampoules Hue présentent un bug et ne fonctionne tout simplement pas du tout dans la dernière stable, problème confirmé sur le Git officiel par plusieurs autres utilisateurs et qui sera probablement résolut prochainement mais sur une stable lors de test de validation d’une solution ça refroidit direct … sinon ça avait l’air vraiment pas mal, avec support des équipements et des scènes beaucoup plus abouti qu’avec le plugin deCONZ, dommage.
  • Je n’ai pas non pu réussi à émuler de façon satisfaisante un pont Hue avec diyHue qui est quand même loin d’être abouti et ça m’a donc fait abandonner cette piste.

Je suis donc retombé sur mon deCONZ que j’ai d’abord voulu monter en docker sur synology mais des problème de reconnaissance USB sous DSM7 m’ont fait au final monter deCONZ en VM ESXI, déporté de jeedom donc, sur un debian 10 avec Gnome pour le moment, que je vais prochainement switcher vers une debian headless avec serveur VNC pour ne plus trainer Gnome juste pour le GUI de deCONZ … il est en effet possible de lancer deCONZ en mode GUI sans environnement desktop en transmettant le GUI directement vers le serveur VNC.

Et depuis que deCONZ est dans sa propre VM déporté de jeedom je n’ai plus de problème de plantage toutes les heures … ça a l’air bien plus stable maintenant.

Helloo,

Quel est le bug avec les groupes ? J’en utilise un depuis peu avec 2 ampoules Hue et ça fonctionne pour les commandes on /off. Ça bugue sur d’autres commandes ?

Sinon diyhue a l’air intéressant sur le papier. Tu l’as lance comment ? Dans un docker ?

Lors de mes tests j’avais appairé 6 lampes Hue, (2 White and Colors et 4 White Ambiance) et un dimmer switch philips, j’avais fait un groupe avec les 2 « colors » et un groupe avec les 4 Ambiance et j’ai eu le même problème sur les 2 groupes, il était impossible de commander les actions sur les groupes, ni ON/OFF ni la luminosité, même directement depuis l’interface zigbee2mqtt, l’état du groupe était par contre bien remonté.
Dans le log de zigbee2mqtt j’avais lors de chaque action ce warning :

Warning: Received message from unsupported device with Zigbee model 'undefined' and manufacturer name 'undefined'

Je suis donc tombé sur ce post qui correspond au problème que j’ai rencontré avec ces groupes :

https://issueexplorer.com/issue/Koenkk/zigbee2mqtt/9218

Le problème a été remonté par un premier utilisateur le 18/10 et par d’autres ensuite et Koenkk a réclamé un log le 27/11, donc hier. Il semble que ce problème dépend des types de lampes utilisées dans le groupe, il n’est donc pas forcément visible chez tout le monde.

Pour diyHue je l’ai installé directement sur ma VM jeedom, c’est du python 3 mais la doc est très limitée, il a fallut que j’aille voir moi-même dans le code pour voir comment lancer le script python sur un autre port que le 80 car forcément ce port était déjà utilisé par mon jeedom et le script « plantait » sans s’interrompre sur l’ouverture du port car ils n’ont prévu aucune gestion d’erreur sur ce cas de figure dans leur code.
J’ai essayé la version stable mais elle supporte pas le mqtt et la dernière version qui est encore en beta mais qui a totalement changée et s’est enrichie et qui elle supporte le mqtt.
Mais après avoir l’avoir linkée avec zigbee2mqtt au travers du broker tout ce qui est remonté dans diyHue c’est le dimmer switch et pas les lampes.
C’est d’ailleurs peut-être normal car c’est pas très clair mais il me semble que diyHue est surtout fait pour pouvoir créer ses propres lampes DIY sur base ESP et pour y appairer certains périphériques zigbee qui ne sont pas supportés par les ponts hue standard.
Donc choux blanc pour émuler un pont hue qui donnerait accès aux lampes appairées avec zigbee2mqtt, je pense que le but de diyHue est plutôt de faire l’inverse.

Je testerai des groupes sur différentes lampes du coup.
Pour l’instant j’ai juste testé un groupe avec 2 GU10.

Dommage pour diyhue, l’idée de pouvoir utiliser les applis mobiles dont celle de Phillips avec les lampes déclarées sur zigbeelinker (sans pont Philips donc) était plutôt sympa ( le beurre et l’argent du beurre :slightly_smiling_face:)

Et si ça tombe le problème de groupe dépend peut-être aussi du type de clé zigbee, j’ai pas vérifié si les autres utilisateurs stipulaient leur modèle de clé. Dans on cas c’était une Combee II.

Moi c’est une sonoff : https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/

Les commandes de groupes sont natives, c’est des requêtes zigbee, pour moi aucune raison pour qu’une clé fasse une requête différente d’une autre.

C’est un bug de zigbee2mqtt, pas vraiment un bug zigbee, donc tout est possible et le comportement de zigbee2mqtt peut être différent d’une clé à l’autre, d’autant plus qu’on doit spécifier dans la config le type de clé, c’est donc bien que toutes les clés ne se managent pas forcément à l’identique, elles ont leur particularités, du côté zigbee elles suivent surement la norme mais du côté USB/Serial elles sont surement pas exactement identiques.

Salut,

Vu que tu es sous VM Esxi, pourquoi n’as-tu pas conservé ta VM Jeedom et créé une autre VM pour Deconz ? Il suffit juste de renseigner l’IP de ta VM dans le plugin Deconz.
Ca permet d’isoler les deux en cas de problème et ça permet d’avoir nativement un Debian 10 graphique avec Deconz Gui d’un côté et Jeedom de l’autre.

A+

2 « J'aime »

C’est ce que j’ai fait :

Il me reste a le refaire sur une debian sans desktop et à forwarder le GUI vers VNC car là avec Gnome qui tourne la VM consomme un peux trop de MHz à mon gout par rapport à ce qu’on lui demande.

Désolé pour le hors sujet, mais comme tu as l’air de t’y connaitre par rapport a ton dernier commentaire, tu aurais la différence de consommation en ressources pour une VM headless et une VM desktop ?

Voici quelques chiffres :
Jeedom Debian 10 Headless :

  • 700 à 800 MHz quasi constant avec des pointes à 1.5GHz (mais j’ai une très grosse installation très automatisée)

Dolibarr (Soft ERP) Debian 10 Headless :

  • 15 MHz lorsque je ne suis pas occupé d’y travailler.
  • 30 MHz lorsque j’y travaille.

Odoo (Soft ERP) Debian 9 Headless :

  • 8 MHz lorsque je n’y travaille pas.

Asterisk (Centrale VOIP) CentOS Headless :

  • 132 MHz en activité normale, sans appel et trunk sur 5 lignes OVH actif.

GitLab Debian 10 Headless :

  • 100 MHz quasi constant.

FileMaker Windows 10 64bits :

  • 76 MHz avec une session lancée et FileMaker en fonctionnement et quelques users connectées à la DB

Windows Serveur 2012 :

  • 106 MHz mais bon il fait vraiment pas grand chose …

deCONZ Debian 10 Gnome :

  • 160 MHz avec une session utilisateur lancée mais verrouillée et deCONZ GUI qui tourne et l’économiseur d’écran actif et sans être connecté à la console.
  • 1,1 GHz En étant sur la console avec la session ouverte et le GUI deCONZ visible.

Un TOP dans la VM deCONZ montre bien que deCONZ ne consomme quasi pas de CPU et que la majorité c’est Gnome qui le pompe.
Donc à mon avis la VM deCONZ en Headless devrait probablement tourner à moins de 50 Mhz et en tous cas à moins de 100 Mhz.

J’ai de la marge car le CPU de mon hyperviseur ESXI dispose de 17.4 GHz de capacité et l’ensemble de mes VM en prennent en moyenne que 1.7GHz, donc la charge est de ± 10% mais bon pourquoi gaspiller de la charge sur deCONZ alors qu’il est possible de faire autrement …

Nickel merci, c’est sympa comme chiffre. Du coup de passer par du desktop ne bouffe pas tant de ressource que ça ? (Relativement parlant, 20 Mhz qui passerait a 150 Mhz non optimisé en plus de ce que consommerait l’appli ?)
Du coup si l’application est gourmande, le bénéfice du headless est moins évident.

J’ai rien compris, si tu as un peu de temps pour m’expliquer je suis preneur.
Pour moi VNC c’est une sorte de moniteur virtuellement connecté à ta machine. Comment tu fais pour avoir Deconz GUI sur un Debian lite grâce à VNC (à moins de passer par un serveur X) ?

Je suis également intéressé si t’arrives à comparer la consommation de ressources entre un deconz GUI en version desktop et en version lite.

Merci.

https://peterkieser.com/2020/11/23/deconz-vnc-access-without-full-blown-xorg-install/

Je suis occupé de l’implémenter mais pas encore opérationnel … quelques adaptations à faire car c’est une debian et pas une rasbian.