Home Assistant & Visonic

Jadis, quand j'ai commencé à m'intéresser à la domotique, avec une Zibase, j'avais intégré les capteurs de mon système d'alarme Visonic Powermaster Pro. Ensuite sous Jeedom je les ai perdus, j'ai bien tenté avec un RFPLayer, qui dans l'absolu intégrait la techno ZiBase, de les retrouver, mais sans succès tant le plugin dédié et payant étant en dessous de tout. Un échec de plus pour Jeedom, peu importe que ce soit de leur faite ou celle de ZiBlue qui ne fournissait que peu d'informations, le résultat était négatif.

Sous Home Assistant j'ai bien essayé de me servir de la ZiBase pour récupérer ces informations, mais je n'ai pas trop insisté et j'ai fini par tout doubler avec des capteurs Xiaomi/Aqara.

Jusqu'à ce que je découvre la semaine dernière qu'il existait une intégration Visonic ! Mais pour ça il faut que ça communique. La centrale a des options que je n'ai pas et j'étais moyennement chaud pour commander une option RS232 à 80 € sur un site exotique. En lisant un peu j'ai fini par découvrir que cette option ne faisait qu'exposer physiquement le signal qui existe en TTL sur des broches accessibles. Alors j'ai fait des tests avec un câble RS232, USB/RS232 et j'ai même acheté un adaptateur Ethernet / RS232 (USR-TCP232-302) mais ça succès alors que certains disent y être parvenus, et même une pince pour sertir des connecteurs Dupont (l'enfer !), bref je me suis cassé le crane tout un week-end sans succès.

Reste une solution que je n'ai jamais explorée, utiliser un ESP_01 avec le firmware ESP-Link qui convertir les signaux TTL série afin de pouvoir les utiliser en Ethernet depuis l'intégration sous Home Assistant.

Communication

Alors d'abord il faut se procurer le module ESP NodeMCU. Ca doit pouvoir fonctionner avec d'autres ESP et d'autres firmwares mais je me suis contenté de suivre ce que j'ai trouvé. Ca vaut 1 €, c'est minuscule et ca peut tenir dans la centrale qui ainsi devient "WI-FI" !

Pour flasher le firmware ESP-Link il faut un adaptateur USB que je n'avais pas commandé pensant pouvoir le faire avec mon adaptateur USB éclaté. Certains ESP ont un bouton pour les passer en mode flashage, sur celui ci rien de tel, pas plus que sur l'adaptateur... C'est un peu le mystère laissé par les barbus, ne pas tout documenter sans quoi ce serait trop facile, ce genre de montage ça se mérite ! Bref, il faut shunter IO0 et GND avant d'insérer l'objet dans le port USB, ça permet de passer en mode programmation (je l'ai fait juste avec un câble Dupont...).

Maintenant il va falloir trouver un outil de flashage. Mais les barbus bossent sous Linux, et même s'il est possible de faire du Bash ou du Python sous Windows, ma machine ne s'est pas avérée très coopérative...

curl -L https://github.com/jeelabs/esp-link/releases/download/v2.2.3/esp-link-v2.2.3.tgz | \
    tar xzf -
cd esp-link-v2.2.3
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 4m -ff 40m \
    0x00000 boot_v1.5.bin \
    0x1000 user1.bin \
    0x7C000 esp_init_data_default.bin \
    0x7E000 blank.bin

Si la plupart des outils de flashage sous Windows fonctionnent, et même Tasmotizer, (Mathieu si tu me lis...), on va avoir besoin ici de flasher plusieurs fichiers .bin à des adresses particulières et le seul utilitaire qui a fonctionné est NodeMCU Firmware Programmer, qui selon les ESP utilisés permet de les fichiers flasher au bon endroit...

Une fois cette opération réussie (YES ! Ca m'a pris l'après midi...), on peu détacher l'ESP_01 de son support USB et aller le brancher dans la centrale. Il sera alimenté en 3.5 v par elle et servira d'interface TCP/Serie. Visonic a prévu des connecteurs dans la centrale afin d'y connecter des cartes optionnelles et couteuses, sauf que les signaux sont disponibles sur les connecteurs et que les cartes ne servent qu'à supporter des connecteurs... Des petits malins on fait un joli travail de recherche (voir les sources). Le connecteur qui nous intéresse est celui de gauche et en branchant un petit câble Dupont à 4 fils sur les 4 du haut à droite on sortira aisément GND TX RX et les 3.75 v nécessaires à l'alimentation de notre ESP.

Il ne reste plus qu'à connecter ça à notre ESP aux bons endroits, en inversant RX/TX et en faisant attention au connecteur d'alimentation car il n'y a pas de fusible...

Ensuite on se connecte en WI-FI sur son SSID (ESPxxx) et on renseigne le réseau WI-FI que l'on consacre aux IoT dans l'onglet WI-FI Station, il redémarre et on peu le pinguer... On pense à le mettre en réservation DHCP... Le seul réglage qui nous intéresse est la vitesse (9600 ou 38400 selon les modèles de centrales), et même si ce firmware permet de faire du MQTT et autres joyeusetées on désactive tout, il ne servira qu'à ça !

Intégration à Home Assistant

Cette intégration j'ai du la lancer 50 fois, mais quand on a la bonne communication ça fonctionne du premier coup. Elle permet beaucoup de choses, mais le mode standard qui me permet de voir et utiliser mes capteurs est suffisant. Je m'en contenterais car dans mes bricolages j'ai perdu le code installateur de la centrale ce qui va me limiter à l'avenir ! (code impossible à reseter). EDIT : Je viens d'apprendre qu'on peut justement le récupérer, grâce à une fonction non documentée de cette intégration...

On installe donc l'intégration Visonic, encore un excellent travail d'un passionné, et on renseigne l'IP et le port (23) de notre ESP. Et c'est tout, comme par magie les capteurs remontent ainsi que le panneau de commande. Il sera ainsi possible d'armer et désarmer la centrale depuis Home Assistant (Géoloc, présence pour l'armement et tag NFC pour le désarmement dans mon cas) et de savoir quel capteur à déclenché l'alarme dans une notification (Slack, TG ou SMS), mais aussi de conserver un log (CSV et/ou XML).

Ce qui m'embête c'est que je me retrouve avec d'un coté mes capteurs Xiaomi / Aqara qui me servaient à l'alarme HA, à couper le chauffage quand on ouvre les fenêtre ou allumer une lampe en cas de passage, et mes capteurs Visonic qui peuvent faire la même chose... Bref, j'aurais su avant je ne me serait pas lâché sur Ali Express...

Sources

J'ai écrit ça rapidement, mais voici mes sources qui contiennent pas mal d'informations pour qui voudra se lancer dans l'expérience

 

Calibre Web & Docker...

J'utilise Calibre pour gérer une bibliothèque libre d'ouvrages numériques. Pour la partager avec mes enfants j'avais jadis monté sur un Synology Calibre Web sous Docker, sans trop savoir de quoi il en retournait, mais bon ça fonctionnait depuis deux ans. J'ai donc décidé d'aller plus loin et de monter ça sur une VM Ubuntu

Installer la VM et Docker n'est pas un soucis et il existe plein de tutos. Installer le container Calibre Web n'est pas non plus un problème, par contre ce que j'ai mis des jours à essayer de faire fonctionner c'est relier ma bibliothèque restée sur le Nas. Naturellement j'ai essayé de monter un volume NFS, voire CIFS, si je parvenais bien à lire et écrire dans ce volume depuis le container Calibre-Web, je n'ai jamais réussit à ce que Calibre Web puisse ainsi fonctionner. Il se passe quelque chose que le développeur de cette image ne sait expliquer, et encore moins moi. Mais en informatique, quand on ne sait pas faire quelque chose, on essaie de trouver un contournement, et je me suis donc dit que si le volume NFS monté dans Docker n'était pas exploitable, ça pourrait peut être fonctionner avec un volume NFS monté directement sous Linux. Et banco !

Explications...

Alors on commence par mettre à jour et installer NFS

> sudo apt update
> sudo apt install nfs-common

Puis on crée les deux répertoires locaux que l'on va utiliser pour nos montages :

> sudo apt update
> sudo apt install nfs-common

Et on mappe nos ressources distantes :

> sudo mount 192.168.20.22:/volume2/Public/Books/calibre /nfs/books
> sudo mount 192.168.20.22:/volume2/Public/Books/calibre-web /nfs/books-config

On crée nos répertoires de travail qui seront utilisés par Calibre Web, ça va nous permettre de vérifier que ça fonctionne :

> sudo mkdir -p /nfs/books.config/config
> sudo mkdir -p /nfs/books.config/app
> sudo mkdir -p /nfs/books.config/kindlegen

Et ensuite on édite le fichier /etc/fstab afin de rendre la chose persistante :

. . .
192.168.20.22:/volume2/Public/Books/calibre /nfs/books   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
192.168.20.22:/volume2/Public/Books/calibre-web /nfs/books-config    nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Bon, je n'ai bien sur rien inventé et les détails sont par exemple ici.

Maintenant je vais pouvoir créer mon Docker calibre-web après avoir adapté la config à ma sauce, c-a-d que tous mes répertoires de travail seront sur mon Nas :

> docker create --name=calibre-web --restart=always \
-v /nfs/books:/books \
-v /nfs/books-config/config:/calibre-web/config \
-v /nfs/books-config/app:/calibre-web/app \
-v /nfs/books-config/kindlegen:/calibre-web/kindlegen \
-e USE_CONFIG_DIR=true \
-e SET_CONTAINER_TIMEZONE=true \
-e CONTAINER_TIMEZONE=Europe/Paris \
-e PGID=65539 -e PUID=1029 \
-p 8083:8083 \
technosoft2000/calibre-web

