Index de l'article

Depuis que nous sommes installés dans une maison, je rêve de domotiser à tout vas pour ne plus sortir mon cul du canapé pour un oui ou un non. Et donc entretenir mon embonpoint. laughing

Plus sérieusement, pouvoir fermer le volet roulant du salon depuis sa chambre c'est quand même ultra pratique. Tout comme piloter tout l'éclairage de son salon/salle à manger sans se battre avec un des deux jeux de 6 interrupteurs. Ou encore avoir une lecture de la t° et le taux d'humidité dans différentes zones de la maison. Et encore, là c'est seulement les trucs qui me viennent spontanément !

Je me suis donc mis en quête du saint graal pour la sauvegarde de mes poignées d'amour : mettre en place un système domotique chez moi...

Comme tout fainéant qui se respecte, je suis pret à travailler beaucoup, si ça peut me permettre d'en foutre le moins possible par la suite ! wink

Image par Gerd Altmann de Pixabay oui, j'avais pas envie de me faire chier!

Le serveur

Hardware

Mon choix s'est porté sur un Lenovo Tiny équipé d'un processeur I5, 16Go de RAM et un SSD le tout faisant tourner une distro Debian tout ce qui a de plus classique.

Planifiant de l'installer dans le salon, il faut que la machine soit discrète aussi bien point de vue encombrement que nuisances sonores. Et, le I5 installé semble être bien optimisé pour l'économie d'énergie, ce qui m'arrange pour mon serveur, il ne devrait pas trop chauffer et donc rester silencieux.

 

Software

Comme vu ci-dessus, l'OS était déjà choisi, une distro Debian, parfait pour un petit serveur amateur à la maison. En ce qui concerne le software domotique en lui-même, de nombreuse hésitations entre Jeedom, Domoticz, Home Assistant et OpenHab ont motivé une recherche plus approfondie d'informations.

 

 

  • Jeedom est une plateforme opensource mûre, versatile et riche en plugin. Mais, si beaucoup des plugins essentiels sont gratuits, d'autres coûtent jusqu'à 8€, dont certains pour le support de certains sticks de communication sans fils.
    Rédhibitoire à mes yeux.

 

 

  • Domoticz, testé rapidement sous windows, est très simple d'utilisation et de mise en route. Mais me laisse comme un goût de limité et la présentation ne me plaisait pas. (j'ai jamais dis que mes arguments étaient bons hein xD ). Très utilisé à une époque par les francophones, son nombre d'utilisateurs décroit au profit des autres logiciels plus modernes et plus actifs.
    Pas Domoticz non plus.

 

 

  • Home Assistant donne beaucoup de liberté à l'admin, les plugins sont gratuits, l'interface utilisateur est jolie et les nouveauté sont vite intégrées grâce à sa communauté très active. Mais, à l'époque où j'ai commencé à bricoler la domotique, il était réputé pour être instable.
    N'ayant pas envie de reboot le serveur tous les x temps, j'ai passé mon chemin mais laisse une possibilité de revenir dessus par la suite.

 

 

  • Reste OpenHab, open source, 100% gratuit, communauté active là aussi, reste stable grâce à son processus de validation des modifications. Dans sa version 2.x, possède des interfaces web plutôt sympa appelées Paper UI pour l'administration et HabPanel pour l'utilisation courante. Il propose aussi un "cloud" gratuit permettant un accès sécurisé à son serveur depuis internet ainsi que la possibilité d'exposer certaines données pour les exploiter dans des services tiers (IFTT ou autres). Très paramétrable, mais pas toujours depuis son interface graphique, il nécessite de temps en temps de mettre les mains dans le cambouis des fichiers texte. Il n'est pas traduit en français mais ça n'est important que pour l'interface admin, donc aucun soucis pour moi. Il propose aussi des applications clients pour android, iOS et Windows10 permettant de se connecter via réseau local ou via leur "cloud".

 

Communications sans fils

