Passerelle Combee II

À 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 (et pas très WAF) 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. 

Edits

  • 01/11/2019 : J'ai voulut déplacer la carte SD (Image Photon) de ma passerelle dans un RPI2 au lieu du 3 et ça ne démarre pas. Retour au RPI3, pas envie d'y passer la soirée...

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

 

ZiGate mon amour...

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.

 

Jeedom : Cloner la carte SD

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 . (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 

Jeedom : RFPlayer et génériques...

Les RFPlayer est une interface USB qui raccordé à Jeedom va permettre de décoder une multitude d’équipement, un peu à la matière du RFX-Com mais sur deux fréquences (433 et 868 MHz) et avec bien plus d’équipement reconnus. Dans la pratique ce n’est jamais que la technologie liée à l’héritage de la feu ZiBase dans une clé USB. Sur le papier glacé c’est génial, dans la pratique pour en tirer le meilleur parti c’est la qualité du plugin assurant l’interface avec la solution domotique retenue qui fera la différence. Sous Jeedom il y a d’abord eu une première version du plugin avec pas mal de problèmes, mais qui reconnaissait nativement les équipements. Ensuite nous avons eu une v2 bien plus stable mais qui fonctionne sur mode générique, dans l’absolu sans limites, mais qui déroute un peu au départ et rebutera plus d’un débutant. D’autant plus que l’équipe Jeedom n’est pas des plus prolixe en matière d’explications. Un peu comme si les nouveaux venus devaient mériter la solution !

Ça n’a donc pas été simple, mais au final le résultat est étonnamment plutôt stable. Si certains équipements sont reconnus nativement (les sondes Oregon par exemple), l’affaire est un peu plus complexe des lors qu’il s’agit d'exploiter des équipement X2D ou Visonic. Je vais essayer de vous donner ici quelques explications. On considère que le RFPlayer est installé, son firmware à jour et le plugin installé dans sa dernière version.

Visonic

En  passant par le plugin en mode inclusion il est aisé de détecter les équipements, il faudra ensuite les localiser physiquement, mais ça on le fera plus tard. Pour l’instant ce qui importe c’est de détecter l’ensemble de capteurs. Ce qui va nous intéresser ici c’est la valeur qualifier qui est une information numérique que l’on exploitera avec un script ou un virtuel. Voici les valeurs pour un détecteur d’ouverture (MCT-302 ou un IR) et ce que j’en ai déduit d’après les informations que j’ai pu trouver sur les forums :

0 Fermé (action immédiate)
2 Ouvert (action immédiate)
4 Warning ? défaut sur le capteur, autoprotection ?
8 Fermé (en veille ou pour supervision par la centrale)
10 Ouvert (en veille ou pour supervision par la centrale)
12 Batterie faible

Ces valeurs n’étant pas binaires il sera impossible de les exploiter directement pour détecter une fenêtre ouverte dans une thermostat ou avec le plugin Alarme. Tout au plus il est possible de programmer une (et une seule) action sur la valeur directement dans les paramètres avancés du qualifier, mais ce n’est pas très propre et limitatif. On peu également créer un widget qui affichera les divers états, c’est ce que l’avait expliqué le support Jeedom, c’est joli, didactique, mais ça ne sert à rien. J’ai donc créé un équipement virtuel, qui pour chaque sonde Visonic va transformer ces informations numériques en informations binaires, après tout ce dont j’ai besoin c’est de savoir si ma fenêtre est ouverte ou fermé !

(#[Alarmes][Chambre Lionel][qualifier]# & 2) == 2 or (#[Alarmes][Chambre Lionel][qualifier]# & 10) == 10

Ce qui nous donne ça en fignolant un peu... 

A partir de là cette information étant binaire elle est directement exploitable dans d’autres plugins ou scénarios.

EDIT : Cette solution permet d’avoir une visibilité globale des capteurs, et je dois bien avouer que je ne savais pas trop faire autrement. J’avais pourtant posé la question tant sur le forum que directement au support Jeedom sans réponse satisfaisante. Jusqu’à ce qu’un développeur de passage sur mes posts du forum m’explique qu’il est possible de faire bien plus simple en ajoutant une commande data::qualifier de type info directement sur l’équipement :

Et ensuite la formule de calcul idoine (#[Alarmes][Test][qualifier]# & 2) == 2 or (#[Alarmes][Test][qualifier]# & 10) == 10 dans la configuration avancée :

Il est également possible de simplifier la formule ainsi (#[Alarmes][Chambre Lionel][qualifier]# & 2) == 2, mais on aura alors que l'état instantané et non l'état en veille, mais c'est généralement suffisant et le résultat est identique. On évite ainsi le Virtuel et on obtient un résultat simplifié et directement exploitable. Je me demande juste pourquoi cette info n'est pas crée lors de la détection de l'équipement et pourquoi les auteurs du plugin ne l'ont documenté nulle part. Et ce n'est pas faute d'avoir cherché !

XD2

Pour récupérer des informations on doit pouvoir procéder de façon à peu près identique. Moi j’avais besoin que de commander un seul actionneur RP600 de chez DeltaDore qui actionne un fil pilote. Dans mon cas je gère ce sèche serviettes avec un thermostat Jeedom, donc ce que je voulais c’est uniquement faire du ON/OFF tout en laissant la possibilité d’utiliser la marche forcée physique du sèche serviettes. (Voir les détails ici). J’ai donc créé un équipement virtuel qui va transmettre ses ordres à l’équipement du RFPLayer et nous donner un retour d’état tout aussi virtuel. J’exécute donc une Action après exécution de la commande ou pour ON j’envoie #[Hardware][X2D RP600 SdB][Confort]# au RFPlayer, et #[Hardware][X2D RP600 SdB][Hors Gel Low]# pour OFF. Chacun adaptera à ses besoins et ça marche à l’identique pour les autres protocoles.

Conclusion

Contrairement aux habitudes, il est bien souvent impossible d’utiliser seul le nouveau plugin du RFPlayer. Il faudra soit écrire du code, des scripts ou des scénarios, soit se simplifier la tâche en exploitant intensément le plugin Virtuel. Quoi que...

Jeedom : Temporisation d'un équipement

Vous allez tout savoir. Je ne prends jamais ma douche à la même heure, il est donc impossible de programmer le chauffage de la salle de bain avec un agenda. Mais en général j’anticipe un peu ma douche, je me dis me dis que je vais bientôt aller la prendre car je ne vais pas tarder à sortir. Bref, l’objectif est donc de passer un sèche serviettes en marche forcée, ou en mode confort, pendant une ou deux heures. Certains vont me dire de bouger mon cul et d’aller appuyer sur le bouton idoine du sèche serviettes, et ils auront raison car la majorité de ces appareils en sont équipés, et c’est le cas du mien. Mais l’idée ici est que la démonstration soit générique et s’applique à n’importe quel équipement.

S’il est possible d’utiliser un smartphone ou n’importe quel bouton poussoir reconnu dans Jeedom, pour la démonstration je vais utiliser un gadget que j’ai sous la main, le bouton multiclic de Aquara de Xiaomi qui communique avec Jeedom grâce à la ZiGate et le plugin qui va bien (je dis « qui va bien » pour ne pas réemployer le mot « idoine » car ça ferait deux fois, mais en fait ce plugin ne va pas toujours bien, il s’améliore toutefois de versions en version).

Sur ce bouton on peut récupérer 3 valeurs : 2, 3 ou 4 clics. Pourquoi pas 1 seul ou 5, ne me demandez pas, c’est ainsi ! Donc grâce à un virtuel, je vais récupérer ces 3 états et en faire des informations binaires

Ensuite je vais créer un scénario qui sera provoqué par un évènement sur un de ces 3 états. Si Multiclics=2 je déclenche mon scénario. Il est des plus simples, avec une ACTION qui passe le thermostat de la salle de bain en mode Confort suivi d’un bloc DANS qui le repassera en mode Eco dans 120 minutes. Le bloc DANS étant une commande secondaire qui va s’exécuter dans 120 minutes contrairement à sleep ou wait qui laisserait le scénario actif pendant 120 minutes ce qui consommerait de la CPU à ce que j’ai compris, voire provoquerait une erreur.

Variantes

On peut également associer à cette action la grande vitesse de la VMC, je ne l’ai pas fait car elle est déjà gérée par l’hygrométrie. Par contre je pensais à utiliser les 3 valeurs des clics pour lancer 3 temporisations différentes.

 

Lampe Xiaomi Mijia

On sort un peu de l’IT pour du beau. Ceux qui me connaissent savent que je suis sensible à ce qui est beau, d’ailleurs cet aspect-là y est sûrement pour quelque chose dans mon choix Unifi… Mais revenons au beau d’aujourd’hui. J’ai donc acheté cette lame parce que je la trouvais belle sans pour autant me préoccuper du fait qu’il s’agissait également d’un objet connecté. Elle est conforme à ce que j’attendais, le reste est un plus.

De base il y a un seul bouton qui permet de gérer l’intensité et le ON/OFF. Si on veut aller plus loin il faut installer l’application Yeelight sur son smartphone et on a accès aux différentes programmations horaires possibles, un mode qui vous avertit qu’il est temps de faire une pause, ainsi que le réglage des températures de blanc et une tripotée de préréglages que l’on pourra personnaliser. Il faut donc un compte MI, et c’est également ce compte qui fera la liaison avec les assistants vocaux.

La lampe est donc reconnue par Alexa qui rend possible la commande vocale de tous les réglages (ON/OFF, variation et température de blancs), chose possible également avec Google Home qui fait toutefois l’impasse sur la température de blancs. Rien à dire, que ce soit avec l’application de base ou les assistants vocaux, on branche et tout fonctionne en quelques minutes et ça donne envie d'investir dans des ampoules de la même marque.

Sous Jeedom, si tant est que ça soit vraiment utile, il est possible en activant le mode développeur de gérer la lampe directement avec le plugin WiFILight2. Vu que c’est du direct IP ça risque toutefois de renter en conflit avec l’application de base et les assistants vocaux qui eux fonctionnent de consort. Il doit également être possible de la gérer plus proprement avec la passerelle Mi Home, mais je n’avais pas envie ce soir de parler chinois !

En conclusion pour une cinquantaine d’euros (voire moins sur les sites chinois) on a une belle lampe qui éclaire bien, avec un design que je trouve très réussit. Soit le prix moyen d’une telle lampe sur le marché. Le fait que ce soit aussi un objet connecté est la cerise sur le gâteau, libre à chacun d’utiliser ces fonctionnalités !

Jeedom : Gérer les coupures EdF

Etre informé d’une coupure électrique peut sauver le contenu d’un congélateur lors d’une absence. Dès lors faisons fonctionner la domotique. Il existe un micro module pour ça, l’ITS23 d’InterTechno (la doc est ici) qui fonctionne avec une pile et que l’on pourra associer à Jeedom via un RFPlayer ou un RFXCom. Il doit également être possible de gérer les coupures avec les retours des onduleurs, mais j’ai préféré gérer ça de façon indépendante.

Attention, ce micro module a deux modes de fonctionnement, activation quand le contact est fermé ou activation quand le contact est ouvert, cela joue pour le poussoir qu’il gère en parallèle mais également pour le sens des codes émis. Et c’est là que ça se complique car de fait à la reprise électrique il s’associera automatiquement aux prise Chacon qui elles aussi redémarrent et au départ sont toujours en mode association. Donc il s’associe sans que l’action soit voulue et ensuite les allume et les éteint. Avant de comprendre cet effet de bord je me suis bien cassé la tête à comprendre ce qui faisait allumer des lampes lors de chaque reprise électrique… Il va donc falloir contourner cet inconvénient avant de mettre en service nos scénarios.

On choisit la position O (activation quand le contact est ouvert), ce qui va provoquer le passage en position ON des objets Chacon associés. Dans notre cas ce n’est pas grave car ces objets sont éteints lors d’une coupure électrique, donc sans incidence, sauf que c’est un peu déroutant pendant les tests. On aura donc un OFF lors de la reprise électrique et là on pourra toujours compenser avec un scénario associé (de toutes façons un Chacon est toujours OFF lors de son branchement / alimentation).

On associe l’ITS23 à Jeedom, ici via le RFPlayer, et on obtient deux infos qui vont nous intéresser. Une Info Numérique que l’on va nommer Coupure Alim qui retournera 1 si coupure et reviendra à 0 lors de la reprise, et une autre Info Textuelle que l'on nommera Alerte EdF et qui retournera ON si coupure et OFF lors de la reprise.

 

En allant dans la configuration avancée (la petite roue crantée à côté du bouton tester) de ces deux valeurs on va pouvoir configurer des actions. Comme on ne peut configurer qu’une action par valeur, on va se servir des deux, j’utilise la valeur OFF de Alerte EdF pour envoyer un sms notifiant la coupure, et la valeur 0 de Coupure Alim. pour envoyer une notification de reprise et lancer un scénario sur reprise, avec un délai afin de pallier au micro coupures.

Pour l’instant je ne me sert pas de la valeur du poussoir, mais on pourrait imaginer que cet équipement pourrait servir à autre chose…

Jeedom : Recycler sa ZiBase

La ZiBase avait pour elle une fonctionnalité très intéressante : ses voyants. Ces 5 leds pouvaient s’activer par scénario et ainsi apporter une information visuelle instantanée. Sous Jeedom il n’y a pas de voyants et j’avoue que ça manque. Alors j’ai cherché des afficheurs, il y a bien sur des choses toutes faites comme Lametric qui vaut un bras ou des solutions DIY qui imposent le fer à souder, ce dont je n’ai pas envie. Et puis en réfléchissant je me suis dit qu’il devait être possible de recycler la ZiBase désormais éteinte, puisqu’on peut la commander via une url… Et que de toute façon il était inutile de la coller sur le boncoin !

Préparation

Coté ZiBase

La première chose à faire de la nettoyer. En effet si on la rebranche il y a des chances que s’exécutent des scénarios qui vont interférer avec l’actuel Jeedom. Un reset me parait hasardeux car c’est un produit non maintenu et il y a des chances pour que ça ne redémarre pas. Il faut donc supprimer à la main tous les scénarios et tous les actionneurs. Et clairement s’armer de patience car ça prend un temps de fou, c’est là que l’in se rend compte combien elle était lente…

Ensuite on va créer 15 nouveaux scénarios dont le seul but sera d’allumer, faire clignoter ou éteindre chacune des 5 leds. Coté ZiBase c’est tout, et comme ces scénarios sont stockés en local, même si les serveurs Zodianet s’arrêtent un jour ils seront persistants.

Coté Jeedom

Ici on va créer 5 scripts avec le plugin idoine (on en fait un et on duplique). Ces scripts auront pour but de lancer les requêtes http locales vers la ZiBase.

Une fois ces scripts créés il n’y aura plus qu’à s’en servir, dans un thermostat par exemple, ou quand je chauffe j’allume une led, et quand je ne chauffe plus j’éteins la led. Ou dans un scénario ou tout autre usage libre à votre imagination.

That’s all folks !

Jeedom : Tuya via IFTTT

 

Edit du 11/11/2019 : Il existe maintenant un plugin Tuya / SmartLife, l'utilisation de IFTTT perd donc de son intérêt...

L’objectif est de pouvoir commander dans Jeedom des équipements Tuya comme (Konyks par exemple, mais on en trouve à foison sur Amazon ou les sites chinois à bien moins cher). Ces objets connectées WI-FI ne sont pas pilotables en local, on va donc biaiser en passant par IFTTT. Le prérequis est bien sur un compte IFTTT et y avoir associé son compte Tuya SmartLife (lié aux applications : TuyaSmart, Smartlife ou encore Konyks (ce soint des OEM Tuya), ou autre comme eWlink pour Sonoff) en ajoutant le service SmartLife à IFTTT (Google est votre ami…).

Sur IFTTT on crée une applet +this et on cherche Webhooks que l’on sélectionne :

 

On lui donne ensuite un nom Prise_Halogene_ON (sans espaces et sans accents) + Create trigter et on clique sur +that et on cherche SmartLife et on choisit Turn on :

Et on choisit ensuite dans la liste la prise que l’on souhaite allumer par cette action, on crée Create action et on valide sur la page suivante ou se trouve également l’option permettant de recevoir une notification sur l’application mobile. Sur la page suivante on fait un check. Ensuite on va sur Services / Webhooks et on clique sur le bouton documentation en haut à droite et on arrive sur la page qui va nous permettre d’obtenir la commande curl. Il suffit alors d’insérer le nom de notre commande dans le champ {event} pour obtenir en bas la ligne de commande que l’on utilisera dans Jeedom. J’ai volontairement coupé car c’est ici qu’il y a la clé secrète… On peut ici également tester que notre prise s'allume bien !

Utilisation avec Jeedom

La solution retenue ici est Jeedom, mais ça peut fonctionner dans n’importe quel système sachant envoyer une commande curl. Dans ce cas d'usage le plugin IFTTT ne sert à rien (j'ai perdu un peu de temps à le comprendre, il sert en fait à commander Jeedom via IFTTT). On va utiliser le plugin SCRIPT et créer un équipement activé mais non visible que l’on nommera par exemple IFTTT Prise Tuya. On ajoute deux commandes de type Script + Action que l’on nommera Prise_Halogene_ON (ou Prise ON, ça n’a pas de rapport avec le nom IFTTT) et dans la requête on crée un script (bouton vert) dans lequel on colle notre ligne curl. On fait pareil pour OFF et on sauvegarde.

Ensuite on passe au plugin VIRTUEL dans lequel on va créer notre interrupteur virtuel. On ajoute un équipement, on le nomme, on l’active et on le rend visible. On crée le ON, le OFF comme sur la capture et on sauvegarde ce qui nous crée une commande d’info que l’on configure en Binaire et que l’on nomme Etat.

On clique sur la petite roue à dent à droite du ON pour configurer le type générique, ici une prise et la commande vers le script que l’on a créé précédemment. On refait pour le OFF et pour l’Etat on choisit Prise Etat en type générique. C’est aussi ici que l’on va choisir l’icône qui apparaîtra sur la commande dus Dashboard. La configuration du type générique prend son importance par exemple avec des applications externes comme Imperihome.

Voilà c’est terminé.

On peut maintenant utiliser cet équipement dans n’importe quel scénario ou commande. L’inconvénient de cette solution est qu’elle passe par Internet + IFTTT + le cloud Tuya. Un plugin Jeedom, qui comme sous d’autres solutions domotique, utiliserait les API Tuya serait le bienvenu. Cela simplifierait l’usage, mais surtout on gagnerait en réactivité et on serait plus synchro avec l’application mobile Tuya. L’idéal serait que cet hypothétique plugin sache parler aux équipements en local. Des bricolages de type RE existent pour les ampoules (plugin WIFI-Light2), mais cette solution est tributaire des changements possibles des spécifications de Tuya, et je ne pense pas que Tuya, dont l’objectif est de proposer un écosystème cloud aidera dans ce sens...

EDIT 15/04/2019 : Je me lasse un peu de ces équipements parfois peu solides. J’avais une ampoule sous la marque Konyks que j’ai mis au rebus, de même que des prises de la même marque dont le bouton local est inopérant après quelques mois. Pour les ampoules je préfère utiliser des Xiaomi moins coûteuses, plus performantes, ouvertes et donc accessibles dans Jeedom directement avec le plugin idoine sans bricolages. Vivement que Xiaomi rende ses prises compatibles avec le marché français.

Sources

https://www.planete-domotique.com/blog/2018/08/01/prises-konyks-ifttt/
https://www.planete-domotique.com/blog/2015/09/22/connectez-ifttt-a-votre-serveur-domotique/

Jeedom : SSL avec Cloudflare

Pour sécuriser un site en SSL il y a plusieurs façons de faire, comme je l’avais expliqué ici. Si on passe outre les modèles payants, Let’s Encrypt qui impose l’ouverture du port 80 pour son renouvellement, il nous reste la passerelle OVH qui ne permet pas facilement une sécurisation de bout en bout. On va voir aujourd’hui comment utiliser l'alternative Cloudflare pour sécuriser de bout en bout en utilisant le certificat qu’ils fournissent gratuitement et qui ont la bonne idée d’avoir une durée de vie très longue (auto-renouvellement pendant 15 ans). Ce tuto est fait pour Jeedom sur Debian, mais on peut tout à fait utiliser cette technique sur un autre serveur, IIS sur Windows par exemple.

L’utilisation de Cloudflare sous-entend que le DNS du domaine soit géré par le Cloudflare. Ça peut paraître gênant mais au final c’est pas mal du tout car leurs DNS sont pratique et des plus rapides, notamment en réplication. Quand on va créer un domaine sur Cloudflare, celui-ci va aspirer notre ancienne configuration DNS et en créer une copie. Il n’y aura plus ensuite qu’à se laisser guider pour changer les serveurs de nom sur son registrar (Gandi, OVH, etc…), ce qui peut prendre un peu de temps avant d’être activé.

Une fois le domaine géré par Cloudflare il y a deux onglets qui nous intéressent ici, DNS et Crypto (allez fouiller car il y a plein d’autres choses intéressantes à explorer).

Sur DNS on va créer un enregistrement A (et AAAA si on veut être compatible IPV6) qui va pointer sur l’IP publique de notre serveur (ou un CName vers un DynDNS, je n’ai pas testé mais ça peut marcher, auquel cas ça deviendrait intéressant pour ceux qui n’ont pas d’IP fixe).

Ensuite on passe sur Crypto et on va créer un certificat que l’on prendra soin de récupérer (attention à bien stocker également la clé privée en .key). Voilà, pas besoin de CSR, le certificat est un willcard, ce qu’il veut dire qu’il pourra être utilisé pour d’autres sous-domaines (jeddom.domaine.tld, cam.domaine.tld …). C’est possible car son usage est conditionné par le transit via Cloudflare qui joue un rôle de reverse proxy. Donc ce certificat n’est pas utilisable (quoique...) sans Cloudflare et il ne sert qu’à sécuriser le flux entre Cloudflare et votre serveur.

Il suffira alors d’installer le certificat, facile sous IIS après une conversion en PFX, là c’est mon monde et j’ai l’habitude. Sous Jeedom, donc le couple Linux et Apache, j’ai un peu plus tâtonné car je ne suis pas dans mon domaine de compétence, mais Google est mon ami et j’ai fini par trouver en compilant plusieurs sources.

Activer SSL et installer le certificat sur le serveur Jeedom

Il va falloir se connecter en « root » sur le serveur Jeedom. Pour y parvenir il faut commencer par autoriser le SSH sur le user « root ». J’utilise BitWise SSH Client, mais on trouve d’autres alternatives et ce n’est pas très important. 

  • Login en SSH avec l’utilisateur « pi » + le mot de passe « raspberry » que vous avez j’espère changé au début de l’installation..
  • Edition du fichier de configuration avec la commande « sudo nano /etc/ssh/sshd_config.
  • Ici on change la ligne #PermitRootLogin without-password (ou un autre attribut) en en PermitRootLogin yes.
  • On ferme (ctrl + X) et on sauvegarde (Y) + validation.
  • Enfin on active avec sudo /etc/init.d/ssh restart.

On en profite pour changer le mot de passe « root » avec sudo passwd root (idem pour le user « pi » si on ne l’a pas fait).

On se déconnecte et on se reconnecte avec le user « root ».

A l’aide du gestionnaire de fichiers on va copier le certificat et sa clé privée quelque part (dans /etc/apache2 pour cet exemple).

Ensuite on va aller ajouter un serveur virtuel et dire à apache ou sont les certificats en ajoutant une section <VirualHost * :443> dans le fichier /etc/apache2/sites-enabled.conf (possible également depuis le gestionnaire de fichiers si on n'est pas fan de Nano).

<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www/html
ErrorLog /var/www/html/log/http.error
SSLEngine      on
SSLCertificateFile        /etc/apache2/domain.tld.pem
SSLCertificateKeyFile     /etc/apache2/domain.tld.key
</VirtualHost>


On sauvegarde et on active le SSL avec un sudo a2enmod ssl. On peut aussi faire un apachectl configtest. En l’état ça ne doit nous retourner que l’erreur AH00558, ce qui veut juste dire qu’on n’a pas renseigné le bon hostname et qu’on l’attaque en local. Pas important dans notre usage.

On relance Apache avec systemctl reload apache2.

On se connecte pour tester depuis le PC avec « https://ip-du-pi » et on by-pass l’erreur qui est normale car un certificat est toujours lié à un domaine et non une iP. A ce stade on va renseigner nos infos dans Jeedom sur l’onglet « réseaux ». Mais là ça ne sert que d’information à Jeedom, par exemple pour appliquer la bonne config au client mobile.

Sur le routeur, le firewall ou là box on crée une règle qui va accepter une connexion externe sur le port 2053 et la renvoyer sur le port 443 de l’ip du Pi. Pourquoi 2053, simplement parce que Cloudflare n’accepte pas toutes les ports et qu’on va éviter d’utiliser le 443 (mais c’est possible).

Maintenant on va tester depuis l’extérieur (un mobile en 4G par exemple) et vérifier que la connexion est bien SSL de bout en bout.

That’s all folks !

Utiliser un certificat Cloudflare en local

Peut-on utiliser les certificats Cloudflare en dehors de leur DNS ? Par exemple pour l’installer sur des équipements locaux qui ne sont accessibles qu’en HTTPS (routeurs par exemple) et ne plus avoir les erreurs de sécurité des navigateurs. En fait la réponse est oui, mais il va falloir tricher un peu.

D’abord le certificat est lié au domaine, donc il ne fait plus appeler l’équipement par son IP mais par une url https://routeur.mondomain.tld . Pour y parvenir il faudra soit avoir un DNS interne et tricher en donnant à Cloudflare un CNAME local monrouteur.domain.local mais c’est contraignant), soit tricher avec le fichier HOSTS (et là je vous conseille cette petite merveille, Hostmanager), c’est parfait car en général cette utilisation ne concernera qu’une seule machine qui sert à l’administration.

Ensuite il faudra aussi truster le certificat RSA de Cloudflare que l’on trouvera ici. Sous Windows, par exemple, il faut le convertir en PKCS#7 (on peu aussi le faire en local avec OpenSSL) avant de l’importer dans les autorités trustées (On peut utiliser MMC + certificats, ou l'outil Digicert, ou encore Keystore Explorer qui fonctionne sur toutes les plateformes..

Et le tour est joué !

Sources :