J'aurais pu faire ça avec Portainer par exemple, mais c'est finalement bien plus simple de le faire en CLI, surtout avec la masse d'essai que j'ai du faire... D'autant plus que ça ne fonctionne pas, Calibre Web ne fonctionne pas avec le répertoire de config distant. Je me suis donc résolu à le laisser en local, mais pas dans le container mais un répertoire local au cas ou je casserait le container...

> docker create --name=calibre-web --restart=always \
-v /nfs/books:/books \
-v /var/lib/docker/data/calibre-web:/calibre-web/config \
-e USE_CONFIG_DIR=true \
-e SET_CONTAINER_TIMEZONE=true \
-e CONTAINER_TIMEZONE=Europe/Paris \
-e PGID=65539 -e PUID=1029 \
-p 8083:8083 \
technosoft2000/calibre-web

Voilà ! Et comme je ne pense pas pouvoir récupérer mon ancienne configuration, il ne me reste plus qu'à reconfigurer et à créer mes utilisateurs.

Sources

 

 

Unifi Dream Machine Pro

Chez les afficionados de la marque on a généralement tous commencé par un AP WI-FI. Et puis comme ça fonctionnait bien et que c'était beau on s'est laissé aller pour un USG, et là c'était beau, mais pas exempt de bugs et surtout limité en CPU pour exploiter une fibre ou DPI/IPS. Il y a bien eu l'USG Pro, pas vraiment beaucoup plus puissant. Sur tous ces modèles le VPN n'a jamais été le point fort et quant à faire de la publication il n'y a rien d'autre qu'une possible translation de ports entrants comme sur un vulgaire routeur grand public, si cela pouvais se comprendre sur les modèles précédents, on aurait aimé un reverse proxy sur la machine censée nous faire rêver !


(source Unifi)

Mais il n'en est rien, il faut considérer l'UDM Pro, et c'est son positionnement marketing, comme un routeur d'accès avec des services (Contrôleur Unifi, Unifi Protect, contrôle d'accès, téléphonie IP, etc..). Si l'on souhaite publier des services on regardera plutôt du coté de pfsense ou autres Appliance qui font ça très bien. Et si on veut faire du VPN,  ce qui est par contre dans la cible du produit, ce sera IPSEC ou OpenVPN. Zerotier ayant été porté sur la gamme Edge, il y a des chances que quelqu'un fasse le portage sur l'UDM Pro, voire qu'Unifi le fasse, à moins qu'ils ne se laissent tenter par WireGuard...

A 319 € (HT) l'UDM est un produit intéressant qui combine donc plusieurs fonctions : 

  • un USG performant avec fonctionnalités de firewall avancées (IPS/IDS, DPI)
  • un switch 8-port Gigabit et un port 10G SFP+, un port WAN Gigabit et un second port WAN en 10G SFP+ (de quoi y raccorder les nouveaux produits en 2.5 GB et 10 GB actuellement en Early accès et profiter des offre fibre en 2.5 GB ou 10 GB proposées par certains FAI).
  • un contrôleur UniFi (= CloudKey ou CloudKey Gen2+).
  • un NVR UniFi Video avec emplacement disque dur 3.5″ ou 2.5".
  • d'autres contrôleurs à venir (contrôle d'accès, téléphonie IP, et certainement quelques autres projets dans les cartons...).
  • et enfin comme tous les Gen2 de la marque on est en présence d'un petit écran de contrôle en face avant. Petit gadget pour doigts de fée !

Si le contrôleur Unifi intégré pourrait très bien trouver sa place ailleurs (VM, Cloud, ...), l'enregistreur vidéo (Unifi Protect), qui est identique, mais plus puissant que celui que l'on trouve sur le CloudKey 2+, constitue un vrai plus si on veut gérer un grand nombre de caméras et stocker jusque à 14 TB de vidéos de surveillance. A noter qu'il existe chez Unifi un autre NVR plus puissant avec le support de 4 disques.

Le NVR

Ca c'était le bla bla marketing annoncé. Dans la pratique Unifi Protect sur l'UDM Pro me semble bien bogué pour un produit sorti il y plus de six mois. Ca commence avec le disque dur, quelque soit le modèle installé parfois il le voit, parfois pas, et quand il le voit il ne l'exploite pas (impossibilité d'enregistrer). Certains conseillent de le retirer et de le formater en ext4, pas mieux, de juste supprimer les partitions, là il est visible mais non exploitable. Pas très normal qu'on ne puisse pas lancer l'initialisation/formatage depuis l'interface. Et je passe sur les paramètres des caméras qui sont pris en compte depuis l'application mobile mais impossible depuis le portail web qui lui répond que la caméra n'est pas reconnue, alors qu'elle l'est bien sur... A cette heure je regrette ma CloudKey 2+ !

Le routeur

Le routeur d'accès qui lui remplacera l'USG reste à apprécier à l'usage, Ca remplace mais ça reste un USG dont je ne vais pas reprendre le détail ici, un une partie qui mériterais de la part d'Unifi quelques évolutions, avec notamment l'intégration à l'interface de tout ce qui n'apparait pas mais reste faisable en CLI.

2 ports WAN, mais un seul en 10 G !

A noter que le WAN1 qui est en 1 GB est toujours le port principal WAN et que si on souhaite faire du failover on le fera avec le WAN 2 qui lui est en 10 GB (SFP+) ou en 1 GB en utilisant un adaptateur UF-RJ45-1G. C'est d'autant plus bête qu'en utilisation normale on peut imagine une grosse fibre sur le WAN principal et un xDSL en secours. Ca reste du soft, et on peut imaginer une évolution du firmware, et pourquoi ne pas banaliser tous les ports en WAN/LAN comme le fait Cisco depuis plus de 10 ans sur des produits SMB de la gamme RV.

Dans tous les cas, sur le papier, on reste sur de l'agrégation ou du failover utilisable en sortie, et pour l'instant c'est failover only (La seule solution intégrale d'agrégation via un tunnel restant l'OTB d'OVH ou sa version open source openMPTCP).

Quand au WI-FI contrairement à l'UDM, l'UDM Pro qui se place dans un rack n'intègre logiquement pas d'AP. Alors on est tout de même en droit de se demander pourquoi sur un produit qui est censé gérer des AP et des caméras en POE, on ne trouve aucun ports POE ? Je pense simplement qu'à la conception la question a bien du se poser, le marketing l'a emporté en argumentant que cela ferait vendre des commutateurs POE, produits sur lesquels la marge est certainement bien plus importante. C'est dommage car avec quelques ports POE l'UDM Pro aurait été presque parfait ! Business is business !

Un firmware intégré...

Contrairement aux habitudes prises avec Unifi, ici le firmware intègre tout, le firmware de la machine de base proprement dite (USG), le contrôleur Unfi Network, le contrôleur Unifi Protect et les autres applications... Si la bonne idée est de simplifier, on va voir que dans la pratique ce n'est pas si simple tant les versions sont évolutives chez eux...

Coïncidence, mon UDM Pro est arrivé le lendemain du jour ou j'ai mis à jour (par erreur) ma CloudKey 2+ avec le contrôleur avec 6.0.20. Mal m'en a pris car cette version, tout comme la suivante en 6.0.22 est tellement buggées qu'on peut aisément penser qu'elle a été lâchée en release par erreur (un stagiaire ?). Problème, la 6.0.x n'existe pas sur l'UDM Pro qui est en firmware 1.8 qui intègre le contrôleur en 5.x. Dès lors impossible de migrer une installation en 6.x vers du 5.x ! (il ne s'agit pas vraiment d'un process de migration mais une simple opération de backup/restaure, il faut donc que la source ait un niveau de release inférieur ou égal au contrôleur de destination).

Alors j'ai cherché, j'ai fini par installer la 1.8.1 RC3 qui n'apporte hélas pas de contrôleur en 6.x ... et pour finalement découvrir qu'il était possible de mettre à jour le contrôleur d'UDM Pro en SSH. Et pourquoi pas avec un bouton upload ? On a parfois l'impression qu'il y a chez Unifi pas mal d'ingés de l'ancien monde, ceux pour qui le CLI est et reste la seule option possible... Ce qui n'est pas très logique pour un constructeur qui se démarque avant tout par ses magnifiques interfaces !

ssh udm ...
unifi-os shell
cd /tmp
curl -o "unifi_sysvinit_all.deb" https://dl.ui.com/unifi/x.xx.xx_version/unifi_sysvinit_all.deb
dpkg -i unifi_sysvinit_all.deb 
rm unifi_sysvinit_all.deb 

Et comme je n'ai pas reçu ce produit du service de presse pour le tester, mais que je l'ai acheté pour l'utiliser, me voilà donc en principe dans la possibilité de migrer. Je fait un export du contrôleur et un export du NVR depuis la CK 2+ (je ne me pose pas la question d'exporter les vidéos de la CK 2+, mais il parait que c'est possible...). Ensuite je débranche l'USG et la CK 2+, c'est important. A partir de la il me suffira en principe d'importer le backup du contrôleur sur l'UDM Pro et ensuite le backup du NVR.

