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

Protocoles de communication Zigbee
21

Un projet perso c’est toujours une occasion pour développer des compétences.

Proxmox propose déjà une fonctionnalité de Haute Disponibilité (HA - High Availability), et permet déjà de synchroniser les conteneurs ou vms d’une machine à une autre.

Il faut 3 machines pour que chaque serveur puisse déterminer s’il est en panne lui-même ou pas, mais on peut s’en sortir avec 2 machines qui gèrent des VMs et un QDevice (Corosync Quorum Device). Un QDevice c’est un service qui s’installe sur un petit « serveur » debian par exemple (un raspberry pi, etc).

Donc si l’essentiel peut être synchronisé, la problématique principale avec le Zigbee c’est qu’il faut que le coordinateur soit « à jour ».
Là, je vois 2 solutions:

  1. Utiliser un coordinateur/gateway accessible depuis le réseau. Donc si un serveur Proxmox plante, le coordinateur reste le même et ce même lors du basculement.
  2. Avoir une clef sur chaque machine Proxmox. Détecter le changement et à ce moment-là restaurer la configuration Zigbee sur la clef. L’automatisation de cette étape nécessite probablement encore qqs évolutions dans ZHA ou Z2M.

Si on veut aussi la redondance zigbee lorsque le coordinateur est accessible par le réseau, il faut un deuxième coordinateur d’avance. Il pourrait être tenu à jour régulièrement (sans le lancer vraiement), ou bien recevoir la restauration du réseau Zigbee le moment venu.

22

Intéressant, intéressant,…
je ne suis pas à ce niveau là. D’ailleurs je ne comprends ce que vous dites.

Je suis parti sur la solution d’un device zigbee inséré dans le réseau et « binded » à la mesure et aux commandes.
J’ai le device par contre le bind ne fonctionne pas donc je suis bloqué là.
Si le bind fonctionnait la redondance serait très facile à faire.

  • est ce que le rasberry fonctionne?
  • si oui je ne fais rien
  • si il ne fonctionne pas je prends la main avec une régulation de température simplifiée.
  • c’est tout

Ce device zigbee coute 15€.
Il a un ESP32 donc peut communiquer de façon indépendante pour faire remonter la panne de la Raspberry.
Donc oui cela vaut vraiment le coût de tenter l’expérience.

23

J’ai fait un petit essai ce matin concernant une gateway zigbee (UZG POE) en ethernet. l’essai a été fait a l’arrache : j’ai cloné ma VM et juste changé l’ip du serveur mosquito au niveau des paramètres de zigbee2mqtt sur la seconde machine. au niveau zigbee les deux machines ont l’air de fonctionner normalement, la gateway detecte bien deux clients.
Si je rajoute un périphérique zigbee a zigbee2mqtt sur une machine, l’autre machine le rajoute aussi, mais si on renomme sur l’un l’autre garde son ID par défaut (ce qui est logique).

Je vais la laisser allumée aujourd’hui pour voir comment ca se déroule pour les automatisme (qui seront doublé…) sinon je créerai un automatisme qui active tous les autres quand la première machine ne répond plus.

Bref il n’y a plus qu’a trouver un moyen d’uploader les modifications de la machine principale a l’autre de manière automatique. Ou de faire un script qui clone la machine principale toutes les nuits, l’upload vers la deuxième machine et change l’adresse du serveur moquito dans les paramètre zigbee2mqtt. Mais si c’est juste un serveur backup pour les automatisme,data ca fonctionne deja pas trop mal. j’imagine que je vais trouver des bugs sur la durée.

Concernant la double gateway réseau, j’ai essayé : le problème c’est que le deuxième coordinateur n’a pas l’air de vouloir s’incruster dans le maillage zigbee de l’autre coordinateur. si on éteint l’autre coordinateur j’ai toujours un message disant qu’il y a un réseau avec le même panID a proximité (probablement du a mon réseau de routeurs assez dense) et donc refuse de démarrer. Il y a deux possibilités pour le forcer a rentrer avec le backup de zigbee2mqtt : éteindre tous les plombs pour que les routeurs zigbee (ampoule prise etc) ne soient pas alimenté. Ce n’est pas très pratique du coup, j’ai trouvé une autre astuce : enlever l’antenne (ça n’a pas suffi.) et de mettre la passerelle dans une boite en metal pour l’isoler du réseau présent. Du coup, elle a bien voulu se connecter et refaire un maillage sans réappareiller toute l’installation.

