Rendre robuste une installation: 2nd clef Zigbee dans un réseau? binding?

Bonjour

Chez moi, la température repose sur HA et des fils pilotes commandés en Zigbee.
J’ai constaté que mon ensemble pouvait facilement tomber en panne durant les vacances. Comme je ne veux pas me retrouver avec du chauffage à fond h24, je suis en train de réfléchir à comment le sécuriser…

D’où ma question, est il possible d’insérer une seconde clef Zigbee (avec un second Raspberry) qui se comporterait comme un routeur en temps normal et pourrait prendre le relais lorsque la principale ne réagit plus?
Est ce que le futur ESP-H2 sera capable de faire cela? Dans ce cas ce serait cet ESP qui ferait la régulation rapide et HA ne serait plus que l’interface utilisateur…

Salut…

C’est un vaste le maintien en condition opérationnelle…
Mon avis sur le sujet est assez radical : Sécuriser avec du matériel backup en mode FailOver c’est illusoire :

  • il faut TOUT en double, pas juste le clé, car si le PI Est mort, ça ne marche pas mieux
  • il faut basculer TOUTE la configuration (le programme de la clé par exemple) mais aussi HA
  • il faut revoir TOUTE la partie réseau
  • dans l’hypothèse où ça fonctionne il faut TOUT tester régulièrement, le petit changement d’infra peu avoir pas mal de conséquences
  • il faut que TOUT soit automatiquement …

Bref, on est pas en entreprise et ça ne vaut absolument pas le coup.
Par contre il y a une alternative : faire en sorte d’avoir de la tolérance aux pannes :

  • Dans le quotidien avoir des trucs qui marchent SANS domotique (les interrupteurs)
  • S’assurer que quand c’est planté ça reste dans un état acceptable : par exemple piloter les chauffages avec des consignes sur des thermostats indépendants de HA, ça permettrai de te sauver

Perso, le plus simple pour sécuriser mon install HA, c’est mon boîtier HA (boîtier odroid N+2 avec cle zigbee et zwave) branché sur une prise hue connecté en zigbee à mon pont hue, et branché (prise hue et pont hue) sur onduleur. Comme cela, si panne électrique, HA tourne toujours, si HA planté, on/off de la prise électrique HUE. C’est pour moi le plus secure. C’est pas de la haute dispo, mais ça pare à la plupart des problèmes.

Malgré les éléments dans la spécification Zigbee qui montrent qu’un coordinateur de backup a probablement été un sujet, rien n’est prévu concrêtement à ce sujet.

Il y a un chercheur qui a mis un système comme cela en place, mais cela reste un sujet de labo qui n’a pas été étendu aux usages courants.

Avant de parler d’une deuxième clef qui prend activement part au réseau au temps normal, il faut déjà considerer une solution plus simple: une clef compatible, en attente.

Il est alors possible en cas de pépin, de restaurer une sauvegarde de la clef en panne à cette deuxième clef. Il y a des travaux qui ont été faits pour généraliser la sauvegarde, et à priori aussi la restauration de la configuration Zigbee vers une autre (sous ZHA/zigpy). C’est tout frais, donc cela demande encore d’être expérimenté par les utilisateurs mais avec assez de motivation il devrait être possible d’automatiser la restauration (la sauvegarde étant déjà automatisable facilement).

Certes, comme il est dit, on peut avoir beaucoup de pannes, mais on peut aussi se protéger d’un sous-ensemble des pannes pour commencer. On n’est jamais complètement protégé.

Si on veut se rapprocher de ce qui se fait (ou faisait) dans un A320 il faut un Raspberry Pi et un NUC par exemple, dans un sous-système, et plusieurs de ces sous-systèmes, 2 implémentations différentes de HA et de ses modules pour éviter des bogues identiques, etc.: How does the Airbus flight computer's voting system work? - Aviation Stack Exchange .

C’est pour dire qu’il n’y a pas besoin de sur-réagir. Automatiser la restauration de Zigbee ne peut être bénéfique puisque c’est aussi faciliter la migration d’une clef Zigbee à une autre.

1 « J'aime »

Tout à fait en accord ! :slight_smile:

ce qui se fait (ou faisait) dans un A320

je vais faire décoller ma maison… :exploding_head:

Pour les votes, synchronisations ou redondances, mon soucis reste toujours le point unique par lequel passe la commande et la réception des messages…

:thinking: je pourrais programmer Rasberry avec HA et en parallèle un ESP, si les deux utilise la même clef Zigbee, j’ai toujours le point faible.

:point_right: l’idée est d’avoir deux systèmes qui parlent aux radiateurs. Le premier par défaut est comme mon système actuel et le second écoute les commandes envoyées aux radiateurs et, si il n’y a plus de commande, il prend la main en donnant des ordres à la place du premier. Après tout, c’est juste un signal radio…

