Il y a un peu plus d'un an j'écrivais un article pour exprimer mes questionnements quant à l'évolution de la Zibase vers Jeedom. Jeedom n'est pas la panacée, mais c'est une boite à outils. Voici donc points par points en reprenant le fil de 2018 comment ça a évolué.

L'objectif est de rendre tout cela le plus acessible que possible, de sortir de Jeedom ce qui ne sert à rien et de piloter de plus en plus d'équipements via Alexa tout en conservant un contrôle local hors cloud.

Se pose également la question du passage à la v4 de Jeedom, mais ça attendra une version bien finalisée, en tous les cas pas avant la fin de l'hiver !

Objectifs

Le chauffage électriques sur 6 zones avec divers scénarios.

• Le plugin Thermostat est parfait
• Les plugins Agenda, Présence et Mode permettent de gérer manuellement ou automatiquement en fonction de calendriers et des événements (j’ai des amis pour diner, périodes de vacances scolaires, etc…).
• J'ai viré toutes les sondes Oregon peu esthétiques au profit de sondes Xiaomi / Aquara en Zigbee ou Bluetooth. Je n'en pouvais plus de devoir ré-appairer les sondes à chaque changement de piles.

Le chauffe-eau

• Le mode nuit du chauffe-eau était géré par la ZiBase, il est maintenant géré par un agenda une nuit sur deux pendant les heures creuses. J'ai abandonné l'idée d'y intégrer une sonde.

La VMC

• Je ne la gérais pas mais il doit être simple de la gérer via Jeedom à partir de l’hygrométrie de la salle de bain ou de la cuisine (article). C'est chose faite en fonction de l'hygrométrie ambiante dans la salle de bains.

Simulation de présence

• Pour l’instant, j’ai choisi de ne pas intégrer cette fonction à Jeedom mais de la gérer en autonome avec des prises WiFi et l’application Tuya. Jeedom dispose maintenant d'un plugin qui fait le job.

Confort et éclairage

• Idem, c’est facilement géré en autonome avec des ampoules ou des prises WiFi et l’application Tuya, la commande se faisant depuis un smartphone, une tablette ou mieux en vocal avec Google Home (Alexa possible, j’aime bien sa voix…). Bref, c’est plus naturel. Pas de design ou de tablette, on ne contrôle pas une centrale nucléaire et je pars du principe que la domotique doit se faire oublier. Uniquement Alexa en vocal ou via son interface qui constitue une alternative à la désastreuse application mobile proposée par Jeedom.
• Donc il n’est pas utile pour l’instant de reporter ça dans Jeedom, sauf si on veut que certains équipements soient actifs quand les habitants sont présents. J’ai bon espoir de voir l’arrivée du plugin idoine. Ça reste possible en IFTTT, mais c’est un peu lent (2 sec environ)
• Jeedom dispose maintenant du plugin SmartLife / Tuya pour les prises et ampoules, d'autres ampoules Xiaomi / Yellight sont également gérées, ainsi que les modules Shelly. J'aime bien ces modules car ils permettent de conserver l’appareillage original (interrupteur) et d’ajouter une entrée domotique, pilotable via Jeedom grâce à un plugin et sur Alexa. Il ne faut pas que la domotique supprime les fonctionnalités de base de la maison, n'importe doit pouvoir continuer à allumer un luminaire !

Consommation des appareils énergivores

• Les prises Konyks via Tuya gèrent la consommation, notamment en veille, et parfois ça fait peur. De plus elles permettent de gérer des scénarios de base et un minuteur (genre, j’allume le home cinéma et celui-ci s’éteindra dans deux heures, soit après que j’ai regardé mon film). Tout cela est finalement un peu gadget, la domotique apporte du confort, pas des économies !
• Comme pour l’éclairage, on n’encombre pas Jeedom pour l’instant avec ça.

Les coupures EDF

Pourquoi en utiliser plusieurs points de détection ? En province il y a souvent des coupures EdF (vent, orages, vétusté) mais aussi parfois des différentiels de section qui tombent (surement d’humidité quelque part). Et dans ce cas il est important de savoir ce qui s’est passé à distance afin de pouvoir faire intervenir et guider un proche afin de ne pas retrouver un congélateur perdu au retour de voyage.

• Sur la ZiBase j’utilisais des micro-modules InterTechno alimentés sur piles pour déclencher une action en cas de coupure EdF. Ça doit être réutilisable sous Jeedom via le RFPlayer. C'est fait, même si le RFPlayer et sont plugin sont la partie la plus désastreuse de l'installation !
• Pour la partie informatique je devrais pouvoir récupérer les infos des onduleurs APC avec le plugin SNMP.
• Notification SMS / Pushbullet et / ou action voire IFTTT. J'ai basculé toutes notifications vers Slack.

Alarmes

• Le système d’alarme Visonic est autonome. C’est un principe minimal de sécurité.
• Par contre la remonté des capteurs sur Jeedom peut être intéressante afin d’identifier ce qui a déclenché une alarme à distance, voire déclencher une action secondaire en cas d’intrusion. Contrairement à la Zibase les RFPlayer dont il est issu remonte très mal les infos Visonic, enfin, c'est plutôt le plugin qui ne fait pas le job, mais visiblement a décidé de le laisser à l'abandon, et comme Ziblue est en liquidation ça laisse peu de perspectives...
• Plus pratique, se servir des contacts d’ouverture pour désactiver un radiateur ou des capteurs de présence en temporisant pour réduire l’éclairage ou la climatisation (gadget en phase 2…). Ce seront plutôt des capteurs d'ouverture en Xiaomi en Zibgee qui feront un jour ce travail...

Présence

• Déterminer via la localisation du mobile la mise en route du chauffage ou climatisation. Il y a je crois un plugin pour ça… Rien de stable, donc rien place...
• Gérer l’éclairage extérieur à l’approche de la maison via le WiFi. J'ai fait quelques test en BLEA avec un porte clés Tile, ça fonctionne.

Les logiciels