24

Super Intéressant!
Quelques questions pour bien comprendre le montage avec la gateway zigbee:

  • la gateway sort toutes les info du réseau vers l’ethernet? et peut commander tous les devices du réseau?
  • que se passe t’il si tu retire le routeur? Est ce que la gateway peut envoyer des commandes à la place du routeur? donc avoir des devices commandées par à la fois la gateway et une clef zigbee sur par exemple une RPI avec HA?
    → si c’est cela c’est exactement ce qu’il me faut!!
25

pour le point 1 : la gateway sert de coordinateur, donc c’est elle qui gere le reseau zigbee (plus besoin de clef usb)

le point 2 : ? je ne comprend pas la question :slight_smile: en zigbee les routeurs servent grossomodo de relais pour les maillages du réseau mais ils ont besoin d’un coordinateur pour fonctionner. ce n’est pas possible d’avoir deux coordinateurs allumé en meme temps sur le même reseau (ca demarre mais ca ils l’air de rentrer en conflit au niveau du maillage). Maintenant si l’autre coordinateur s’allume que quand le premier est en rad, ca devrait fonctionner mais il faut que ce coordinateur ait deja rejoint ce réseau une premiere fois (et donc de le mettre dans une boite en métal pour l’isoler), je ne sais pas si le coordinateur backup garde en mémoire longtemps les paramètres pour rejoindre le réseau. l’ideal serait probablement de lui laisser l’occasion de le rejoindre tout les X jours (en profitant d’une mise a jour de la machine principale par exemple). J’imagine que c’est mieux que se soit deux même modèles de coordinateur (chez moi j’ai deux UZG zigstar pour faire les test)

26

ok merci je comprends…
mon but n’est pas de remplacer un coordinateur par un autre

J’avais compris que le gateway s’insérait dans un réseau existant et qu’on pouvait l’utiliser pour lire et commander des devices de ce réseau. Et donc potentiellement qu’il pouvait servir de relais quand le coordinateur était en panne.

Sinon oui, a priori, on ne peut pas avoir deux coordinateurs en même temps.

27

Mais… je vais supposer que ton chauffage n’est pas à fond quand tu n’es pas chez toi, mais plutôt le « contraire ».
Donc si le serveur tombe en panne, il y a plus de chances que ça reste à une température plutôt basse.

Et oui on doit pouvoir supposer qu’un thermostat décède au cours d’une phase de chauffage mais dans ce cas, à part si ton thermostat fonctionne soit à 0%, soit à 100 %, ça ne sera pas à fond non plus, et ça ne concernerait qu’un thermostat.

Le problème n’est pas l’automatisation en soi, ça pourrait aussi arriver avec un thermostat centralisé « à l’ancienne ». Le problème est qu’il y a plus de pièces donc la probabilité qu’une de ces pièces lâche augmente. Mais que tout ton système soit mis en défaut… pas forcément je dirais. J’ai un thermostat centralisé qui est mort en décembre chez moi (résultat plus de chauffage).

Et ayant également un thermostat centralisé, il me ser(vira) de contrôle supplémentaire, en limitant la température max. Donc si jamais ton cas que j’estime très rare m’arrivait, je perdrais « juste » un peu d’argent, mais ça ne va pas non plus transformer la maison en sauna.

Après, la solution peut aussi être un voisin / membre de famille pas trop loin qui peut rentrer chez soi au moyen d’un clé (pour la porte je veux dire :slight_smile: ) et intervenir sur les thermostats directement si jamais on ne peut pas se connecter à son HA depuis l’extérieur.

28

Salut
Oui la panne de mon thermostat est soit radiateur à fond soit éteint.
Ce sont des radiateurs électriques qui sont allumés puis éteint sur des périodes de 5mn.
Et là où je te rejoins, c’est que même si le thermostat lâche lors d’une période radiateur allumé, le radiateur a sa propre régulation de température à peut près vers 20° (mon thermostat ne fait que descendre la température).

29