Sur le papier c’est joli. Dans la réalité on commence à la fois à avoir besoin de solides connaissances mais aussi de traiter les cas bizarres.
Si on reprend ton système qui écoute et prends la main quand l’ autre n’est pas là… Admettons que ça bascule au bon moment de la panne du 1er système. A partir de là comment tu écoutes le retour (miraculeux) du 1er système ? La première réponse c’est de se dire pas besoin de revenir à l’ état précédent, mais ça veut dire qu’il faut ajouter un peu de logique (des automatisations, des consignes, des événements) pour maintenir le fonctionnement minium de ton chauffage…

Oui bien sur que ce n’est pas du tout cuit.
Par contre, l’étape nécessaire est que la 2nd clef Zigbee puisse s’insérée et être reconnue comme fournisseur de commande acceptable par les radiateurs/récepteurs. C’est là le nœud du problème.

Si c’est en effet le 1er truc nécessaire ça me semble par contre loin d’être le plus difficile : il y a déjà des outils de dumps et les futures versions de ha devraient disposer d’un mécanisme de backup / restore ZHA & z2m
À mon avis : le temps qu’il va falloir passer + le cout + la maintenance qu’il faut prévoir en vue d’une solution suffisante n’est pas du tout rentable fasse à la fréquence de ce type particulier de défaut. Je reste partisan d’une remediation bien en amont

Qu’est ce que c’est les mécanismes de dumps?
Mon gros soucis, cela a été cet été, à mon retour de vacances, quand ma clef deconz ne redémarrait plus. Est ce que ces mécanismes de backup/restore auraient pu remettre le truc en ordre de marche?

Regarde ça par exemple. Le dump consiste à extraire de façon plus ou moins exploitable les infos essentiels d’un réseau zigbee.

Tu devrais mieux te rendre compte de l’étendue du sujet.

Une clé qui démarre plus c’est peu précis sachant qu’en soi c’est pas tellement la clé qui fait le job. C’est ni plus ni moins qu’un émetteur / récepteur… Ha est à la manœuvre derrière.
En théorie ça marche… dans la réalité il faut être dans les bonnes conditions et rendre ça automatique est une usine à gaz

…sécurisé, qui n’accepte qu’un seul coordinateur à la fois.

Côté sécurité il a des clefs secrets (récupéré en partie par le backup) et des compteurs de trames avec les objets pour éviter que d’anciennes trames puissent être rejouées et si la copie du coordinateur n’est pas en ligne avec ces compteurs on arrive sur un dialogue de sourds.
Oui, chaque objet réçoit les trames, peut savoir si cela lui est adressé ou pas, mais ne pas accepter le contenu.

Mais bon, sauvegarder, restaurer (et ajuster les compteurs avec une certaine marge), reconfigurer ZHA pour utiliser l’autre clef (autre port du système ou autre adresse réseau) devrait (bientôt) être réalisable moyennant l’effort de codage, tests.

Savoir s’il faut basculer nécessite une certaine logique et comme on n’est pas vraiement sur la haute disponibilité ici, mais plutôt sur un dépannage quand nécessaire, la première approche c’est de déclencher le basculement manuellement, par exemple après avoir notifié à un utilisateur qu’il y a une panne afin qu’il puisse vérifier l’état du système et faire le bon choix.

Il est plus critique d’assurer que la connexion réseau reste valide pour permettre cette intervention.

Faire simple et ne pas monter des usines à gaz est mon credo.

Je suis en ZHA avec plus de 60 devices et ça ne plante pas. Le moment ou il peut y avoir des problèmes c’est quand on fait une mise à jour ou on ajoute un truc pas reconnu, mais à ce moment là on est présent pour corriger. Z2M est tout aussi fiable, mais on introduit avec MQTT une étape supplémentaire, d’où ma préférence pour ZHA.

Et ne jamais oublier qu’en Zigbee on est sur un réseau maillé et que prises et ampoules servent au maillage. En gros ça veut dire que les devices Zigbee ne sont pas vraiment mobiles et qu’il vaut mieux les appairer à l’emplacement définitif et éviter de les bouger, surtout si la surface est grande.

2 « J'aime »

C’est ni plus ni moins qu’un émetteur / récepteur… Ha est à la manœuvre derrière.

oui c’était un problème Deconz, j’ai du redémarrer la raspberry, arreter/relancer Deconz…

pour le dump, cela n’a pas l’air simple effectivement.

Sinon je découvre les histoires de binding entre équipements zigbee. Cela montre que si l’équipement est conçu pour, il peut recevoir des infos d’autres équipements…
C’est ce genre de chose qu’il me faudrait.

J’ai mis mon problème sous forme de dessins…

Le point faible: raspberry, HA et clef deconz

1er idée: 2 clefs zigbee
La seconde clef en redondance comme coordinateur prêt à se faire passer pour le principal si celui ci fait défaut.

2nd idée : un device inséré dans le réseau et « binded » à la mesure et aux commandes

Pour ce dernier point, l’équipement idéal qui pourrait faire le job serait un ESP32-H2 avec zigbee au lieu de la wifi…

Il faut aussi ajouter la solution docker où par exemple z2m et nodered sont indépendant de HA
La raspberry et la clef restent les points faibles.