Dans la pratique c'est un peu plus compliqué. Si l'importation se passe bien le redémarrage annoncé ne s'opère pas. Je le fais manuellement au bout d'une heure. Mais au retour je ne peux me connecter localement, ni sur l'ancienne l'IP (192.168.1.1), ni sur l'IP de configuration importée (192.168.210.1). Par contre je peux le faire à distance (à noter que c'est un nouveau portail d'administration). Et là en fouillant je constate deux choses :

  • Le port 11 (SFP) qui assure la liaison avec mon USW-48 a perdu sa configuration en 1 GB FDX (et non il n'est pas auto sense...)
  • Que si l'IP LAN a bien été importée dans la configuration, c'est toujours l'ancienne IP qui répond, et de fait le système ne voit pas les autres équipements importés (SW, AP).

Réactiver le port SFP en FDX est facile, pour que l'IP LAN soit bien prise en compte j'ai finalement rentré l'ancienne à la place de la nouvelle, appliqué la configuration, et ensuite remis la nouvelle, et oh merveille ça fonctionne. Oh merveille mon cul, car c'est vraiment n'importe quoi.

A ce stade tout semble fonctionner, bien que dans cette version non finalisée (6.0.22) certaines choses sont à faire dans la nouvelle admin (VPN) tandis que pour d'autres actions il faudra revenir à l'ancienne interface. beta bug beta bug ! Enfin, tout sauf que si le WAN2 sait bien fonctionner en failover, contrairement à l'USG il est ici impossible de la basculer en agrégation (pas de réponse à ce sujet pour l'instant).

Il y a également depuis le 6.0.x des équipements WI-FI qui décrochent. C'est par exemple systématique sur les ampoules Xiaomi/Yeelight, j'ai tout retourner sans trouver de contournement. Et pour mémoire, quand on migre d'une 5.x vers une 6.0.20 il y a un Vlan only network - 0 qui se crée, je pense que c'est lié à la nouvelle façon de gérer le WI-FI Guest, en attendant il empêche toute connexion WIFI normale et il faut donc l'effacer ou le le changer d'ID (en 100 par exemple). Sur le 6.0 le WI-FI est géré différemment et on peu créer plus de 4 SSID, ce qui est par exemple plus souple pour les différencier en 2 ou 5 Ghz. et en isoler certains (IoT par exemple).

Domotique

Pour information les intégrations Unifi et Unifi Protect que l'on utilise dans Home Assistant fonctionnent et reconnaissent bien l'UDM. Petit hic il faut les réinstaller car je n'ai pas trouvé (pas trop cherché non plus) la façon de changer l'IP du contrôleur et du NVR (dans HA). Le résultat est que certaine entités peuvent changer de nom et qu'il faudra s'adapter.

Conclusion

Par la force des choses je me retrouve :

  • en prod avec du matériel qui tourne intégralement sur des versions beta. Une pratique à éviter.
  • avec un enregistreur qui n'enregistre plus rien...
  • des équipements WI-FI qui décrochent.
  • avec une foule de bugs dont une agrégation de ports inopérante.

Vous l'aurez compris, la machine à rêver ne m'a pas fait rêver mais perdre beaucoup de temps et me retrouver dans une situation très instable !

  • EDIT 22/09/2020 14:00 : la v6.0.23 du contrôleur est sortie et ça règle bien plus de choses qu'annoncé. Dont mes déconnections avec les ampoules Xiaomi/Yeelight. En fait non, mais ça tient quelques heures au lieu de 5 minutes...
  • EDIT 22/09/2020 17:30 : S'agissant de l'enregistrement sur détection de présence (Protect) et de l'enregistrement il semblerait qu'un paramètre n'ait pas été pris en compte lors de la migration ou qu'il soit nouveau (sur chaque caméra, Recording/Motion Events/Motion Algorithm), il faut faire un choix et aucun des deux n'était sélectionné. Dès lors qu'un disque dur est bien reconnu on a donc bien les enregistrements.
  • EDIT 23/09/2020 04:37 : Il est possible d'intervertir WAN1/WAN2 afin que WAN1 (le principal) profite de l'interface 10 GB sur WAN1 (et sans passer par SSH). Par contre pour l'instant seul le support du mode Failover, pour le Load Balancing (supporté sur l'USG) il faudra repasser plus tard.
  • EDIT 23/09/2020 18:22 : En parlant de plus tard, le SNMP, un peu la base sur un routeur, est caché (New Seetings + search snmp), mais pour autant il ne fonctionne pas. Il parait que apt-get ... etc... On se marre !
  • EDIT 23/09/2020 19:30 : Passage de la 6.0.23 en release et sortie de la 6.0.24 en beta. Ca turbine chez Uniquiti, il faut dire que ça grogne partout ! Nouveaux firmwares UAP/USW. Nouvelles déconnexions sur les ampoules Xiaomi.
  • EDIT 29/09/2020 17:17 : S'agissant des ampoules Xiaomi, j'ai essayé tous les paramètres possibles et imaginable ainsi que les version beta de firmware sans obtenir de résultat. J'en conclu que quelque chose a vraiment changé dans cette version qui a plus une allure de beta que de release. J'ai donc honteusement ressorti un vieil AP Netgear...
  •  

J'espère pouvoir échanger avec Unifi et qu'ils sauront m'apporter des réponse satisfaisantes à tous ces problèmes. Je mettrais bien sur à jour cet article énervé en fonction de.

Sources

 

Homme Assistant & BLE : Présence

Il y a quelques temps je vous avait déjà parlé de BLE (Bluetooth Low Energy) pour remonter des sondes de température Xiaomi. Le composant utilisé fonctionne bien et ça évolue, il n'y a rien à redire, sinon que ça ne gère pas la présence. Hors la notion de présence est importante en domotique.

Il y a plusieurs façons de gérer la présence dans Home Assistant

  • En géolocalisation en utilisant les API Google. Ça fonctionne bien au point de faire peur, mais ce n'est pas suffisamment réaction pour certaines actions. Par exemple si je veux ouvrir le portail, allumer des lampes et désactiver l'alarme lors de mon arrivée, il y a des chances que j'attende 5 minutes face au portail... Et que si j'ouvre le portail avec une télécommande l'alarme soit encore active lorsque je rentre dans la maison. C’est donc inutilisable pour cet usage.
  • Une application genre OwnTrack n'est pas beaucoup plus performante et consomme plus de batterie.
  • Un TAG RFID, ça fait le job mais il y a une interaction physique. Donc OK pour l'alarme, mais pas pour le portail...
  • Le WI-FI, en s’appuyant sur l'intégration Unifi (il y en a d'autres), c’est pas mal mais il me faudrait un AP à l'extérieur pour un meilleur résultat.
  • Un gardien ou un majordome serait idéal, mais je n'en ai pas les moyens !
  • J'ai pensé au ZigBee, mais la portée est trop courte et il me faudrait déporter un répéteur.
  • Il reste donc la voie du BLE que j'avais laissé de coté car l'intégration de base n'est pas à la hauteur de ce que j'avais avec un des meilleurs plugin sous Jeedom.

Pour palier à l'intégration BLE d'origine sous HA on dispose à ce jour de deux projets bien aboutis qui peuvent fonctionner soit de façon autonome sur un RPI, soit sous forme d'addon à installer directement dans Home Assistant. Dans les deux cas ils communiqueront avec HA en MQTT, et c'est un plus indéniable ! En ce qui me concerne j'ai testé les addon, mais un RPI0 indépendant sera idéal si on veut créer un réseau avec le second projet.

Monitor

Bluetooth Presence Monitor s'installe en ajoutant son dépôt dans le gestionnaire d'addon ou en partant du dépôt original si on veut l'installer à part. La configuration est simple :

mqtt:
  broker: 192.168.210.44
  port: 1883
  username: user
  password: password
  topic_root: presence
  publisher: ''
known:
  beacons:
    - 'F8:DE:32:B1:07:3D Tile'
  static:
    - '94:65:1D:D1:AD:96 5T'
    - '50:77:05:F6:0F:2F Note 9'
blacklist:
  - '58:2D:34:10:1D:4F'
  - '58:2D:34:10:12:77'
extra_arguments: '-a -x -b -tdr -r'

Par contre il faudra prendre soin d'aller régler le port BT dans le fichier /share/presence-monitor/behavior_preferences afin que cela ne rentre pas en confit avec un autre port (à ce niveau l'O/S ne gère pas le partage des ports comme celà pourrait être le cas sous Windows ou MacOS par exemple). Cela veut dire que si on a déjà une intégration qui utilise un port BT il faudra un dongle USB BT. Dans mon cas j'utilise une clé SENA TD100 que l'on trouve encore ici. C'est dans ce même fichier de configuration que l'on pourra ajuster tous les paramètres, fichier que l'on aurait aimé accessible depuis l'addon bien sur...

PREF_HCI_DEVICE=hci1

A partir de là on lance l'addon et on observe le log pour ajuster la configuration afin de choisir ce qui sera notifié au broker MQTT. Ensuite il faut créer un sensor: qui aura pour valeur le pourcentage d'éloignement ainsi qu'une très utile notion de départ / arrivée.

  - platform: mqtt
    state_topic: 'presence/homeassistant/tile'
    value_template: '{{ value_json.confidence }}'
    unit_of_measurement: '%'
    name: 'Tile BLE'
    icon: mdi:bluetooth

On va également créer un device_tracker: qui lui nous fournira un device tracker que l'on retrouvera comme d'habitude dans le fichier known_devices.yaml

  - platform: mqtt
    devices:
      TileBLE: 'presence/homeassistant/tile/device_tracker'
      name: "Tile BLE"
      icon: mdi:bluetooth

A ce stade ça fonctionne avec une prise en compte des équipements perfectibles, mais je n'ai pas creusé les paramètres avancés car entre temps je suis tombé sur Room Assistant. Par ailleurs mon TAG Tile ne semble pas être le meilleur pour cet usage et j'ai commandé un Nut 3.

Room Assistant

Room Assistant est à ce jour ce que j'ai trouvé de plus complet et de plus prometteur. L'installation de l'addon se fait depuis ce dépôt (ou ici si on installe à part) et on se concentrera sur le fichier de configuration, un lancement à vide nous permettant de repérer les adresses MAC des différents équipements.

Le gros avantage de Room Assistant est qu'il offre la possibilité de fonctionner en réseau, ce que l'on connaissait avec le plugin BLEA de Jeedom. Il sera ainsi possible de localiser les habitant d'un logement à la pièce près en se basant sur le signal BT/BLE. Je n'ai pour l'instant pas exploité cette possibilité, mon besoin étant le départ / arrivé de mes utilisateurs.