Ok maintenant je comprends mieux.
Après reste pour moi une question importante, le retour sur investissement. Et là, pour moi ça coince.
Si j’ai bien compris, HA ne sert « qu’à » piloter les chauffages, pas de sécurité ou autres possibilités. Donc si il y a panne, elle sera surtout gênante quand vous n’êtes pas là longtemps donc plutôt les vacances. Sinon, c’est une situation d’une journée de travail maximum.
Je vais partir du principe que tu n’es pas rentier et que tu as peut être des enfants scolarisés donc ça va être compliqué de partir plus de quelques semaines.
Donc… si on prend en compte l’achat d’un second Rapsberry plus clé Zigbee « au cas où », c’est à dire un minimum de 100€, plus le surcoût certes faible de cette conso électrique supplémtaire, il faudrait combien de mois (années ?) de pannes pour que ce coût soit rentable, par rapport au surcoût d’un chauffage non contrôlé ?

Je pense que le plus simple ou en tout cas le moins cher serait de pouvoir être averti par HA si jamais il ne reçoit plus le signal d’un des radiateurs, ça c’est plutôt facile, mais aussi de recevoir une notification du portable s’il n’arrive plus à s’y connecter à distance. Je sais pas si c’est nativement possible, j’attends toujours mon Rapsberry pour commencer à jouer avec HA :smiley:
Et dans un tel cas, demander à un voisin / membre de famille à côté de passer vérifier et régler les thermostats manuellement, en l’invitant après au resto pour sa bonne action, coûtera sûrement moins cher.

30

Salut
L’année où j’ai mis en place mon thermostat j’ai gagné 600€.
Tout a été remboursé: clef zigbee, 3 sorties de câble Legrand, capteurs de température, fer à souder (un collègue m’avait offert une Raspberry).
J’en ai aussi profiter pour déplacer un radiateur et optimiser le chauffage.
Du coup, j’ai maintenant un second Raspberry et un contacteur pour l’eau chaude sanitaire.
Mon problème est que le second Raspberry ne peut pas remplacer automatiquement le premier quand ce dernier tombe en panne.

31

Salut,
je pense sérieusement que cela n’a pas été prévu pour l’instant par HA… car bizarrement peu de gens doivent se poser ce genre de problématique, même quand ça gère aussi la sécurité de la maison.
Par exemple, j’ai un serveur Truenas et j’ai le disque contenant l’OS qui est « doublé », ainsi si un disque tombe en panne, l’autre prend le relais, me prévient et j’ai normalement le temps de remplacer le défectueux avant un nouveau problème, mais mon système reste actif.
Les disques durs sont toujours le point faible d’un ordi. Le CPU est virtuellement increvable, surtout vu l’utilisation d’un tel système, et le reste c’est un peu pareil. Donc faudrait voir si y a moyen de doubler le disque OS, un RAID 1 quoi du disque système. Mais je crois pas que ce soit prévu. Enfin du moins j’ai pas vu cette fonction proposée. Mon installation est maintenant sur un HA yellow, où ce serait possible vu qu’il y a une mémoire intégrée et la possibilité de rajouter un SSD, donc oui on pourrait. Mais faut que le système le permette. Ou… faut installer Home assistant dans un Docker sous Linux, et que ce Linux fonctionne en RAID1. Mais ça rajoute peut être des complications, j’ai pas du tout regardé ce mode de fonctionnement.
Le reste des pannes ? Une panne électrique, mais là bien sûr c’est une autre problématique :slight_smile: et la chute, ce qui est rare normalement quand personne n’est à la maison. Perso, je considère que si tu arrives à sauvegarder la future perte de ton disque contenant l’OS, tu élimines 99 % des raisons pouvant justifier d’avoir un second appareil pour le remplacer.

Et comme dit plus haut par d’autres, faudrait que les deux se « parlent », pour éviter que tu doives faire des copier-coller de ta config si jamais tu changes, normalement tu joues pas tous les jours à tout changer mais bon ça serait plus simple, et faut être sûr que les deux ne se gênent pas. Et je pense que jamais personne n’a prévu cette utilisation pour HA.

Et encore une fois, que de problématiques à résoudre pour un risque somme toute assez minime = que ton système se plante alors que ton chauffage est en cours de fonctionnement et surchauffe donc la pièce. Risque somme toute limitée à quoi, 6 mois de l’année ? et pour une période de vacances de peut être 2 semaines max, à moins que tu sois chanceux sur ce point.
Là, vraiment, t’aurais pas de pot. Je comprends bien que t’as économisé de l’argent en installant HA, mais le gain / coût (le temps a une valeur pour moi, surtout mon temps personnel) me parait hautement aléatoire.

