Hello à tous,

je crée ce fil pour partager mon retour d'experience et mon setup domotique.
J'enfonce probablement beaucoup de portes ouvertes pour ceux qui baignent dans le domaine, mais ça permettra (j'espère) de clarifier certaines choses pour les nouveaux arrivants

EDIT : c'est à compléter / améliorer dans les jours à venir

** TODOLIST **
- installer cockpit pour le monitoring de la machine (+ accès terminal)
- installer portainer pour le suivi exhaustif des containers docker
- simplifier le tuto d'installation des containers en exploitant Portainer à la place des lignes de commande (à la place des "docker run" )
- installer un soft (CloudCommander? Xplorer ? pydio ?) pour avoir un webaccess au système de fichier :
- simplifier le tuto de configuration en passant par le webaccess à la place des lignes de commande (création & édition de config)
- installer rtail pour le suivi des logs applicatives
- installer rtail avec watchdog pour monitorer automatiquement les nouveaux fichiers de logs créés
- gérer la persistence de configuration OpenHab dans influxDb
- gérer la reprise sur panne
- rajouter toutes ces applis dans le dashboard de OpenHab

** CHANGELOG **
23-07-2019 : première version : besoins + concepts + choix
23-07-2019 : software : raspbian + docker + OpenHab
25-07-2019 : software : mosquitto + zigbee2mqtt
25-07-2019 : hardware : arrosage
30-07-2019 : software : ajout des entrées sur le dashboard OpenHab
31-07-2019 : software : cockpit
01-08-2019 : software : portainer
27-10-2019 : hardware : nouveau setup à base de miniPC ACute
31-10-2019 : software : ajout de RTail

>>>>>>>>>>>>>>>>
>>> MON BESOIN
>>>>>>>>>>>>>>>>
J'ai récemment emménagé dans un nouvel appart, et je souhaite domotiser une partie de mon installation.
Dans les objectifs à atteindre, j'ai :
1> Piloter mes volets roulants Somfy (via télécommande)
2> Connaitre le statut d'ouverture/fermeture des fenêtres et porte d'entrée : pour partir de chez moi en n'oubliant pas une fenêtre ouverte
3> Avoir des indications sur la température chez moi (dans les différentes pièces) et en dehors de chez moi
4> Pouvoir piloter l'arrosage de mes plantes sur le balcon
 
 
>>>>>>>>>>>>>>>>
>>> MON APPROCHE
>>>>>>>>>>>>>>>>
Une solution :
- ouverte
- évolutive
- stable/fiable
- facile

 
 
>>>>>>>>>>>>>>>>
>>> LES CONCEPTS
>>>>>>>>>>>>>>>>
Je passe rapidement sur la partie "concept domotique" : tout est abordé en détails sur le topic dédié :
https://forum.hardware.fr/hfr/elect [...] et_5_1.htm
Mais ça donne quelques éléments sur mes choix.
 
Concrêtement, il faut :
1] SERVEUR PHYSIQUE
Il doit être connecté au réseau, et avoir des ports USB pour rajouter des extensions/dongles
Ca peut être:
- un Raspberry, souvent conseillé car adapté à ce genre d'usage, cout réduit, bonne maintenance, communauté de dingue
- un NAS (ex: Synology)
- un équipement réseau (ex: Xiaomi Mi router 3G)
- un équipement dédié (ex: Jeedom)
 
 
2] APPLI DOMOTIQUE
Sur ce serveur physique, il faut installer un système de gestion domotique.
C'est lui qui va gérer les différents équipement, les règles pour piloter cet équipement, et offrir une interface pour le piloter (via une page web ou une appli).
Il y a entre autres :
- Jeedom : https://www.jeedom.com/site/fr/
- Domoticz : http://www.domoticz.com/
- Home Assistant : https://www.home-assistant.io/
- OpenHAB : https://www.openhab.org/
- EEdomus : https://www.eedomus.com/fr/
 
