Bonjour,
J’ai une ConBee II actuellement sous deConz. Quel serait l’intérêt de passer sur Zigbee2MQTT?
Des avantages d’une solution par à l’autre? Des inconvénients?
La solution d’avenir?
A vos claviers!
Salut,
ma conBee II est sous ZHA, alors pourquoi pas parler des trois solutions pour trouver la solution d’avenir…
@+
Allez y, un petit challenge, chacun liste les points positifs et négatifs de la solution qu’il utilise et on fera un tableau récapitulatif pour mettre en concurrence les différentes solutions.
Ça en aidera sûrement plus d’un pour choisir 
1 « J'aime »
J’ai édité le titre pour y inclure ZHA
C’est bien le but de ce sujet… un récapitulatif de ce que propose les différentes solutions afin de guider les néophytes (dont je fais partie).
Je ne connais pas deConz ni ZHA, mais j’utilise zigbee2mqtt
Les points forts de z2m selon moi :
- Ca fait du z2m !!! Enfin je veux dire que nativement ca tourne sous mqtt ce qui permet derrière de faire plein de choses, sous Nodered notamment
- L’interface web est plutôt sympa, avec la carte notamment
- Possibilité de l’installer en plugin pour HA OU en standalone sur une VM ou un rpi
- Compatible avec pleins de clés zigbee du marché
- Compatible avec une liste impressionnante de devices zigbee
- le site zigbee2mqtt.io est très bien documenté, on trouve pas mal d’infos
- très stable en fonctionnement, une fois bien configuré
Les contres :
- Je cherche encore …
- Peut être pas super super simple d’accès aux grands débutants qui ne connaissent que Windows ?
Niveau device je pense que decon est un peu a la bourre mais niveau facilité il est clairement au dessus.
pas besoin de trifouiller le code tout se fait via l’interface. les debutants s’y retrouveront plus facilement, perso j’ai les deux qui tournent chez moi actuellement car je n’ai pas tout migré vers z2m…
@Vinceg77 z2mqtt est plus complexe (nécessite un brocker mqtt) mais semble plus dynamique (communauté, mise à jour, devices supportés).
@DcJona tu passes tout vers z2mqtt au final ? bon tu es un fervent utilisateur de node-red je pense que ça doit motiver 
Pour ma part j’utilise d’add-on deCONZ de HA, je n’ai pas testé les 2 autres solutions. Ni plus, ni moins satisfait, il faudrait que je teste les autres pour me rendre des points faibles/forts.
Je suis sur ZHA avec une Conbee 2. Pas d’addon (1 pour Deconz, 2 pour Z2M) donc plus de RAM libre, « natif » à HA, réactivité à toute épreuve.
J’étais sur Deconz avant, j’ai pu voir la différence en terme de réactivité. J’ai migré à l’origine car l’addon s’est mis un jour à planter 2/3 fois par jour et je devais le relancer manuellement.
En terme de device supporté, je peux me tromper mais il me semble que c’est Z2M qui gère le plus de device, ensuite Deconz et enfin ZHA. Néanmoins, tous mes modules sont commun et donc supportés par tous (aqara, xiaomi et IKEA).
En terme de contrôleur, ça en gère un paquet également.
j’utilise deconz qui est tres simple a installer et aussi pour l’intégration des modules. je me pose la question sur importer tous sur mqtt mais avant ca il faut que je devienne un pro de nod red sinon aucun intéret
Quel avantage de passer par NodeRed pour gérer un protocole à travers un addon (Z2M), comparativement à du natif (ZHA) ou un addon qui se gère tout seul (deConz) ?
Le fait d’ajouter un addon qui pilote un addon doit allonger la réactivité.
Sans oublier le passage par le serveur MQTT. Donc, ça fait du Z2M → Broker → HA → API → NodeRed.
Dans mon cas, le broker mosquitto n’est pas un add-on mais il est à part. C’est ma configuration et c’est « instantané ». Entre le moment ou j’appuie sur un bouton aqara (par exemple) pour allumer une yeelight (IP!), on ne perçoit pas de décalage.
J’ai choisi Z2M, justement pour ce découplage. Même si j’apprécie HA, je n’ai pas envie de mettre tous mes oeufs dans le même panier.
Z2M, NR et HA sont trois containers indépendants sur la même VM. Je dois faire le lien entre les trois à la main, mais, c’est faisable. Si je redémarre HA (il n’y pas si longtemps pour toute modif il fallait redémarrer), rien d’autre ne bouge.
Bah non, Nodered avec la palette qui va bien est un client MQTT comme un autre. Inutile de passer par HA en amont…
Ca donne donc: Z2M → Broker (==> partie incompressible !) → NodeRed → (puis tous les traitements avals que l’on souhaite)
J’ai ca en prod chez moi, avec z2m sur un Rpi, NR sur une VM et Mosquitto sur une autre VM. C’est très rapide, et tout est bien cloisonné !
C’est vrai, mais, si tu veux gérer facilement le changement d’état grâce à la palette websocket entre HA et NR, c’est bien le cheminement que j’indique.
Les deux sont faisables (avec ou sans detour par HA), mais, et c’était la question initiale, aucune des deux options ne ralentit le traitement.
Pas sur de bien comprendre… ou de te suivre !
Moi ce que j’imagine que tu appelles les changements d’état, je les gère en aval de nodered. J’ai :
z2m → Broker → Nodered → (éventuellement) HA grâce à la palette websocket
Bon après c’est vrai que ca revient un peu au même au final, c’est juste un ordre différent
Ce que j’ai voulu dire, c’est que pour, par exemple, un capteur d’ouverture xiaomi, tu as deux options:
- un noeud mqtt sur nodered qui écoute sur le topic et qui agit. Donc, là, c’est Z2M → broker → NR
- un noeud « trigger » sur nodered qui écoute l’événement venant de HA. Dans ce cas, c’est Z2M → broker → HA → NR
Oui ok j’ai compris et on est donc bien en phase.
Et j’ajoutais que à partir du moment ou tu as une action en aval, ca revient en fait au même. Que tu fasses :
Z2M → broker → NR → action websocket sur HA
OU
Retour websocket sur HA → NR → broker
c’est quasi kif-kif
au final de toute façon en terme de réactivité on est super bon des deux cotés et pour moi ca reste instantané ici, même en ajoutant une couche avec un nextion … certains ont pu le voir a travers mes vidéos
Et du coup, pour le MQTT, vous utilisez l’add on ou un autre broker?
Un autre. J’ai une installation de mosquitto sur un container LXC sur mon proxmox.
L’installation de mosquitto est très simple. L’add-on (à mon avis) n’apporte pas grand chose.