Home Assistant vs Jeedom

Comme bien des utilisateurs, Jeedom, que j’utilise depuis deux ans, m’exaspère bien souvent. De fait s’est installé dans les communautés d’utilisateurs un étrange mouvement de Jeedom Bashing. Jeedom exaspère car s’il s’agit bien d’un programme Open Source, dans la pratique bien des options sont payantes, et même si le prix de ces options est parfois dérisoire (2 à 8 € pour un plugin), le simple fait de payer conduit à ce que les utilisateurs se sentent autorisés à râler envers les développeurs qui font parfois (souvent) la démonstration de leur arrogance. Les gens râlent face à des plugins qui ne sont pas toujours bien maintenus, peu documentés, parfois abandonnés, et face à des choix discutables et arbitraires. Bref, Jeedom respire parfois l’amateurisme et surtout l’ambiance qui règne sur les forums fait que bien souvent les utilisateurs n’osent même plus poser une question légitime de peur de se prendre un mauvais retour !

Alors quand on est pas content, on a envie d’aller voir ailleurs si l’herbe est plus verte, c’est d’ailleurs le conseil parfois donné sur les forums par des personnes plus ou moins représentantes de Jeedom (ça on ne sait jamais vraiment). Aller ailleurs quand on a énormément investit sur une plateforme n’est pas une décision anodine car il s’agit là d’une activité chronophage et l’on n'a pas l’assurance de pouvoir faire mieux, voire simplement aussi bien, avec une solution concurrente.

S’il existe d’innombrables solutions concurrentes tant en mode commercial que DIY, et que je ne vais pas comparer ici, celle qui a vraiment la cote ces temps-ci c’est Home Assistant. HASS est une solution full open source qui dispose d’une énorme communauté internationale. Et là on sort déjà du cadre car Jeedom n’a jamais réussi à dépasser l’hexagone, le revers de la médaille est qu’il faudra d’une part un minimum de maîtrise de l’anglais, et d’autre par que certaines spécificité du marché national seront peu prise en charge.

