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. Le futur prouvera que j'avais tort à propos des nuisances sonores.

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 (pour mon usage) 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.
  Ayant peur de cette réputation d'instabilité, 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.

Mise en route du serveur

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). Or 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.

Satisfait ?