Après le Zigbee, c'est le Z-Wave qui est sur sa panse, j'ai fait avec pendant un temps… Puis récemment, le RFXcom ne fonctionnait plus que par alternance. Et là, ça a été la goutte d'eau !
Passant plus de temps à me battre avec OpenHab pour tenter de tout avoir fonctionnel qu'à bosser sur de la vraie automatisation, j'ai décidé d'aller voir si l'herbe est plus verte chez le voisin.
Comme j'avais déjà envisagé Home Assistant lors du premier brainstorming au sujet d'un serveur domotique et que juste après OpenHAb, c'était celui qui me plaisait le plus, c'est donc lui que je testerai en premier (et peut-être en dernier).
En plus, un raspi a été récemment libéré, celui qui s'occupait de mon NextCloud, il est disponible pour servir de “banc test”.
Après avoir etcherisé l'image pour raspi sur un HDD dans un boitier USB3, branché le HDD sur le raspi et zou !
Faut le temps que je me fasse aux grosses différences de philosophie, mais les sticks Z-Wave et Zigbee sont connectés dessus et les différents capteurs et actionneurs sont fonctionnels.
Beaucoup d'outils sous forme d'add-on sont disponibles sur le repo de Home Assistant, par exemple une intégration de VScode version web qui permet d'éditer facilement les fichiers de config du serveur. Ou une DB (ouais, c'est du mariaDB et pas du postgres, mais on fera avec) qui ne nécessite que très peu d'intervention pour être 100% fonctionnelle (ajouter un mot de passe dans la config de l'add-on et une ligne dans le configuration.yaml).
Avec un peu de délais, le RFXcom est lui aussi branché sur Home Assistant, les volets peuvent bien être commandés, tout va bien!
Le système est globalement similaire à OH. Là où on avait des “rules” dans OH, on a des “automatisations” dans HA (alors oui, j'ai mis HA en français, voilà, TUVAFERKWA?) et dans les deux, on a des “scripts”. En plus des “automatisations” et des “scripts” dans la section dédiée à l'automatisation, HA ajoute les “scènes” et les “blueprints”.
Les scènes permettent de définir une liste d'appareils et l'état dans lequel chacun doit se retrouver lorsqu'on active la scène.
Les blueprints permettent d'écrire des “squelettes” de scripts ou d'automatisations, pratique lorsque on a plusieurs comportements similaires à appliquer à plusieurs appareils ou groupes d'appareils différents.
Sous OpenHab, j'avais fini par automatiser (par fainéantise) les volets du salon et de l'atelier bricolol pour qu'ils s'ouvrent à 7:30 du lundi au vendredi et qu'ils se ferment au coucher du soleil. Évidemment, il y avait un bool qui activait ou désactivait cette automatisation.
Sous Home Assistant, ma tentative ira plus loin. A 7:30, en plein hiver, c'est la nuit noire, donc pas grand intérêt d'ouvrir les volets. Par contre en été, à 7:30, le soleil est levé depuis longtemps, mais nous on va à peine faire le café. Ce que je veux, c'est que le volet se lève au plus tôt à 7:30 et au plus tard au levé du soleil.
Comme pour OH, c'est un script qui gérait le plus gros du truc et qui était appelé par une automatisation.
Donc, dans HA, je crée une automatisation dont les triggers vont être :
On y ajoute une “time condition” qui permet de définir une plage horaire, ici entre 7:29 et 23:00.
Et finalement, on appelle le script de gestion des volets.
Les conditions temporelles sont partiellement gérées par l'automatisation, mais vous étonnez pas si je fais de la redondance.
J'ai aussi créé deux booléens, un pour autoriser le fonctionnement automatique, l'autre pour grosso-merdo “vérifier l'exécution du script”.
alias: Script gestion volets sequence: - if: - condition: state entity_id: input_boolean.automatisation_volets state: "on" then: - if: - condition: and conditions: - condition: state entity_id: input_boolean.volets_ouverts state: "off" - condition: sun before: sunset after: sunrise - condition: time weekday: - mon - tue - wed - thu - fri after: "07:30:00" before: "11:00:00" then: - device_id: ********** domain: rfxtrx type: send_command subtype: Up - delay: hours: 0 minutes: 0 seconds: 0 milliseconds: 50 - device_id: ********** domain: rfxtrx type: send_command subtype: Up - delay: hours: 0 minutes: 0 seconds: 0 milliseconds: 50 - service: input_boolean.turn_on data: {} target: entity_id: input_boolean.volets_ouverts - stop: Volets ouverts automatiquement else: - if: - condition: and conditions: - condition: state entity_id: input_boolean.volets_ouverts state: "on" - condition: sun before: sunrise after: sunset then: - device_id: ********** domain: rfxtrx type: send_command subtype: Down - delay: hours: 0 minutes: 0 seconds: 0 milliseconds: 50 - device_id: ********** domain: rfxtrx type: send_command subtype: Down - service: input_boolean.turn_off data: {} target: entity_id: input_boolean.volets_ouverts - stop: Volets fermés automatiquement mode: single
Bah globalement, ça fonctionne toujours, sauf que …
Gros crash du HDD, complètement mort, même pas moyen de récup des données dessus. Qu'à cela ne tienne, on récupère un ssd sata et on réinstalle HA dessus! Ça n'a pas pris bien longtemps, tout était fonctionnel en moins de deux.
Déjà avant la réinstall, un capteur t°/humidité qui déconne. Mais c'est probablement un soucis avec ce modèle particulier de capteur (marque SONOFF). L'implémentation zigbee de ce dernier doit encore avoir été bricolée pour qu'il ne fonctionne correctement sur le long terme qu'avec un contrôleur de la même marque.
Le capteur aquara t°/hygro/baro a aussi merdé, mais encore une fois c'était parce que la pile était HS.
L'automatisation des volets a évolué :
Le fonctionnement est toujours autorisé via un booléen en entrée, histoire de pouvoir débrayer l'automatisation juste avec un interrupteur on/off. Mais aussi avec un scheldule, un petit “calendrier” qui se présente comme suit ↓
Ça ne me sert pas à grand chose pour le moment, mais ça rend la programmation des volets plus versatile. Plus besoin de modifier du code pour ajouter ou retirer un jour, par exemple.
Pour m'amuser j'ai aussi séparé l'aspect pilotage des volets dans un script à part, un “menu déroulant” permet de sélectionner en quel “mode” doivent se mettre les volets. Dans le script d'automatisation, j'exploite aussi cette variable, ce qui m'évite de devoir recoder tous les pilotages de volets à plusieurs endroits. Là, si on fait poser un volet sur une fenêtre, je n'ai que le script de gestion de mode volet à éditer et il sera géré partout.
Beh ça fonctionne toujours ! Malgré les updates, malgré les bidouillages que je fais de temps à autres, malgré les coupures électriques (je sais que les batteries li-ion tiennent au moins une dizaine d'heures :P ), le serveur fait sont taf sans faillir.
Donc là, j'ai réussit à convaincre madame d'investir dans du matos, vu qu'elle constate que ça fonctionne bien depuis longtemps.
Des prises murales encastrées et deux variateurs pour éclairage de type Schneider Wise en zigbee. Un module zigbee pour compteur électrique Linky de marque Lixee. Un détecteur de fumée zigbee de marque Nous. Un thermomètre avec sonde déportée (histoire de pouvoir suivre l'état du dedans du frigo) de marque Owon.
Et de quoi bricoler tout un tas de trucs homemade en wifi et peut être même en zigbee, mais ça, c'est à voir là dedans : Comment domotiser son garage?.
Gros investissement d'un coup, on avait quasi rien à part des capteurs, les volets et 3-4 points lumineux connectés jusqu'ici.