Une alerte de ton téléphone t’indiquant qu’il ne peut plus communiquer avec ton serveur et une personne physique ayant accès à ton domicile pour régler le potentiel problème, ça me parait bien plus simple à mettre en place au vu de la problématique.

32

Bonjour
Je relance ce sujet qui m’intéresse, ça peut peut-être aider quelqu’un.
Pour moi le point faible de l’installation, c’est le réseau Zigbee.
Le Raspberry et HA ne semblent pas poser de problème.
Je surveille mon Zigbee de la façon suivante :
Quand je demande de démarrer un appareil, je lance un script qui vérifie si ça s’est passé. sinon je fais un RESET du Zigbee2mqtt et je retente 5 fois maxi.
C’est un peu l’idée du chien de garde sur les micro-contrôleurs.
On obtient ceci :

En général 1 seul reset suffit depuis que j’ai un Pi4 avec 2Go de RAM. Mais on peut aussi aller jusqu’à un reset de HA si ça ne suffit pas.

Le script swON
(swOFF est très semblable).
Le passage de paramètre se fait par la variable cible qui indique l’entité à commuter.

alias: swON
sequence:
  - repeat:
      count: 5
      sequence:
        - data:
            entity_id: "{{ cible }}"
          action: homeassistant.turn_on
        - delay:
            hours: 0
            minutes: 0
            seconds: 15
            milliseconds: 0
        - if:
            - condition: template
              value_template: "{{is_state (cible, 'on' ) }}"
          then:
            - stop: Passage à ON réussi
          else:
            - target:
                entity_id: button.zigbee2mqtt_bridge_restart_2
              data: {}
              action: button.press
            - metadata: {}
              data: {}
              target:
                entity_id: input_boolean.defaut_swon
              action: input_boolean.turn_on
            - delay:
                hours: 0
                minutes: 4
                seconds: 30
                milliseconds: 0
mode: single
icon: mdi:light-switch

Pour appeler le script depuis une automatisation
il faut préciser la cible (ici le contacteur VMC)
Appel swON

1 « J'aime »
33

Bonjour
Je me permets d’ajouter ma Pierre à l’édifice étant du métier du réseau et du système et ce poste étant ultra intéressant.

Pour reprendre les postes de certains oui pour le commun des mortels c’est compliqué et cher de doubler tous les hardware. D’autant effectivement que d’avoir 2 dongles Zigbee ou Zwave en actif passif c’est pas possible ou très compliqué.

Pour ma part et comme dit, j’ai déjà choisi de n’avoir aucune criticité sur HA (chauffage par exemple ou lumière, j’ai donc des inters z wave ou zigbee dans 100% des cas, alarme AJAX). Les boutons restent accessibles. Pour mon chauffage j’ai un thermostat connecté ZWAVE en appairage directe avec le module qui commande le relais de puissance. Si mon ZWAVE est HS (ce qui m’est jamais arrivé en 4 ans contrairement au zigbee) le chauffage marche. Cela me permet de gérer mon chauffage quand tout va bien avec l’intégration régulateur PID proprement et d’avoir un backup au cas ou.

Bref sinon tous nos automatismes que l’on met en place avec HA, bah finalement même si ils ne sont pas critiques, et bien on a du mal à s’en passer… C’est pour ça que j’ai tout de même choisi une installation robuste qui gère aussi ma vidéo surveillance.

Le point important aussi c’est de pouvoir redémarrer au cas ou ses équipements à distance en cas de plantage. Cela m’arrive très occasionnellement à cause de la chaleur dans ma baie info par exemple.
Pour ça la solution est d’avoir un ou 2 mini-PC ou serveurs (Proxmox) avec une carte réseau IPMI ou VPRO (IPMI du pauvre).
Dans le cas ou il n’y a pas de serveur proxmox mais un équipement type Raspberry, le mieux est de l’alimenter en PoE de façon à ce qu’il puisse être rebooter en dur depuis le switch PoE.
En effet dans la pratique les équipements réseaux (switch) plantent quasi jamais donc je préfère à titre perso tout miser sur la fiabilité du réseau contrairement à des mini PC, raspberry ou autre qui peuvent être plus facilement fragiles.