Les protocoles utilisés en domotiques sont nombreux, les plus usités dans nos contrées sont, à l'heure où j'écris ces lignes, ZigBee, Z-Wave, 433MHz (pas vraiment un protocole en lui-même, mais j'y reviendrai plus tard), le WiFi et le Bluetooth.

Des sites spécialisés recommandaient le Z-Wave, c'est donc sans me poser beaucoup plus de questions vers ce système que je me suis dirigé. J'ai commandé un contrôleur USB Aeotec Z-Stick Gen 5, choisi pour sa compatibilité et pour sa batterie qui maintient le réseau Z-Wave en cas de coupure électrique. J'y ai ajouté un capteur multiple de la même marque, histoire de pouvoir tester le fonctionnement, vu qu'aucun appareil n'était compatible Z-Wave dans la maison ^^.

Les périphériques Z-Wave sont très variés, de la vanne thermostatique de radiateur jusqu'au contrôleur de bandes de leds en passant par la motorisation de velux et le détecteur de porte ouverte. Pas de soucis donc pour faire évoluer l'installation avec ce protocole. De plus, il est possible pour les appareils du réseau d'échanger des infos (par exemple entre un capteur de mouvements et une sirène d'alarme) et d'agir en fonction, le tout sans passer par un serveur domotique (il est nécessaire de configurer les périphériques).


Fonctionnement d'OpenHab

Tout est très organisé, dans OpenHab. Je vais passer rapidement sur quelques concepts essentiels, histoire d'être au clair pour la suite ^^.

Add-ons

Dans OpenHab, les add-ons couvrent divers sujets tels que l'interface graphique, la connexion à une DB pour la persistance, ou la gestion d'un nouveau type de réseau domotique.

L'installation et désinstallation des add-ons peut être réalisée à partir de Paper UI, mais peu aussi être faite manuellement en déposant/supprimant le fichier dans le dossier adéquat.

Bindings

Les Bindings donnent les moyens à OpenHab de dialoguer avec un élément extérieur. Qui peut être un contrôleur de réseau hardware (stick usb, ...) ou juste une passerelle software (connexion à un service, ...).

Le binding Z-Wave pour exploiter ces réseaux via un stick USB ou le binding Freebox permettant de lier sa box et récupérer des infos pour les afficher dans l'interface domotique.

Things

Les Things sont la représentation des objets connectés via un binding. Ils contiennent des channels qui sont les canaux de données exposés par le périphérique. Certains objets sont configurables et c'est via l'interface des things que l'on va pouvoir réaliser cette configuration.

Le contrôleur Z-Wave lui-même sera définit en tant que thing, tout comme une ampoule connectée, un capteur, etc.

On peut attribuer un lieu à chaque thing, information exploitée pour l'affichage des things dans l'onglet Control de l'interface Paper UI.

Items

Les Items sont des variables. On doit leur définir un type de donnée à stocker, il est possible les ajouter dans un ou plusieurs groupes, mais pas nécessaire. Les items sont des entités à part entière, ils peuvent être liés à un Thing via un channel, mais peuvent rester "isolé". Les groupes sont des items dont le type de donnée a été définit comme group.

Par exemple, le multi capteur cité plus haut possède deux channels, un pour la température et le second pour la luminosité ambiante. Deux items seront donc créés, l'un lié au channel t°, le second au channel luminosité.
Sur une ampoule connectée, on pourrait avoir un item pour le channel variateur et un second pour le channel t° du blanc...
Et toutes les ampoules pourraient faire partie du groupe définit par l'item Eclairage.

Rules

Les règles sont le système d'automatisation des actions. Un événement va déclencher l'exécution de la règle, cet événement peut être la fin d'un timer ou le changement d'une donnée dans un item.

Par exemple, si la valeur du capteur de luminosité passe sous un seuil entre 17h et 20h, alors on envoie la commande de s'allumer à tous les membres du groupe eclairageSalon.

