Sur Jeedom j’ai openzwave et zigbee2mqtt.
J’avais dans l’idée de passer sur ZwaveJS (surement 2mqtt) mais finalement, je passe directement sous HA.
Mon Z2M est un container (J’avais externalisé le Z2M car il n’était pas possible à l’époque de l’avoir intégré à Jeedom) sur ma VM docker. Même chose pour mon broker MQTT.
Ma VM docker et ma VM HA (supervised) sont sur le même NUC (Esxi).
J’ai pour le moment très peu de Zigbee (j’étais initialement parti sur Zwave) - 3 modules
Ma question est donc plutôt de l’ordre de la recommandation avec votre experience.
Est-il dans mon contexte, plus intéressant de rester en docker pour mon Z2M et faire un container ZwaveJS2Mqtt, ou bien les intégrer dans HA en tant que modules complémentaires (pas nécessairement MQTT à vous de me dire si c’est mieux) pour centraliser un peu tout, utiliser le watchdog de HA, ainsi que l’intégrer dans les backups (même si backup le docker déjà) ?
Il me semble avoir vu dans un topic que ZwaveJS n’avait pas d’interface graphique d’où l’interet de ZwaveJS-UI? Le post était un peu vieux, c’est toujours le cas ?
J’avoue que cela dans la doc ne me rassure pas trop sur l’idée d’externaliser :
Si tu es sur HA Supervised, le plus « logique » c’est d’utiliser des add-ons. Tu as l’intérêt du tout-en-un et de la gestion des mises à jour simplifiée.
Après, c’est aussi possible d’avoir les containers à côté, dans une autre VMs ou sur une machine à part.
Vu que tu as déjà du MQTT, j’aurais tendance à continuer dans la logique MQTT pour zigbee (donc zigbee2mqtt et pas ZHA par exemple).
L’autodiscovery, c’est sur, c’est pratique. Mais, sauf si on rajoute des capteurs très souvent, ce n’est pas trop compliqué de les rajouter à la main. Pour moi, ce n’est pas une raison suffisante de se passer de MQTT. Là, encore avis perso.
Enfin, je dois reconnaitre que mon avis est un peu biaisé. Je ne suis pas fan de HAOS ni de supervised. Le truc « magique » qui fait les trucs pour moi, ça me fait penser à windows.
Je maitrise linux, debian, je gère tout ça en container. Si quelqu’un fait une connerie, je sais ou il est
golfvert a bien résumé et je serais plutôt de son avis, à savoir rester sur MQTT si vous y êtes habitué.
J’ai HAOS sur un RPi et je suis en train de passer vers à une version dockerisée (ou core, je ne sais pas encore) qui exploitera plus MQTT que je ne le fais aujourd’hui.
Avec MQTT si on doit changer sa base domotique ou si chez les dev de HA décident de faire une mise à jour un peu « radicale » d’un composant (ça m’est arrivée, tout est tombé), on a beaucoup moins de config à faire pour remettre tout en place que si on devait configurer tous mes modules dans HA (re-détecter, renommer/réassigner toutes ses entités…).
En plus, ça permet d’avoir les clés USB ailleurs que sur le serveur HA (même si du coup on fragilise un peu l’ensemble qui devient dépendant du réseau local).
Merci à vous deux pour vos réponses.
J’ai vu que a priori on peut utilise ZwaveJS-UI en addon (et je suppose aussi en container externe) qui discute avec l’integration ZwaveJS via Websocket.
Donc finalement, l’utilisation de docker n’est plus lié à MQTT pour ZwaveJS et donc à l’autodiscovery.
Après, je m’y attendais, les réponses sont plus de l’ordre de la philosophie. J’aime aussi beaucoup docker mais comme tout est sur la même machine physique, je me dis que l’éclater dans plusieurs VM/Container n’apportera pas grand chose.
Je suis d’accord avec ca. De toute façon Z2M sera obligatoirement en MQTT, la question est plutôt savoir si je le switch en addon ou si je le garde en container hors de la VM HA.
Pour ZwaveJS je doute que ce cas puisse arriver depuis que le fondateur de ZwaveJS a rejoint l’équipe Nabu Casa :
Totalement en phase avec toi, mais dans mon cas, c’est le même NUC physique qui porte les clés donc pas vraiment un argument dans mon cas personnel.
donc pas vraiment un argument dans mon cas personnel.