Ensuite niveau protocoles domotiques c’est la même chose, je vais largement privilégier des dongles réseau plutôt que USB plus fragiles. De plus en USB, si on est sous proxmox, ça ne permet pas de faire des migrations de VM facilement. Donc en parallèle de mes minis PC, j’ai un raspberry (avec un disque M2 NVMe forcément pour la faibilité, les OS sur cartes SD, bien trop fragiles) sur lequel je suis en train de basculer mon dernier device USB. Il ne m’en reste qu’un seul car pour la partie Zigbee, il y a un excellent dongle réseau SMLIGHT de plus alimenté en PoE. La cerise sur le gateau quoi (cf-ci dessus) !!. Et le dernier élu est le Z-Wave… Protocole dont je ne me séparerai jamais tant il est fiable et les devices sont paramètrables à souhait.

Vous allez me dire « Oui mais je vais pas doubler le raspberry » !!! Et non car dans cette logique chaque protocole est indépendant niveau réseau et peut être rebooter séparément et si l’un plante, ça ne plante pas tout le reste ! Et encore une fois il n’y a pas de criticité derrière tout ça.

Sinon juste pour info pour la partie mini -PC, j’ai depuis récemment 2 workstation Minis forum MS-01. C’est (juste) top. ports réseaux 2,5G et 10G, plétor d’USB au besoin, VPRO permettant de rebooter à distance même si on pert l’OS proxmox ou si la machine est éteinte, et 3 emplacements M2 qui permettent de faire un peu les configs que chacun souhaite. Ca m’a permis du coup de virer ma clé USB Coral Frigate pour la remplacer par une carte M2 PCIe Coral, une dans chaque machine.

Voili Voilou. J’essayerai de faire une présentation de mon install un peu plous poussée dès que j’ai un peu de temps

1 « J'aime »
34

Super intéressant Naej !
Merci

35

Merci pour ta réponse.
Dans mon cas, la criticité c’est le chauffage et le fait qu’il pourrait soit chauffer à fond ou soit plus du tout si tout s’arrête.

Comme la prise zigbee Legrand est super fiable, je voulais tester le bouding de la prise avec une autre device zigbee programmable comme l’ESP H2 ou le
Lilygo T-Zigbee.
C’est à dire me passer de l’ensemble de l’intégration dans ce mode secours avec juste une device et les prises Legrand.

36

Bonjour
je rajoute l’appel du script en yaml, car on ne peut sans doute pas le faire en mode graphique

action:
  - data:
      cible: switch.vmc
    action: script.swon

Par ailleurs en regardant le code du script, on voit qu’il signale les problèmes sur un input_boolean (switch) qui est utilié comme voyant sur un tableau de bord :
voyants
On a ainsi une idée de la fréquence des défauts.

1 « J'aime »
37

Bonjour
Pour ajouter à la sécurité, il semble qu’on peut avoir un module chien de garde dans HomeAssistant
Ce « Watchdog » vérifie que le serveur répond et sinon fait un reset du Raspberry Pi.
J’espère que ça plante pas les mises à jour.
Voici le lien

38

Dans ce cas, rajoute des relais, en ultra redondance pour avoir une bonne connectivité partout, et le problème est réglé. Bien plus sûrement qu’en rajoutant un 2e serveur.
J’ai 2-3 prises connectées qui n’ont pour but que d’améliorer la qualité de mon réseau dans ma vieille maison aux murs bien trop bloquants.

Et ta routine surveille qu’un appareil se lance… mais ne peut pas vérifier qu’un appareil s’éteint. Donc tu « règles » ton problème de l’allumage, mais pas de l’extinction. Donc pareil pour le chauffage.

39

Bonjour. Il y a bien sûr aussi un script qui surveille l’extinction, il est presque identique. Les voyants montrent qu’on surveille les 2 types de problème.
Et j’ai effectivement rajouté une prise Test1 qui ne sert qu’a relayer les messages dans une zone où le réseau Zigbee est peu dense :

ZigSch
ZigSch743×604 89 KB

Mais la seule chose qui marche vraiment pour moi, c’est le reset de Zigbee2mqtt quand ça commence à planter. depuis que j’ai fait cela, il n’y a plus jamais de ratés sur mes automatismes.

40

Merci pour ces messages.
Je suis curieux de ce Test1 qui surveille le réseau:

  • quel algorithme?
  • comment surveille t’il exactement?
  • et que se passe t’il quand le réseau tombe?

De mon coté quand j’ai ouvert le post j’ai identifié mon point faible comme la raspberry+combee avec une piste que je n’ai pas réussi à faire fonctionner qui est le bind de devices zigbee.