Il existe plusieurs méthodes pour créer des rules, la coder dans un fichier texte, utiliser l'add-on Rule Engine pour Paper UI (en cours de développement) ou utiliser l'interface graphique intégrée à HabMin (interface qui n'a jamais fonctionné correctement chez moi).

Le codage manuel est évidemment le plus souple, mais demande l'apprentissage de la syntaxe.

L'interface graphique intégrée à HabMin permet de s'affranchir de la syntaxe puisqu'on manipule des blocs à la manière de Scratch. Mais à priori, c'est assez peu utilisé par la communauté.

Le Rule Engine permet de créer des règles simples très rapidement, sans aucun besoin de connaitre la syntaxe.


Premier déploiement

Extrêmement simple un apt-get install plus tard et le serveur démarrait!

Le plus complexe a été d'attribuer les droits d'accès aux interfaces TTY à OpenHab pour lui permettre de dialoguer avec le stick Z-Wave. Quelques éditions de fichiers config plus tard et c'était fait.

Il a ensuite fallu attendre qu'OpenHab termine son premier démarrage et j'étais près à configurer mon stick Z-Wave!

Pour ajouter le stick Z-Wave à OpenHab, installer le "Z-Wave Binding" depuis la page Add-Ons et, sous l'onglet Binding. Une fois le binding installé, il est possible d'ajouter un Thing Contrôleur Z-Wave manuellement. Attention à bien configurer le port TTY correspondant à votre stick Z-Wave.

Reste à lancer une découverte automatique de périphériques Z-Wave et activer le mode appairage sur ce dernier. Si tout se passe bien, un objet unknown devrait apparaitre dans la liste, en un clic sur l'icone verte, il est appairé avec le contrôleur. Une fois appairé, le périphérique va exposer ses différents channels à OpenHab, qui mettra à jour le Thing.

En Z-Wave, cette étape peut prendre du temps. La raison est la suivante : ce protocole est prévu pour économiser la batterie des périphériques. Ils se mettent en veille et ne se réveillent que lorsqu'il y a un changement de valeur pour la transmettre au contrôleur ou lorsqu'on leur envoie des commandes. Les infos du périphérique peuvent donc mettre pas mal de temps à être transmises. Sur certains périphériques, il est parfois possible de forcer la transmission via le même bouton que pour l'appairage.

Maintenant qu'il est appairé et que tous les channels disponibles sont exposés, on peut lier à chaque channel un Item soit en créant un nouvel item, soit en liant un item existant. Permettant l'affichage du Thing avec ses items dans l'onglet Control de Paper UI. Dans mon cas, un capteur multiple qui remonte la t°, la luminosité et qui fait aussi détecteur de mouvements. (jamais réussit à utiliser le détecteur de mouvements correctement)

Du coup, mon capteur me remonte bien la température ainsi que la luminosité de la pièce.

Considérations vis à vis des réseaux domotiques

Le Z-Wave fonctionne plutôt bien, mais les périphériques peuvent être assez chers, de plus mes volets roulants somfy sont déjà pilotables via leurs télécommandes. Il reviendrait cher de remplacer tous les pilotes de volets somfy par des pilotes z-wave. Et en plus, les télécommandes actuelles ne fonctionneraient plus.

Il semble préférable de trouver un stick usb qui permettrait à OpenHab de communiquer avec ces contrôleurs de volets. Comme beaucoup d'actionneurs de volets, portes de garages et autres portails, ils utilisent la fréquence 433MHz (j'avais dit qu'on y reviendrait). Hors un stick quasi "universel" pour les communications sur fréquence existe, le(s) RFXcom. Ils permettent, entre autres, de dialoguer avec les périphériques (liste très loin d'être exhaustive) : Somfy, DIO de Chacon, des stations météo variées, sondes de t° / humidité, de nombreux modèles de climatiseurs, ... Malgré le prix conséquent, je finis par craquer.

Les manipulations sont similaires au stick Z-Wave pour ajouter l'émetteur-récepteur RFXcom. Par contre, pour les périphériques comme les volets somfy, c'est sensiblement différent. J'ai du créer manuellement un Thing Binding RFXcom de type Rfy par volet et lui ajouter l'item Send Program Command. Une fois tout créé, passer un volets en mode appairage en utilisant la télécommandes Somfy, et cliquer sur le bouton virtuel Send program command depuis Paper UI. La télécommande virtuelle d'OpenHab est ajoutée dans le contrôleur du volet. Il ne reste plus qu'à créer l'item de type "rollershutter" et le lier au channel shutter du Things volets et au passage retirer l'item lié à send program command qui est inutile à l'usage courant.

Persistence

A chaque reload de la page control, les informations remontée par mon capteur passent à NaN (Not A Number) parce que les informations précédentes remontées par le capteur ne sont stockées nulle part. Pour éviter ça, la seule solution est d'installer un système de persistance des informations.