global:
  instanceName: canaletto_ble
  integrations:
    - homeAssistant
    - bluetoothLowEnergy
    - bluetoothClassic
    - xiaomiMi
homeAssistant:
  mqttUrl: 'mqtt://192.168.210.44:1883'
  mqttOptions:
    username: user
    password: password
bluetoothClassic:
  minRssi: '-20'
  hciDeviceId: 1
  addresses:
    - '94:65:2D:D4:XX:77'  # Mon mobile
bluetoothLowEnergy:
  hciDeviceId: 0
  onlyIbeacon: true
  timeout: 30  # Utile pour éviter les faux départs sur certains tags
  whitelist:
    - f8dedfgh73d  # Mon Tag Tile
  tagOverrides:
    f8dedfgh73d:
      name: Tile
xiaomiMi:
  hciDeviceId: 0
  sensors:
    - name: Clear Cuisine  # Xiaomi CGG1
      address: 582d3dfgsd6d
    - name: Clear SdB  # Xiaomi CGG1
      address: 582d3dgf3286
    - name: Clear Exterieur  # Xiaomi LYWSDCGQ
      address: 4c6dfgd1db75
    - name: Clear Square  # Xiaomi LYWSD02
      address: 3fdfg88270ca
    - name: Clear Clock  # Xiaomi CGD1
      address: 58sdfgsd3292
      bindKey: cc0d9dfgdsfgsdf4e7f495d27eacf5250e2e8
entities:
  behaviors:
    ble-f8desdb1073d-tracker:
      debounce:
        wait: 10.75
        maxWait: 20

On passe rapidement sur la classique config MQTT pour noter que si l'intégration bluetoothLowEnergy et xiaomiMi peuvent partager le même port BT (BLE dans les deux cas), ce port devra être différent pour du bluetoothClassic. Le développeur travaille au partage de port mais ce n'est pas pour l'instant possible.

L'intégration, la création, dans Home Assistant des sensors: est automatique via MQTT (présence, température, etc..), par contre il faudra manuellement créer les device_tracker: si on souhaite les exploiter.

  - platform: mqtt # Room-Assistant
    devices:
      ra_tile: 'room-assistant/device_tracker/ble-f8de32b1073d-tracker/state'
      name: "Tile BLE"
      icon: mdi:bluetooth
    payload_home: 'true'
    payload_not_home: 'false'
    source_type: bluetooth   

Ensuite il va falloir exploiter et pour le debug je me sert de Slack pour faire un log dynamique. On commence par deux automations pour simuler un départ et une arrivée (je me contente d'enlever la pile du Tile ou de le coller dans le micro onde... Je me sert ici du device_tracker:

- alias: Alarm Test Tile leave
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'home'
    to: 'not_home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave" 

- alias: Alarm Test Tile enter
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'not_home'
    to: 'home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return" 

Mais, car il y a un mais, j'ai remarqué que visuellement mes deux icônes ne changeait pas d'état à la même vitesse, le sensor: étant plus rapide. Je fais donc une seconde paire d'automation avec lui...

- alias: Alarm Test Tile leave device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'canaletto_ble'
    to: 'not_home'

  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave Sensor" 

- alias: Alarm Test Tile enter device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'not_home'
    to: 'canaletto_ble'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return Sensor" 

Et là on a une vraie surprise dans les résultats car on gagne 10 secondes ! Et 10 secondes sur une arrivée c'est hyper important car c'est à peu près le temps que je dois mettre pour aller du portail à la porte d'entrée...

14/09/2020, 23:12:41 > TEST TILE Leave using sensor:
14/09/2020, 23:12:52 > TEST TILE Leave using device_tracker:
14/09/2020, 23:13:01 > TEST TILE Return using sensor:
14/09/2020, 23:13:12 > TEST TILE Return using device_tracker:

Voilà, il va maintenant falloir faire des tests en live, l'idéal serait que le tag puisse être détecté quand je me gare devant le portail, mais pour ça il me faudra que j’équipe la clé SENA avec une antenne plus performante. Je trouve que les délais d'Accroche / Décroche des mobiles sont excellents et j'attend mon Nut pour d'autres tests.

Le support des capteurs Xiaomi est récent et pour l'instant l'information concernant le niveau de batterie n'est pas disponible pour tous contrairement à MiTemp. Mais ça devrait venir. Ce qui est amusant, sinon intéressant, c'est que dans cette intégration un capteur de température Xiaomi peut devenir un TAG et être vu par HA en tant que tel... Mon Tile ne fonctionnant pas très bien, j'ai donc pensé à laisser un CGG1 dans ma voiture...

Voilà pour ces petits tests, je suis bien sur disponible pour échanger sur TG ou ici dans les commentaires. N'hésitez pas à partager vos expériences afin que je puisse au besoin mettre à jour cet article.

EDIT : Je n'ai pas encore eu le temps de tester mais les informations trouvées ici me semblent pertinentes.

Et en WI-FI

Si gérer la présence en Bluetooth peut sembler évidente, à l'usage on s'aperçoit que le BT des mobiles décroche trop souvent, que celui des tags BLE n'est pas assez rapide et surtout que même avec une clé Sena et une antenne la portée est trop réduite. Finalement le WI-FI reste une très bonne solution, à condition d'avoir un AP gérable (Unifi avec intégration Unifi ou Unifi AP qui est légèrement plus rapide) et d'autres marques reconnues, Netgear par exemple. Ce qui est intéressant ici c'est que dès que l'AP voit le mobile (sa MAC, sans pour autant que le signal soit suffisant pour un appairage et qu'il ait une IP) HA est informé de la présence du device et peut ainsi gérer des automatismes. Le décrochage est long ce qui garantie l'absence de faux positifs mais l'accrochage est lui très rapide.

Sources

 

 

Configuration automatique POP/IMAP

Quand on configure sous Outlook un compte Exchange, Office 365, Google et quelques autres fournisseurs, celà se fait tout seul, il suffit de rentrer son adresse mail et son mot de passe et un obscur mécanisme nommé AutoDiscover se mets en place et le tour est joué. Vous imaginez qu'il y a un peu de mécanique derrière cette automatisation. Que ça utilise MAPI ou EAS, votre fournisseur le fera pour vous et si vous gérez votre propre serveur Exchange on premise vous trouverez plein de documentation en ligne sur ce sujet.

Et en POP3/IMAP4 ?

C'est pareil, certains gros services de mail proposent cette automatisation (Google par exemple), par contre si vous gérez votre propre serveur de messagerie ou que vous utilisez votre nom de domaine sur les serveurs de Gandi ou OVH par exemple, il y a peu de chances que celà se fasse tout seul et il faudra que vos utilisateurs renseignent manuellement les noms de serveurs IMAP/POP/SMTP, les différents ports en SSL/TLS, etc... C’est fastidieux, d'un autre âge et c'est également pitoyable que des fournisseurs tels OVH ou Gandi laissent leurs services de mail en l'état, ils ne proposent d'ailleurs toujours pas de connexion EAS pour les mobiles.

Il ne reste donc plus qu'à faire le travail.

La première solution consiste à aller déposer un fichier /autodiscover/autodiscover.xml sur un serveur que l'on adressera dans le DNS avec un CNAME du genre autodiscover.domain.tld. Ça peut suffire dans certains cas, mais à cause d'un bugg dans Outlook on ne récupérera que le username sans le domaine. Et si le serveur l'exige il faudra alors terminer la configuration manuellement. Ce n'est pas très propre et tant qu'à automatiser autant aller au bout des choses.

La seconde solution consiste à mettre un peu de code et la façon la plus simple que j'ai trouvée, j'y ai tout de même passé 8 heures..., est de le faire en PHP. On monte un petit serveur web avec du PHP, on crée un enregistrement DNS autodiscover.domain.tld qui pointe dessus et on le configure avec un certificat valide (un Let's Encrypt par exemple). Ce point est important car sans SSL Outlook ne reconnaîtra rien. On teste que ça fonctionne et que le certificat est valide. Dans la racine on crée un fichier autodiscover.php, en gros c'est surtout un XML, la partie PHP ne servant qu'à récupérer l'adresse mail pour la transformer en LoginName. Bien sur on adapte aux besoin, POP/IMAP, etc...

<?php
//get raw POST data so we can extract the email address
$data = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $data, $matches);

//set Content-Type
header("Content-Type: application/xml");
?>
<?php echo '<?xml version="1.0" encoding="utf-8" ?>'; ?>

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <Account>
            <AccountType>email</AccountType>
            <Action>settings</Action>
            <Protocol>
                <Type>IMAP</Type>
                <Server>mail.gandi.net</Server>
                <Port>993</Port>
                <DomainRequired>off</DomainRequired>
                <LoginName><?php echo $matches[1]; ?></LoginName>
                <SPA>off</SPA>
                <SSL>on</SSL>
                <AuthRequired>on</AuthRequired>
            </Protocol>
            <Protocol>
                <Type>SMTP</Type>
                <Server>mail.gandi.net</Server>
                <Port>465</Port>
                <DomainRequired>off</DomainRequired>
                <LoginName><?php echo $matches[1]; ?></LoginName>
                <SPA>off</SPA>
                <Encryption>TLS</Encryption>
                <AuthRequired>on</AuthRequired>
                <UsePOPAuth>off</UsePOPAuth>
                <SMTPLast>off</SMTPLast>
            </Protocol>
        </Account>
    </Response>
</Autodiscover>