Chaque solution a ses avantages et ses inconvénients, il n'y a aucun système qui sort franchement du lot et on se dit "mais oui mais bien sur, c'est celui là !"
(sinon ça se saurait et tout le monde serait dessus).
Néanmoins, Home Assistant a l'air d'être la solution a plus en vogue en ce moment, avec une communauté qui grandit de jour en jour.
 
 
3] SYSTEME D'EXPLOITATION
Ce logiciel domotique a besoin de tourner sur un système d'exploitation : c'est majoritairement du Linux sur ce genre de matériel (très grande disponibilité, demande peu d'entretien, économe en ressources).
La distribution la plus répandue sur Raspberry est la RaspBian : https://www.raspberrypi.org/downloads/raspbian/
une Debian pour Raspberry.
 
 
4] CONTEXTE D'EXECUTION
Certaines solutions domotiques proposent un "package" : une image qui contient l'OS + le logiciel domotique + tout ce qu'il faut pour faire fonctionner tout ça.
Home Assistant => Hass.io : https://www.home-assistant.io/hassio/
OpenHab => OpenHasbian : https://www.openhab.org/docs/instal [...] abian.html
La maintenance est censée être facilitée, mais UNIQUEMENT si le serveur domotique est dédié à ça (sinon ça devient vite le bordel).
 
 
Il existe une autre approche, basée sur les conteneurs.
Mais quessako ?!?
Globalement, l'application n'est pas installée sur le système, mais tourne de manière "isolée" dans un conteneur.
Le conteneur :
- embarque donc tout ce dont l'appli a besoin pour fonctionner (dépendances, autres applis)
- ne pollue pas le système d'exploitation (pas de fichiers éparpillés, etc.)
- est versionné
- peut être démarré, arrêté, supprimé, téléchargé, partagé, etc.
Ca peut être assez pratique, et même si l'approche est originale (déroutante ?), ça apporte au final un gain de temps dans la gestion du système
Docker est le précurseur et le plus commun aujourd'hui : https://fr.wikipedia.org/wiki/Docker_(logiciel)
 
 
5] BUS DE COMMUNICATION
Ce point n'est pas toujours obligatoire, mais peut le devenir en fonction du setup domotique.
Le bus de communication est un concept : Chaque "interlocuteur" (ça peut être une application domotique, un appareil connecté, un autre serveur domotique, etc.) poste et écoute des messages.
Ces messages sont normalisés dans leur format, donc tous les interlocuteurs "parlent le même langage" : ça permet donc d'échanger facilement des informations sans se prendre la tête avec tous les problèmes habituels (pas le même langage, pas de protocole propriétaire, pas les mêmes points d'entrée/sortie, etc.).
En plus, les bus offrent des contrats de service. Ils peuvent par exemple garantir qu'un message émis par un interlocuteur sera bien reçu par son destinataire (pas de messages perdus)
Mosquitto est souvent plébiscité : il a été conçu pour faire bus de communication IOT (Internet Of Things) : https://blog.groupe-sii.com/le-prot [...] dans-liot/
 
 
6] PASSERELLES
De base, tous les équipements réseau TCP/IP sont compatibles, sans aucun ajout nécessaire.
Concrêtement, une ampoule Wifi pourra être pilotée directement...
 
Mais le Wifi est loin de faire l'unanimité dans le domaine de la domotique, et d'autres protocoles sont plus adaptés en fonction des besoins.
Souci : il faut un moyen de communiquer avec les objects connectés qui utilisent ces autres protocoles de communication.
Le "moyen", c'est un appareil "contrôleur", qui va servir de point d'accès au protocole en question (on appelle ça souvent une "gateway" ou une "passerelle" ).
 
Ces passerelles peuvent prendre différentes formes :

• périphérique USB [ex: zigate classique, dongle CC2531, Arduino, etc.] => nécessite des drivers et un logiciel pour le piloter
• borne indépendante qui dispose du Wifi [ex: Xiaomi Gateway passée en "réseau local"] => on communique en Wifi avec la borne, qui se débrouille ensuite pour communiquer sur son protocole
• borne indépendante connectée (nécessite une connexion internet) [ex: Xiaomi Gateway "de base"] => on communique avec les serveurs distants du concepteur de la solution, qui communique avec la borne, qui se débrouille ensuite pour communiquer sur son protocole (NB : pose souvent des problèmes de confidentialité des données... surtout avec du matos chinois : ça passe par internet)

 
Dans mon cas, j'ai besoin de 2 passerelles :
6.1] PASSERELLE ZIGBEE
Le Zigbee https://fr.wikipedia.org/wiki/ZigBee est un protocole basse consommation d'envoi / réception d'évènements.
Il a comme avantage d'être exploité par les accessoires en alimentation autonome (une pile bouton dure plusieurs années). Inconvénient : les appareils émettent lors d'un changement d'état, mais ne peuvent pas être interrogés sur leur état à un instant T.
 
Il est utilisé par les capteurs Xiaomi, les ampoules connectées Philips Hue et Ikea, etc.
Normalement, il faut la Xiaomi Mi Home, qui fait office de contrôleur (+ le pont Philips Hue pour gérer les ampoules de la marque + le pont Ikea pour gérer les ampoules connectées du suedois).
 

 
L'idéal, c'est d'avoir un moyen d'interagir directement sur le protocole Zigbee, sans multiplier les box propriétaires.
Il y a quelques approches différentes
- Ti CC2531: 10€ pour le dongle (comme une clé USB) + 10€ pour l'outil de flash  
- Zigate : 50€ https://zigate.fr/
 
la première solution a quelques avantages :
+ plus abordable
+ plus versatile (on peut mettre dessus le firmware Zigbee que l'on souhaite)
+ est compatible avec Zigbee2MQTT : https://github.com/Koenkk/zigbee2mqtt... qui est une solution sur mesure pour tous les appareils connectés "capricieux" sur le Zigbee, et qui est facilement pilotable via un bus MQTT
- très "bidouille" : il faut la flasher à la main, avec des outils assez bas niveau
 
Une fois installé, des scripts permettent de piloter la majorité des appareils fonctionnant sur le protocole Zigbee 2.4Ghz
 
 
 
6.2] PASSERETTE SOMFY RTS
L'appartement est équipé de volets roulants Somfy qui sont pilotés par des télécommandes sans fil en 433MHz. Il n'y a pas forcément de retour d'état (tout dépend de la génération de Somfy RTZ), c'est donc parfois de l'uni-directionnel (on balance un signal au récepteur du store, qui applique la commande, sans répondre).
 
