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.

Disposer d'une solution domotique c'est aussi avoir pour objectif de réaliser quelques économies en étant un peu plus green et en acceptant de porter une laine les jours de grand froid. Un des arguments d'EdF était les abonnements EJP puis Tempo ou l'électricité est moins couteuse pendant toute l’année sauf pendant les périodes de pointe dites rouge ou le tarif devient exorbitant. Ces jours-là on évite de lancer les appareils qui sont de gros consommateurs, mais on va voir ici comment baisser automatiquement la température de quelques degrés afin de minimiser la facture.

On commence par créer un petit scénario qui va s’exécuter au lancement (provoqué #start#) et toutes les nuits (programmé 0 4 * * *).

Ici on récupère l'info EJP ou Tempo en provenance du plugin EcoWatt2 et on crée des variables avec les valeurs que l'on souhaite obtenir selon que la journée soit classée rouge (tarif très fort) ou pas.

Ensuite on applique la variable dans le thermostat au mode idoine.

Il faudra juste multiplier ces actions si on utilise des consignes différentes selon les pièces avec plusieurs thermostats.

Voilà 

La qualité du WI-FI revient souvent sur la table et on me demande souvent ce qu’il faut changer pour améliorer la situation. 

Un WI-FI de qualité devient la base de toute installation. Pour les équipements mobiles (smartphone, tablettes, laptops), multimédia (Apple TV, Android TV) mais également les objets connectés ou certains utilisent le WI-FI. D’aucuns parlent de routeurs de plus en plus puissants et évolués, mais il ne faut pas perdre de vue que le routeur (ou la box) n’est généralement pas placé au meilleur endroit pour assurer une couverture optimale des lieux, simplement parce que la ligne n’arrive généralement pas au bon endroit. Bref, la box au fond du garage ne couvre pas toute la maison, et si je la remplace par un routeur avec douze antennes mais toujours au fond du garage ça ne changera pas grand-chose. C’est pourquoi je dénigre généralement cette approche. 

Voyons les options possibles

• Pour les petites surfaces et un usage modéré, généralement les dernières générations des box proposées par les fournisseurs suffisent. Les Freebox Révolution et 4K dont l’électronique est similaire assurent toutes les fonctions utiles. Si les autres box sont un peu moins geek, elles font pour autant ce qu’on attend d’elles.
• Si on est un peu geek un bon routeur WIFI bien placé peut être une alternative intéressante, dans ce cas on passe la box en mode bridge (on perd souvent la TV, mais pas toujours). On peut aussi envisager un modem / routeur. Dans tous les cas cette solution sera équivalente à la box des FAI avec plus ou moins de fonctionnalités et parfois des régressions (TV, téléphone).
• Une solution professionnelle du genre routeur / firewall et des bornes WI-FI indépendantes. C’est une configuration de type entreprise que j’ai déployée dans mon home lab. Ca nécessite quelques connaissances de base, mais c’est illimité en termes de possibilités. Après avoir longtemps travaillé avec des routeurs de la gamme RV de Cisco j’ai basculé vers de l’Unifi avec un USG à la place du routeur et des bornes WI-FI de la même marque. L’USG gère deux accès ADSL en mode répartition de charge ce qui assure également une tolérance aux pannes et j’envisage une option 4G. La Freebox et le modem du second opérateur sont en mode bridge. Si j’avais de la fibre je pourrais me passer du modem en connectant directement le port WAN sur l’ONT. Et pour revenir au WI-FI, si une seule borne AC Pro placée au centre de la maison assure une bonne couverture, je pourrais en chainer plusieurs, ce que l’on fait aisément sur de plus grandes surfaces.
• Enfin, les solutions de maillage pour le grand public avec plusieurs bornes WI-FI. C’est la solution à la mode proposée par plusieurs constructeurs dans des packs avec généralement 3 bornes. Personnellement je conseillerais Google WI-FI ou Amplifi d’Unifi qui se configurent en quelques minutes avec un simple smartphone. Mais les Netgear & co ont aussi les leurs. Dans ce cas on ne fait qu’étendre le WI-FI sans toucher au routage. On désactivera donc la fonction WI-FI de la box ou du routeur pour configurer à la place la solution maillée. Si on avait déjà un SSID personnalisé, autant reprendre la même configuration et mot de passe afin de ne pas avoir à ré authentifier tous les équipements. On peut également en profiter pour créer un réseau pour les invités qui n’auront accès qu’a Internet et non aux équipements locaux.

Le réglage des canaux

Dans un contexte saturé on évitera les canaux encombrés. Les équipements disposent généralement de réglages automatiques mais on pourra affiner avec une application sur smartphone qui permettra de visualiser la situation avec les équipements des voisins sur lesquels on ne pourra pas agir. Dans une maison isolée il peut y avoir d’autres équipements à contourner qui ont leur propre WI-FI direct (TV, imprimantes) ou des réseaux cachés comme celui de Sonos. Pour améliorer le débit on choisir une largeur de bande de 40 Mhz pour peu qu’il y ait de la place… 

Les normes

Ces normes sont définies par l’IEEE. Actuellement on parle de 802.11n et 802.11ac. Pour faire simple la plus répandue est le 802.11n ou les appareils assurent également la compatibilité b et g. Le 802.11ac travaille sur des fréquences plus hautes, sa portée est moindre mais son débit est plus important. Le minimum à ce jour est de disposer de 802.11bgn et un nouvel investissement devra inclure le 802.11ac. Le 802.11ax arrive mais il n’y a pas d’urgence car peu d’équipements terminaux sont disponibles. Enfin, le marketing s’empare de la chose et pour plus de clarté ces normes vont être renommées WI-FI 1 2 3 4 5… Pour comprendre tout ça il y a plein d’articles sur la toile, comme ici par exemple.

Enfin, n’oubliez jamais que le WI-FI ne remplacera jamais le câble Ethernet. D’ailleurs pour brancher des bornes aux bons endroits il faut du câble. Donc dans une construction ou un contexte de rénovation il ne faut pas hésiter à passer des câbles dans tous les sens et les ramener vers un point central (câblage en étoile). Ne pas perdre de vue que l’endroit idéal pour poser un point d’accès se situe généralement en hauteur, un peu comme un détecteur de fumée dont la forme est souvent reprise.

Le passage en SSL d’un serveur peut être une opération fastidieuse si on ne connait pas le système cible ou qu’il n’est pas aisé d’y mettre les doigts. Ou simplement si le système ne le supporte pas HTTPS. De plus les certificats sont souvent onéreux et ils nécessitent un renouvèlement régulier. On va voir ici comment sécuriser un site ou un équipement disposant d’une interface web en utilisant la passerelle SSL d’OVH qui est gratuite pour un usage personnel ou d’association.

La première chose à faire est de disposer d’un compte OVH. C’est gratuit aussi et si on vous demande un moyen de de paiement rien ne sera débité pour ce service. Une fois que le compte OVH est validé on se connecte sur l’interface client et on cherche Sunrise et SSL Gateway :

Ensuite on valide le bon de commande à 0 € comme s’il s’agissait d’une transaction payante et on attend le mail de confirmation (on peut consulter l’état d’avancement de la commande dans le compte OVH sur le menu Facturation). Une fois la confirmation reçue il va falloir reconfigurer l'entrée DNS correspondant au sous-domaine. Attention, tout au long de ce processus il faut être patient car la passerelle va communiquer avec le DNS et le DNS met généralement un peu de temps à se répliquer…

On va donc commencer par rediriger le sous-domaine vers la passerelle en modifiant l’enregistrement A (et AAAA si on veut de l’PV6) sur le DNS. Cela permettra de valider l’utilisation du domaine qui ici n’est pas enregistré chez OVH mais chez Gandi. C’est expliqué dans le second mail reçu avec les adresses IP.

il ne reste plus qu’à retourner sur l’interface de gestion de la passerelle et on clique sur l’entrée idoine. On attend que le DNS se réplique et on en profite pour configurer le service. L'option qui nous intéresse est bien sur la redirection HTTPS (seules certains options sont disponibles en version gratuite, mais c’est suffisant).

Une fois que toutes les vérifications sont faites par la passerelle, le service est configuré on doit se retrouver avec quelque chose qui ressemble à ça. L’IPV6 est en rouge car je n’ai pas ajouté les enregistrements AAAA. A ce stade si l’IP du serveur cible est bien configurée dans l’onglet Serveurs, le service est fonctionnel. A noter que l’onglet Taches permet de suivre les différentes étapes alors que l’onglet Graphique fournira quelques statistiques.

Attention, le serveur cible est toujours configuré en HTTP et reste accessible sans SSL via son IP. Si l’on souhaite verrouiller cet usage il suffira de le configurer afin qu’il n’accepte que les IP de sorties de la passerelle (à ce jour les réseaux 213.32.4.0/24 et 144.217.9.0/24).

Si le serveur n’est pas directement exposé mais installé derrière un firewall, un routeur ou une box, il conviendra bien sûr de faire une redirection de ports et le cas échéant d’ouvrir ces ports sur le firewall, mais là on est déjà hors sujet…

Pérennité : OVH fait partie de sponsors de Let’s Encrypt, autorité de certification sur laquelle s’appuie ce service. Au risque de me tromper, je pense que la version gratuite de ce service fait partie de leur engagement. Si ce service devait cesser ou devenir payant, cela ne se fera pas du jour au lendemain et il sera bien temps de chercher une alternative.

Depuis longtemps il existait des prises commandées, les plus connues étant les DI-O. Elles se commandent grâce à une télécommande et sont généralement intégrables dans une solution domotique via le protocole Chacon, dont la fiabilité est parfois aléatoire, à l’aide d’un RFPlayer ou d’un RFX-COM. Il y avait également les équipements Z-Wave, mais leur prix a fait que ce protocole est un peu délaissé par l’industrie. Quant à Bluetooth sa portée limitée le restreint à des usages tout aussi limités.

A l’ère des objets connectés on voit apparaître une nouvelle génération de prises et autres objets connectés. Il se dégage deux tendances qui utilisent deux protocoles bien différents qui ont tous les deux leurs avantages et inconvénients, ZigBee et WI-FI.

Zigbee

Il s’agit d’un protocole maillé ou, pour faire simple, les objets connectés au secteur servent de relais. Par exemple une prise sera un relais sur lequel pourra s’appuyer un capteur de température et ainsi mailler une plus grande surface. Pour communiquer avec l’extérieur (applications mobiles par exemple), Zigbee nécessite une passerelle qui se connecte en Ethernet sur le réseau local. Il est intéressant de noter qu’une passerelle de marque X pourra supporter des objets de marque Y.

Coté domotique pour communiquer avec Zigbee il faudra une clé de type ZiGate et le plugin idoine. Il en existe deux sous Jeedom par exemple et c’est intéressant pour les capteurs de température ou d’ouverture.

C’est ce protocole qui est utilisé par les objets connectés des grandes marques, la plus connue est Philips avec son écosystème Hue, mais également Osram, Ikea et Xiaomi. On trouve également sur Amazon ou eBay plusieurs chinoiseries à un tarif attractif mais avec les risques que cela suppose.

WI-FI

L’avantage du WI-FI c’est qu’il est présent partout. Ainsi les objets connectés WI-FI ne nécessitent pas de passerelle particulière pour peu que l’on dispose d’une couverture WI-FI stable. Amazon regorge de de prises, ampoules et autres objets connectés en WI-FI. Un écosystème se dégage autour de Tuya qui permet aux fabricants de proposer des objets OEM sous leur marque tout en utilisant le cloud de Tuya. On se retrouve donc face à des objets qui dépendent d’un cloud, et qui plus est d’un cloud chinois qui pourra en effrayer certains. Ils se pilotent garce à une application mobile fournie par le fabricant qui est généralement une version adaptée de l’application Tuya, donc autant prendre l’originale qui sera à jour et permettra de piloter tous les objets de l’écosystème.

Coté intégration domotique plusieurs options se présentent et des développements sont en cours.

• L’API Tuya qui permet un usage parallèle mais dépendante du cloud Tuya.
• IFTTT qui fonctionne sur quasiment toute les solutions avec la double dépendance IFTTT + Tuya et une certaine lenteur.
• Enfin, certains développeurs travaillent sur des solutions autonomes basées sur du reverse engineering non dépendantes.

Il existe d’autres écosystèmes plus ou moins répandus sous nos contrées et généralement chinois. Le plus connu est Sonoff que l’on trouve sur Amazon et qui propose des produits intéressants et généralement hackables pour un pilotage autonome depuis une solution domotique. Contrairement aux autres les produits Sonoff gèrent généralement l’état (on, off ou état antérieur) après une coupure électrique ce qui est un vrai plus.

Certains objets, les prises Konyks Priska (avec un vrai label CE) par exemple, permettent également de remonter des statistiques sur la consommation. Ainsi quand on s’aperçoit que l’ensemble HI-FI / Home Cinéma consomme 35 watts en veille, la décision de connecter l’ensemble à une multiprise WI-FI est rapidement prise ! Mais une autre attention se portera également à la consommation propre à ces objets WI-FI. Si certains sont raisonnables, ce n’est pas toujours le cas pour certaines chinoiseries et cette information est généralement absente des descriptions.

Plusieurs options de scénarios

En Zigbee comme en WI-FI les applications mobiles sont à même de créer des scénarios simples (exemple j’allume la tv et l’ampli et j’éteins les lampes pour voir un film) et une automatisation des objets (genre allumage répétitif tous les jours à telle heure ou compte à rebours ou l’objet va s’éteindre au bout de x minutes).

Difficile de parler d’objets connectés sans Alexa ou Google Home. La seconde option consistera donc à utiliser son enceinte intelligente préférée, qui servira enfin à quelque chose, pour gérer des petits scénarios. On peut ainsi facilement dire « je vais regarder un film », ce qui activera le home-cinéma et éteindra certaines lampes, puis à la fin du film dire « je vais me coucher » afin d’éteindre le home-cinéma, les lampes de la zone vie, baisser le chauffage et allumer la chambre… Ce n’est pas de la science-fiction, c’est amusant et très facile à mettre en place.

Enfin pour des scénarios plus évolués, mais aussi pour agir sur l’ensemble des équipements (chauffage, sécurité) on pourra toujours se tourner vers une centrale domotique avec des possibilités infinies. Mais là c’est vraiment plus complexe à mettre en œuvre et ça rentrera dans un projet plus qu’un achat impulsif.

Il y a fort à parier que la domotique grand public évoluera avec les objets connectés associés aux écosystèmes des constructeurs et des enceintes connectés. Pour être utilisable et commercialisable à grande échelle la domotique doit être WAF (en 2018 on ne dit plus WAF mais HAF, comme "human acceptance factor"), donc simple. On exclut donc une usine domotique pour piloter deux prises et quatre ampoules. Donc même si on dispose d’une solution domotique, on peut très bien imaginer que certains objets gravitent autour sans pour autant êtres interdépendants.

Maintenant ou demain ?

Pour gérer quelques ampoules et prises en Zigbee ou en WI-FI c’est maintenant si on en a besoin. L’investissement est limité et les produits des grandes marques s’adapteront généralement aux évolutions à moyen court terme.

Pour se lancer dans un projet domotique global je serais plus mesuré. Cela fait 20 ans que l’on parle de domotique sans qu’il se dégage une vraie direction industrielle.

Personnellement j’utilise depuis 10 ans une ZiBase que je vais faire évoluer sous Jeedom pour la simple raison que je ne trouve sur le marché aucun système de thermostat connecté capable de gérer 6 zones de chauffage électrique. Pourquoi ? Parce que le chauffage électrique est une exception française imposée par l’énergie nucléaire et le mirage de l’électricité à bas coût. Le résultat est que l’industrie mondiale ne s’y intéresse pas et que les rares solutions se basent sur la gestion du fil pilote dont les maisons des années 70/80 ne sont pas équipées. Sans ça pas sûr que je persiste dans Jeedom !

Ou acheter ?

Depuis son fauteuil sur Amazon bien sûr, et en surveillant les promos qui sont courantes sur ces produits. La grande distribution spécialisée (FNAC, Castorama, Leroy Merlin ou Boulanger pour ne citer qu’eux, privilégie généralement Zigbee plus simple à vendre sous blister. On trouve également ces produits chez les boutiquiers de la domotique, mais eux ajoutent des frais de ports que l’on évitera chez Amazon Prime. Pour les produits « no name » Amazon permet un retour sans condition pour les produits expédiés par leurs soins. Une bonne solution pour tester la compatibilité et la consommation.

Voilà le résultat de mes cogitations et recherches. C'est par essence incomplet, je reste donc ouvert aux sujétions et nouvelles infos et idées.

L'hiver approche et il est temps de se pencher à nouveau sur la gestion du chauffage. Depuis une dizaine d'année je gère mon chauffage électrique avec une centrale domotique ZiBase de première génération. Chaque année j'ai peur qu'elle rende l’âme, ce produit n'est plus maintenu et de plus elle est dépendante d'un serveur que les repreneurs de Zodianet ont eu la générosité de laisser en l'état, je doute toutefois qu'ils soient prêts à faire quelque chose si ces serveurs venaient à lâcher.

Je cherchais donc une solution de remplacement moderne et autonome, tout au moins autonome pour les parties vitales comme le chauffage. Après avoir longtemps exploré le marché, je me suis tourné vers Jeedom, pas tant par choix, mais plus par la possibilité d'installer cette solution sur un Raspberry et commencer à explorer. Ce n'est pas la solution la plus simple, mais c'est surement une des plus complète et ouvertes. Il n'y a pas que de bons cotés, l'un des plus désagréables étant la guerre de clans que l'on peu observer sur les communautés. Mais vu le temps que j'y ai investi, j'y suis et j'y reste pour un moment !

Je vais essayer ici de décrire mon approche, la transition depuis la ZiBase et ce que j'ai pu ou voulut récupérer.

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 d’évènements (j’ai des amis pour diner, périodes de vacances scolaires, etc…).
• Le plus compliqué sera de choisir les sondes de température (et hygrométrie) les plus adaptées.

Le chauffe-eau

• Le mode nuit du chauffe-eau était géré par la ZiBase, il le sera avec le plugin idoine sous Jeedom. Reste à résoudre la problématique de la sonde à installer sur l’appareil.

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)

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.

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

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).
• 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 micromodules 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.
• 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

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.
• 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…)

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…
• Gérer l’éclairage extérieur à l’approche de la maison via le WiFi

Les logiciels

• Jeedom
• Application mobile Jeedom (je ne suis pas fan)
• Application mobile ImpériHome (je m'en servait déja sur la ZiBase) via le plugin idoine dans Jeedom
• Application mobile TuyaSmart

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.

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.
• Xianomi et Xianomi 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.
• Xianomi 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.

Présence

• Capteurs d’alarme Visonic via le RFPlayer
• Capteurs Xianomi via la ZiGate
• BLEA + tag Nutt
• WiFI via les smartphones

Notifications

• SMS (Free API)
• Pushbullet

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.
• Possible extention en Philips Hue, Osram, Ikea and co (Zigbee) via la ZiGate et son plugin

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.

• 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.
  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 fasable via la ZiGate et son plugin. J’ai une Osram qui me fait le maillage.
• Prise et ampoules WiFi : via Tuya, plugin en devenir ? Pas d’urgence.

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.

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.

Multimédia

Vidéo

• Emby (j’y reviendrai dans un post à part) en remplacement de Kodi. Des box NVidia Shield et Xanomi 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 chaine 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.