La persistance permet , lors d'un reload de la page ou d'un reboot du serveur, de recharger les valeurs précédentes de tous les items configurés pour persister. Mais aussi de générer des graphes pour le suivi des valeurs. De nombreux autres usages sont possibles.

Un nouveau apt-get plus tard et j'ai un serveur postgreSQL fonctionnel, ajout puis configuration de l'add-on JDBC PostgreSQL via Paper UI et finalement création des règles de persistance dans un éditeur de texte.

Dans les règles de persistance, je décide de sauver les valeurs de t°, humidité et luminosité toutes les 30 minutes et à chaque changement de valeur. C'est suffisamment fréquent pour générer des graphes détaillés sans pour autant avoir une masse de données ingérable.

Ayant quelques soucis d'humidité dans la maison (trop d'isolation -> mauvais renouvellement d'air + végétation dense autour de la maison + rivière toute proche), j'ai décider d'équiper la maison de deux capteurs de t° et humidité. Le premier rejoint le salon, le second la chambre. Grâce à ces capteurs et aux graphiques générés grâce à la DB, madame est convaincue d'acheter un absorbeur d'humidité en attendant qu'on puisse investir dans l'installation d'une VMC hygroréglable ou double flux.

Pendant très longtemps j'en reste là, à part une vague tentative d'ajouter un coordinateur ZigBee qui se termine en échec parce que linux-fu en panne complète...

 

Puis le covid arrive et d'un coup, je me dis que merde, c'est con d'en rester là alors que j'ai tout mon temps !

Après un combat acharné, le zigbee finit par fonctionner et pilote une ampoule RGB et un contrôleur de ruban de leds RGBWWCW. \o/


Grande migration

Le Lenovo étant un peu bruyant dans le salon (oui, je suis chiant et j'assume), je me suis finalement dirigé vers un kit rapsberry pi version 4B 4Go de RAM et tout ce qu'il faut pour le démarrer. Installation d'openhab, d'un base de données, tout s'est bien passé, tout était fonctionnel très rapidement.

MAIS !

Mais le raspberry tourne sur un carte SD, OpenHab écrit énormément de données de log etc. Le risque est de tuer la carte SD très rapidement. De plus, je voudrais pouvoir utiliser le rapberry pi pour d'autres choses en parallèle. Donc l'idéal aurait été un bon vieux HDD, surtout qu'en USB 3, on obtient des taux de transfert tout à fait satisfaisants. Hors, à l'heure actuelle, le 4B ne permet pas le démarrage depuis un appareil USB nativement.

C'était sans compter les petits futés qui ont mis au point BerryBoot, un bootloader à copier sur une carte SD qui permet d'installer et de lancer un ou plusieurs OS depuis n'importe quel support (encore merci aux membres du Discord magique pour l'info, vous vous reconnaitrez wink).

Donc, un DL, une installation de raspbian et quelques tests plus tard, tout se passe bien. Le transfert de la config d'une install à l'autre semble bien se passer jusqu'à ce que j'essaye de restaurer la DB et de réactiver le stick ZigBee. Mais au final tout refonctionne et j'arrive même à conserver l'historique des capteurs de t° et d'hygrométrie. (j'écope aussi d'un bon mal de crâne et de tensions musculaires dans les épaules lol)

Par contre le ventilateur de 30mm de côté installé dans le boitier, n'est pas très efficace malgré le bruit qu'il génère. Même sous volté à 3.3V, le bruit dans la maison calme est tellement insupportable que je craque et commande un radiateur passif. Autant en profiter et ajouter un capteur Aqara de température, hygrométrie et pression atmosphérique pour le bureau récemment rafraichi et réorganisé.

Après installation du radiateur passif, je remarque que le CPU tourne à des t° moins élevées sans aucun bruit et même si la carte semble moins protégée des éléments extérieurs, c'est une amélioration non négligeable. A terme, je compte bricoler un boitier qui contiendra le raspberry avec son radiateur passif, le disque dur, une batterie qui fera office d'alimentation de backup et un ventilateur de taille raisonnable. En profiter aussi pour bricoler un contrôleur de ventilo PWM avec sonde de t° wink !Le capteur Aqara est un peu chiant à appairer dans un réseau ZigBee (parce que le capteur ne respecte pas à 100% la norme ZigBee), mais ça fini par passer et les valeurs sont remontées au serveur. Pour appairer "correctement", il aura fallu appuyer à de nombreuses reprises sur le bouton appairer du capteur tout en lançant plusieurs recherches de périphériques ZigBee sur OpenHab.