Il faut donc une passerelle 433MHz pour communiquer avec les stores.
Mais ATTENTION, ce n'est pas aussi simple...
1> Le Somfy utilise des messages en 433.42Mhz, alors que le "433MHz" commercial est souvent en 433.99MHz. Il en résulte des difficultés à communiquer avec les stores Somfy lorsque l'on a une passerelle qui emet sur le 433MHz "standard".
2> Les messages sont envoyés avec codes tournants (deux impulsions successives sur le même bouton d'une télécommande n'envoie pas exactement le même signal). Il faut être capable de construire ces messages à code tournant.
 
Il faut donc un appareil capable de gérer la transmission à 433Mhz et le système de codes tournants de Somfy.
Il y a très peu d'appareils compatibles. Les plus connus sont :
- RFXCOM RFXtrx433E : 80€ http://www.rfxcom.com/epages/78165 [...] cts/14103R
- RFPlayer : 120€ https://www.planete-domotique.com/t [...] iblue.html
- RFLink fait maison : 30€ http://domo-attitude.fr/montage-et [...] re-rflink/ si construit à la main
- RFLink monté : 45€ https://www.nodo-shop.nl/en/rflink- [...] cable.html en version "propre" monté sur une carte mère (et pas un sac de fils), avec antenne externe (attention, pensez à rajouter la prestation "soudure" )
 
Le RFXCom peut être utilisé avec un plugin pour l'interfacer sur un bus MQTT : https://github.com/destroyedlolo/Marcel
idem pour le RfLink : https://github.com/SensorsIot/RFLink-MQTT-Gateway
 
Le RFlink est de loin le moins cher de tous pour le modèle fait à la main, mais il demande beaucoup de travail.
La version "montée" de nodo-shop a l'air d'être le meilleur compromis possible.

>>>>>>>>>>>>>>>>
>>> MES CHOIX
>>>>>>>>>>>>>>>>
je précise bien : MES choix, qui n'engagent que moi. A partir de tous ces concepts, j'ai donc choisi pour faire mes premiers pas :
1> un serveur physique Raspberry Pi 3B+
Normalement assez puissant, abordable (30€), robuste, facilement remplaçable en cas de panne, et bien supporté par les couches logicielles.

 
2> une solution domotique OpenHab
J'aime l'approche définie par Eclipse IOT, qui pose les concepts propres et réfléchis de ce que doit être la domotique, et comment elle doit être gérée (OpenHab est basé dessus).
C'est une solution basée sur Java, langage que je manipule fréquemment, donc plus facile de me dépatouiller en cas de problème.
La communauté est importante et active (mais surtout allémante)
Le logiciel évolue, avec des version majeures régulières qui apportent de grosses améliorations
 
3> un système d'exploitation Debian
Une distribution Linux avec un bon suivi et une très grosse communauté.
De loin la solution la plus populaire pour sur Raspberry (sous le nom de Raspbian)
 
4> un système de conteneurisation Docker
Pour isoler mes différents "aspects" et ainsi faciliter la maintenance, limiter la pollution du système, et pouvoir plus facilement gérer la montée de version
 
5.1> une passerelle Zigbee CC2531 + Zigbee2Mqtt
Zigbee2Mqtt est le projet le plus actif à ce jour sur le support des périphériques Zigbee "spéciaux" (i.e. qui ne respectent pas scrupuleusement les specs)... comme les Xiaomi.
Cette solution impose de passer par un bus MQTT. J'ai donc choisi un bus Mosquitto pour faire ça
 
5.2> une passerelle SomfyRTS RfLink
ouvert, abordable, qui m'a l'air performant.
et le protocole de pilotage est très simple à mettre en oeuvre (des simples commandes textuelles communiquées à la passerelle, qui se démerde pour envoyer la bonne trame correspondante), là où le RfxCom fonctionne en binaire.

>>>>>>>>>>>>>>>>
>>> ACHAT DU RFLINK
>>>>>>>>>>>>>>>>

Le RfLink nécessite :
1- une carte Arduino pour faire le lien entre l'USB et l'émission/réception RF
2- un module RfLink

on peut acheter le kit directement sur le site de nodo.nl
https://www.nodo-shop.nl/en/rflink- [...] cable.html
ATTENTION : le kit n'est pas soudé !
Pensez à prendre l'option soudure à 5€ si vous voulez recevoir un kit pré-assemblé.

>>>>>>>>>>>>>>>>
>>> SETUP DU RFLINK
>>>>>>>>>>>>>>>>

inspiré de ces tutos :
1> le programmer : https://easydomoticz.com/rflink-un- [...] ateriel-2/
2> l'associer comme télécommande des stores existants : https://matdomotique.wordpress.com/ [...] -et-somfy/

1] FLASH DU ARDUINO
1.1] - récupérer la dernière version du Firmware
disponible ici : http://www.rflink.nl/blog2/

1.2] - connecter le Arduino Mega en USB sur le PC
pas besoin d'une alimentation supplémentaire