Ensuite on va faire en sorte que le serveur retourne le contenu XML nécessaire à Outlook quelque soit l'URL ou la casse utilisée. Si dans le monde Windows il n'y a pas de différence entre les majuscules et les minuscules, ce n’est pas le cas sous Linux. Et Microsoft à codé en dur dans ses clients de messagerie tantôt en majuscule tantôt en minuscule, voire souvent la première lettre en majuscule, il va falloir ajuster... Pour y palier on va utiliser la fonction REWRITE et coller ça dans un fichier .htacess si on utilise un serveur Apache :

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ autodiscover.php [NC,L]

Ou le convertir (ici) et le placer dans le fichier de configuration si on utilise un serveur Nginx :

if (-e $request_filename){
	set $rule_0 1;
}
if ($request_filename ~ "-l"){
	set $rule_0 1;
}
if (-d $request_filename){
	set $rule_0 1;
}
if ($rule_0 = "1"){
#ignored: "-" thing used or unknown variable in regex/rew 
}
	rewrite ^/.*$ /autodiscover.php last;

Il ne reste plus qu'à tester sous Outlook ou Courrier (Mail) sous Windows 10.

Attention toutefois, sous Outlook 2016/2019 Microsoft a changé les règles du jeu. Le pernicieux but est certainement de pousser les clients vers Office 365, ce système s'appuie sur la fonction Simplified Account Creation introduite après le rachat de la société Acompli (Outlook mobile). Ce système gère les domaines Microsoft, ceux enregistrés sur Office 365 et quelques autres selon leur importance et de façon plus ou moins obscure. On ne trouve nulle par le moyen d'ajouter un domaine à ce service et certaines discutions qui en parlaient sur les forums Technet sont maintenant effacées. On peu donc penser à des ajouts de gré à gré pour les sociétés sous contrat avec Microsoft.

il ne faut donc pas ajouter un compte depuis Outlook mais contourner la chose en passant par l'ancien panneau de contrôle (WIN+R+Control) tant qu'il existe. C'est d'autant plus curieux que ça fonctionne très bien sous l'application Courrier de Windoiws 10, qui au passage s'est bien améliorée. Il existe toutefois un moyen simple de désactiver Simplified Account Creation via le registre ou par GPO.

Et si j'ai plusieurs domaines ?

Dans tous les cas il faudra un serveur web par fournisseur de messagerie. Par contre ayant plusieurs domaines chez Gandi je vais pouvoir tout concentrer sur un seul serveur. Pour y parvenir, deux solutions :

Avec un enregistrement SRV par domaine

Je crée un serveur web générique, par exemple avec comme adresse

autodiscover-gandi.domain-gen.tld

(SSL activé) et dans le DNS de mes domaines je crée un enregistrement SRV de type

_autodiscover._tcp 1800 IN SRV 10 10 443 autodiscover-gandi.domain-gen.tld. 

La résolution sera un peu plus longue car c’est la dernière chose que recherchera Outlook, mais ça fonctionnera.

Avec un certificat multiple sur le serveur

Dans ce cas je fais pointer tous mes domaines sur le même serveur, par contre j'ajoute tous ces domaines (autodiscover.domain1.tld, autodiscover.domain2.tld...) au certificat du serveur, ce qui du reste est très facile avec Let's Encrypt.

Et Thunderbird ?