• Jeedom
• Application mobile Jeedom (je ne suis pas fan). Définitivement oublié. Il vaut mieux je pense utiliser l'interface web en mode mobile....
• Application mobile ImpériHome (je m'en servait déja sur la ZiBase) via le plugin idoine dans Jeedom. Le plugin est abandonné mais je m'en sert encore, il faudra un jour trouver une alternative.
• Application mobile TuyaSmart, complétée par Xiaomi et Shelly pour les setups, mais surtout par Alexa.

Le matériel

Serveur, box domotique

Jeedom est installé sur un Raspberry Pi3 et les dongles USB utiles. Evolution possible dans une VM VMWare ESXi. Toujours sur un RPI afin que la domotique reste indépendant de tout le reste. C'est aussi plus simple pour gérer les clés des protocoles.

Avant que l’on me pose la question je vais expliquer pourquoi  je n’ai pas utilisé de Z-Wave, qui est pourtant le protocole roi dans cet univers, protocole ayant eu le soutien de tous les boutiquiers de la domotique (maintenant remplacés par Amazon…). Bref, je n’en ai jamais utilisé sur la ZiBase et j’ai pu m’en passer. Et surtout c’est trop cher, le moindre module Z-Wave étant affiché à 50 €.

Sondes de température :

• Oregon : j’en ai plusieurs, elles étaient reconnues par le ZiBase et elles fonctionnent correctement via la clé RFPlayer (125 €) et le plugin idoine. Inconvénient, elles sont moches et il faut refaire l’appairage à chaque changement de piles ce qui est une corvée à l’usage. Vendues et replacées par des Xiaomi / Aquara.
• Xianomi et Xiaomi Aquara en Zigbee (6/12 €) : Fonctionnement OK via la clé ZiGate (45 €) et le plugin idoine. En cas de longue distance on peut mailler avec une prise Zigbee. Ces sondes esthétiques et très discrètes ne transmettent les infos (température, humidité, pression) que s’il y a un changement d’état et / ou très aléatoirement s’il n’y a pas de changement. Le modèle carré (Aquara) semble plus volubile. A valider en période de chauffage. J'ai abandonné la clé ZiGate dont les évolutions rendaient l'installation instable au profit d'une Combee II installée sur un second RPI qui fait office de passerelle Zigbee universelle (Phoscon / Deconz). C'est stable.
• Xiaomi en Bluethoth 12/18 € : reconue par le plugin BLEA. Intervalle réglable. Elles sont très esthétiques. La portée est réduite avec le Bluetooth intégré au Pi mais ça devient correct (100 m²) avec une clé Bluetooth longue portée (UD100, 45 €). Test ici. Je m'en sert là ou j'ai besoin d'une sonde avec afficheur, elles sont hélas un peu généreuses, +1°...

Présence

• Capteurs d’alarme Visonic via le RFPlayer toujours en chantier...
• Capteurs Xianomi via la ZiGate Replacé par Combee II
• BLEA + tag Nutt Tag Tile
• WiFI via les smartphones : Pas vraiment exploitable car les smartphones mettent de plus en plus le WIFI en veille. Il faudrait le faire en Bluetooth, je crois qu'un plugin est en préparation.

Notifications

• SMS (Free API)
• Pushbullet Remplacé par Slack que j'utilise au quotidien.

Alarmes et sécurité

• (voir présence)

Eclairages et appareils

• Prise et ampoules Konyks ou Sonoff, WiFi via Tuya. Les prises Sonoff S26 permettent de gérer l'état à la mise sous tension, ce n'est pas le cas des prises Konyks ou c'est plus aléatoire. J'ai disqualifié Konyks (cher pour ce que c'est), Sonoff (pas CE/NF) au profit de Shelly.
• Possible extension en Philips Hue, Osram, Ikea and co (Zigbee) via la ZiGate et son plugin Les ampoules Xiaomi SmartBulb en WIFI sont très bien.

Actionneurs

• IPX800 : pour l’instant j’ai une IPX800 v2.
  C’est une simple carte 8 relais qui me sert pour l’instant à actionner les radiateurs et le chauffe-eau. En sortie j’ai câblé des contacteurs de puissance Finder avec le bon pouvoir de coupure et de ne pas forcer sur les relais de la carte. L’intérêt de ces contacteurs est de disposer d’un bypass manuel et ainsi de pouvoir passer les équipements en manuel en cas de défaillance de la domotique. Les versions 3 et 4 de l’IPX800 n’ont pas d’intérêt dans mon cas.

• Prises et modules Chacon : ils se pilotent via le RFPLayer, mais ça reste un protocole peu fiable.
  Etat aléatoire lors de la remise en tension après une coupure EdF, auquel cas il est gênant de retrouver la moitié des prises ON… Impossibilité également d’utiliser deux équipements proches, c’est by design. Donc mon aventure Chacon / DI-O est terminée. J'élimine Chacon / DI-O au profit de prises Tuya et des modules Shelly avec retour d'état.

• X2D : Je n’utilisais qu’un seul module DeltaDore pour commander le sèche-serviettes et je dois pouvoir le gérer avec le RFPlayer. Il est toujours présent, mais il passera à la trappe bientôt...
  Cette solution permet de gérer le fil pilote, mais il est vrai que je pourrais le faire avec un jeu de diodes. A voir.
• Prises et ampoules Zigbee : via la ZiGate et son plugin. J’ai une Osram qui me fait le maillage. Remplacé par Combee II
• Prise et ampoules WiFi : via Tuya, plugin en devenir ? Pas d’urgence. Plugin OK

Réseau et Wi-Fi

• Le réseau et le WiFi sont gérés depuis longtemps avec du matériel Unifi (AP AC Pro et USG). Le top ! Au-delà de cette solution qui reste un peu complexe pour un particulier je recommande Amplfi de chez Unifi ou la solution WiFi proposée par Google. Un bon réseau est une base impérative en domotique et généralement le WiFi proposé par les box est à oublier. On attends la Dream Machine Pro...

Vidéo surveillance

• Caméras et PVR Unifi (je sais, je suis fan de cette marque) dans une VM VMWare. C’est géré à part de façon autonome. J'ai remplacé le NVR soft par Unifi Protect sur une Cloud Key II, c'ets le jour et la nuit....

Multimédia

Vidéo

• Emby (j’y reviendrai dans un post à part) en remplacement de Kodi. Des box NVidia Shield et Xaomi Mi Box 3S sous Android TV ont remplacé les PI. Elles supportent également Netflix et Amazon Vidéo.
• TV : Tuner réseau HDHome Run qui permet de recevoir les chaînes sur les box Android TV et les autres devices (même si dans la pratique je ne regarde pas la TV). Ce n’est pas compatible Canal, ce n’est pas mon problème car je ne suis pas fan, mais le cas échéant il est toujours possible d’installer MyCanal ou Molotow sur les box.

Musique

• Sonos dans toutes les pièces, certains équipements datent de 2005 et n’ont pas pris une ride. On ne change rien. Spotify et base locale de CD numérisés. Je me suis fait plaisir avec un Sonos AMP auquel j'ai ajouté des voies arrière avec deux petites enceintes Ikea by Sonos, au départ c'était pour la musique mais le rendu en home cinéma est fabuleux !

La solution Unifi Protect fonctionne bien mieux que l’ancienne version Unifi Video. Sauf qu’un client vous demandera toujours ce qui n’existe pas… Si on peut très facilement visionner ses cameras sur un navigateur (astuces inside : 1 - 2) ou un application mobile, mais rien n’est prévu sur un TV isolé, sauf à connecter un PC. Et un PC n’est pas franchement ce qui sera le plus fiable sur la durée. Je suis donc allé chercher du coté de chez Raspberry, le nano ordinateur à tout faire et on y trouve un petit projet simplement nommé DisplayCameras. 

L’installation devait être simple mais m’a tout de même un peu cassé la tête, en fait simplement parce que j’ai pris une image Raspbian trop récente pour que tout se déroule normalement, donc voici : 

1. On télécharge une image Raspbian, la Buster lite fera très bien l’affaire (Ou simplement une Stretch ici qui sera compatible avec le script). Avec Etcher (ou autre chose) on prépare la carte µSD
2. Une fois terminé, on insère la carte dans le RPI et on y connecte un clavier et le réseau
3. Une fois qu’il a démarré on lance sudo raspi-config et on configure ces options :

^{(3) Boot Options > Wait For Network at Boot
(4) Localisation Options > Change Timezone > (tant qu’à y être aussi votre langue et clavier…)
(5) Interfacing Options >  SSH >  Yes
(7) Advanced Options > Expand File System
(7) Advanced Options > Memory Split > 256}

5. On en profite pour faire une petite mise à jour
   sudo apt-get update && sudo apt-get upgrade -y && sudo reboot
6. A ce stade je recommande de passer l’IP en statique avec sudo nano /etc/dhcpcd.conf (on enlève les # et on complete). Mais avant allez repérer le nom de votre interface avec un ip a car eth0 ça devait trop simple… Et ensuite on redémarre avec un sudo reboot.

# Example static IP configuration:
interface enxb827eb1aa100
static ip_address=192.168.210.35/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=192.168.210.1
static domain_name_servers=192.168.210.12 8.8.8.8

7. A partir de là on oublie le clavier du RPI et on passe en SSH, avec Teminus par exemple. C’est plus pratique pour la copié / collé. On se connecte avec le username / password par defaut si on ne l’a pas changé plus haut (ce serait bien de le faire…) :
   Username = pi / Password = raspberry 

8. Une fois connecté on va télécharger le code qui nous intéresse, le décompresser et enfin l’installer...

wget https://github.com/Anonymousdog/displaycameras/archive/0.8.3.3.zip
unzip 0.8.3.3.zip
cd displaycameras-0.8.3.3
chmod +x install.sh
sudo ./install.sh

Sauf que comme le script d’installation n’est pas fait pour l'ultime version de Rasbian, il en oublie l'essentiel. Il va falloir ruser un peu :

sudo apt-get update
sudo apt-get install omxplayer

Maintenant on va configurer le flux de nos caméras avec sudo nano /etc/displaycameras/layout.conf. Ce fichier contient également tous les réglages possibles de positionnement, mais par défaut il est configuré pour 4 caméras sur un écran HD. La principale partie qui nous intéresse est celle-ci :

camera_feeds=( \
"rtsp://192.168.1.2:7447/i6m4f1act8nwtp4bg0veqw4u_1" \
"rtsp://192.168.1.2:7447/ifkjakg27dboh5ho6ull349u_1" \
"rtsp://192.168.1.2:7447/n7jt8fimlqvm6o0a0nwjdal6_1" \
"rtsp://192.168.1.2:7447/9lqpgwvrusvk8u0br7n3t2ki_1" \

CameraDisplay ne s’appuie pas sur Unifi Protect mais sur les flux RTSP qui sont configurables en option dans Unifi Protect au niveau des réglages de chaque caméras et ce en différentes résolutions. J’ai fait mes tests sur un RPI2, je me suis donc abstenu de passer en full HD, mais c’est jouable sur un RPI3. Dans les liens ci dessous vous trouverez d’autres réglages, tel que la rotation d’images si on dispose de plus de 4 caméras par exemple…

A ce stade on est pressé de voir le résultat, alors on lance sudo systemctl restart displaycameras.service. On peut aller brancher le RPI au dos de la TV sans clavier, il redémarrera tout seul avec la bonne config. Voilà !

EDIT

Il y a des choses qui se préparent chez Unifi...

Sources 

• https://selfhostedhome.com/raspberry-pi-video-surveillance-monitor/
• https://github.com/Anonymousdog/displaycameras
• https://tutorials.technology/tutorials/Tutorial--Raspberry-Pi-3-RTSP-Stream-Viewer.html
• https://community.ui.com/questions/Tutorial-Raspberry-Pi-3-RTSP-Stream-Viewer/cc54f892-b8d6-46c5-81f3-ee58b9284889?page=1
• https://community.ui.com/questions/NUC-ODROID-H2-TinkerBoard-RTSP-Multi-monitor-viewer/dda27a47-f502-48f5-956b-cb6dc15fbbc4
• https://www.bitpi.co/2015/03/18/raspberry-pi-surveillance-monitor/
• https://community.ui.com/stories/My-First-Unifi-Video-Setup-with-Raspberry-Pi-Monitor/c00fd0a1-1b62-4a9c-bdeb-97a83ab1ef01?page=1

À la suite de mes mésaventures avec la clé ZiGate, j’ai commandé une clé Combee II.

Etant sous Jeedom j’avais découvert la naissance d’un plugin officiel qui lui est dédié (6 € tout de même, mais en principe les plugins officiels sont mieux maintenus dans la durée que les plugins tiers, encore que parfois Jeedom décide arbitrairement de les abandonner aussi). A première vue j’ai failli suivre bêtement la recommandation du plugin qui consiste à installer la gateway deCONZ / Phoston sur le RPI Jeedom. Puis je me suis ravisé, sans avoir à ce moment-là totalement appréhendé l’affaire, je me suis dit qu’il ne fallait pas tout lier à Jeedom. En fait installer la passerelle à part la rend indépendante puisque de toutes façons le plugin Jeedom n’est qu’un client IP de cette passerelle qu’il interroge localement (127.0.0.1) si elle est installée sur la même machine et via son IP dans le cas contraire. D’une part ça permet de la placer au centre de la maison, et également de la contrôler directement avec d’autres applications en se passant de Jeedom (Alexa par exemple), sachant que Jeedom recevra de toutes façons les retours d’état. Et pour faciliter la chose, plusieurs images SD pour RPI sont proposées sur le site Phoscon (attention de base le client DHCP de ces images ne prend pas la GW, de toutes façons vaut mieux figer l’IP, donc éditer la configuration).

Voilà déjà une chose impossible avec l’approche ZiGate. Ensuite à mon sens il faut oublier l’approche tout Jeedom. Ce qui compte c’est que Jeedom connaisse l’état d’un équipement. En effet, prenons l’exemple d’un interrupteur Ikea qui va allumer une ampoule Philipps. On configure la chose depuis Phoscon de façon très simple, ça fonctionne sans Jeedom mais ça n’empêche pas Jeedom d’agir, par exemple dans le cadre d’un scénario plus évolué. L’idée est que ce qui pourra être géré dans Phoscon déchargera Jeedom. La passerelle Phoscon remplace simplement toutes les passerelles propriétaires (Ikea, Hue, etc..), et Jeedom (ou d’autres solutions domotique) viens s’y connecter en IP via une API.

Un autre avantage est que Phoscon se connecte directement et facilement (et gratuitement) avec Alexa / Google Home, ce qui n’est pas le cas de Jeedom qui nécessite un plugin et un abonnement obligatoire (12 € / an, même après avoir acheté un Service Pack Power Ultimate, moi qui pensait que ça incluait tous les plugins officiels). Et je ne parle même pas des connexions avec IFTTT, qui, si elles permettent pas mal d’interopérabilité, n’en sont pas moins compliquées à maintenir. Donc pour demander à Alexa d’allumer la lumière de la cuisine, autant limiter les intermédiaires, Alexa communiquera avec Phoscon / deCONZ plutôt qu’Alexa (en supposant qu’on ai ajouté Alexa à Jeedom) demande à Jeedom qui lui va demander à Phoscon / deCONZ d’allumer la cuisine…

Mobile

Phoscon ne dispose pas d’application mobile, mais la page est responsive et parfaitement utilisable sur un mobile ou une tablette. Cela étant c’est sans intérêt à l’usage si on lie Phoscon à Alexa ou Google Home car l’application mobile des assistant vocaux sera bien plus ergonomique. Je me disais d’ailleurs que lier Jeedom à Alexa présenterait au moins l’intérêt de disposer d’une interface mobile utilisable, en opposition à celle de Jeedom qui est une calamité. En attendant j’utilise Impérihome qui fonctionnait bien avec Jeedom, mais le plugin vient d’être retiré du Market Jeedom au profit d’une approche Impérihome sans plugin qui ne fonctionne pas. Je n’ai pas l’impression que Jeedom et Impérihome (ex ZiBase / ZiBlue & co.) soient très copains…

Intégration Jeedom

Pour revenir à Phoscon, tout ne semble pas géré dans la passerelle, si on peut créer des scènes et des associations, il y a d’autres équipements, les sondes de température par exemple ou d’ouverture de porte que l’on ne peut pas utiliser directement, mais généralement on n’en a besoin que dans Jeedom.

Le plugin remonte des valeurs propres à chaque équipement, on n’aura pas les classiques infos binaires ou numériques (on/off ouvert/fermé) mais un code numérique propre à chaque équipement. Par exemple une télécommande Ikea va envoyer 1002 si on appuie au centre, il n’y a plus ensuite qu’à traiter directement l’information (scénario, virtuel, etc…) pour créer une action dans Jeedom. En revanche les sondes (températures, humidité, pression) remontent bien les valeurs et sont exploitables directement.

Attention cependant aux capteurs, les Xiaomi, par exemple, ne supportent pas de perdre leurs parents, donc si vous changez de canal Zigbee ou si le maillage passe par une prise Zigbee que vous retirez, il vaudra mieux les réinclure (le maillage peut se voir sur l’application graphique deCONZ). De même il ne faut pas oublier qu'un objet Zigbee ne peut être inclut que une sur passerelle. Ainsi si vous incluez un objet avec Foscon alors qu'il est déjà inclut dans la passerelle Xiaomi, cet objet sortira du réseau géré par la passerelle Xiaomi afin de rejoindre celui géré par la passerelle Foscon.

Conclusion

Au départ j’hésitais à remplacer ma douzaine de sondes Oregon gérés par le RFPlayer (les sondes Oregon perdent leur identifiant lors de chaque changement de piles, il faut donc les appairer à nouveau, ça reste fastidieux, même si c'est prévu par le plugin. Et je passe sur toutes les déconvenues liées au RFPlayer que je ne recommande vraiment pas), par des sondes Xiaomi gérées par la ZiGate, mais comme la solution Combee II + plugin deCONZ fonctionne plutôt bien, je pense me tourner de ce côté rapidement. Je mettrait bien sur à jour cette page pour vous narrer mon expérience…

La Combee II + Phoscon sur un RPI (SD ready) peuvent servir de passerelle universelle Zigbee compatible avec les assistant vocaux et ainsi remplacer les passerelles des constructeurs (Ikea, Hue, etc...). Phoscon comme Jeedom avec le plugin DeCONZ s'appuient sur la couche deCONZ. 

Mise à jour

$ sudo systemctl stop deconz

# Mise à jour de la Combee II
$ wget http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF
$ sudo GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f deCONZ_ConBeeII_0x26580700.bin.GCF

# Mise à jour Deconz
$ wget -N http://deconz.dresden-elektronik.de/raspbian/deconz-latest.deb
$ sudo dpkg -i deconz-latest.deb
$ sudo reboot

Bonus

Certains me demandent pourquoi j’utilise des RPI alors que j’ai un gros serveur VMWare ESXi dans le garage, ce qui faciliterait la manipulation des VM et leur sauvegarde. Simplement parce que je considère que la domotique gère des fonctions vitales de la vie courante (chauffage par exemple) et qu’elle ne doit dépendre de rien d’autre. Imaginez, le serveur se plante, il faut réparer le serveur sans chauffage… De plus les clés utilisées pour les divers protocoles ne seraient pas idéalement placées au fond du garage

Sources

• https://presentationdeconz.wordpress.com/
• https://jeedomiser.fr/article/vos-equipements-zigbee-avec-la-cle-conbee-ii-et-jeedom/
• https://phoscon.de/en/app/doc

La clé ZiGate permet d’utiliser le protocole Zigbee que l’on retrouve chez Ikea, Philips, Xiaomi et bien d’autres. Je l’utilise depuis ses débuts et ça fonctionne plutôt bien. 

Il y a une semaine, je me suis décidé de passer ma clé de 3.0d en 3.0f dans l’espoir de pouvoir inclure une prise et un inter IKEA. La chose devait être simple. 

Après la mise à jour de 3.0d en 3.0f et un redémarrage du plugin et mise à jour des dépendances, mes équipements sont toujours là mais aucune information ne remonte dans Jeedom, les interrupteurs sont inopérants et il est impossible d’associer quoi que ce soit. J’ai fini par mettre à jour la clé en 3.1a sans plus de succès. 

En désespoir de cause j’ai désinstallé le plugin Zigate pour le réinstaller. Là je peux inclure à nouveau mais plus aucune trace de mes 12 équipements. Donc je me refais les inclusions et les configuration (genre « temperature » à renommer en « Température », etc… cocher ce que je veux voir, changer les widget, bref, passionnant… et perte de temps). Certains capteurs qui fonctionnaient avant ne voulaient plus s’inclure. Résolu en changeant de pile (qui remontait pourtant bien les infos avant hier) et en rapprochant le capteur de la Zigate (On peut donc en déduire que pour associer un équipement vaut mieux que la pile soit en très bon état !). 

Et pour les équipements Ikea, c’est encore moins user friendly, le passage en groupe 0 ça va pour une prise mais pas vraiment exploitable pour plusieurs, ni à la portée de tout le monde. Inutile toutefois de débrancher la clé (comme recommandé sur le site Zigate), on peut passer par le mode terminal du plugin...

Commande : 0x0060

Les donnes à envoyer sont 02ABCD01010000 (ou ABCD est la short adresse de la prise IKEA)

Ensuite on peut associer l’inter livré avec la prise (facultatif) et on peut commander cette prise avec l’inter ou Jeedom, retour d’état compris. Si j’ai tout compris un inter commandera toutes les prises, alors que ces dernières sont adressables individuellement dans Jeedom. Pas réussit avec la télécommande qui semble dédiée aux ampoules suédoises. La solution Ikea / Zigate pour les prises est trop compliquée. Personnellement je recommande les prises Osram que l’on trouve régulièrement à 10 € sur Amazon si on veut absolument du Zigbee.

Cette mésaventure pose tout de même question. On sait tous que c’est du DIY et que ça comporte des risques inhérents à la pratique. Il n’en reste pas moins que les sondes de température relèvent du sensible dans une installation qui gère le chauffage. Donc manips à proscrire en plein hiver ! Il reste le cas de la panne à envisager. 

La clé ZiGate et ses plugins (ZiGate ou Abeille) sont en développement permanent et c’est normal pour du DIY. Dans mon aventure je ne sais pas ce qui a merdé (interaction entre la clé, sa mise à jour et/ou le plugin) ni comment j’aurais pu l’éviter. Que sauvegarder ? La clé contient des infos sur les équipements ? Que faut’ il sauvegarder ? Un petit topo sur les bonnes pratiques serait le bienvenu de la part des auteurs (qui sont certainement déjà bien surchargés…).

Énervé j’ai commandé dans la foulée une clé Combee II, je vais tester sans pour autant être persuadé que ce soit mieux, les deux solutions étant du RE (reverse engineering). A suivre ici...

EDIT 01/11/2019 : Suite à la dernière mise à jour du plugin ZiGate plus rien ne démarrait. J'ai donc retiré les équipement qui lui restaient associés et je les ai associés à la Combee II. Bref, ZiGate, c'est terminé, OFF et débranchée.

Il existe un bugg (https://dev.freebox.fr/bugs/task/22818) bien gênant sur la Freebox (Révolution et 4K) en mode bridge, toujours pas résolu par Free au fil du temps. Pour faire court, en cas de déconnexion FTTH/xDSL, le routeur qui lui est adossé ne voit plus la box qui joue ici un rôle de modem. Redémarrer le routeur ne sert à rien, c’est la Freebox qu’il faut redémarrer.

Redémarrer une Freebox peut se faire en coupant sauvagement l’alimentation, depuis la face avant avec le petit afficheur (quant il n’est pas HS) ou via Freebox OS (auquel dans ce vas on n’aura pas accès localement). Il existe une autre option avec l’API Freebox OS qui prend tout son sens si l’on supervise la Freebox à distance, dans notre cas avec PRTG Network Monitor installé dans un VPS et qui est gratuit jusqu’à 100 sensors (il existe bien d’autres solutions). PRTG envoie des notifications, mais permet également de lancer des scripts PowerShell, et c’est l’objet de cet article.

Script PowerShell permettant de rebooter une Freebox

Petit didacticiel aussi simple que couper une tomate mûre en tranches avec une sandale...

L'application PS dont ce didacticiel traite s'appelle "Remote Control". Elle permet de rebooter une Freebox depuis un script PowerShell et/ou de récupérer un flux JSON avec les informations temps réel de la Freebox, par exemple pour disposer d'un monitoring depuis une page HTML (il peut être modifié afin d'obtenir d'autres informations disponibles via l'API).

1. Fichiers accompagnant ce didacticiel

L'archive ZIP dans laquelle se trouve ce didacticiel contient les fichiers suivants :

• Adresse_Freebox_Locale.ps1 est un script PowerShell qui retourne l'URI de la Freebox installée sur le réseau local. Cet URI est utilisable depuis un navigateur internet situé dans ou hors du réseau local, si elle est autorisée.
• Autoriser_Remote_Control.ps1 est un script PowerShell à lancer sur un PC du réseau local, attribuant une autorisation à l'application "Remote Control" afin qu'elle puisse contrôler la Freebox locale.
• Freebox ECC Root CA.cer est l'un des deux certificats requis pour accéder à la Freebox en HTTPS.
• Freebox Root CA.cer est l'autre certificat.
• Remote_Control.ps1 est le script PowerShell qui servira à faire rebooter la Freebox ou à récupérer ses informations.

2. Principe de fonctionnement

La Freebox peut être contrôlée de manière locale ou distante via une API pouvant être appelée en respectant l'architecture REST. Afin d'éviter que des commandes permettent la prise de contrôle d'une box par un tiers malintentionné, un ensemble de sécurités est mis en œuvre :

1. Attribution d'un droit à prendre le contrôle, requérant une action physique sur la box,
2. Attribution d'autorisations quant aux actions possibles lors de la prise de contrôle,
3. Fourniture d'un jeton lors de cette attribution, lequel ne sera jamais transmis lors des appels à l'API, mais remplacé par une donnée cryptée.

L'API de la box peut être appelée en HTTP ou en HTTPS. Cependant la documentation indique que la possibilité d'utiliser HTTP sera retirée dans une version prochaine, et qu'il est fortement conseillé de n'utiliser que HTTPS. Afin de respecter cette consigne, "Remote Control" fonctionne par défaut en HTTPS, même s'il est possible de le faire fonctionner en HTTP moyennant une ou deux modifications du script et pas mal de simplifications dans le processus indiqué ci-dessous.

Afin de pouvoir utiliser "Remote Control" pour dialoguer avec une Freebox locale ou distante, il faut donc réaliser les opérations suivantes :

1. Installer les certificats nécessaires pour pouvoir causer HTTPS.
2. Autoriser l'application "Remote Control" sur la Freebox
3. Installer "Remote Control" sur une machine du réseau local ou sur une machine distante (non testé), et le paramétrer correctement pour qu'il puisse interagir avec la Freebox.

L'installation et l'utilisation de "Remote Control" nécessite l'utilisation d'un PC situé sur le réseau local derrière la Freebox, un opérateur capable d'appuyer sur un bouton de la Freebox, et un PC de contrôle situé sur le réseau local derrière la Freebox ou distant via l'internet.

3. Installation des certificats

Lorsqu'une connexion HTTPS est réalisée avec la Freebox, cette dernière nécessite un certificat attribué à Freebox ECC Root CA ou Freebox Root CA. Les fichiers correspondants sont fournis dans le zip. Il faut les installer sur le PC qui va permettre d'autoriser l'application "Remote Control" sur le réseau local derrière la Freebox ET sur le PC qui va prendre le contrôle de la Freebox.

Pour les installer, double-cliquer sur les fichiers dans l'explorateur Windows, demander à installer les certificats dans le dépôt des certificats racine. Afin de tester la bonne mise en place des certificats, ouvrez un navigateur internet et entrez dans la zone d'adresse https://mafreebox.freebox.fr, si vous accédez à l'interface de Freebox OS, c'est OK. Conservez le navigateur ouvert, on en aura besoin au point numéro 6 de ce didacticiel.

Si vous avez une page d'erreur ou une indication SEC_ERROR_UNKNOWN_ISSUER, c'est raté. Lancez MMC et le plug-in Certificats, cherchez dans le bazar les deux certificats Freebox, supprimez-les et recommencez tout depuis le début en maudissant l'auteur de ce didacticiel pour son manque de précision.

4. Autoriser l'application "Remote Control"

Cette opération doit être réalisée depuis un PC situé dans le réseau local derrière la Freebox, selon la documentation du SDK. Il n'est pas possible d'autoriser une application depuis un PC extérieur. Dixit la doc. Il faut aussi avoir sous la main une personne physique capable d'appuyer sur un bouton sur la Freebox.

Double cliquez sur le script PowerShell Autoriser_Remote_Control.ps1 puis suivez les indications à l'écran, vous demandant d'appuyer sur le bouton "Flèche vers la droite" sur la façade de la Freebox alors que cette dernière demande si elle doit autoriser l'application "Remote Control". Appelez la personne physique devant la Freebox et expliquez-lui ce qu'elle doit faire. Une fois le bouton de la Freebox appuyé, le script devrait afficher que l'autorisation a été donnée, accompagné de l'URI de la Freebox et d'un identifiant d'application (de la bouillie en Base64). Copiez-coller l'URI de la Freebox et l'identifiant d'application dans un coin.

Nous n'aurons désormais plus besoin du fichier Autoriser_Remote_Control.ps1. L'autorisation a été donnée à l'application et sauvée dans la Freebox ad vitam aeternam, sauf :

• Si vous supprimez l'autorisation depuis les paramètres de la Freebox (voir point 6)
• Si vous faites une réinitialisation usine de la Freebox,
• En cas d'échange de la Freebox, par exemple si elle venait à tomber en panne,
• En cas d'erreur non répertoriée dans les documentations,
• Ou si vous passez chez Bouygues et renvoyez la box chez Free.

6. Attribuer les droits nécessaires à l'application "Remote Control"

Toujours depuis le PC situé dans le réseau local, reprenez le navigateur internet que vous aviez utilisé pour le point numéro 3, qui doit toujours afficher la page d'accueil de Freebox OS de la Freebox qui vous intéresse. Si vous l'avez bêtement fermé, collez-vous une baffe, puis relancez un navigateur internet et allez sur https://mafreebox.freebox.fr. 

Identifiez-vous, puis sélectionnez successivement :

• "Paramètres de la Freebox",
• "Gestion des accès",
• "Applications" (en haut de la fenêtre).

Recherchez dans la longue liste des applications autorisées celle que vous venez d'ajouter : "Remote Control (demande)". Cliquer sur le bouton "Editer" à droite et modifiez les autorisations pour activer "Modification des réglages de la Freebox". Vous pouvez d'ailleurs désactiver tout le reste qui a été activé par défaut mais qui n'est pas utile. Évitez de cliquer sur la dernière icône, en forme de poubelle, qui retire l'autorisation de l'application et vous forcerait à tout recommencer depuis l'étape 4 ci-dessus.

7. Paramétrer le script de contrôle à distance

Nous allons maintenant modifier le contenu du fichier Remote_Control.ps1 pour y insérer les paramètres de fonctionnement correspondant à la Freebox qui nous intéresse. Si vous souhaitez contrôler plusieurs Freebox, vous pouvez bien entendu copier le fichier, renommer sa copie comme vous l'entendez et la modifier. Cette opération doit être réalisée sur le PC local ou distant qui devra prendre le contrôle de la Freebox pour la rebooter. Ce PC devant de plus disposer des certificats racine, installés comme décrit au point 3 de ce didacticiel.

Il faut modifier deux lignes dans le script :

• Ligne 43, remplacer [Insérer l'URI ici] par l'URI retournée par le script d'autorisation de l'application Autoriser_Remote_Control.ps1, URI que vous avez copié dans le bloc-notes, un email ou taggué en fin du point n°4 de ce didacticiel :

Avant :

$AdresseFreebox = "[Insérer l'URI ici]"

Après (par exemple) :

$AdresseFreebox = "https://vivalasvegas.fbxos.fr:12345"

Faites gaffe avec les guillemets, ils doivent être présents après modification de la ligne.

• Ligne 46, remplacer [Insérer l'identifiant d'application ici] par le jeton de l'application, noté avec l'URI de la Freebox au point 4 :

Avant :

$JetonAppli = "[Insérer l'identifiant d'application ici]"

Après (par exemple) :

$JetonAppli = "M0nqsaiDup0ul3tMfgtyhbut0risaTi0nTyT0uch3pa5"

Faites gaffe avec les guillemets, comme précédemment. Sauvez le script, fermez l'éditeur, c'est prêt.

8. Tester l'installation

Ouvrez une ligne de commande PowerShell sur le PC qui doit prendre le contrôle, PC local sur le réseau local ou PC distant (non testé) puis entrez la commande suivante sans oublier le ./ :

./Remote_Control.ps1 –Info

Bien entendu, il faut être dans le dossier contenant le fichier, sinon vous aurez une erreur indiquant que la commande est inconnue, mais bon, je suppose que vous ne vous ferez avoir qu'une seule fois. Si tout va bien, la fenêtre de PowerShell va vous afficher une longue liste d'informations sous la forme d'un flux JSON avec en vrac la température du CPU, la vitesse du ventilo, la durée de fonctionnement depuis le dernier reboot, l'âge du capitaine, toussa-toussa.

Dans la fenêtre PowerShell, entrez maintenant :

./Remote_Control.ps1 –Reboot

Ça devrait vous répondre que la Freebox est en train de rebooter, et là, paf, plus d'internet si vous êtes en local. Tout qui s'allume en rouge dans les superviseurs de tous poils, les utilisateurs du réseau local qui gueulent, le drame quoi.

Patientez quelques minutes puis rafraîchissez la fenêtre de votre navigateur internet qui était toujours en train d'afficher les infos de la box. Vous devrez sûrement retaper le mot de passe. Rendez-vous dans "État de la Freebox" et normalement, si tout va bien, derrière "allumée depuis", il devrait y avoir une valeur en secondes ou en minutes, preuve que votre Freebox a bien redémarré, que le script PowerShell a bien fait son boulot et que l'auteur de ces lignes n'est pas si con que ça.

9. Conclusion

Il ne vous reste plus qu'à entourer tout ça d'un ruban rose, de mettre en place tout ce qu'il faut pour que ça bosse automatiquement sans vous faire ch... à chaque fois que la Freebox décroche, puis il vous faudra penser à reprendre ce didacticiel pour renuméroter les titres car le crétin qui a écrit ce document a sauté le point 5.

Lequel crétin remercie Emin, auteur de l'article Piloter sa freebox, disponible ici : ainsi que Mika-NT28 auteur du plugin Freebox OS pour Jeedom qui permet de superviser la box depuis Jeedom, lequel a également été une source d'inspiration. Et moi je remercie mon collègue FredV qui a passé une nuit sur ce petit projet !

Download

https://github.com/mycanaletto/Reboot-Freebox

Release : Reboot_Freebox_01.zip

Bonus

Comme indiqué dans le bug la collection de buggs de la Freebox, la nouvelle version du Compagnon Freebox, mais également tout ce qui accède localement à l'url sécurisée de la Freebox, ne parvient plus à trouver la Freebox en mode bridge et donc à générer une nouvelle association. Il existe une solution ici.

Sources 

^{https://lafibre.info/routeur/free-usg-mode-bridge-down-apres-desync/ 
https://dev.freebox.fr/bugs/task/22818 
https://kb.paessler.com/en/topic/18963-how-can-i-use-powershell-scripts-with-prtg-s-execute-program-notification 
https://p0w3rsh3ll.wordpress.com/2013/07/04/piloter-sa-freebox/ 
https://github.com/DjMomo/ClassePhpFreebox 
https://wiki.deimos.fr/Rebooter_sa_Freebox_Server_6_en_ligne_de_commande.html 
https://forum.universfreebox.com/viewtopic.php?t=55120 
https://dev.freebox.fr/bugs/task/12939 
https://dev.freebox.fr/sdk/os/}

Depuis plus d’une décennie je suis un grand fan des produits Sonos, que je conseille à qui veut bien m'écouter. A l’opposé des enceintes Bluetooth, le système Sonos à démocratisé le multi-room en Ethernet et WI-FI à un coût abordable face aux systèmes multi-room coûteux proposés par les intégrateurs pour résidences de luxe, type Crestron et autres. Du coup j’en ai dans toutes les pièces, des Play 1 et Play 3 et j’ai récemment fait l’acquisition d’un Sonos AMP pour le séjour, c’est fabuleux tant en musique qu’en vidéo. Je ne vais pas vous faire l’article, il y en a pas mal sur la toile, mais j’ai vraiment redécouvert certains enregistrements de façon bien plus agréable qu’avec mon ancien Connect associé à un ampli basic, tout en conservant les mêmes enceintes Amadeus, associées avec un bon sub, qui sont alors pleinement exploitées.

EDIT du 6 septembre 2019

Hier, Sonos a annoncé 3 nouveau produits.

• Une enceinte portable, la Play Move est une sorte de Play One avec une très lourde batterie et du Bluetooth à 400 €. Trop chère et trop lourde pour être emmenée partout, je ne suis pas convaincu par la pertinence de ce produit. J’ai déjà une Play 1 sur la terrasse ou il y a déjà une prise électrique.
• Une enceinte sans micros, la Play One SL une Play One allégée, moins chère elle sera parfaite pour qui ne veut pas d’assistants vocaux ou en complément home cinéma, encore qu’elle soit en concurrence avec l’enceinte étagère proposée par Ikea à 99 €.
• Et enfin le Port qui remplace le Connect et se trouve être un AMP sans ampli destiné à être connecté à une installation HI-FI classique, plutôt haut de gamme, sans quoi il existe pas mal d’accessoires qui feront le job, comme le ChromeCast audio sans dépenser 450 €. Et tout comme sur le AMP, toujours pas d'entée RIAA pour y connecter une platine vinyle sans ajouter un pré-ampli.

Tout cela pose une fois de plus une question, utilisons-nous réellement du multi-room ou voulons-nous simplement de la musique dans chaque pièce ? Dans la pratique je constate, que tant moi que mes enfants, utilisons de plus en plus l’application Spotify et que dans ce cas il faut juste pouvoir se connecter à une pièce compatible Spotify Connect… Pas forcément sur un Sonos…

Dans la salle de bain j’avais un Connect AMP, un peu poussif, associé à des enceintes encastrées dans le plafond de qualité moyenne. Hélas le Connect AMP a fait son temps (2005) et j’ai découvert à cette occasion que le SAV Sonos en France ne répare pas ses produits. Sous garantie ils les échangent, et hors garantie ils proposent un échange standard à 80% du prix du neuf (Lire 1 2) (soit environ 450 € pour un Connect AMP obsolète). Bref, il faut le savoir, et même si je n’ai vu qu’une panne en 15 ans, les produits Sonos ne sont pas réparables, sauf peut être par de bons bricoleurs !

Soit, je me suis donc dit qu’une petite Play One dans la salle de bain ferait largement l’affaire. Il n’en reste pas moins que voir ces deux enceintes encastrée inutilisées me chagrinait. Avec un peu réflexion je me suis dit qu’un petit ampli avec un Chromecast Audio que j’avais sous le coude ferait l’affaire, car plus que du multi-room, là ce sont surtout mes enfants qui envoient leur flux Spotify quand ils vont se doucher. En cherchant un peu je suis tombé sur des amplis classe T à un tarif dérisoire pour la puissance annoncée (30 € pour 2 x 50 W, Bluetooth inside !)

A ce tarif je me suis offert le NS-10G de NobSound sur Amazon mais on peut en trouver d’autres moins coûteux sur AliExpress, je l’ai raccordé au ChromeCast Audio (Google ne le propose plus mais ça se trouve facilement pour une trentaine d’Euros) qui est compatible directement avec Spotify. Il est également possible de recycler un utiliser un Raspberry avec un peu de logiciel (1|2|3), ou un adaptateur comme ceux d'Arylic (sur AliExpress en morceaux 1|2) et que l'on trouve également monté sur Amazon, le A50 semble très bien...

Alors me direz-vous, quelle différence entre un vieux Sonos Connect AMP à 550 € et un bricolage à base de chinoiserie à 60 € ? Et bien c’est quasiment pareil, en tous cas avec ces enceintes moyennes et une source Spotify, on ne sent pas vraiment de différence, si tant est qu'on ne pousse pas trop la puissance. Attention à ne pas confondre avec le Sonos AMP qui lui est juste fabuleux, il est vrai associé à des enceintes Amadeus d’un autre calibre, avec lesquelles le Connect AMP ou Connect ne donnaient pourtant pas grand-chose…

Bref, il est temps de s’intéresser aux amplis de classe D et pourquoi pas classe T.

Alternatives et liens connexes

^{http://www.doukaudio.com
http://www.smsl-audio.com des choses sérieuses… 
https://www.amazon.fr/gp/product/B07GB6H9B1/ref=as_li_tl?ie=UTF8&tag=canaletto-21&camp=1642&creative=6746&linkCode=as2&creativeASIN=B07GB6H9B1&linkId=055d0ce2444f8d60788d2c4886dc340d 
https://www.amazon.fr/gp/product/B07KX3MHLV/ref=as_li_tl?ie=UTF8&tag=canaletto-21&camp=1642&creative=6746&linkCode=as2&creativeASIN=B07KX3MHLV&linkId=c26908559bdc1fee991df4bf2a6a672d 
https://www.ebay.com/b/Nobsound-Mini-Amplifiers/14970/bn_89892901}

Bonus

Pas de lien direct, mais une lecture amusante, j’aime ces amateurs qui poussent très loin… Je n’ai pas testé mais ça va dans le sens où j’affirme depuis des lustres qu’il ne faut pas se faire enfler par les vendeurs de HIFI et leurs câbles à 100 € le mètre !

^{https://www.homecinema-fr.com/forum/diy-cables/cable-hp-viablue-sc-4-vs-ethernet-ou-ptt-la-claque-t29933292.html 
http://petoindominique.fr/php/cablehp.php 
http://g.dubuc.free.fr/CableRJ.html 
https://www.touslescables.com/cordon-rj45-enceinte-H9AL-2098.html}

On ne vantera jamais assez les mérites d’un reverse proxy en termes de sécurité. Mais au-delà de la sécurité, un reverse proxy peut aussi nous faciliter la vie pour la publication de services web en mode sécurisé, et donc la gestion des certificats.

Si selon le niveau de protection et d’assurance il faudra continuer à acheter des certificats hors de prix, dont la sécurité a parfois été corrompue même chez les soi-disant plus sérieux fournisseurs, pour bien des services l’utilisation de certificats Let’s Encrypt fera parfaitement l’affaire.

Au passage vous noterez que si j’étais fan de Sophos XG, je suis en train de m’orienter vers pfSense que je trouve bien plus simple et mieux documenté par la communauté.

Il y a plusieurs façons d’utiliser Let’s Encrypt :

• Via un script ou un logiciel installé sur le backend (le serveur web) qui génère le certificat, il faudra ensuite l’exporter manuellement ou via un script vers le reverse proxy si on en utilise un en frontal, mais on peu aussi passer en direct, en NAT ou une simple redirection de ports.
• Via un script géré par le firewall / reverse proxy. C’est ce que je vais décrire ici en utilisant pfSense ou j’installerais les paquets Acme et HAProxy.

Acme

Automated Certificate Management Environment, for automated use of LetsEncrypt certificates.

Cette implémentation très complète va nous permettre de générer et renouveler automatiquement des certificats Lets’s Encrypt (Standard, Wilcard ou San) et de les installer dans pfSense. Cette implémentation sait s’appuyer sur les API des principaux DNS, ce qui nous évitera d’avoir à ouvrir un port 80 comme cela était nécessaire auparavant. Le plus simple sera de générer un wilcard : *.domaine.tld.

Il sera également possible d’exporter ces certificats, manuellement, ou via un script vers un serveur web si nécessaire (par exemple, un script PowerShell sur un serveur Exchange pour récupérer les certificats, les installer et les activer).

Dans notre exemple on n’exporte rien car on va se servir de HA Proxy comme Frontend, c’est à lui qu’incombera la gestion du SSL (le SSL Offloading consiste à déporter la gestion du SSL sur le reverse proxy / load balancer, et donc sur le serveur web on ne laisse que le service HTTP, les sessions HTTPS n'étant cryptées qu'entre l'internaute et le reverse proxy qui peut également jouer un rôle d’équilibreur de charge si nécessaire).

HA Proxy

The Reliable, High Performance TCP/HTTP(S) Load Balancer.

Il s’agit ici d’un reverse proxy moderne qui permet également d’équilibrer la charge vers plusieurs Backends.

On aurait pu utiliser le paquet Squid, mais je lui reproche de ne pas gérer SNI (à vérifier) et donc de ne pouvoir servir plusieurs domaines en SSL. Squid est toutefois plus simple et fera l’affaire pour une installation simple ou domestique. A noter également que tant HA Proxy que Squid permettent de publier un serveur Exchange, et donc de remplacer avantageusement de vieux ISA ou TMG que Microsoft nous a tant vanté avant de les oublier…

Je ne vais pas reprendre un fastidieux steep by steep de publication il y en a de très bien faits… mais juste résumer :

1. Installation de pfSense (il y a des VM toutes prêtes) avec un lien WAN et un lien LAN. On peut éventuellement ajouter des IP virtuelles (VIP) coté WAN si on en dispose.
2. On crée une règle sur le firewall ou on autorise le port 443 (HTTPS) en entrant sur le WAN.
3. Sur HA Proxy on crée un Backend avec l’IP interne sur le port 80 (ou autre) et sans SSL (sans car on pourrait également sécuriser le flux interne). Dans les options de LoadBalancing on choisit None si on a qu’un Backend, et dans ce cas on n’oublie pas de choisir également None au niveau Health checking. Et c’est tout, le reste si on ne sait pas, on ne touche pas.
4. Sur HA Proxy on crée un Frontend qui écoute sur le port WAN (ou VIP), on coche SSL Offloading et plus bas dans SSL Offloading on choisit le certificat lié au domaine que l’on va utiliser (une règle Frontend par domaine géré). Dans Default backend, access control lists and actions on va gérer nos serveurs en utilisant l’expression Host Matches et la valeur, par exemple canaletto.fr que l’on nomme www (inutile si on n’a qu’un seul serveur à sécuriser). Ensuite plus bas dans Actions on va dire que la condition www est redirigée vers le Backend idoine. Ici aussi, c’est tout, le reste si on ne sait pas, on ne touche pas, car comme vous pourrez l’observer HA Proxy dispose d’une multitude d’options qui ne seront utiles que dans certains cas.

Test

Pour tester ce genre de configuration l’idéal est de disposer une machine connectée sur l’internet en dehors de votre réseau. La machine d’un ami en remote (TS, TeamViewer, NoMachine ou AnyDesk) ou encore une machine connectée en 4G.

Comme à ce stade on n’a probablement pas encore renseigné le DNS public, le plus simple est de créer une entrée dans le fichier hosts (sous Windows le plus simple est d’utiliser HostMan). 

Ensuite on lance une session dans le navigateur et on vérifie que c’est vert et que le certificat est valide et correspond bien à celui utilisé. Si c’est le cas il n’y a plus qu’à s’occuper du DNS public.

Info

Vous imaginez bien que je n’ai pas creusé ce sujet uniquement pour publier un Jeedom. Au départ il s’agissait de publier des serveurs Microsoft Exchange avec des certificats SAN classiques et couteux, et quand on publie de l’Exchange on peut faire à peu près tout. Ensuite j’ai trouvé la gestion Let’s Encrypt tellement simple dans pfSense que je me suis dit que finalement cet outil embarqué dans une VM ou un petit Appliance pouvait d’adapter à toutes les situations, même les plus simples. Du coup je vais probablement remplacer Sophos XG et pourquoi pas également chez moi à la place ou à côté de l’USG qui est très bien pour le trafic sortant mais n’évolue pas trop et ne permet pas de faire du reverse proxy.

Sources

_{https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html
https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://pixelabs.fr/installation-role-transport-edge-2016-partie-2/
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://www.supinfo.com/articles/single/6326-mise-place-serveurs-web-haute-disponibilite-avec-haproxy-pfsense
https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://forum.netgate.com/topic/99804/squid-reverse-proxy-for-multiple-internal-hosts
https://tecattack.ch/index.php/2018/12/10/pfsense-2-4-4-haproxy-reverse-proxy-multiple-http-server-ubuntu-16-04/
https://all-it-network.com/pfsense-reverse-https/
https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/}

Il y a quelques semaines j’ai installé dans le studio d’un ami un ensemble de caméras Unifi. Au départ j’étais tenté par piloter l’ensemble avec une Cloud Key II+ ou pour 200 € on dispose d’un contrôleur Unifi et d’un NVR avec 1TO de disque. Problème, ce produit n’est pas vraiment disponible en France et je n’avais aucun recul sur la chose. Finalement j’ai recyclé un DL360G5 que j’avais déposé il y a quelques mois, même pas eu besoin de le réinstaller car son ESX 5.5U3 tournait comme une horloge, très largement suffisant pour faire tourner une VM Windows qui supporte le NVR soft d’Unifi. On est face à une installation professionnelle, la qualité est au rendez-vous, notamment le retour audio qui est assez bluffant, et l’ensemble est cohérent pour un coût contenu.

Bref, si je vous raconte ma life c’est pour introduire un petit jouet que j’avais commandé en parallèle pour tester, la Mi Home Security Camera 360°. En fait je ne pensais même pas que c’était une caméra motorisée, mais c’est le cas et la qualité Xiaomi est au rendez-vous. Et Xiaomi, je suis plutôt fan. Elle pivote donc de haut en bas, du sol au plafond et sur 360°, c’est du full HD 1080p avec un zoom numérique 16x acceptable et une vision nocturne donnée pour 9 mètres. Elle dispose d’une détection de mouvement dopée à l’IA et il est possible d’enregistrer les séquences en local sur une SD ou encore sur un NAS.

Que dire d’autre sur ce gadget ? Ah si, il y a un truc qui est bluffant et que d’aucuns trouveront restreignant. Ici pas de serveur web embarqué chip comme sur la plupart des caméras asiatiques, tout se passe uniquement via l’application Mi Home sous Android ou IOS. Et ce qui est bluffant c’est que l’installation se fait en deux minutes chrono. On lance l’application Mi Home, on choisit le SSID de son réseau Wi-Fi ainsi que le mot de passe et on place son smartphone sur lequel s’affiche un QR Code face à la caméra. Et basta, la petite caméra est configurée. Pas besoin de jouer avec des ports et des IP, c’est out of the box, mais il faudra cependant il faudra toujours passer par l’application du constructeur.

Ah si un dernier truc pour se laisser tenter, le prix c’est 39,99 € et sur Amazon on trouve même des modèles de démo reconditionnées pour moins cher. Autre option, l’Asie en direct chez Gearbest ou AliExpress, mais c’est à peine moins cher et bien plus long…

On en découvre tous les jours ! Je vais vous parler des équipements Wi-Fi Shelly. Il s’agit de micro-modules, avec un ou deux contacts, des modules au format DIN à insérer dans un tableau électrique, des contrôleurs RGBW ainsi qu’un capteur de température et d’humidité. Rien de bien neuf sur le soleil me direz-vous, mais contrairement aux équipements asiatiques habituels (Sonoff par exemple) qu’il faut flasher ou hacker en perdant au passage le mode de fonctionnement original, les équipements Shelley sont totalement ouverts, et si on souhaite les flasher en ESP Easy le constructeur fournit tout ce qui est nécessaire pour le faire. 

De base on dispose d’une application mobile qui permet la configuration et le pilotage. Un cloud (optionnel) pour un pilotage à distance sans box, la comptabilité MQTT, une API REST et il est bien sur possible de les piloter avec Google Home ou Alexa. Cerise sur le gâteau, ces produits fabriqués en Roumanie sont vraiment certifiés CE et les tarifs sont très attractifs (10 € le relais simple). 

Attention, c’est du Wi-Fi, donc il est impératif d’avoir un réseau Wi-Fi stable.

L’appairage se fait en quelques secondes avec l’application idoine, et des lors que les modules sont reconnus sur le réseau il est possible de terminer la configuration sur le serveur web intégré à ceux-ci. Etant donné que l’on va les exploiter avec une solution domotique externe, Jeedom en l’occurrence, je ne saurais trop conseiller de leur attribuer une IP fixe. Si cela est possible dans la configuration web de chaque module, personnellement je préfère me servir de mon serveur DHCP.

Pour exploiter ces modules en domotique il y a la possibilité MQTT, il doit être également possible de passer des commandes http aux modules, mais je n’ai pas testé car il y a un plugin qui fait très bien le job et qui permet de conserver la compatibilité avec l’application mobile du constructeur. Ce plugin est simple et efficace, pour chaque équipement il suffit de renseigner l’adresse IP et ensuite d’utiliser l’équipement.

Attention toutefois au module capteur de température et humidité, il fonctionne sur pile et se mets en veille, le plugin n'est de ce fait pas toujours capable de récupérer les valeurs et les relevés sont donc trop espacés.

Je trouve ces modules intéressants à plusieurs titres. La simplicité, des tarifs attractifs pour un matériel de qualité, le format DIN et une puissance admissible compatible avec la plupart des radiateurs. A prendre en compte pour remplacer par exemple des équipements Chacon au comportement parfois aléatoire, bref un pas de plus pour l’élimination du RFPLayer…

Sources :

_{https://lunarok-domotique.com/2019/01/shelly-1-domotiser-prise-10-euros/}

Une plateforme Jeedom, même sur une Raspberry Pi est un serveur qui reste faillible, surtout quand on le fait tourner sur une carte SD. Certains sont adeptes de montages sur SSD, d’une part un SSD n’est pas infaillible et d’autre part je préfère faire simple. On va donc explorer deux méthodes de clonage de notre fragile carte SD, étant entendu qu’en parallèle on fera bien sur des sauvegardes régulières (automatisées) de la configuration via Samba.

Clonage carte à carte

La première méthode va consister à cloner la carte SD vers une seconde carte SD insérée dans un adaptateur USB. Ça a l’avantage d’un redémarrage rapide en cas de crash, il suffit d’échanger la carte SD et de restaurer la dernière sauvegarde Samba. La configuration et l’exécution se font en SSH, il s’agit d’une exécution occasionnelle qui visera à garder sous le coude une carte SD avec une configuration stable.

git clone https://github.com/billw2/rpi-clone.git
cd rpi-clone
sudo cp rpi-clone rpi-clone-setup /usr/local/sbin

Utilisation

On commence par arrêter les services.

cd rpi-clone
sudo service mysql stop
sudo service cron stop
sudo service apache2 stop
sudo service mariadb stop

Pour une copie SD vers USB (Ou sans -f ensuite pour faire juste une synchro, -v pour voir ce qu'il se passe...).

sudo rpi-clone sda -f

Redémarrage des services. (Personnellement à ce stade je préfère faire un « sudo reboot »)

sudo service mysql start
sudo service cron start
sudo service apache2 start
sudo service mariadb stop
sudo systemctl daemon-reload

On peut éventuellement ajouter un Cron si on laisse une carte en place…

Clonage vers un fichier image 

La seconde option consiste à créer une image de la carte SD vers un serveur NFS (Un Nas par exemple). On part du principe que le NAS est correctement configuré en NFS, la procédure pour Synology est ici.

On va commencer par tester les prérequis et notamment la présence du protocole NFS et de PV (Pipe Viewer) qui nous permettra de voir la progression du clonage lors de nos tests :

dpkg -l | grep nfs-common _ou apt-get install nfs-common _{pour l’installer.}
dpkg -l | grep pv _ou apt-get install pv _{pour l’installer.}

Le clonage

On commence par créer un point de montage

sudo mkdir /mnt/Backup_NAS

Ensuite il faut inscrire le montage dans fstab, ce qui va permettre le montage automatique du partage au démarrage du système et qui sera utile pour l’automatisation : « 

sudo nano /etc/fstab

Et on ajoute la ligne suivante :

IP du NAS:/volume1/Backup/Jeedom    /mnt/Backup_NAS    nfs    rw,user    0    0

On teste avec

sudo mount -a && sudo df

Et le montage distant doit apparaître. On peut aussi tester l’écriture avec

sudo mkdir /mnt/Backup_NAS/totofaitdubato

On va maintenant pouvoir lancer manuellement la création de notre première image, en prenant soin auparavant de stopper les services et bases :

sudo service mysql stop
sudo service cron stop
sudo service apache2 stop
sudo service mariadb stop _{# j’ai parfois eu des erreurs quand je n’arrêtais pas ce service #}
sudo dd if=/dev/mmcblk0 bs=4M | sudo pv -treb | sudo dd of=/mnt/Backup_NAS/SD_Backup/Backup_SD_TEST.img && sync

L’image aura la taille de la carte SD, il est possible de la compresser, mais vu que cette opération est déjà très longue, je ne suis pas sûr que ça vaille le coup d’alourdir la tâche.

sudo dd if=/dev/mmcblk0 bs=4M | sudo pv -treb | sudo gzip -1 -| sudo dd of=/mnt/Backup_NAS/SD_Backup/Backup_SD_TEST.img && sync

Une fois le clonage de test effectué on va graver une nouvelle carte avec Etcher et la tester. Normalement cette carte peu remplacer celle d’origine.

Automatisation

On part du principe que l'on dispose d'une sauvegarde quotidienne dont on vérifie le processus, rien de plus désagréable que les sauvegardes ne fonctionnait plus quand on en a besoin. Re cloner la carte SD reste à faire quand on effectue des modifications du système, comme par exemple de grosses mise à jour du core ou des changements dans les plugins.

Script + Cron + envoi de mail... (à venir...)

Lire la carte SD Jeedom sous Windows

Il peut parfois être intéressant de lire une carte SD Jeddom sous Windows, par exemple pour y récupérer une sauvegarde quand on est une buze sous Linux. En fait c'est assez simple, il suffit d'installer le driver idoine qui se trouve ici et les explications sont là. (pour mémoire les sauvegardes sont ici : /var/www/html/backup)

Sauvegarde via Samba

Vers un PC (à venir... Mais il existe plein de tutos sur le net...)

Sauvegarde Cloud

Vers Droopbox, Google drive, OneDrive, SFTP et FTP (à venir... Mais il existe des totos sur le net...)

Sources 

• https://github.com/billw2/rpi-clone
• https://www.jeedom.com/forum/viewtopic.php?f=152&t=31252
• http://astrolabo.com/2017/02/11/script-de-clonage-dune-carte-sd-vers-nas/
• https://github.com/billw2/rpi-clone
• https://domopi.eu/sauvegarde-de-la-carte-sd-du-raspberry-pi-sur-un-serveur-externe/
  
• https://www.alexpage.de/usb-image-tool/