Création de Règles

J'ai fait le choix d'utiliser le codage manuel pour sa souplesse et sa puissance.

Première tentative

Créons une gestion de "scènes" pour gérer l'éclairage dans le salon (qui pour le moment se limite à ma bête ampoule rgb) :

  • Créer un item de type string dans Paper UI qui servira de trigger.
  • Dans HabPanel, créer un widget de type sélection avec comme valeurs Eteint, TV et Lecture.
  • créer un fichier .rules dans le dossier dédié d'OpenHab2.x
  • programmer !

Code

rule "Salon scenes"  // Définition du nom de la règle
when // Zone de définition du trigger
    Item sSceneSalon changed // Détection de changement de valeur
then
    // Ici se trouve le code exécuté lorsque le trigger est déclenché
    // J'utilise un switch case tout con pour définir quelle scene a été choisie
    switch sSceneSalon.state {
        case "Eteint" : {
            logDebug("ruletest", "Cas Eteint") // un peu de logging pour debug                 // pour chaque élément dans le groupe lampe blanches du salon,
// si l'élément est un variateur et si sa valeur est plus grande que 0, on lui envoie la commande 0
// par contre, si ce n'est pas un dimmer, on envoie la commande OFF
                gEclairageBlancSalon.members.forEach[b|
                        if (b instanceof DimmerItem && b.state > 0) { b.sendCommand(0) }
                        else { b.sendCommand(OFF) }
                ]
                gEclairageCouleurSalon.members.forEach[c|c.sendCommand(0)]
                logDebug("ruletest", "Eteint exécuté")
        }
        case "TV" : {
                logDebug("ruletest", "Cas TV")
                gEclairageBlancSalon.members.forEach[b|
                        if (b instanceof DimmerItem) { b.sendCommand(5) }
                        else { b.sendCommand(OFF) }
                ]
                gEclairageCouleurSalon.members.forEach[c|c.sendCommand(10)]
        }
        [...]
    logDebug("ruletest", "Salon switch case OK")
end

Globalement, toutes les scènes auront exactement la même construction. Seules les valeurs envoyées varieront.

Evidemment, vu le peu de matos installé actuellement, la système de scènes n'est pas vraiment utile. Mais au moins, j'ai une structure de base que je pourrai étoffer par la suite.

Comme par exemple, ajouter la gestion de la température des ampoules blanches en fonction des heures de lever et coucher du soleil ou activer automatiquement la scène TV dans le salon quand on active l'activité "regarder la tv" sur le hub Harmony et que le soleil est déclinant/couché.


Mais comment on l'utilise, ton bouzin?

Ce qui se faisait

La solution historique dans OpenHab, c'est de créer un sitemap qui sera exploitée dans Basic UI.

Pour ce faire, un générateur nommé Home Builder est installé d'office et fait très bien son travail. Dans ce sitemap, on va créer les étages/zones de la maison, pour chaque étage on renseignera les pièces et pour chaque pièces on pourra renseigner les capteurs et autres actionneurs disponibles.

L'interface Basic UI dans toute sa "splendeur"

L'interface n'est ni très moderne, ni vraiment jolie, ni très ergonomique à mon goût (et encore, comparé à Classic UI c'est la fête du slip!)... Mais il faut malgré tout prévoir de créer cette sitemap car c'est la seule UI disponible pour les applications natives  iOS et Windows.

 

Ce qui se fait

PaperUI étant une interface d'administration, c'est HABPanel qui est proposée comme interface facile et rapide à mettre en place, pour l'usage de tous les jours.

L'écran d'accueil, nommé "panneau" dans les paramètres, est un menu, des boutons seront générés pour chaque "tableau de bord" que l'on va créer.

Ces boutons sont redimensionnables et positionnables (dans une certaines mesure vu qu'il "s'empilent" obligatoirement en haut de l'écran) sur une grille dont on va pouvoir régler le nombre de colonnes entre 1 et 6.

Les tableaux de bord sont les écrans dans lesquels on va placer les éléments de l'interface. Le positionnement de ces éléments, nommés widgets dans HABPanel, se fait sur une grille de cases carrées. La grille est divisée en 12 colonnes et autant de ligne que nécessaire pour accueillir les widgets ajoutés, peu importe les dimensions en pixels de votre fenêtre (défilement uniquement vertical). Vous imaginez bien que sur le screenshot à droite, les widgets affichant les valeur font bien plus d'une case de grille. Sur un écran horizontal en 1080P, on verrait probablement au mieux la ligne Salon et le dessus de la ligne Bureau.

Il est donc quasiment impossible de créer une interface qui soit universelle pour format vertical et horizontal. Heureusement il est possible de sauver de multiples configurations de panneau ! Prévoyez au moins 2 formats : un vertical pour votre téléphone et le second horizontal. Un bon conseil si vous prévoyez d'avoir plusieurs écrans de contrôle dans la maison, choisissez des écrans au même format et à la même résolution, ça vous simplifiera grandement la vie.

Boutons, curseurs, voyants et bien d'autres éléments sont des widgets disponibles dans la bibliothèque de base. D'autres widgets créés par la communauté pourront être téléchargés directement depuis l'interface d'édition. Ces widgets sont redimentionnables dans les deux dimensions avec des résultats plus ou moins heureux en fonction de la taille des cases et de leur contenu. Ils sont positionnables partout (contrairement au panneau d'accueil qui "stack" tout en haut), dans la limite des 12 colonnes.

La plupart du temps, après avoir renseigné le ou les items avec lesquels le widget va interagir dans les menus déroulants et sauvé les modifications, le widget est fonctionnel. Certains widgets plus complexes (comme le widget openWeather Map que je veux ajouter à certains tableaux de bord) demandent l'ajout de ressources (images ou autres) à OpenHab pour pouvoir fonctionner.

J'ai choisi un thème sombre histoire de ne pas terminer aveugle quand je l'utilise la nuit, mais d'autres thèmes son fournis d'office. Il est aussi possible d'ajouter une image de fond directement depuis les paramètre OpenHab. Si vous vous y connaissez en CSS, vous pourrez bien entendu créer votre thème perso. 

 

Améliorations

Après avoir ajouté un binding pour open weather map et le widget qui va bien, je me suis rendu compte que sa mise en page ne fonctionnait pas bien sur l'écran de mon téléphone. Quelques éditions de code du widget plus tard...

L'affichage de l'heure est remplacé par la pression barométrique.

Les dimensions des deux colonnes supérieures sont mieux équilibrées et permet d'éviter des retours à la ligne impromptus dans la colonnes des mesures.

Il reste encore quelques soucis de mise en page. La taille du texte casse la mise en page et le CSS sombre ne contient pas la classe mettant la première lettre d'un texte en majuscule.

De plus, le créateur du widget semble ne pas avoir prévu le cas où on voudrait utiliser son widget sur un fond clair. Les icônes pour la l'humidité et la vitesse du vent sont blanche et au format PNG. Pourtant, toutes les autres icônes sont des svg ce qui permet de choisir la couleur de remplissage. Une autre amélioration à réaliser

 L'icône de la pression barométrique n'existe pas, dans un soucis d'unité graphique, il faudra l'ajouter.

 L'icône de t° n'existe pas non plus, il serait envisageable de la créer et d'ajouter l'option de l'afficher ou non...

 

 

 

 

 

Et plus loin

Des utilisateurs encore plus avancés se sont amusés à créer des plans d'étages en .svg de leur maison et à les intégrer dans HABPanel. Ca donne des écrans très simple à utiliser, mais pas toujours très jolis en fonction des compétences en graphisme des créateurs (les goûts et les couleurs).

 Je suppose qu'il ne me reste plus qu'à prendre grossièrement les mesures de la maison et refaire un plan sur un logiciel de dessin vectoriel. Une fois que ça sera fait, il sera possible d'ajouter des éléments pour contrôler les volets directement, des afficheurs de t° et autres directement dans l'image.