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.

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 !

L’USG d'Ubiquiti est un routeur qui offre de nombreuses possibilités. De versions en versions il se bonifie, mais il reste encore pas mal de choses à faire à la main. Si le Dual WAN en sortie répartit bien la charge entre les deux ports ou utilise le second en secours, il reste encore des choses simples, qui se font par l’interface de gestion sur la plupart des routeurs, mais qui nécessiteront ici de se plonger dans Linux comme on le ferait sur un vieux gros Cisco… Tant qu’à se plonger dans le CLI, il serait peut-être temps d’en finir avec les techniques de Dual WAN et de s’orienter vers des implémentations libres de MPTCP (et je ne parle pas de l’OTB d’OVH qui s’avère au final une solution commerciale coûteuse, bugs compris !). De par son architecture il y a d’ailleurs plus de chances que cette technologie intéresse d’autres opérateurs que des constructeurs.

Mais revenons à l’USG. Les développeurs avancent mais il reste pas mal de choses qui ne sont pas implémentées dans leur magnifique interface. C’est le cas par exemple si l’on veut qu’un trafic spécifique (ports, ip, source, destination) passe par une liaison spécifique, comme par exemple forcer le flux TV vers le port WAN sur lequel est installée la ligne Free, alors qu’au premier abord on aurait pu penser qu’une simple route statique dans cette magnifique interface de gestion aurait suffit, et bien non :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop WANx_IP_Gateway
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Un autre "piège" se situe au niveau de port forwarding. Dans l’interface on configure cela facilement et ça crée automatiquement les règles de firewall associés. Normal, sauf qu’à l’utilisation on s’aperçoit que ça ne fonctionne que pour le WAN1. Et c’est repartit pour un peu de SSH… Attention toutefois, l’interface WAN2 peut aussi être PPPOE1 selon votre connexion…

configure
set service nat rule 4000 description "WAN2 tcp 80"
set service nat rule 4000 destination address WAN2_IP
set service nat rule 4000 destination port 80
set service nat rule 4000 inbound-interface pppoe1
set service nat rule 4000 inside-address address 192.168.210.18
set service nat rule 4000 inside-address port 80
set service nat rule 4000 protocol tcp
set service nat rule 4000 type destination
commit;exit

Pensez aussi à noter les règles ainsi crées (on peut aussi les retrouver avec un show service nat et les effacer avec un delete service nat rule RULE_NUMBER). Il va falloir rendre cette configuration pérenne au reboot grâce à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci-dessous).

Il me reste à explorer le comportement des liens VPN IPSEC en cas de passage en mode secours sur le WAN2, mais ça sera pour une autre fois, à moins que vous ayez des idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/235723207-UniFi-USG-Port-Forwarding-Configuration-and-Troubleshooting
https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json
https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing
https://help.ubnt.com/hc/en-us/articles/360002668854-UniFi-Verifying-and-Troubleshooting-IPsec-VPN-on-USG}

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…

Tous les possesseurs de Freebox 4K le savent, ce n’est pas le pied ! Avec sa télécommande indomptable, ses bugs audio à répétitions. Même avec la dernière mise à jour, cette box TV ne cesse d’être capricieuse. Mais il parait que c’est bien mieux que la box Android TV de son conçurent BT. Bref, même les box génériques chinoises font mieux, mais je ne conseillerais pas ces produits pour qui veut un bon player Android TV.

En fait à mon sens il y a deux produits qui tiennent la route sous Android TV. La Nvidia Shield est la reine ou même la v1 est toujours excellente et mise à jour régulièrement, l’outsider étant la Mi Box 3 de Xiaomi en attendant le v4 annoncée il y a un mois avec des améliorations qui semblent cosmétiques. Il y a deux alternatives viables, un ChromeCast ou un Apple TV pour ceux qui ne se sentent bien qu’avec les produits d’Apple, mais ce n’est pas le propos ici.

Pour revenir à Android TV, et si l’on ne dispose pas d’un HD HomeRun ou l’intégration est parfaite, il va se poser le problème de l’intégration des chaines TV de son opérateur en IPTV à partir du fichier .M3U fournit par les FAI. Si l’on exclut certaines applications douteuses, il existe une solution qui permet une intégration parfaite : TVIrl. TVIrl est une application Android TV qui va permettre d’utiliser la playlist fournie par le FAI ainsi qu’un lien vers une source EPG. Le soucis c’est que si les FAI fournissent bien le fichier de leurs chaines en IPTV, il n’en est rien pour l’EPG et les logos.

Internet fourmille de fournisseurs d’EPG dans différents formats, notamment XMLTV ou même des acteurs comme Télérama s’y sont mis, ou encore ça, internet est vote ami). Mais la vraie question sera d’agréger ces informations avec les chaines dans la bonne numérotation avec leur EPG et leurs logos. Si la première solution, notamment pour comprendre est Notepad, on atteindra rapidement ses limites en matière de patience. Il existe des logiciels plus ou moins bugées et des sites. Pour ma part j’ai testé avec X.Tream qui a l’inconvénient d’être payant mais l’avantage de fournir un résultat impeccable et durable. On peut tester avec un trial de 7 jours et ensuite partager les frais à plusieurs.