Un soir dans un fil Telegram on a été plusieurs à se dire « chiche ? » et c’est ainsi que j’ai passé 24 heures avec Home Assistant, que je vais essayer de vous narrer (les vidéos sont prises au hasard en deux clics sur Google, mais la toile regorge d'informations).

Homme Assistant s’installe à peu près n’importe où (base Linux) et ne pose aucun problème particuliers, si en mode production un RPI4 est conseillé, je l’ai personnellement installé en quelques minutes sur une VM ESXi pour tester et grâce à un VMDK pré-buildée. La configuration est tout aussi simple, on découvre une interface hyper réactive et intuitive, mais également que HASS découvre tout seul une grande partie de vos équipements installés sur le site ! Avantage à HASS.

Une solution domotique doit communiquer avec l’extérieur, et pour cela il faut du SSL. HASS propose deux solutions, basées sur Lets’Encrypt, la première avec DuckDns prends 5 minutes et suffit amplement, la seconde adaptée à un domaine personnalisée est un peu plus longue mais pas vraiment plus. Et vu que l’adresse liée à ce domaine ne servira qu’à vous ou votre application mobile, le fait qu’il soit personnalisé n’a que peu d’importance. Avantage à HASS.

On passe ensuite à l’application mobile, on est ici face à une application très fluide qui s’appuie sur l’interface native de HASS. On y retrouve tout avec en prime la localisation qui est intégrée. Que dire, rien, si le SSL est bien configuré, on lance l’application qui reconnait toute seule HASS et ça fonctionne. On est à des années lumières du semblant d’application mobile payante de Jeedom. Avantage à HASS.

Homme Assistant dispose de plusieurs « boutiques » d’addons, tant officielles que communautaires, parler de boutiques est abusif car ici tout est gratuit et bien documenté. On est très loin de Jeedom qui se prend pour l’Apple Store. En option je recommande l’installation de HACS, la boutique communautaire optionnelle de référence basée sur Github. Avantage à HASS.

Si à l’utilisation on fait souvent beaucoup de copié / collé de code sous HASS, la majorité des automatisations et la gestion des scènes se font via l’interface utilisateur. Personnellement ce qui m’a conduit à utiliser d’abord une ZiBase, puis Jeedom, c’est la gestion de mes thermostats virtuels pour gérer mon chauffage électrique. Le chauffage électrique avec plusieurs convecteurs est une spécificité bien de chez nous. Et sur ce point, si HASS dispose bien d’un équivalent au niveau thermostat, qui s’appuie sur un capteur de température et un actionneur, son niveau est en deçà et si on veut remplacer les plugins MODE et AGENDA faciles à mettre en œuvre sous Jeedom, il faudra plonger dans le cambouis car rien n’existe vraiment, à part coder. Avantage à Jeedom. (pour l’instant j’espère).

EDIT : Après quelques semaines je me rends compte que si HA mériterait un agenda, c'est d'ailleurs en cours de développement, ce n’est pas bien compliqué de mettre les doigts dans le cambouis, et au moins on peut faire du sur mesure, et que finalement l'agenda étaient plus compliqués ! Donc finalement, avantage à Home Assistant, même s'il faut bien reconnaître qu'au début c’est moins évident à appréhender ! (voir les articles suivants : 1 | 2 )

Enfin concernant la prise en charge des Assistants vocaux Google Home ou Alexa, si cette option est bien intégrée, sous HASS la prise en charge de l’infrastructure cloud nécessaire a été confiée à un partenaire, c’est cher ($ 5 par mois contre 12 € / an pour Jeedom) mais le service est professionnel. Rien à ajouter sur cette facturation, qui est tout à fait compréhensible de part et d’autre.

Conclusion, je suis conquis. Bien sur ce n’est pas exhaustif et ces quelques lignes sont discutables, mais en 24 heures j’ai fait le tour et pas trop mal maîtrisé Homme Assistant, ce qui m’avait pris des semaines lorsque j’ai basculé de ZiBase vers Jeedom. C’est clair, aéré et fonctionnel. Ce qui n’est pas là n’est pas là, mais ce qui est proposé fonctionne, donc pas de perte de temps inutiles. J’espère donc ne jamais avoir à basculer vers Jeedom v4 et il n’est pas exclu que je laisse pour l’instant le chauffage sur Jeedom tout en migrant le reste sur Home Assistant.

Sources

 

Exception d'un chemin http dans HA Proxy sous pfSense

J'utilise HAProxy sous pfSense pour publier divers sites. Outre l'économie d'adresses IP, j'augmente la sécurité, je peux faire de la répartition de charge et je profite des certificats Let's Encrypt via le plugin Acme.

Tout fonctionne très bien, sauf sur un site ou pour lequel une URL en http a été codée en dur dans un logiciel distribué aux quatre coins du monde, logiciel que les utilisateurs rechignent à mettre à jour. Ce process http fait du GET et du POST et après avoir testé une redirection http vers https de type 308 au lieu de 301 sans grand succès, je me suis dit que la seule solution consisterait à contourner le problème... en faisant une exception pour l'url du formulaire.

Explications (en partant du principe que le lecteur connait un peu le couple pfSense / HAProxy)

  1. Je crée un SharedFrontEnd HTTPS sur une IP publique de type http / https (OffLoading) en SSL OffLoading sur le port 443
  2. Je crée un premier FrontEnd qui s'appuie sur le SharedFrontEnd HTTPS avec le certificat qui va bien, cela qui va faire transiter le flux HTTPS vers mon BackEnd. On vérifie le bon fonctionnement depuis un navigateur avec https://www.domain.tld. OK.
  3. Je crée un SharedFrontEnd HTTP sur la même IP publique de type http / https (OffLoading) sans SSL OffLoading sur le port 80
  4. Je crée un second FrontEnd qui s'appuie sur le SharedFrontEnd HTTP qui lui va faire transiter en HTTP mon exception via deux ACL (hostname + path) vers mon Backend avec ces deux conditions (au sens HAProxy) et redirigera tout le reste vers le premier FrontEnd en HTTPS grâce à une règle qui exclut mon exception.

 

Voici le règle de redirection que l'on peut également placer en custom rule.

http-request redirect code 301 location https://%[hdr(host)]%[path] unless REG_PATH

J'avoue que j'en ai un peu bavé (avec l'aide de Victor), mais ça prouve une fois de plus qu'il y a peu de choses en la matière que l'on ne peut faire avec le couple pfSense / HAProxy. D'ailleurs, je ne vais pas l'expliquer ici car je n'ai fait que suivre un bon tuto, mais il est parfaitement possible de publier ainsi un serveur Exchange avec répartition de charge et éviter de coûteux répartiteurs de charge.

Sources :

 

SSL mi amor… & pfSense

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

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

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

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

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

Acme

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

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

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

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

HA Proxy

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

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

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

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

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

Test

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

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

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

Info

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

Sources

https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html

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