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…
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.
Pour les votes, synchronisations ou redondances, mon soucis reste toujours le point unique par lequel passe la commande et la réception des messages…
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.
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.
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.
Je vois que ce sujet est le plus proche de ce que je me pose comme question en ce moment, je me permets de le réouvir.
Je partage ce qui a été dit, à savoir : avoir un système avec une redondance, disons, instantanée est complexe, mais sans doute faisable.
Ma proposition pour faire de la redondance
Utiliser HA sous Machine Vituelle (ou conteneur)
Deployer cette VM dans un cluster Proxmox.
C’est à dire 3 machines physiques fédérées par proxmox
Demander à proxmox de gérer le backup et le redéploiement de la VM dans le cluster en cas de panne de la machine.
Ce qui implique que chaque machine a une clé zigbee et que proxmox saura faire le PCIe passthoug entre la VM est la clé
Ca demande de solides connaissances sur la virtualisation et la gestion des hyperviseurs de type1. Que, pour l’instant, je n’ai pas. Donc je ne absolument sais pas comment faire mon étape 3, mais je sais que proxmox en est capable. Mais peut-être que certains savent si c’est absurde ou pas?
Question sous-jacente : le backup, notamment d’une clé zigbee
Cependant, j’ai une grosse question. A défaut de faire de la résonnance à chaud, je me posais déjà la question de comment redéployer un système complet en cas de panne matérielle.:
Si c’est le serveur qui lâche → Redeployer dans un second mini PC qu’on a dans nos cartons, ou temporairement dans une VM sur son PC « normal »
Ca, c’est suuuuuper facile avec les backups, en particulier avec l’add-on Google drive backup
Mais si la clé zigbee lâche (ca va bien arriver un jour à ou l’autre). Comment on fait?
Est-ce il faut refaire tous les appairages à la nouvelle clé?
Est ce zigbee2mqtt ou ZHA va réinjecter la configuration dans la nouvelle clé?
Si oui, est-ce qu’il faut la même clé (est-ce qu’il faut en acheter 2 avant que son modèle ne soit plus vendu)?
Perso la gestion de la résilience comme en entreprise, ça vaut pas le coup à notre niveau…
3x fois les infras (coût !!), la conso électrique, la maintenance etc pour traiter le cas (rare on espère) où un défaut matériel survient !!
Je préfère passer mon temps à construire/penser une domotique qui fonctionne en mode dégradé (j’ai encore assez de ressources pour lever mes fesses du canapé et allumer la lumière à l’ancienne)
Oui c’est vrai, je pense qu’il faut avant tout penser l’installation comme fonctionnelle lorsqu’il n’y a pas de serveur.
Parfois c’est d’ailleurs un vrai casse tête. Mais, est ce que c’est pas ca fait partie du fun
Mais n’oublions pas quelque chose, je pense que beaucoup d’entre nous, ces projets sont pour le fun ou le sport, ou le challenge…
Si la redondance tient à cœur à certain comme @haz, (ou moi) c’est un projet.
Je prendrais ce message comme: Prévoyez toujours une alternative physique pour contrôler la maison, avant de compter sur la redondance.
Cependant, à minima, une stratégie de backup, me semble très importante. Parce que bien que rare, le matériel lâchera un jour, c’est sur et c’est dur de refaire plusieurs mois/années de travail.
PS: c’est vrai que je rigole bien quand je vois des chaines youtube expliquant l’intérêt économique de la domotique puis qui juste après présente leur matos qui une baie full size à 700W de conso
Effectivement il y a une part de challenge et de fun, mais à ce compte, il faut aussi inclure le FAF (Family Acceptance Factor, pas que le WAF)…
Parce que la domotique, ce n’est pas QUE les gros barbus comme nous… Les simples utilisateurs se fichent pas mal de savoir comment ça marche, et acceptent parfois assez mal qu’il faille passer du temps à réparer. J’ai la chance que ma petite femme soit plutôt en phase avec les nouvelles technos, donc c’est assez facile au quotidien, mais quand même, j’ai le droit de temps en temps à quelques remarques.
Je partage par ailleurs ton avis à propos de backup (1 fois par jour mini, stocké ailleurs que sur le matos principal, voire externalisé en plus sur gdrive) c’est la base… J’ai un mal fou à me mettre à la place de l’utilisateur quand je vois « j’ai un backup du mois de mai »… La domotique ça évolue tous les jours chez moi !
Par contre la gestion d’un backup c’est facilement faisable sans doubler l’infra… et sans gérer la bascule sur un mini PRA, des clés usb etc etc.
Et pour finir, prévoir quelque chose qui fonctionne sans domotique c’est aussi se faciliter la vie en cas d’évolution du matériel, voire de changement de logement
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.
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…