1.3] - Flasher
(cf. https://easydomoticz.com/rflink-un- [...] ateriel-2/ )
Décompresser le firmware.
Lancer le logiciel RFLink Loader
- se placer sur le port série correspondant
- en haut à gauche, choisir "select file" et pointer le fichier présent dans le dossier du firmware
- cliquer sur "upload/program firmware to device"

2] ASSOCIATION DES TELECOMMANDES
via le logiciel RFLinkLoader contenu dans le package du Firmware.
(cf. https://matdomotique.wordpress.com/ [...] -et-somfy/)

2.1]  - Configurer le RFLink loader pour interagir avec l'arduino
- se placer sur le port série correspondant
- dans la partie "logging", cliquer sur "Serial port logging"

2.2] - Lister les commandes enregistrées
dans la zone "command to send", envoyer cette commande :

la table des télécommandes virtuelles s'affiche dans la log :

2.3] - préparer la commande d'appairage
dans la zone "command to send", préparer le contenu de la commande /!\ mais ne PAS l'envoyer /!\

0F0FF2 => identifiant de la télécommande (que l'on choisi)
0200 => indice de départ du rolling code (sur 4 digits !)
2 => zone mémoire dans laquelle mettre le réglage

2.4] - passer le store en mode appairage
prendre la télécommande Somfy existante et appuyer quelques secondes (3s au moins) sur le bouton situé à l'arrière.
Le store correspondant doit faire un bref aller/retour

2.5] - lancer la commande d'appairage.
Le store doit refaire un aller/retour pour indiquer qu'il a bien reçu le message

2.6] - tester le fonctionnement du store
il est ensuite possible de piloter le store via les instructions suivantes :

>>>>>>>>>>>>>>>>
>>> ACHAT DU CC2531
>>>>>>>>>>>>>>>>
instructions ici : https://www.zigbee2mqtt.io/getting_ [...] _need.html

Concrêtement il faut :
1> une clé USB avec une puce CC2531
2> un debugger pour programmer la clé (installer le firmware)
3> un cable pour faire la connexion entre le débugger et la clé USB

Il y en a pour 15€ environ sur Aliexpress (forte inflation depuis 2018 )

>>>>>>>>>>>>>>>>
>>> SETUO DU CC2531
>>>>>>>>>>>>>>>>
TODO

>>>>>>>>>>>>>>>>
>>> INSTALLATION ARROSAGE
>>>>>>>>>>>>>>>>

Le but : piloter l'arrosage des plantes qui sont dans les bacs de mon balcon.

je connecte le tout sur un robinet d'eau (format classique 3/4" G français pour l'arrosage / l'alimentation de l'électroménager) sur l'extrémité du tuyau chromé (là où l'on distingue une pastille bleueu, en haut à gauche de la photo)
Et je peux piloter ça via une prise connectée. Chez moi la prise est une Osram Bulb+ (Zigbee), mais on peut utiliser n'importe quel type de prise connectée (le but est de piloter avec une prise ON/OFF)

J'ai pris volontairement du matos assez "qualitatif" pour limiter les risques de fuite/panne.
Je voulais une électrovanne normalement fermée (se coupe automatiquement en cas de coupure d'alimentation), et des éléments en acier/laiton en amont (et pas les trucs en plastique mal ébavuré comme les programmateurs d'arrosage à 50€ en magasin de bricolage...   )

DETAIL DU KIT

5,61€
Tuyau d'alimentation Inox - 3/4" G femelle-femelle - 50cm de long
https://fr.aliexpress.com/item/LF16 [...] 05900.html

2,60€
 Adaptateur secteur 220V AC vers 12V DC - Prise Française
https://fr.aliexpress.com/item/Powe [...] 98722.html

16,30€
Electrovanne professionnelle - Normalement Fermée - 3/4" type G (NTP) - pilotée en 12V DC
https://fr.aliexpress.com/item/Free [...] 56638.html

3,04€
2 adaptateurs mâle-mâle 3/4" G (pour raccorder l'électrovanne au reste du circuit)
https://fr.aliexpress.com/item/wxrw [...] 40240.html

6,75€
Système de micro-irrigation goute à goute 15m de tuyau + 20 diffuseurs
https://fr.aliexpress.com/item/Micr [...] 06225.html

moins de 35€ pour le tout.
ça fonctionne parfaitement

>>>>>>>>>>>>>>>>
>>> SETUP RASPBIAN SUR RPI
>>>>>>>>>>>>>>>>

j'utile mon Raspberry uniquement en serveur.
il n'est jamais (et n'ai jamais été) connecté en HDMI à un écran, ou à un clavier + souris.
je donne donc de quoi l'installer et l'administrer à distance dans les meilleures conditions possibles.

========
FIRMWARE
========

1- préparer l'image raspbian
sur une carte microSD, installer l'image de Raspbian (on trouve plein de tutos sur le net)
ATTENTION : préférer une version stretcher plutôt que buster (mieux supportée) :
https://downloads.raspberrypi.org/r [...] 019-04-09/

2- activer le SSH
créer un fichier 'ssh' dans la partition boot de la carte SD (la seule partition visible depuis Windows).
ça permettra au raspberry d'activer sa connexion ssh

3- démarrer le raspberry
mettre la SD dans le raspberry et le démarrer... patienter 2min, la led verte doit clignotter

4- se connecter en SSH sur le raspberry (password = raspberry)
depuis MacOSX via le terminal, depuis Windows via Powershell

