Grande migration

Le Lenovo étant un peu bruyant dans le salon (oui, je suis chiant et j'assume), je me suis dirigé vers un kit rapsberry pi version 4B 4Go de RAM et tout ce qu'il faut pour le démarrer.

J'ai effectué une rapide installation d'openhab et d'une base de données sur une carte µSD pour tester comment ça se comporte. Après tout, c'était mon premier contact avec un raspi (j'en avait jamais vraiment eu l'utilité jusqu'ici.
Tout s'est bien passé, openhab était fonctionnel très rapidement.

MAIS !

Mais 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. UPDATE : Ils sont maintenant parfaitement capables de boot sur USB sans aucun souci.

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 reconnaîtrez). BerryBoot,maintenant inutile pour boot un raspi 4b sur partir d'un stockage USB, est toujours utile si on veut faire du multiboot.

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 rafraîchi 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 boîtier 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°!

Le capteur Aqara est une plaie à 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 réussir à 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.

Évidemment, 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'é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 redimensionnables 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.

Mise à jour