Le principe est simple, on insère son fichier .m3u, ici freebox.m3u et ensuite on va faire le tri dans les chaines afin d’écarter celles qui ne nous intéressent pas, les versions SD ou certaines chaines étrangères par exemple. On les trie dans l’ordre souhaité pour finir dans le section EPG afin de faire coller une source EPG à chacune des chaines retenues (il y a un doc ici qui décrit le processus. Le menu Picons servira à associer les logos de façon automatique.

Dans la section downloads de X.Tream Editor on obtiendra deux url, la première sera la playlist formatée et la seconde l’EPG. Il va falloir coller ces deux url dans TVIrl sous Android TV. Sachant que TeamViewer ne fonctionne pas très bien sous Android TV, le plus simple sera de se servir de la télécommande Android pour faire un copié / collé. Une fois l’opération terminée on va dans les options de Chaines en direct pour sélectionner les canaux souhaités. L’avantage de cette solution c’est qu’elle est pérenne. A tout moment on peut aller dans X.Tream Editor et y faire des modifications qui seront répercutées dans les Chaines en direct d’Android TV via TVIrl.

Unifi et dual WAN

Il reste un cas particulier qui n’a rien à voir avec ce que j’exposais précédemment. Si on utilise un routeur dual WAN avec deux FAI (ADSL, fibre et 4G) il va falloir indiquer au routeur par ou doit passer le ou les flux TV. En effet le flux Free ne sera accessible que via la ligne Free tout comme le flux Orange devra passer par la ligne Orange. Si sur certains routeurs le réglage est accessible dans l’interface de configuration il n’en est bizarrement rien pour l’USG d’Unifi ou il va falloir y aller en dur via SSH :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop 1.2.3.4
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Ou 1.2.3.4 est l’ip de la passerelle de la ligne Freebox que l’on peut retrouver avec un show ip route. Il va falloir rendre cette configuration pérenne au reboot grace à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci dessous).

Si vous avez d'autres idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing 
https://help.ubnt.com/hc/en-us/articles/215458888 
https://matthijs.hoekstraonline.net/2017/10/29/configuring-source-address-based-routing-on-my-unifi-usg/ 
https://www.reddit.com/r/AndroidTV/comments/6oo99t/guide_to_setting_up_live_channels_for_android_tv/ 
https://www.reddit.com/r/IPTV/comments/83keyw/tvirl_or_alternatives_android_tv_love_channels_w/}

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 !

EDIT 01/11/2019 : Il existe maintenant un plugin officiel (Edité par Jeedom SA) de simulation de présence et qui permet de récupérer un localisation et de créer la variable idoine...

Aussi curieux que ça puisse paraître et contrairement à d’autres solutions domotique (la vieille Zibase ou de simples prises WI-FI), Jeedom ne dispose pas de base de l’heure du couché et lever du soleil, pas plus qu’une variable jour/nuit. Sur le forum les modérateurs, fan de la première heure ou développeurs s’en défendent en répondant avec plus ou moins de mépris (quand ils répondent aux questions, car souvent la communication fait penser à Free lors d’une panne nationale), bref, c’est démerdez vous avec des scénarios ou des plugins. En plus il semblerait que le forum ait été purgé et l’historique perdu. Il faut dire que le forum de Jeedom tourne sous une solution logicielle à l’ancienne (bonjour l’insertion d’images…) qui ne supporte probablement pas la profusion de questions ! Moralité le néophyte qui débarque est plus que perdu et beaucoup ont oublié que le DIY consiste à s’entraider et à partager l’information, même s’il y a parfois de vrais boulets qui devrait continuer à faire confiance à Casto ou Merlin !

Je vais essayer de résumer ou trouver ces informations et quels sont les avantages et inconvénients des diverses options.

Plugin Météo

C’est un plugin officiel donc maintenu au fil des versions de Jeedom. Il nous donne l’heure de coucher et lever du soleil, mais pas dans un format directement exploitable. Une conversion s’imposera.

Plugin Héliotrope

Ce n’est pas un plugin officiel, donc attention lors des mises à jour du core. Pourquoi faire simple là où on peut se compliquer la vie. Plutôt que de demander les coordonnées GPS de la position, il s’appuie sur un second plugin (Géotrav), donc double risque de casse. Pour le reste il fournit une foison d’information, mais pas un simple binaire Jour ou Nuit. A la place on trouve un numérique qui indique si on se trouve en phase d’aube ou de crépuscule astronomique, civil ou nautique. Par contre le plugin est propre et gratuit.

Plugin Domogeek

C’est un plugin officiel, donc suivi. L’inconvénient c’est qu’il s’appuie sur des données en provenance d’un site externe. C’est utile pour certaines infos comme EJP / Tempo ou les vacances mais pas pour ce qui nous préoccupe. Pas de binaire Jour / Nuit.

Plugin Actions sur lever et coucher du soleil