ou

5- changer le Password

6- mettre à jour le système

7- redémarrer le raspberry (conseillé après une première installation)

============
REMOTE ACCESS
============
pour pouvoir se connecter à distance sur le desktop du raspberry (comme si on avait un écran directement connecté dessus)

1- installer le serveur RDP

2- configurer l'accès

3- déclarer un "écran" virtuel sur le serveur

4- se connecter sur le raspberry depuis un accès Windows "remote connection"

ou depuis MacOSX via la combinaison 'command' + K dans un finder
adresse de l'hôte + ':' + id de l'écran (ex: raspberry.local:1 )

5- mettre le serveur VNC en startup
dans /home/pi/autostart/
créer un fichier tightvnc.desktop

>>>>>>>>>>>>>>>>
>>> SETUP DEBIAN SUR ACUTE PC
>>>>>>>>>>>>>>>>
suivre le tuto présent sur le topic dédié.
 
lors de l'installation, on peut cocher la case "ssh" pour activer la connexion SSH.
(à ne faire que si vous souhaitez activer le SSH de base sur la machine, sans passer par une extension tierce (je pense notamment au plugin SSH sur hass.io)
 
En tips :  
1> pour désactiver la mise en veille, une fois connecté en ssh sur le acute :

 
2> pour forcer l'heure système et la persister d'un redémarrage à un autre (attention, l'heure est RESET à chaque fois que l'alimentation est coupée)  

 
>>>>>>>>>>>>>>>>
>>> SETUP HOME ASSISTANT
>>>>>>>>>>>>>>>>
en premier lieu, vérifier que la command apt fonctionne correctement :

 
suivre les instructions sur la page de hass.io :
https://www.home-assistant.io/hassi [...] reparation

===========
MONITORING / WEB TERMINAL
===========
l'appli Cockpit est idéale pour pouvoir monitorer le fonctionnement du Rpi sans devoir se connecter dessus en ssh.
instructions issues du tuto disponible ici : https://eercan.com/post/monitoring- [...] g-cockpit/
 
C'est une des rares applis que j'installe en dehors de docker, pour la simple et bonne raison que cette appli de monitoring a besoin d'avoir un accès complet à la machine pour pouvoir la monitorer... alors que le principe des container est justement d'isoler au maximum l'execution de l'appli de la machine hôte.
 
1- installer le package
il faut rajouter un nouveau repo, les clés associées (et donc de quoi rattacher les clés)

 
et on peut enfin installer l'appli

 
2- accéder à l'interface de monitoring
https://raspberrypi:9090/
 
au besoin, passez outre l'alerte de sécurité (le serveur est en https, mais sans certificat authentifié)

 
se logger avec les identifiants du pi (comme en ssh)
loggin : pi
pwd : mot de passe du pi
cocher la case qui propose d'utiliser le même mot de passe pour les élèvations de droits :

 
 
 
L'interface donne accès à toutes les statistiques du serveur et aux users, et offre un web terminal :

 
 
3- installer l'extension docker pour cockpit
pour pouvoir piloter les containers docker depuis cockpit  

 
se delogger et relogger.
il y a maintenant une nouvelle entrée "container" qui expose les conteneurs docker et permet de les manipuler
(lancer un container, une image, etc.)
... enfin, une fois que vous avez docker installé    
 

 
 
 
 

=======================
GERER LES PERIPHERIQUES USB
=======================
de base, les dongle connectés en USB apparaissent sous la forme de "device" /dev/ttyACM*, ou le * est un chiffre qui correspond à l'indice de l'appareil.
problème :
- cet indice est alloué dynamiquement à la connection du dongle, et n'est pas garanti. on a donc des appareils dont l'identifiant change au gré des redémarrages et des déconnexions .
 
Heureusement, Linux crée automatiquement un alias basé sur les caractéristiques du périphérique (fabriquant, modèle, numéro de série)
pour retrouver cet alias dynamique :

et on a la liste des périphériques série (comme un dongle CC2531 ou un RFlink) qui apparaissent :
 

 
il suffit de renseigner les chemins complets (donc précédé du /dev/serial/by-id/ ) où c'est nécessaire
 
 
 
ANCIENNE METHODE OBSOLETE ET INUTILEMENT COMPLEXE
0> créer un groupe qui possèdera les droits d'accès aux devices personnalisés

 
1> lister les devices connectés

liste les connecteurs "ttyACM" du Raspberry... mais difficile de s'y retrouver.
 
2> identifier les devices connectés
petite commande sympa pour retrouver quel périphérique USB est connecté sur quel port logique :

 
bilan :  
ttyACM0 = CC2531
ttyACM1 = RfLink
 
3> définir des alias pour avoir une affectation systématique sous le même nom
en reprenant le résultat de la commande précédent, on a accès aux informations techniques de chaque périphérique USB :

 
A partir de là, on peut définir une rule qui va automatiquement créer un alias pour le périphérique, en se basant sur ses caractéristiques (identifiant vendeur, identifiant produit, etc.)
la syntaxe a cette forme, à mettre dans un fichier dans /lib/udev/rules.d :

 
 
en pratique, dans mon cas, dans un terminal sur le rpi :  

 
j'ai donc maintenant un périphérique /dev/ttyUSB_cc2531 à chaque fois que je connecte ma clé Zigbee, et/ou que je redémarre mon Rpi, et un périphérique /dev/ttyUSB_rflink pour mon RfLink
ces périphériques sont accessibles par tous les users du groupe "device"
 

>>>>>>>>>>>>>>>>
>>> SETUP DOCKER
>>>>>>>>>>>>>>>>

1- aller dans le dossier Downloads

2- récupérer et lancer le script d'install auto

3- modifier les droits de docker pour autoriser les lancements sans élèvation de droits

4- redémarrer le raspberry

5- tester le fonctionnement de docker

Portainer permet de gérer l'instance docker, et tout ce que l'on peut faire avec : administrer les containers, les images, etc.
instructions ici : https://portainer.readthedocs.io/en [...] yment.html

6- créer les dossiers de persistence de portainer

7- lancer le premier container : portainer

8- accéder à l'interface web de portainer
http://raspberrypi:9000/
créer le user "admin"

Toute la suite du tuto exploite des containers docker (1 container par application).
Dans le tuto, chaque container est lancé via des lignes de commandes rentrées dans un terminal, mais il est possible de tout faire via l'interface de Portainer

on peut améliorer le setup de Portainer en rajoutant des certificats pour le https :

>>>>>>>>>>>>>>>>
>>> SETUP CLOUDCOMMANDER
>>>>>>>>>>>>>>>>

CloudCommander est un browser via une interface Web.
Il permet de se déplacer dans l'arborescence et les drives d'une machine, de visualiser les fichiers, de compresser/décompresser, de transférer, d'éditer, et offre même un terminal pour effectuer des opérations sans avoir à se connecter en SSH.

Ca parait pas mal sur le papier, en pratique ça peut être pratique, puisque ça offre une interface bien plus "user friendly" pour manipuler et administrer son serveur domotique (surtout si on n'a pas d'écran connecté dessus)

1- créer l'image Docker
cloudcommander peut fonctionner dans un container docker.
souci, l'image Docker existe, mais elle n'est dispo qu'en x86 (donc pour processeur Intel/AMD de PC "classique" ). Le RPi a une architecture ARM (smartphone en gros), et n'est donc pas capable de faire fonctionner l'image existante.
On va donc devoir créer une image "perso".

A> dans le dossier /Documents du user "pi", on va donc se créer de quoi construire l'image docker de cloudcommander.
et ça passe par un fichier qui porte le nom de "DockerFile"

ce fichier contient les instructions pour construire l'image, qui sont dans notre cas (avec nano par exemple)

B> on construit l'image

après quelques minutes, on a une image créée, qui porte le nom du tag qu'on lui a donné (via le -t <montag> dans la commande docker build)

2- lancer l'image Docker cloudcommander
reste à lancer l'image fraichement crée.
REMARQUE : l'explorateur de fichier va tourner dans le container, il aura donc accès au système de fichier de l'intérieur du container, et pas le système de fichier du système hôte qui fait tourner docker... il faut donc rattacher le système de fichier de Raspbian dans le container docker

on peut alors accéder à l'interface de cloudcommander à cette adresse : http://raspberrypi:8080
attention : le système de fichiers du raspberry est dans le dossier /mnt/fs !

>>>>>>>>>>>>>>>>
>>> SETUP RTAIL
>>>>>>>>>>>>>>>>

RTail est une solution Web pour pouvoir suivre les modifications et le contenu de fichiers. Il est particulièrement adapté au suivi des fichiers de log !
https://github.com/kilianc/rtail
Il fonctionne sur la base d'un serveur, qui gère l'affichage Web
et d'un client par fichier suivi, qui va envoyer les dernières lignes du fichier vers le serveur.

Comme pour CloudCommander, il n'existe pas d'image directement exploitable en ARM pour un Raspberry.
On va donc devoir en créer nous même.

Pire que ça : coté client, RTail est initialement conçu pour suivre un fichier spécifique à partir d'une commande entrée explicitement par l'utilisateur.
Dans notre cas, on souhaite suivre automatiquement les fichiers du dossier de logs, et rajouter automatiquement les nouveaux fichiers.
On ne va donc pas avoir un container docker par fichier à suivre, mais un container docker par dossier de log à suivre, et ce container va se charger de créer et gérer autant de RTail que nécessaire pour suivre chacun des fichiers de logs de ce dossier.

Ce tuto est inspiré de :
https://github.com/Maluuba/docker-f [...] ail-server
https://github.com/Maluuba/docker-f [...] cker-rtail

COTE SERVEUR>
il faut créer un fichier Dockerfile "custom" pour pouvoir créer l'image, et mettre les instructions suivantes dedans

puis créer l'image du Serveur depuis de Dockerfile avec cette ligne de commande (docker utilisera automatiquement le Dockerfile présent dans le dossier courant, et pousse l'image générée dans le repo d'images de la machine) :

et enfin lancer le container docker depuis l'image avec cette ligne de commande :

le server Rtail doit normalement démarrer, et être accessible sur le port 8188 : http://raspberrypi:8188

COTE CLIENT>
Il faut là aussi un Dockerfile custom :

et un fichier rtail-client.sh à coté du Dockerfile avec ce contenu :

Ce script permet de :
1> Monitorer dans rtail tous les fichiers qui ont été modifiés dans les TAIL_TEMPO minutes avant le lancement du script.
2> Monitorer automatiquement chaque nouveau fichier créé dans RTAIL
3> Associer à tous ces fichiers le préfixe TAIL_PREFIX dans l'interface du serveur rtail.

Pour construire l'image Client depuis de Dockerfile

Il est ensuite possible de lancer un container client sur le dossier de logs de son choix :

Donc en pratique :

pour OpenHab

pour zigbee2mqtt

pour mosquitto

En revenant sur la page Web du serveur rtail, vous devriez voir les entrées des différents fichiers de logs des différents services.
(dans mon cas on voit clairement dans les logs du mosquitto que mon OpenHab essaie d'initier le RfLink sur un device qui n'existe pas : /dev/ttyACM1)

>>>>>>>>>>>>>>>>
>>> SETUP MOSQUITTO / DOCKER
>>>>>>>>>>>>>>>>

Mosquitto sur RPi : https://projetsdiy.fr/mosquitto-bro [...] pberry-pi/
container = eclipse-mosquitto (officiel)

1- créer les dossiers pour la persistance & le user mosquitto

et rajouter ces lignes de configuration dans le fichier

2 - récupérer et lancer le container mosquitto
https://hub.docker.com/_/eclipse-mosquitto/
(interactif)

vérifier qu'il n'y a pas de message d'erreur de droits, et que le fichier de logs est correctement généré

(daemon)

>>>>>>>>>>>>>>>>
>>> SETUP ZIGBEE2MQTT / DOCKER
>>>>>>>>>>>>>>>>

https://github.com/Koenkk/zigbee2mqtt/wiki/Docker
1- créer les dossiers pour la configuration

2 - lancer le container en interactif

3 - modifier la configuration
le fichier de configuration doit avoir été créé dans le dossier /opt/zigbee2mqtt/data
modifier l'adresse du serveur MQTT & activer la détection :

4 - lancer le container en daemon

>>>>>>>>>>>>>>>>
>>> SETUP INFLUXDB / DOCKER
>>>>>>>>>>>>>>>>

InfluxDb = base de données TimeSeries
Chronograf = appli Web permettant d'administrer une base InfluxDb
Telegraf = appli de récupération d'indicateurs système (pour avoir des stats et un suivi de la machine)

https://hub.docker.com/_/influxdb
1- créer les dossiers pour la persistence

2- générer la configuration et l'éditer si besoin

3- lancer le container

https://hub.docker.com/_/chronograf
4- créer les dossier pour la persistence Chronograf (admin & visualisation)

5- lancer le container Chronograf

6- se connecter sur l'instance Chronograf
http://raspberrypi:8888
à la première connexion, Chronograf propose de créer des dashboards pour divers systèmes.
choisissez Docker dans la liste.

7- rajouter l'entrée Chronograf sur le dashboard openhab

https://hub.docker.com/_/telegraf
8- créer les dossiers pour la persistence

9- générer la configuration

10- éditer la configuration
dans la catégorie [[outputs.influxdb]],
spécifer la base influxDb à utiliser :

descendre dans le fichier de conf jusqu'à la section INPUTS,
et rajouter une entrée pour pouvoir auditer les stats docker

11- lancer le container

en retournant sur Chronograf et en cliquant sur Dashboard > Docker, toutes les stats doivent apparaitre :

>>>>>>>>>>>>>>>>
>>> SETUP OPENHAB / DOCKER
>>>>>>>>>>>>>>>>

tuto complet ici : https://docs.openhab.org/installation/docker.html
1- créer l'utilisateur openHab et son groupe

créer les dossiers & les rattacher au user

2- identifier le container à lancer
https://hub.docker.com/r/openhab/openhab/
c'est normalement : <version>-<archi>-<distrib>
version = 2.4.0
archi = armhf
distrib = debian

3- lancer le container docker en interactif

(pas besoin de spécifier les ports, on est en --net=host)
(pas besoin non plus de spécifier le user : le user openhab a déjà été créé avec les bons droits)

l'interface Openhab est dispo à cette adresse : http://raspberrypi:8080

... en profiter pour installer le plugin SerialRxTx [nécessaire pour RfLink]

via la  console (geek inside):

si besoin après s'être connecté à la console openhab du container docker avec cette commande:

ou via l'interface (pour les humains "normaux) :
en installant le plugin "Serial Button" dans Paper UI > Addons > Binding
(ce binding installe automatiquement la couche de transport série en dépendance)

... ainsi que le plugin MQTT (nécessaire pour exploiter la couche MQTT, même sans le rendre explicitement actif) [nécessaire pour Zigbee2MQTT]
aller dans l'interface Paper UI > Addons > Binding, et taper "MQTT" dans la barre de recherche.
cliquez sur le "Install" à coté de MQTT Binding

... et pour installer la dernière version des bindings
à placer dans le dossier "addons" créé précédemment :
RfLink : https://github.com/cartemere/org.openhab.binding.rflink
Zigbee2MQTT : https://github.com/nibi79/zigbee2mqtt

4- éditer la configuration
pour pouvoir rajouter des entrées ensuite dans le main dashboard

rajouter directement une entrée pour Cockpit qui a été installé précédemment

en profiter pour rajouter les images / logos des différentes entrées que l'on va rajouter :
(chaque image est à sauvegarder dans le dossier /opt/openhab/conf/static/ )
chronograf.png

cockpit.png

portainer.png

5- lancer le container docker en daemon

6- [si besoin] connexion au container docker et accès à la console OpenHab
pour accéder directement à la console : (pwd = habopen )

pour accéder au container docker :

Dur dur pour les noobs...

Drapal aussi ça m'intéresse beaucoup !

J'ai posé un favoris, pas besoin de poser un  , mais je te remercie tout de même pour les infos  

Merci pour l’initiative.
 
(Drap masqué)

drapoual

Drap

j'ai rajouté les alias sur port USB pour avoir toujours les mêmes noms de périphériques quelque soit l'ordre de branchement
+ Cloudcommander (avec création d'une image custom pour Raspberry)

drap

Drap

Une petite photo de ton installation raspberry pi ? Je suis curieux de voir à quoi ça ressemble avec tous les modules au cul

Euh, j'ai pas de photo sous la main, mais j'ai que 2 ports usb utilisés.
Un pour la clé Zigbee
Un pour le RfLink pour taper le Somfy.

Je suis en train de migrer tout ça sur un mini PC x86 à base d'atom + 8Go de RAM pour être plus a l'aise.
Mais je vais finir le tuto sur Rtail

voilà ce que ça donne (encore posé à l'arrache sur un coin du bureau )

Le RPi B3+ en haut, avec:
- Alim micro USB
- réseau Ethernet
- Clé USB CC2531 Zigbee (avec la led verte)
- Cable USB vers l'arduino (cable USB bleu)
 
et en dessous l'Arduino avec son circuit pour le RFLink, et l'antenne déportée en dessous
 

Merci, un joli bordel
 
Vu que tu dockerises tout, je pense que ça pourrait être intéressant que tu partages tes dockerfiles / docker-compose.
 
Enfin j'imagine que tu vas utiliser docker-compose pour tout réinstaller d'un coup si un jour ton rpi crash.

je vais pousser tous les DockerFile + Docker-compose sous mon github, vu que je suis en train de switcher du RPi vers un ACute PC

Je profite d'un jour de congés pour rajouter le setup de RTail :
https://forum.hardware.fr/hfr/elect [...] tm#t266099

mais la solution me plait à moitié :
- ça fait un port de plus utilisé pour une interface Web
- le projet n'est plus maintenu depuis des années maintenant (dernières modifs en 2015)
- il y a quelques bugs référencés, qui ne seront probablement jamais traités.

je regarde pour utiliser les inputs de Telegraf et injecter les logs dans InfluxDB...
Ca a l'air bien puissant, mais un peu compliqué à mettre en place (notamment pour le parsing des logs)

Comme promis, voici ma configuration DockerFile (pour le ACute en x86, donc avec les images déjà existantes) :
 
j'en ai profité au passage pour rajouter une stack ELK (ElasticSearch + Logstash + Kibana) et un MetricBeat pour alimenter tout ça.
je teste ça en parallèle du combo InfluxDB + Telegraf + Chronograf et je ferai mon choix ensuite

Hello, je me tâte suite à l'achat d'un Synolgy DS218+ : Docker ou VM ?
 
J'utilise Domoticz mais ça change pas grand chose. Est-ce "grave" de mélanger docker (MQTT, domoticz par exemple) et une VM (pour juste python ?)
 
Mon soucis principal c'est la gestion de la connexoon (Somfy) qui nécessite un script en python3 qui tourne en tant que service (donc interdit le docker ?)
 
Merci

je comprends pas trop ton problème...
 
tu peux tout à fait lancer un container Docker pour faire tourner du Python, et interfacer ce container Docker avec d'autres containers Docker.
 
Il est aussi possible de "mélanger" des applis qui tournent en natif sur la machine et des applis conteneurisées.
 
Sur un DS218+, tu as un CPU intel X86, donc accès nativement au support Docker via les packages Synology.

Je me demandais si il était possible qu'un conteneur docker fonctionne avec un autre mais apparement le script python sert juste de "serveur" et peut même être mit sur une autre machine donc ca devrait aller ..
 
Il faut que je regarde du côté des containers docker python 3

un container docker peut parfaitement fonctionner avec un autre, tant que cles interactions se limitent à des fichiers / sockets / ports réseau
 
Il n'y a pas à ma connaissance de lien "direct" pour merger 2 containers, mais rien ne t'empêche de venir aggrémenter une image de service existante pour lui rajouter d'autres services.

 
???
 
Et pourquoi ça ? C'est pas un souci normalement : https://runnable.com/docker/python/ [...] pplication    
 
et d'autres infos : https://www.linickx.com/docker-your-python-scripts
 
Mais surtout, l'intérêt d'avoir un docker pour juste tourner un script est plus que limité donc autant le lancer sur ta machine qui host tes containers, c'est plus simple.

bah l'intérêt c'est d'éviter d'avoir python qui tourne en natif sur la machine, mais dans un container :  
plus de flexibilité pour mettre à jour, pour éventuellement tester une version alternative, etc.