Même si plus grand monde utilise ce client, il existe une possibilité (que je n'ai pas testé et je suis preneur de vos retours). Et cette possibilité semble plus simple car elle permet de base de gérer plusieurs domaines que l'on appellera depuis le client avec une url : 

http://autoconfig.domain.tld/mail/[email protected]

Je ne pense pas qu'il soit utile de disposer de PHP, un simple fichier XML faisant l'affaire :

/wwwroot/domains/domain.tld/public_html/autoconfig/mail/config-v1.1.xml

<clientConfig version="1.1">
 <emailProvider id="domain.tld">
   <domain>domain.tld</domain>
   <displayName>%EMAILADDRESS%</displayName>
   <incomingServer type="imap">
     <hostname>mail.domain.tld</hostname>
     <port>993</port>
     <socketType>SSL</socketType>
     <username>%EMAILADDRESS%</username>
     <authentication>password-cleartext</authentication>
   </incomingServer>
   <outgoingServer type="smtp">
     <hostname>smtp.domain.tld</hostname>
     <port>587</port>
     <socketType>STARTTLS</socketType>
     <username>%EMAILADDRESS%</username>
     <authentication>password-cleartext</authentication>
   </outgoingServer>
 </emailProvider>
</clientConfig>

Une dernière chose, pour faire tout ça j'ai utilisé aaPanel, j'en parlerais bientôt mais je vous encourage à découvrir !

Sources

Etant donné que je n'ai bien sur rien inventé, voici de la lecture...

 

Imprimantes et numérisation

On nous annonçait jadis que l’informatique conduirait au zéro papier, mais ce n'est pas le cas ! Et les imprimantes constituent toujours un problème. J'imprime peu, je déteste les jets d'encre qui se bouchent et j'ai une préférence pour les laser couleur. Bon, c’est cher, mais dans tous les cas c’est toujours cher d'imprimer quelques feuilles. Et puis il faut aussi numériser, donc depuis quelques années j'ai opté pour un multifonction.

Pour sortir un peu des sentiers battus (HP depuis la LaserJet 1 dans les années 90) je m'étais offert une Samsung C460w avec chargeur de documents (la division print de Samsung a depuis été rachetée par HP et on se demande pourquoi). J'ai toujours eu des problèmes avec cet appareil, mauvaise impression, sortie de veille impossible à la débrancher, et depuis quelques temps des bourrages récurrents dus à une pièce défectueuse, une cale en plastique de 1 cm, mais il faudrait des heures et de la patience pour la changer (voir 1 - 2 ). Donc même si la numérisation a toujours bien fonctionné, ça reste un modèle à éviter. Faute de temps je me suis résolu à la mettre à la casse (si ça intéresse quelqu'un...), après avoir longtemps hésité car je venais de changer les 4 toners.

Pour la remplacer il me fallait un modèle peu profond afin de pouvoir l'installer au même endroit. Mon choix s'est porté sur la Lexmark MC3326awde. Le coût à l'impression est élevé, mais j'imprime peu et ils offrent une garantie de 4 ans.

Coté impression rien à redire, elle est reconnue tant sous Windows que MacOS. Coté numérisation ça se complique. Si sous MacOS tout est facile et qu'il n'y a rien à télécharger, sous Windows c’est un peu différent, le pilote Twain pour l'utiliser avec NASP2 date d'un autre age et surtout il nécessite d'aller valider la numérisation sur le panneau de l'imprimante, quant à WSD déjà que ça a du mal pour imprimer, pour numériser ça ne fonctionne simplement pas (merci MS d'avoir boycotté Twain). Lexmark fournit un ersatz de logiciel (ScanBack) qui lui aussi impose d'aller valider sur l'appareil.

Heureusement il y a des alternatives qui consistent à lancer la numérisation depuis le panneau de contrôle avec des paramètre que l'on aura prédéfinis. On peut ainsi numériser vers une destination SMB ou FTP, c'est vraiment pas simple à configurer et hors de portée du grand public, ou vers une adresse mail, ce n'est pas plus simple et ça imprime chaque fois une inutile page de confirmation. Il est également possible de numériser vers un Cloud Drive (Box, Dropbox, Google Drive ou OneDrive) quand on a compris la procédure...

Mais les habitudes ont la vie dure, moi je veux juste numériser depuis NAPS2 comme je ne faisais avant. Et ça c'est juste impossible sans passer par cette étape ridicule : 

D'autant plus ridicule que sous MacOS cela se passe très bien et sans avoir rien à installer. Alors j'ai cherché et j'ai fini par trouver un logiciel commercial, VueScan, qui lui permet de faire le travail. Leur point fort est de reconnaître tous les scanners via leur pilote TWAN universel. Hélas ce pilote n'est utilisable que par leur application et si on l’appelle depuis NAPS2 il lance VueScan.

Une fois de plus on se rend compte qu'il y a des produits qui n'évoluent pas, les imprimantes multifonctions en font partie avec une partie logicielle très désuète. Par exemple cet appareil joue également le rôle de télécopieur, mais qui a encore une ligne dédiée Fax ? Pour ceux qui en ont encore besoin, une innovation aurait peut être été une compatibilité SIP ou avec des prestataires de fax. Et je passe sur l'écran tactile qui à la taille minuscule d'un téléphone du début du siècle ou il est impossible de saisir quelque chose sans se tromper, sans oublier les touches situées à coté non rétro éclairées et donc invisible dans la pénombre de mon bureau... Bref, il faudra faire avec car avec ses 20 kg. elle ne va pas rentrer dans la boite aux lettres pour un retour Amazon facile. Et je ne suis pas sur de trouver mieux chez les autres fabricants.

Autres problèmes...

Du coup j'ai essayé de faire fonctionner VueScan avec deux copieurs Ricoh 3003/3004 d'un client qui ne sont plus mis à jour et imposent du SMB1 si on veut faire du scan vers PC. Nada, bien que dans la liste ils ne sont pas reconnus, pas plus que NAPS2 ne reconnait les pilotes Twain de la marque... Encore un bel exemple d’obsolescence programmée.

Home Assistant IR, AC & More...

Pour piloter un climatiseur avec Home Assistant il existe plusieurs options, mais vu qu'il n'existe pas de protocole unifié (à par peut être KNX que l'on oublie pour des questions de coûts), ça va bien souvent se terminer en IR, là ou une option MQTT sur les interfaces WI-FI des constructeurs aurait été une bénédiction. En dehors de Dalkin qui dispose d'une intégration et Xiaomi (non importé), ces interfaces sont bien sur propriétaires et fermées.

Alors on se rabat sur l'infrarouge, ce qui n'est pas très sexy en 2020 ! D'ailleurs si vous voulez juste piloter une clim avec une application, plutôt que de payer cher une option WIFI du constructeur, pour 80/90 € offrez vous simplement un Tado ou un Sensibo, ça fera le job en mieux et ce sera compatible Alexa et Google Home, avec des intégrations Home Assistant (Tado | Sensibo) à la clé. Sauf que c’est du cloud et que je veux un pilotage local.

On va donc partir sur un Broadlink qui dispose d'une intégration. A la base ce gadget permet de piloter n’importe quel appareil IR depuis une application mobile. Ici on va faire la même chose, mais de puis Home Assistant, et on va voir qu'il existe plusieurs façons de faire, et accessoirement que j'ai perdu bien du temps en ne trouvant pas la seconde option tout de suite...

Intégration du Broadlink à Home Assistant

Ça c'est la première chose à faire dans tous les cas, sans perdre de vue que votre Broadlink sera sur l'application ou sur Home Assistant, pas les deux. Il est toutefois intéressant de l'ajouter une fois à l'application pour récupérer son IP et son adresse Mac.

  1. On supprime le Broadlink de l'application mobile.
  2. Sans le débrancher on lui fait un reset en appuyant 6 secondes avec un trombone.
  3. On ajoute le Broadlink au réseau avec l'application, mais sans le connecter au cloud Broadlink, pas maintenant, pas plus tard. On sort de l'application et on l'oublie.

Ensuite on ajoute ces quelques lignes au fichier configuration.yaml en reportant les infos précédament récupérées et on redémarre HA. Idéalement on place une réservation DHCP sur cette IP.

remote:
  - platform: broadlink
    name: rm4_mini
    type: rm4c_mini  # Ça c'est très important....
    host: 192.168.210.132
    mac: '24:AF:A2:30:0D:E2'

A partir de là on a deux possibilités. La première va consister à apprendre les codes IR et à les restituer. Pour les apprendre on va faire un petit script et se laisser guider par les notifications de Home Assistant pour presser sur les touches idoines au bon moment...

learn_tv_commands:
  alias: Apprentissage IR
  sequence:
  - data:
      command:
      - turn on
      - turn off
      - volume up
      - volume down
      - chanel up
      - chanel down
      device: television_sam
      entity_id: remote.sam
    entity_id: remote.rm4_mini
    service: remote.learn_command

Et on va se retrouver avec les fichier /config/.storage/broadlink_remote_24dfa2300de2_codes qui va contenir nos codes IR, fichier dans lequel il nous suffira d'aller récupérer les bons codes.

{
    "data": {
        "television_sam": {
            "chanel down": "JgDSAJOUEjcTNxQ1ExIUERMSExITERQ2FDYTNhMSExITEhMSFBETERQRExITEhM2FBETEhMSFDYUNRM3FDYTEhM2EzcTNhQABgKWkhQ2EzcUNRQRExITEhMSFBEUNRM3EzYUERMSFBEUERQRExITERQRExIUNhMSFBEUEBQ2EzYUNhM3FBETNhM3EzYVAAYBlpIUNhQ2FDUTEhQRFBEUERMRFDYUNhM2FBEUERQRExIUERQQFBEUERMSFDUVEBQRExIUNhQ1FDYUNhQQFDYUNhQ1FQANBQAAAAA=",
            "chanel up": "JgAYAZSTEzcTNhM3ExIUERMRFBETEhQ2FDUUNhQRExITERUQFBETEhQ2FBEUEBQ2ExIUERQRFDUTEhQ2FDUUERQ2FDUUNhQABgOUkxQ2EzcUNRMSExIUERQRFBAUNhQ2FDUUERQRFBEUERQRFBAUNhQRExIUNRQRFBETEhM2FRAVNRM3FBETNhQ2FDUVAAYClZIVNRQ2FDUVEBQRFBEUERMSFDUUNhQ2FBAVEBMSFBEUERQRFDUUERQRFDYTERUQFBEUNhMSFDUUNhMSFDUUNhM3FAAGApWTFDUUNhM3FBAUERQRFBETEhQ1FTUUNhQRExEVEBQRFBETEhQ1FRAUERQ2FBETERQREzcUERQ1FDYUERQ1FDYUNhQADQUAAAAAAAAAAAAAAAAAAA==",
            "turn off": "JgBGAJGVEzcTNhQ2ERQTEhMSExEUERM3EzcTNhMSExITEhEUExEUERM3ExITEhMREhMTEhMSEzYUERQ2ETkTNhQ2EjgTNhQADQU=",
            "turn on": "JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA==",
            "volume down": "JgDSAJSTEzYTNxM3ExIRExMSExITEhM3ETgSOBMSExITERQRExITNxM2ExITNxEUExISEhMSExITEhM3ERMTNxM3EzYSOBEABgSWkxE5ETgTNxEUExITEhISEhMTNxM2EzcTEhMSExIRExMSEzcTNhITEzcRFBMSExIRExMSExITNxEUEjcTNxE4EzcTAAYDlZMTNxM2EzcTEhMSExITERQREzcTNxI3ExITEhMSExITERQ2EzcTEhM2ExITEhMSExETEhMSEzcTEhM2EzcTNxM2EwANBQAAAAA=",
            "volume up": "JgDSAJKVETgSOBE5ERQRExITEhMRFBE5ETgSOBEUERQRExITEhMRORE4EjgRFBEUERQRExITEhMRFBEUETgSOBE5ETgSOBIABgSVkxQ2EzYUNhMSExITERQRFBEUNhM2FDYUERMSExITERQRFDYTNhQ2FBETEhMSExITERQRFBETEhM2FDYUNhM2FDYUAAYClJQTNxM2FDYTEhITEhMSEhMSEzcSNxM3ExISExEUEhISExM3EjgROBITERQRFBEUERMSExITEhMROBI4EjgROBI4EQANBQAAAAA="
        }
    },
    "key": "broadlink_remote_24aca7a1dce2_codes",
    "version": 1
}

Ensuite on va créer un switch qui pourra d'ailleurs en contenir plusieurs... Et avec lesquels ont pourra interagir depuis des automation, scripts ou l'interface Lovelace...

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !
  timeout: 15
  switches:
    tv_on:
      friendly_name: "TV Power"
      command_on: 'JgCMAJWTEzYTNhQ2FBETEhMSExEUERQ2EzYUNhQRFBETEhMSExEUERQ2ExITEhMRFBEUERQREzYUERQ2FDYTNhQ2FDYTNhQABgOVkhQ2FDYTNhQRFBEUERMSExITNhQ2EzYUERQRFBEUERMSExITNhQRFBETEhMSExEUERQ2ExITNhQ2FDYTNhQ2FDYTAA0FAAAAAAAAAAAAAA=='
      command_off: 'JgDSAJKUFDYSOBI3ExITEhITEhMSExI2FDcSNxMSExITEhITEhMSExI3ExISExITEhITEhMSEjgSExI3EzcSOBI3EzcSNxMABgOVkxQ2EzcSOBMRFBETEhITExITNhQ2EjcUERQRFBETEhITExITNhMSExITEhMSExEUERM3ExISNxQ2EzcTNhQ2EzcTAAYClZQTNhQ2EzcTERQRFBETEhMSEzYUNhM3EhMSEhMSFBETEhITEjcTEhMSEhMSExITEhITNxITEjgSNxM3EjcTNxM3EgANBQAAAAA='

Ça c'était la version manuelle, c’est pratique car ça permet d'associer n’importe quel appareil piloté par une télécommande IR. Par contre c'est fastidieux et j'ai passé mon après-midi à me dire qu'il était impossible que quelqu'un n'ai pas fait mieux, à savoir une intégration ou je n'aurais qu'à choisir la référence de mon climatiseur pour le commander avec une carte Climate. Et ça existe !

SmarIR

SmartIR s'appuie sur le Broadlink, ou d'autres interfaces IR, qu'il s'agisse de Xiaomi, d'un ESP DIY ou d'un objet en MQTT. Pour le configurer il nous faut avoir intégré notre interface à HA, ici le Broadlink, et installer le composant depuis HACS.

Pour activer cette intégration on ajoute une entrée dans configuration.yaml :

smartir:

Une entrée dans switch.yaml :

- platform: broadlink
  host: 192.168.210.132
  mac: '24:AF:A2:30:0D:E2'
  type: rm4c_mini  # Toujours aussi important !

Et enfin une dernière dans climate.yaml ou l'on n'oubliera pas de reporter le bon code IR : 

- platform: smartir
  name: Office AC
  unique_id: office_ac
  device_code: 1260  # Ici le code IR pour les climatiseurs Toshiba
  controller_data: 192.168.210.132
  temperature_sensor: sensor.temperature  # Ici on peut associer un capteur de température externe
  humidity_sensor: sensor.humidity  # Ici on peut associer un capteur d'hygrométrie externe
  power_sensor: binary_sensor.ac_power

Un petit redémarrage et on est prêt à piloter notre climatiseur comme on le ferait pour n'importe quel thermostat, sauf qu'ici on dispose de toutes les commandes utiles (mixte, chauffage, refroidissement, de-humidification, ventilation) propre au modèle choisit (on ne voit pas

Mon projet portait sur la climatisation, mais avec SmartIR il est également possible de piloter des ventilateurs ou du matériel Audio / Vidéo, pourquoi pas votre magnétoscope VHS ! Et ce qui ne sera pas possible avec SmartIR le sera en mode manuel.

EDIT HA 0.115 : Broadlink est maintenant intégré à HA, donc on vire ce qui est dans configuration.yaml et switch.yaml et on adapte l'utilisation avec le device ID que l'on trouvera dans l'intégration, ici remote.ir_clim_remote :

- platform: smartir
  name: AC Sejour
  unique_id: ac_sejour
  device_code: 1260
  controller_data: remote.ir_clim_remote
  temperature_sensor: sensor.mi_t_carre
  humidity_sensor: sensor.mi_h_carre
  power_sensor: binary_sensor.ac_power

Sources

Gérer ses VM Azure...

Ceci est un Notepad en évolution... Revenez...

Start / Stop

Un des intérêts d'une VM dans le cloud, c’est de n'en payer que l'usage. Pour la faire courte et pour donner suite à mon article sur les Bureaux à distance, je me suis retrouvé pour ce client avec VM qui n'était pas assez puissante. Sous Azure, c’est facile, en deux clics on change la taille de la VM, on choisit une instance avec plus de CPU, RAM, IO et bien sur le tarif augmente... Et si Azure est fonctionnellement remarquable, les tarifs sont purement stratosphériques si on les compare à une VM sur un serveur dédié chez Scaleway ou OVH (qu'il faudra bien sur géré, ce qui a aussi un coût et n’est pas faisable facilement par tout le monde). Bien sur ont peut facilement imaginer que les grand comptes obtiennent des remises tout aussi conséquents, sauf que pour une PME ça reste bien souvent inaccessible.

Vu que cette VM ne va être utilisée qu'aux heures de bureau, une façon de faire quelques économies va consister à programmer une heure de démarrage et une heure d'arrêt. Pour l’arrêt c’est facile, il suffit de configurer ça dans les paramètres de la VM. Mais allez donc savoir pourquoi il n'y a pas la même facilité pour la démarrer ? Chez Microsoft il appellent ça By Design. Il doit bien y avoir une raison puisque qu'il semblerait que ce soit à peu près le même fonctionnement chez les autres fournisseurs d'instances cloud et même chez OVH ou Scaleway. Bref, ce serait trop facile.

Il y plusieurs solution pour palier à ça !

Azure CLI

On peu bricoler quelque chose avec Azure CLI (Linux, Mac, Windows) et ainsi lancer un script qui va lancer ou stopper a VM. Pas très sexy ni trop sécurisé. 

Attention : Il ne faut pas se contenter d’arrêter la VM depuis l'O/S car si cela arrêtera bien la VM, elle continuera à être facturée, simple, mais sans intérêt. Pour qu'elle ne soit plus facturé il faut la désallouer (Deallocate) et ainsi seul le stockage continuera à être facturée.

Démarrer la VM

az vm start --name MyVM --resource-group MyVMGroup

Arrêter et désallouer

az vm stop --name MyVM --resource-group MyVMGroup
az vm deallocate --name MyVM --resource-group MyVMGroup

Il est également possible de faire ça en utilisant directement les ID des VM

az start --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az stop --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az deallocate --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"

Azure Automation

Tout ça n'est pas très sexy ni user friendly. Une autre façon de faire va consister pour l'administrateur de programmer le démarrage de la VM et son arrêt en considérant que l'utilisateur s'en servira à heures fixes. Pour l’arrêt on va se servir de la fonction intégrée car elle est capable de base d'envoyer un mail à l’utilisateur lui proposant d'outrepasser l’arrêt programmé sans avoir à se connecter. Pratique.

Pour le démarrage par contre ça va être un peu plus compliqué. On va commencer par créer un compte Automation, simplement en cherchant dans la barre de recherche. Comme tout sur Azure, ce service est également payant, mais dans sa grande bonté Microsoft nous offre (jusqu'à quand ?) un petit forfait gratuit tous les mois qui sera amplement suffisant pour ce qu'on va faire.

Une fois dans notre compte Automation on va créer un Runbook, on lui donne un nom et on choisit un Flux de travail PowerShell (PowerShell Workflow) et on le crée. Une fois créé on va aller l'éditer

workflow Start-Ma-VM
{
# Association to the Azure subscribtion
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

# Start the virtual machine
Start-AzureRMVM -ResourceGroupName "MonGroupeDeRessources" -Name "MaVM"
}

Il ne reste plus qu'à aller dans le menu Planifications et d'en ajouter une en configurant l'heure de démarrage et la récurrence, sans oublier de choisir le bon fuseau horaire. Si on veut envoyer une notification par un mail ou faire autre chose il est bien sur possible de le faire dans le script.

A ce stade ça reste toutefois limité, la VM va démarrer tous les jours, même quand personne ne travaille.

Heureusement il est également possible de créer un WebHook et ainsi démarrer la VM depuis une URL. Ici depuis PowerShell mais on peut tout à fait imaginer intégrer ça dans un portail intranet ou un simple raccourcis sur le poste de l'utilisateur... Ou mieux utiliser un planificateur évolué tenant compte des jours fériés et des week-ends, voire interagir avec un agenda Google ou Microsoft 365...

PS C:\Users\Lionel> Invoke-WebRequest -Uri https://6bc1fsdfs-aesdf4c2f-8d31dsfsdf7fsd5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFqgqgfqsqgdgB%2qsdgfqsdgjc%3d -Method POST

Alternatives

Si la lecture de la documentation n'est pas toujours très lisibles, il faut bien admettre qu'Azure est très complet. Et si cela ne vous suffit pas il existe des fournisseurs de service qui se sont spécialisés dans la planification des VM et plus globalement vous aideront à réduire les coûts du cloud, que ce soit sur Azure, AWS ou GoogleCloud. Je pense par exemple à ParkMyCloud ou MyCloudToolbox, mais il y en d'autres. Se posera alors la question de la confiance que vous accorderez à ces services.

L'accès des clients aux VM

Comme on l'a vu le plus simple consiste à utiliser le client d'accès à distance. Le protocole RDP n'étant pas franchement des plus sur. Sécuriser RDP imposerait de passer par des certificats et une passerelle complexe et coûteuse ou par une alternative non Microsoft du genre Royal TS Server. La logique impose de passer par un VPN. Azure propose bien entendu tout une panoplie de solutions de sécurité, n'ayant ni envie de passer à la caisse ni celle de me compliquer la vie pour ce type d'utilisation, je vais simplement utiliser ZeroTier. C'est plus un SDN qu'un VPN, c'est OpenSource et gratuit et ça fait parfaitement le travail (j'en avais déjà parlé et on trouve maintenant une multitude d'articles).

On donnera une IP fixe au serveur et tous les clients autorisés pourront accéder au serveur RDP. Ensuite on prendra soin de ne plus autoriser l'accès via l'IP externe Azure ou de forcer un ACL sur une IP cliente sure. Easy, d'autant plus que mon client utilise déja cette solution pour sécuriser l'accès à des ressources SMB distantes.

Scénario pratique....

Sur le poste de on prépare un script PowerShell qui va lancer le WebHook pour démarrer la VM Azure, attendre que le serveur soit lancé, tester le port RDP et lancer le Bureau à distance, et au passage notifier un IT si quelque chose se passe mal. S'il doit y revenir dans la journée il ne lancera que le client RDP (Bureau à distance), en fin de journée le serveur sera programmé pour s’arrêter tout seul et si l’utilisateur veut faire des heures supplémentaires il n'aura qu'à cliquer dans le mail reçu pour reprogrammer l’arrêt...

On commence par brouiller à minima le mot de passe du mail...

"P4ssww0rd!" | Convertto-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-file C:\Users\User1\admin.txt

Et ensuite on prépare un petit script qui se lancera depuis un raccourcis sur le bureau...

$password = Get-Content C:\Users\User1\admin.txt | Convertto-SecureString # On récupère le mot de passe encrypté dans un fichier...
$username = "[email protected]"
$From = "[email protected]"
$To = "[email protected]"
$SMTPServer = "mail.gandi.net"
$SMTPPort = 587
$subject = "Client : Utilisateur (Machine)"
$Credential = New-Object System.Management.Automation.PSCredential ($username, $password)

try {
    $response = Invoke-WebRequest -Uri https://6bcghgdfh-afgh-4ghgfdf-8ghfgdh5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFshghshhh5+fgshs+f5h5+65sh -Method POST
    if($response.StatusCode -eq 202) {
        Write-Host "waiting..."
        sleep 60   # Temps d’attente estimé pour le démarrage de la VM
        if (Test-NetConnection 10.17.22.15 -Port 3389 | ? { $_.TcpTestSucceeded } ) {
            C:\Users\User1\vm.rdp  # On lance le client RDP
        } else {
            cls
	    Write-Output "RDP 1" # Si test NetConnection échoue (pas de réponse)
            Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection Fail' -Credential $Credential  -Port $SMTPPort -UseSsl
	    sleep 15
        }
    } else {
        cls
	Write-Output "Erreur RDP (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Si NetConnection code autre que 202
        Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection 40x ou 500x' -Credential $Credential  -Port $SMTPPort -UseSsl
	sleep 15
    }
} catch {
    cls
    Write-Output "Erreur VM (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Erreur NetConnection code 40x ou 50x
    Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur au lancement de la VM' -Credential $Credential  -Port $SMTPPort -UseSsl
    sleep 15
}

Ainsi, contrairement à une planification en début de journée, la VM ne sera lancée que quand l'utilisateur en a l'usage afin d'économiser sur la facture Azure. Au besoin on peut également faire un petit script pour l'éteindre.

Migration

Dans un autre contexte je dois migrer une VM Azure vers ESXi. Expérience à venir.

Sources

 

Home Assistant & SSL

Maintenant que votre serveur Home Assistant est en place, il va falloir le faire communiquer avec l'extérieur de la façon la plus sécurisée possible. Sur le principe on ouvre le port (TCP/8123 en général) sur le routeur et on redirige le flux vers le serveur local. Je ne vais pas vous faire un dessin, d'autres l'ont fait. Ensuite il va falloir d'occuper de la mise en place du certificat SSL

Pour faire court deux cas de figure se présentent.

Soit votre fournisseur d'accès vous met à disposition une IP fixe, soit non, et c’est hélas le cas de beaucoup. Certains comme Free fournissent maintenant une IP fixe partagée, dans ce cas il faut demander via l'interface une IP full range. Si vous disposez de votre propre nom de domaine, et ce n'est absolument pas obligatoire pour ce genre de site, par essence privé, on va privilégier Let's Encrypt.

  • IP Fixe + Nom de domaine : Add-on Let'sEncrypt.
  • IP Dhcp avec ou sans nom de domaine : Add-on DuckDNS

L'add-on Let's Encrypt

Il s'installe depuis le superviseur et peut s’appuyer sur les API d'OVH, Gandi et CloudFlare (et bien d'autres). Si tout est bien renseigné comme ci dessous par exemple, en quelques minutes vous obtenez votre certificat et le tour est joué.

email: [email protected]  # Pour Let's Encrypt
domains:
  - ha.domain.tld  #  Domaine don le DNS est chez CloudFlare
certfile: fullchain.pem
keyfile: privkey.pem
challenge: dns
dns:
  provider: dns-cloudflare
  cloudflare_email: [email protected]  # Votre compte Cloudflare
  cloudflare_api_token: vYffF-LzhdhdhdgfhjhjjFGJFDGJJGsfgFGJSgjf

L'add-on DuckDNS

Il s'installe depuis le superviseur et nécessitera la création d'un compte sur www.duckdns.org afin de préparer la configuration. L'avantage de cet add-on c'est qu'il va tenir informé DuckDNS de vos changements d'IP.

lets_encrypt:
  accept_terms: true
  certfile: fullchain.pem
  keyfile: privkey.pem
token: 952ddsfsdf5-b1sfse-43gfsdgsdfg81-10sgsgdsg2e
domains:
  - ha.domain.tld  # Le domaine choisit lors de la création du compte.
aliases: []
seconds: 300

Alternatives

Pourquoi se compliquer la vie ? Il y a qui aiment ça... Vous pouvez donc utiliser un autre service tout autant gratuit, par exemple...

  • La passerelle SSL d'OVH qui va jouer un rôle de reverse proxy également (à condition d'avoir une IP fixe,). Dans ce cas on a la choix localement d'utiliser un certificat auto signé soit pas de SSL.
  • L'intégration CloudFlare qui semble utilisable sans IP fixe. Voir également ici pour utiliser un certificat CloudFlare.

Reverse Proxy

Se protéger avec une reverse proxy est une très bonne idée. On peut bien sur installer en local NGINX (et le configurer...) ou utiliser un reverse proxy existant dans votre infrastructure (Synology, ou HA Proxy dans pfSense par exemple), mais le plus simple est de déléguer la chose à un reverse proxy CDN, je pense bien sur à CloudFlare, en utilisant ou pas leur certificats. Attention toutefois, CloudFlare n'autorise pas tous les ports, et notamment pas le 8123, il va donc falloir ruser, soit utiliser un port externe et un port interne, soit changer le port de Home Assistant.

Que vous utilisiez ou pas un reverse proxy, il faudra vous arranger pour localement outrepasser le reverse ou le port externe de votre routeur. Inutile en effet d'aller faire un tour sur Internet pour utiliser une requête locale. En plus en cas de panne internet ça ne marcherait plus. Pour ça il faut un DNS menteur local, ça peut être un fichier host sur un PC, un DNS local sous Linux ou Windows, mais je vous conseille plutôt d’installer l'excellent add-on AdGuard qui en plus de dépolluer vos pages web fera également ce travail grâce à sa fonction de réécriture DNS. Bien sur dans ce cas il faudra que votre DHCP local pointe sur ce DNS...

Exemple

Ici j'ai configuré de façon à se que l'accès externe passe par le reverse proxy de CloudFlare (sur le port 2096), ce qui protège mes IP, j'ai fait une redirection DNS locale via AdGuard et j'utilise une URL interne sur mon mobile ou mon accès local sur PC.

URL Home Assistant : https://ha.domain.tld:2096 (pour CloudFlare par exemple).

SSID : Mon SSID (c'est sert au client mobile à savoir s'il faut appeler l'URL interne).

URL Interne : https://ha.domain.tld:8123  (ce sera également l'url local depuis un PC.)

N'hésitez pas à commenter si vous avez des questions.

Bureau à distance Windows et imprimantes

En ces temps ou les télétravail s'impose, l'IT doit s'adapter et proposer des solutions à chaque cas. Beaucoup de salariés se sont retrouvés à bosser sur le PC familial au détriment des règles de sécurité les plus élémentaires. Sachant par ailleurs que le télétravail comporte un cadre réglementaire  qui impose la fourniture des équipement nécessaires par l'employeur ainsi qu'un défraiement pour les frais occasionnés.

Au delà de ces considérations, s'il est facile de travailler à distance sur des applications web ou sur des fichiers gérés dans le cloud avec des applications classiques du genre Office, la chose se complexifie dès lors que l'on travaille sur des applications lourdes qui nécessitent une installation spécifiques sur le poste de travail. Je pense ici par exemple à des application de compta ou de paie (Sage pour ne pas les citer, mais ils sont loin d'être les seuls) ou le simple fait de déplacer l'application d'un poste à un autre nécessite l'intervention d'un partenaire agréé pendant plusieurs heures, je ne pense pas trop me tromper en affirmant que la complexité est ici orchestrée dans le seul but de générer du revenu... Un vaste débat, un autre débat que je n'aborderais pas ici ou je vais me contenter de contourner le problème.

Au départ j'avais j'avais naïvement pensé mettre les fichiers de données sur un cloud synchronisé. Impossible car au fil du temps ces solutions reposent souvent sur du SQL même en local. Les éditeurs proposent eux de configurer un serveur, solution coûteuse et surdimensionnée dans les TPE ou il n'y a bien souvent qu'un seul utilisateur. Installer ce genre de solutions sur un laptop que le salarié risque de perdre ou de se faire voler n'est pas non plus une solution.

L'alternative consiste à se servir un d'un logiciel de prise de main à distance, genre TeamViewer ou AnyDesk, ou carrément d'une session RDP (Bureau à distance) qui offre un bien meilleur confort. Reste à s'affranchir de la lenteur possible du poste de travail distant et de sa connectivité pas toujours à la hauteur.

Il existe une alternative plus durable et plus fonctionnelle. Isoler nos logiciels lourds sur un serveur dans une session RDP. L'avantage est que cette session sera accessible par la ou le(s) personne(s) qui en ont besoin, ou qu'elle soient et tout en se basant sur une application mono poste (donc une seule licence et donc une seule utilisation concurrente). Cela permet également à des salariés disposant d'un Mac d'utiliser des applications Windows.

Dans la pratique ce serveur, qui peut être un Windows 10 ou un Windows Serveur, sera de préférence installé dans un espace sécurisé (data center, Azure, AWS, un VPS ou encore un serveur dédié). Sécurisé en terme d'accès, sécurisé physiquement (vol, incendie, etc...), mais également au niveau de sauvegardes.

On a deux choix possibles, soit on installe un Windows 10 Pro, soit un Windows Serveur. L'avantage du Windows Serveur étant qu'il permettra de base une session RDP pour l'administrateur et une autre pour le client. Les coûts ne sont pas identiques. De plus selon la taille de l'entreprise une solution Windows Serveur pourra évoluer avec RDS (et les licences qui vont avec) vers une solution multi-utilisateurs distants.

La pratique

Installer une instance Windows, une VM, sur une infrastructure se fait en quelques clics. Ensuite on crée une session pour le client avec des droits utilisateur, on lui permet l'accès distant et le tour est joué. Il n'y a plus qu'à lancer le client Bureau à distance sur le PC ou le Mac de utilisateur et ça fonctionne, en mode fenêtré ou plein écran selon la taille des on écran. De plus RDP est bien pus confortable au quotidien qu'une prise de main à distance. A partir de là on demande au prestataire Sage (ou autre) de venir y transférer ses logiciels dont lui seul possède le savoir faire nécessaire et le tour est joué.

Sauf que...

Les utilisateurs de ce genre de logiciels génèrent beaucoup d’impressions. C'est prévu, le client Bureau à distance (Windows et Mac, mais pas celui que l'on trouve sur le Windows Store) permet d'utiliser ses imprimantes locales qu'il redirige dans la session RDP. Si dans la pratique si ça peut fonctionner de façon transparente pour quelques imprimantes qui utilisent des pilotes standards fournis par Windows, dans la majorité des cas il faudra installer les pilotes des imprimantes du poste client sur le serveur, (sauf peut être si on installe RDS avec EasyPrint, ça reste à vérifier et je n'ai pas pris cette peine). Hélas il sera impossible d’installer directement certains pilotes sur le serveur, soit leur module d’installation ne peux fonctionner que sur Windows 10, soit parce qu’il nécessitent que l'imprimante soit en ligne. Il va donc falloir ruser un peu pour disposer des pilotes correspondant aux imprimantes de nos clients sur le serveur.

Il existe sous Windows (sauf la version Home) un outil de migration qui va permettre d'exporter les files d'impression d'un client ou serveur et de les réimporter en réinstallant les pilotes et les imprimantes sur la cible. On va donc lancer PrintBrmUi.exe sur le poste des clients et réimporter le fichier obtenu sur le serveur avec le même outil. Cette opération permettra également l’importation de pilotes 32 bits si ce genre de poste client existe toujours...

Attention cet outil n’est pas fait pour ça mais pour migrer des serveurs d’impression… donc il exporte / importe des files d’impression avec les drivers. Il faudra donc prendre soin de ne pas écraser les pilotes existants et ensuite d’aller faire le ménage dans les imprimantes déclarées sur le serveur mais inutiles car seule nous importe la présence des pilotes. Le plus simple étant bien sur de tout faire avec la console printmanagement.msc qui va nous permettre de visualiser les pilotes installés et de retirer les imprimantes inutiles tout en conservant les pilotes.

Sources