Pour aller jusqu’au bout je me suis fendu de deux euros (au lieu de 4 € car l’article est en solde) alors même que plus rien ne bougeait dans le forum à propos de ce plugin depuis deux ans. Esthétiquement on peut mieux faire et pendant 24 heures je n’ai pas pu obtenir autre chose que l’heure de lever et coucher du soleil ainsi que la programmation d’événements. Ce plugin fonctionne en local et au bout de 24 heures (surement un cron de nuit) j’ai également eu les informations binaires sur l’état du soleil (couché / levé). Il faudrait que je redémarre Jeedom afin de savoir si cette information est conservée car ce qui m’intéresse est de repositionner des actionneurs en cas de coupure EDF. Mon Jeedom est sur onduleur, mais en cas de coupure prolongée il faudra recalculer cette variable.

Simple virtuel

Cette dernière solution présente l’avantage de calculer toute les nuits de façon très simple l’heure du coucher et lever du soleil et de la rendre disponible dans un format directement exploitable dans un scénario. C’est simple et ça évite de se charger en plugins… Et pour le binaire Jour / Nuit un simple #[Informations][Jour-Nuit][Lever-Soleil]#>#[Informations][Jour-Nuit][Coucher-Soleil]# permettra d’obtenir un True ou False et de s’en servir directement ou par le biais d’une variable stockée.

Voilà comment ce qui devait être simple m’a tout de même fait perdre un peu de temps tout en me permettant de comprendre pas mal de choses. La perte de temps est aussi dans ce cas liée au fait qu’il faut attendre l’heure fatidique du coucher ou lever du soleil pour obtenir le résultat…

Sources

_{https://www.jeedom.com/forum/viewtopic.php?t=19537
https://lofurol.fr/joomla/electronique/domotique/169-jeedom-scenario-au-lever-et-au-coucher-du-soleil-volets}

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/}

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 webmaster@localhost
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 :

Vue depuis le RFPlayer les équipements sont vus comme des génériques on/off. S’il est possible de les commander via un scénario ou un plugin, rien ne permet d’afficher leur état à l’écran et encore moins de faire remonter l’information dans Impérihome avec un seul Bouton qui les commande et indiquer leur état, et j’ai une nette préférence pour Impérihome par rapport à l’application mobile officielle de Jeedom.

Je prends l’exemple d'une prise Chacon Di-O, mais ça doit être transposable à d’autres équipements génériques. 

En premier lieu on va créer un afficheur virtuel, un peu comme on ferait un interrupteur virtuel. On commence par ajouter deux Commandes Virtuelles que l’on renseigne avec deux Etats « on avec 1 » et « off avec 0 ». On sauvegarde et s’affiche une ligne supplémentaire nommée Etat. On décoche l'affichage on et off inutile. A ce stade le Virtuel est créé.

Ensuite on il ne reste plus qu’à aller sur l’équipement Chacon dans les paramètres avancées de l’action « Allumer » + tab « Configuration » et d’ajouter une action après exécution de la commande vers le virtuel précédemment créé pour le positionner à « on ».

On répète ça pour l’action « Eteindre » et le tour est joué, on obtient un retour d’état sous la forme d’un voyant virtuel.

Pour faire remonter l’information et la commande dans Impérihome c’est un peu plus tordu. Si l’état 0 ou 1 est bien visible dans les équipements standards, il n’est pas possible ici de commander en même temps notre équipement. On va donc passer par le mode avancé. On ajoute un équipement en choisissant la commande « Rafraichir » de notre retour d’état virtuel, ensuite dans les paramètres on ajoute dans « statut » la commande « Etat » de notre retour d’état virtuel ainsi que les commandes « Allumer » et « Eteindre » dans les « actions ».

On sauvegarde et on rafraîchit sur le smartphone et on obtient un retour d’état dynamique à côté de la commande.

EDIT 1 : J'ai depuis trouvé une façon plus simple sans passer par la configuration avancée d'Impérihome et qui du coup est compatible avec le composant Jeedom d'Impérihome. Je termine mes tests et je mets ça à jour. Je me demande également s'il n'y a pas moyen de modifier l’équipement actionneur Chacon créé par le RFPlayer afin de lui intégrer ce retour d'état (toujours virtuel en ce sens qu'il ne vient pas du Chacon) sans passer par un virtuel de plus., mais là je sèche un peu après de nombreuses tentatives...

EDIT 2 : En fait il faudrait refaire le tuto car il y a plus simple. En deux mots, dans cette version l’actionneur principal était l’équipement Chacon et je le modifiais les options de allumer et éteindre pour lui dire de transmettre  les infos au virtuel. En fait il ne faut pas toucher à l’équipement Chacon, le mettre en invisible et l’actionner depuis le virtuel. Et quand dans un scénario ou une commande on veut faire ON ou OFF il faut agir toujours sur le virtuel. Pour que le virtuel remonte bien dans Imperihome il faut simplement configurer correctement les types génériques. Inutile donc de se servir du mode avancé d’Impérihome.