Redirection de port sous Linux : 2/2

Dans la partie précédente, en bon béotien, j'ai exploré pas mal de techniques de redirection de port, mais j'aurais du commencer par l'exploitation de ce qui est depuis un certain temps de base sans Linux, à savoir IPTables.

Pour cette manipulation on va utiliser un routeur Ubiquiti ER-X avec la dernière version de EdgeOS (2.0.9-hotfix.2). Et sur ce routeur on va commencer par y installer Wireguard (pour changer un peu, mais Zerotier ou les VPN disponibles de base auraient pu faire l'affaire).

On va se rendre compte que la philosophie de WireGuard est bien différente de Zerotier (ou même de TailScale). Ici il faut tout borner, c'est la version barbus et les ACL ne se gèrent pas sur une console d'admin, il faudra pour ça utiliser le firewall du point d'entrée, ce qui à mon gout est bien moins souple et rend impossible certaines restrictions plus granulaires au niveau de l'utilisateur client...

Je ne suis pas expert, mais contrairement à Zerotier ou le client génère un ID propre à la machine, sous WireGuard un simple copié collé suffit à exporter et utiliser la configuration ailleurs... On peut certes utiliser une clé supplémentaire (PresharedKey), mais ça ne changera rien. Un mot de passe qui se transmet vocalement aurait été préférable. Cela ne sera pas trop gênant dans une configuration fermée (la mienne, un serveur verrouillé vers un routeur qui sera tout autant), par contre dans le cadre de l'utilisation pour un utilisateur lambda itinérant et souvent inconscient cela pose question, tout comme le non support apparent d'une clé physique...

WireGuard coté serveur :

On se connecter en SSH et on installer la dernière version que l'on va trouver ici avec les commandes suivantes :

curl -OL https://github.com/WireGuard/wireguard-vyatta-ubnt/releases/download/1.0.20210606-1/e50-v2-v1.0.20210606-v1.0.20210424.deb
sudo dpkg -i e50-v2-v1.0.20210606-v1.0.20210424.deb

Attention à bien remplacer par la dernière version et faire attention car il existe des versions spécifiques à chaque modèle de routeur et pour chaque version de EdgeOS (v1 et v2).

Si on manque de place (df) on fait un show system image et on efface celle qui ne sert à rien après une mise à jour avec un delete system image. Et oui il y a du vécu.

Quand WireGuard est installé on va générer nos clés :

sudo wg genkey | tee /dev/tty | wg pubkey

Ce qui va nous donner deux clés, la première est la clé privée, la seconde la clé publique.

0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=
KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=

On sauvegarde ces clés au chaud et on passe à la configuration de l'interface CLI propre à EdgeOS (configure, commit, save et exit)

configure

On y associe un subnet privé, un port UDP et la clé privée :

set interfaces wireguard wg0 address 192.168.33.1/24 # Ici on choisit l'IP de notre serveur WireGuard
set interfaces wireguard wg0 listen-port 51833       # Ici le port UDP qu'il conviendra de redirigier si on est pas en Bridge ou DMZ...
set interfaces wireguard wg0 route-allowed-ips true  # Pour sortir de ce subnet....
set interfaces wireguard wg0 private-key 0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=

On va ensuite déclarer les pairs (peers) autorisés en associant notre interface à leur clé publique et une IP autorisée. 

set interfaces wireguard wg0 peer N4cuA0WPkMt+3hfidlemsI/VGcupv96NtrkwA/esf2E= allowed-ips 192.168.33.2/32
set interfaces wireguard wg0 peer u2w/+ZNI2RwbYTdft9yggPGnff8QexY9UjjvdvVf0gM= allowed-ips 192.168.33.3/32

On ajoute une règle sur le firewall (Il est également possible aussi de faire ça depuis l'interface du routeur)

set firewall name WAN_LOCAL rule 20 action accept
set firewall name WAN_LOCAL rule 20 protocol udp
set firewall name WAN_LOCAL rule 20 description 'WireGuard'
set firewall name WAN_LOCAL rule 20 destination port 51833

Et on termine par :

commit
save
exit

Il est bien sur possible de faire ça en plusieurs fois, mais dans ce cas là il ne faudra pas oublier de rentrer dans le CLI propre à EdgeOS (configure, commit, save et exit).

Si je fais un scan des ports coté WAN, je ne dois rien voir le seul port ouvert étant le 51833 en UDP.

WireGuard coté client

Le client peut être sous n'importe quel OS, dans mon cas ce sera Windows et on va faire la configuration manuellement (il y a moyen de préparer des fichiers de configuration à importer pour un déploiement conséquent). Plus haut on a ajouté la clé publique fournie par le client dans les pairs autorisés. Cette clé est propre à chaque tunnel défini coté client. Idem pour la clé privée du client que l'on reporte ci dessous, elle est crée lors de l'ajout d'un tunnel sur le client. Ensuite on renseigne le pair du client, c-a-d le serveur que l'on a créé plus haut, sa clé publique, les IP autorisées pour ce tunnel ainsi que l'IP ou le TLD du serveur.

[Interface]
PrivateKey = IIczTA5sdrdcg4+VQNnudslgnveoR5ZDD3ZyL0ZXonU=
ListenPort = 15092
Address = 192.168.33.2/32

[Peer]
PublicKey = KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=
AllowedIPs = 192.168.33.0/24
Endpoint = 69.69.69.69:51833
PersistentKeepalive = 25

Ensuite on active le tunnel et normalement à ce stade on doit pouvoir faire un ping sur l'IP LAN du routeur distant (notre serveur WireGuard) ainsi que les IP de son subnet pour peu que les routes inverses soient configurées.

Si sous Linux l'activation / désactivation d'un tunnel en CLI coule de source, il m'a fallut un peu chercher pour Windows. Mon but étant de permettre à une application de supervision d'éventuellement réactiver un tunnel cas de défaillance.

Donc pour activer un tunnel,  CMD en mode admin... (-h pour en savoir plus..) :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice "C:\Program Files\WireGuard\Data\Configurations\Nom du Tunnel.conf.dpapi"

Et pour le désactiver :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice "Nom du Tunnel"

Pour information et pour les afficionados, on peut très bien installer un serveur WireGuard sous Windows, les explications sont ici, ce n'est pas officiellement supporté et ça a l'air bien plus compliqué.

Sauf que dans le cas qui me préoccupe je ne peux justement pas disposer des routes inverses pour une question de sécurité chez mon client. La seule IP autorisée sera l'IP LAN du routeur. Il faut donc que les services que je doit joindre me reconnaissent avec cette IP. Et c'ets ici qu'interviennent les IPTables.

IPTables

Pour utiliser les IPTables il n'y a rien à installer car cela fait partie de l'O/S. Ca tombe bien car sur ce routeur la place est limitée. Par contre il faut que l'IP Forwarding soit activé, on peut vérifier avec sysctl net.ipv4.ip_forward qui va nous répondre net.ipv4.ip_forward = 0 ou 1 si c'est activé.

Ensuite, toujours en SSH : 

sudo iptables -F
sudo iptables -F -t nat
sudo echo 1 >| /proc/sys/net/ipv4/ip_forward  # En cas de besoin....
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
sudo iptables -t nat  -A POSTROUTING -j MASQUERADE

Depuis le client on va faire pointer nos requetés sur la première IP de WireGuard à laquelle j'ai associé un serveur web sur 192.168.150.20 et un serveur SMTP sur 192.168.169.22. A noter que si le port de destination est bien sur le port sur lequel répond le service, le port source peut lui être identique ou défini différemment (surtout qu'en 80 on a l'interface du routeur...).

Maintenant, depuis mon client, le serveur web de destination répondra sur http://192.168.33.1:8080 et si je fais un telnet 192.168.33.1 25 j'obtiendrait la mire de mon serveur SMTP. Et ces deux derniers ne verront en IP source que l'IP LAN de mon routeur, donc une IP autorisée.

Mais on ne peut pas tout à fait aller dîner... En effet ces IPTables vont disparaitre  au premier redémarrage !

Persistance

Mon premier réflexe était d'utiliser le paquet iptables-persistent. Sauf que j'ai remarqué, que pour une raison que je n'explique pas, mais qui a certainement sa logique, il est impossible d'ajouter une règle au firewall (tout au moins depuis l'interface du routeur) dès lors que ce paquet est activé. Je vais donc créer un script qui se lancera au démarrage du routeur et que je pourrais désactiver au besoin... (si un barbu passe par la merci de me dire sil y a mieux à faire).

Sous EdgeOS on a un emplacement spécifique pour les scripts devant s'exécuter après le démarrage du routeur et de ses services : /config/scripts/post-config.d

sudo vi /config/scripts/post-config.d/myfwd

Et dans ce fichier on va insérer nos commande  :

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
iptables -t nat -A POSTROUTING -j MASQUERADE

Ensuite on va rendre ce script exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Mais, car il y a toujours un mais. Il se peut que la résolution DNS ne se fasse pas au lancement. Donc si vous devez obtenir l’adresse IP à partir d’un nom de domaine, vous devez utiliser dig que vous obtiendrez avec :

sudo apt-get install dnsutils

Ensuite il faudra modifier légèrement le script...

sudo IP_ADDR=$(dig +short smtp.mondomaine.com| awk 'NR==1') 
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to $IP_ADDR::25

Firewall

Attention : dès lors que l'on ajoute ces IPTables il ne sera plus possible de modifier les règles du firewall depuis l'interface, et comme l'interface qui ne fait que lancer des lignes de CLI, idem en CLI. Afin de pouvoir créer ou modifier des règles il faudra temporairement désactiver ce script et redémarrer. En ce qui me concerne je l'ai fait sauvagement en renommant le répertoire qui le contient :

cd /config/scripts
sudo mv post-config.d post-config.d.off

Pour le reste on laisse par défaut, mais on va tout de même éviter de laisser des ports ouverts. On commence par désactiver le service Ubiquiti Device Discovery qui expose en UDP/TCP le port 10001 :

configure
set service ubnt-discover-server disable
commit ; save 

On pourrait désactiver l'interface GUI et le SSH depuis le WAN. Pour ça il est possible de forcer sur l'IP LAN :

set service gui listen-address 192.168.0.1
set service ssh listen-address 192.168.0.1

Mais en fait ça ne m'intéresse pas car je veux que ce soit accessible également via WireGuad, et comme après avoir installé IPTables on ne peu plus utiliser le firewall intégré on va continuer à se servir d'IPTables pour blinder le port WAN, ici eth4 :

# On commence par tout fermer sur le port WAN
sudo iptables -A INPUT -i eth4 -j DROP
# On accepte le port UDP de Wireguard (à noter qu'il est possible de le restreindre à une IP ou un subnet avec -s)
sudo iptables -I INPUT -i eth4 -p udp --dport 51833 -j ACCEPT
# On une IP spécifique sur les ports 22/80/443
sudo iptables -I INPUT -i eth4 -p tcp -m tcp -s 82.65.19.160 --dports 22,80,443 -j ACCEPT

On ajoute au fichier de configuration cité plus haut et on fait un scan (avec ça par exemple) sur l'IP WAN afin de constater la fermeture effective. Il ne reste que l'ICMP et WireGuard en UDP. Si on souhaite encore renforcer la sécurité on peut aussi restreindre l'ICMP et le port UDP de Wireguard avec des IP sources... Le même scan depuis un client WireGuard continuera à présenter les mêmes ports que l'interface LAN.

Dans le fichier ci dessous j'ai donc mes règles DNAT, ensuite je ferme tout sur sur port WAN (eth4) et j'autorise depuis mon IP publique WG en UDP sur le port 51833, en TCP 22, 80, 443 et enfin l'ICMP pour pouvoir monitorer.

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.69.24:25
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 1430 -j DNAT --to 192.168.69.24:143
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.69.16:8000
iptables -t nat -A POSTROUTING -j MASQUERADE   

iptables -A INPUT -i eth4 -j DROP

iptables -I INPUT -i eth4 -p udp -s MyPublicIP --dport 51833 -j ACCEPT

iptables -I INPUT -i eth4 -p tcp -m multiport -s MyPublicIP --dports 22,80,443 -j ACCEPT

iptables -I INPUT -i eth4 -p icmp -s MyPublicIP -j ACCEPT

Et vu que je ne suis pas un grand fan de VI, le plus simple est de préparer le fichier en local, de l'uploader dans le répertoire utilisateur avec un SFTP graphique, et ensuite de le déplacer dans le répertoire idoine :

sudo mv myfwd /config/scripts/post-config.d/

Et de le rendre exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Et pour vérifier les règles :

sudo iptables -L --line-numbers

Pour en savoir plus sur ces règles c'est ici, et vous allez trouver une petite bible dédiée aux EdgeRouter, et notamment pour tout ce qui concerne leur sécurité.

Voilà !

EDIT 25/09/2021: La bonne nouvelle c'es que Free a ajouté WireGuard dans ses Freebox et que ça fait tout le travail... Quand on a une Freebox bien sûr !

EDIT 04/11/2021: Ajustement du script pour EdgeOS.

EDIT 05/10/2022 : Ajustement IPTables pour le Firewall

Sources

 

Redirection de port sous Linux : 1/2

J'ai depuis quelques temps une problématique à résoudre pour un client : accéder depuis l'extérieur à un sous-réseau, ou tout au moins à certains services, sur un réseau pour lequel je ne peux pas être routé. Pour Microsoft la chose était facile, on installe un serveur PPTP sur le réseau autorisé (routé) et à partir de là tout devient facile. Sauf qu'en 2021 même Microsoft déconseille le PPTP, et pour cause ! Et bien sur il n'est pas question d'exposer ces services sur internet via une simple redirection de ports...

J'ai pensé bien sur à une solution de type SDN (Zerotier, Wireguard ou Tailscale pour faire facile). Tous les 3 vont me permettre de router des réseaux distants, mais ça ne fonctionnera pas car je ne peux pas disposer du routage inverse, donc dans le meilleur des cas je pourrais atteindre le réseau distant. De plus je serais vu comme une adresse source suspecte, l'IP Zerotier par exemple...

Afin qu'elle soit valide sur les sous réseaux distants, il faut que mon adresse source soit une IP autorisée, donc une IP du réseau distant.

L'alternative pourrait être de faire un bridge (niveau 2) à l'entrée du réseau distant. C'est possible (ici par exemple avec Zerotier), mais, comme chacun le sait, l'inconvénient d'un bridge est de laisser transiter beaucoup trop de saloperies, à moins de sérieusement les filtrer. A explorer. Bref j'en était là peu avant minuit en explorant comment me dépatouiller de cette affaire, je suivait une piste TCP PROXY quand je suis tombé sur un site d'un gentil hacker qui expose sa trousse à outils dans laquelle on trouve RineTD. A noter que TCPProxy sous OpenWRT ou UbuProxy sous Ubuntu sont des déclinaisons plus ou moins améliorées et supportant IPV6, permettant même l'encapsulation dans un tunnel IPV6..

RineTD

Dans la pratique RineTD agit plus ou moins comme les redirecteur de ports que l'on trouve sur un classique routeur grand public, sauf qu'ici il est capable de le faire sur une machine Linux. Il peut s'utiliser sur tous les ports, sauf le FTP qui lui demande des sockets sur les ports différents. Il présente cependant un défaut qui pour moi devient une qualité : l'adresse source sera toujours l'IP LAN de la machine sur laquelle il est installée. Et c'est justement ce que je souhaite.

On part du principe que Zerotier est configuré et on installe :

sudo apt-get install rinetd

Et ensuite on va éditer le fichier de configuration : 

sudo nano /etc/rinetd.conf
#localip localport remoteip remoteport

0.0.0.0      80  192.168.1.90  8080  # Ecoute sur toutes les IP sur le port 80 et redirection vers 192.168.1.90 sur le port 8080
10.146.50.50 25  192.168.1.50  25    # Ecoute sur toutes l'IP 10.146.50.50 sur le port 25 et redirection vers 192.168.1.50 sur le port 25

logfile /var/log/rinetd.log          # Le fichier de log...

allow IP                             # Ici on gère les IP source autorisée à utiliser le service...
deny 192.168.2.15
allow 10.146.50.*

Et il faudra relancer le service à chaque changement de configuration :

sudo /etc/init.d/rinetd restart

Et c'est tout !

Maintenant si depuis la machine 10.146.50.10 de mon réseau Zerotier je fais un telnet 10.146.50.50 25 je vais tomber sur le serveur SMTP qui se trouve en 192.168.1.50 et lui me verra comme étant 192.168.100.50 qui est l'IP LAN de la machine sur laquelle tourne RineTD.

TCP Proxy sous OpenWRT

Bon, maintenant j'aimerais bien faire la même chose sur OpenWRT. Ici ce qui m'intéresse c'est de faire tourner ça sur un micro routeur, le GL-MT300N car avec sa taille proche d'une boite d'allumettes pour une vingtaine d'€uros on va pouvoir le caser l'importe ou...

On le mets donc à jour dans sa dernière version et on commence par lui installer Zerotier en SSH :

opkg update
opkg install zerotier

Ensuite on édite le fichier de configuration idoine avec vi. (Confidence, je crois que c'est ma première avec VI ! ESC + :wq! pour sauvegarder et ESC + :q! pour juste quitter...)

vi /etc/config/zerotier
# cat /etc/config/zerotier
config zerotier 'sample_config'
    option enabled '1'
    list join 'd5e5fb6537869a7d'  # Que l'on remplace par son ID Zerotier

On passe ensuite à la configuration du firewall si on veut accéder au LAN

vi /etc/config/firewall

Et on ajoute :

config zone 'vpn_zone'
    option name 'zerotier'
    option input 'ACCEPT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option device 'zt+'
    option masq '1'
    option mtu_fix '1'

config forwarding
    option dest 'zerotier'
    option src 'lan'

config forwarding
    option dest 'lan'
    option src 'zerotier'

Et on redémarre tout ça avec :

/etc/init.d/zerotier restart
/etc/init.d/firewall restart

Normalement à ce stade on doit pouvoir pinguer l'IP Zerotier et LAN du routeur depuis puis un client distant.

On passe donc à l'installation de TCPProxy :

opkg install tcpproxy

 Ensuite on édite sa configuration

vi /etc/config/tcpproxy
config listen
  option disabled 0                    # 1 ou 0 pour activer ce port car il peut y en avoir plusieurs
  option local_port '9000'             # Le port d'écoute
  option resolv 'ipv4'                 # Ca peut aussi travailler en IPV6...
  option remote_addr '192.168.210.16'  # L'IP du serveur distant
  option remote_port '8000'            # Son port
  option local_addr '10.147.80.48'     # L'IP locale sur laquelle on écoute​
Et bien sur on redémarre le service :
/etc/init.d/tcpproxy restart

Pour mon test j'ai installé un mini serveur web afin de valider l'adresse source, donc http://10.147.80.48:9000 et quand je vais dans son log je constate que l'IP source est bien 192.168.210.48 qui est l'IP LAN de mon micro routeur.

Alternative

Vous avez noté que je suis toujours passé par Zerotier, par habitude surement. Mais on peu aussi passer par WireGuard qui est de base installé sur ces micro routeurs.

Du coup j'ai acheté un autre micro routeur, le GL-AR300M qui lui est noir et un peu plus puissant. L'interface permet de configurer le serveur WireGuard et de générer la configuration du client qu'il suffira de copier sur le poste distant :

[Interface]
Address = 10.0.0.2/32
ListenPort = 13925
PrivateKey = +LsVmc6LVmdjfggmjgfmjùsgsdkfg3+A0hNncpxcHw=
DNS = 64.6.64.6

[Peer]
AllowedIPs = 192.168.10.0/0, 10.0.0.1/32  # Ici les réseaux que je vais router sur le client
Endpoint = 69.69.69.69:51820
PersistentKeepalive = 25
PublicKey = yeNCdjgfùsjdfùgjùfj*gsd*fgklsfkgsfdg k807pxs6iidhM=

Pour mon usage je pourrais me contenter de renseigner uniquement 10.0.0.1/32 dans AllowedIPs puisque TCPProxy prendra le relais...

Débit

GL-iNet nous assure qu'il est possible de soutenir 50 Mbps avec WireGuard en opposition aux 15 Mbps possibles avec OpenVPN.

Bonus

  • Si votre routeur de test n'est pas en en bridge ou en DMZ, pensez à rediriger vers lui le port UDP idoine pour Zerotier ou WireGuard.
  • Curieusement sur ces micro routeurs le serveur DHCP n'est pas facilement désactivable depuis l'interface, et dans mes bricolages j'ai déjà un serveur DHCP et je ne voudrais pas que celui ci interfère. On doit pouvoir faire ça en éditant /etc/config/dhcp, mais on peu également dans les options avancées installer LUCI, éditer l'interface LAN et lui dire d'ignorer le DHCP sur cette interface.
  • Ce n'était pas mon besoin, mais ces micro routeurs peuvent également êtres configurés en client VPN (WireGuard ou OpenVPN), en client Tor, voire même en répéteur WI-FI très pratique quand on est à l'hôtel avec une seule connexion possible. Dans ce dernier cas il vaut mieux également combiner avec le client VPN...
  • J'ai fait ces manips sur ces routeurs, mais n'importe quel Linux fera tourner WireGuard, une petit tuto ici ou en site to site ici.

Voilà !

Les barbus vont surement trouver à redire et me proposer une autre façon de faire et je serais curieux de qu'ils vont me proposer. En attendant je suis content de moi et ma pauvre culture Windows...

Il semblerait que Rinetd comporte une limitation du nombre de connexions. Il existe également Socat, plus de connexion, mais plus de RAM, ou en encore Redir qui semble moins gourmand. Et bien sur pour un usage plus conséquent il ne faut oublier HAProxy qui est surtout un équilibreur de charge http, https et TCP, mais peut être utilisé pour transférer le trafic Tcp uniquement en utilisant légèrement le processeur et la RAM. Mais HAProxy vous ne l'installerez pas sur un petit routeur...

Mais il existe une autre voie : IpTables ! Son utilisation ne consomme pas de CPU et très peu de RAM, et surtout ça fait partie du système d’exploitation ! Ce sera l'objet du prochain article...

Idées...

On l'a vu ces petits routeurs sont très discrets. Pour mes tests ils sont configurés avec deux interfaces LAN et WAN, LAN et WAN pouvant très bien être WLAN et WWAN... Mais prenons un autre cas de figure, vous devez accéder à un réseau de façon discrète (discrète mais autorisée, je vous rappelle que ce genre de délit relève du pénal et est passible de la case prison). Bref, par exemple le responsable d'une entreprise cliente vous demande (demande écrite pour vous couvrir) une telle solution à l'insu de son service informatique, vous préconfigurez un tel routeur en client DHCP sur le LAN et en serveur Wireguard et le tour est joué. Accès possible au LAN, voire plus via TCPProxy. Et bien sur l'administration du routeur en web et ssh reste possible via le client Wireguard...

 

 

Unifi UDM Pro, ZT, encore...

Longtemps j'ai disposé de deux lignes vDSL à 90 MB en étant proche du DSLAM. Il y avait un peu de bricolage, la Freebox en bridge sur le WAN1 de l'UDMP et Nerim en NAT entre le WAN2 (secours) de l'UDM Pro et vie le LAN sur un subnet différent sur MPTCP et OTB. Je sais, pas très propre, mais c'est juste un labo... Et c'est pourquoi on va optimiser un peu, d'autant plus qu'entre temps je me retrouve avec une fibre SFR et ma Freebox Révolution migrée elle aussi en fibre.

Versions utilisées, relativement stable par rapport à ces derniers mois :

  • UDMP : 1.10.0
  • Network : 6.4.47

Swap des ports WAN de l'UDM Pro

Avec l'idée migrer la Freebox Révolution vers une Delta S afin de profiter d'un lien à 8 GB, j'ai commencé par swapper la logique des deux ports Wan de l'UDMP. De base le port 9 en 1 GB (RJ45) correspond à WAN1 et le port 10 en 10 GB (SFP+) à WAN2. On peut se demander ou est leur logique tant il est évident que le lien principal sera plus performant que le lien de secours. Depuis je ne sais plus quelle beta il est possible d'inverser cette logique, mais attention il reste un bug de taille, le nom du provider (probablement lié à l'ASN) ne sera pas mis à jour et on reste avec ceux de base, et ça peut être déroutant. Comme on le voit ci dessous le port WAN1 avec la Freebox remonte OwCloud (anciennement Nerim racheté par BT), alors que le WAN2 est maintenant branché sur du SFR...). Ce bug est connu, mais comme d'autres il ne semble pas être dans les priorités des équipes Unifi qui préfèrent surement se concentrer sur une nouvelle version de l'interface...

Passer mon mélange de subnets en VLAN

C'est logique, il faut juste trouver un peu de temps. Et on va voir que du temps j'en ai perdu.

Pour créer un VLAN sur Unifi c'est dans l'absolu très simple. On crée un nouveau réseau et dans les paramètres avancés on choisit un VLAN ID et éventuellement le subnet et le mode DHCP, mais on peut faire sans et dans certains cas laisser faire l'Auto Scale Network. Ensuite on associe ce réseau à un port du switch. Sauf que j'ai passé des heures à chercher à faire compliqué car ça ne fonctionnait pas. Et finalement je me suis résolut à un reboot et là ça passe tout seul. Allez donc savoir...

Dans mon cas je voulait un VLAN sur un subnet particulier avec DHCP. Mon objectif étant d'y coller la box SFR qui sera branchée sur le WAN2 et sur ce VLAN et ainsi sera utilisable par mon fils pour ses jeux qui disposera ainsi d'une fibre rien que pour lui et sans aucune restrictions (il est grand !) et sans venir perturber la QoS du réseau principal, même si l'impact sera moindre via que fibre qu'il ne l'était en xDSL.

Sur le subnet de ce VLAN, la passerelle par défaut est donc la box SFR, comme c'est le cas sur le WAN2 de l'UDM. Les deux usages cohabitent, et la box de secours sert à quelque chose...

On peu ensuite créer un réseau WI-FI sur ce VLAN ou taguer des ports sur les switch (port profile) pour qu'ils l'utilisent.

On verra plus tard comment créer un VLAN dédié à l'IoT et surtout comment ouvrir ou bloquer le trafic entre les VLAN.

UPnP mon amour !

Toute cette partie fonctionnelle, je me suis aperçu que mon routeur VPN/SDN Zerotier (un Linux dans une VM) avait un peu de mal à sortir. Dans la configuration précédente il sortait en NAT via ma ligne de secours. Dans ma nouvelle configuration il doit sortir via l'UDMP, et le vas échéant profiter du secours. Curieusement j'ai remarqué que le passage en mode secours était lent et qu'au retour certaine destinations n'étaient pas joignables, bizzarement celles situées sur le réseau Free, Online Sacaleway pour être précis, alors que d'autres distants passaient. Et c'est critique.

On lance la commande :

root@zt:~# zerotier-cli peers

Et l'on obtient la liste des clients distants :

1d20dgr3f3 1.6.5  LEAF      -1 RELAY
2533gtdaef 1.6.5  LEAF      -1 RELAY
338fgte636 1.4.6  LEAF      13 DIRECT 7131     2944

Si DIRECT veut dire que tout va bien, RELAY indique que le distant est injoignable directement, que le trafic va transiter par les serveurs Zerotier. Et que quand le trafic passe, ce qui n'est pas toujours le cas, cela va induire une latence aléatoirement plus importante, au minimum 35 ms. là ou en direct on passera à 12 ms. Et justement, au delà de remplir les poches des Telcos, l'un des objectifs de la fibre est de réduire la latence (même si avec le l'IPV4 encapsulée dans de l'IPV6 on en perd un peu, mais c'est un autre problème et il faudra se pencher sur du full IPV6).

Après moultes recherches j'ai trouvé que 

  1. Que l'UDMP bloquait peut être certains ports en sortie, même si on désactive toute la partie sécurité et que tout est autorisé sur le firewall (pas clair !)
  2. Qu'il est possible de configurer des ports UDP secondaires sur un client (en plus du port UDP natif 9993.

On commence donc par configurer un port secondaire (on ne touche surtout pas au primary (voir ce fil vers la fin) sur le client qui me sert de routeur ZT en créant un fichier local.conf dans le bon répertoire (détails ici) :

{
  "settings": {
    "secondaryPort": 21234
  }
}

Mais visiblement ça ne suffit pas et il va falloir activer l'UPnP pour que tout passe en direct avec un minimum de latence :

Je ne suis pas fan de l'UPnP/NAT-PMP car ce protocole d'automatisation ouvre par définition les ports à la demandes des applications. Applications qui sur un réseau peuvent êtres malveillantes. Pourtant à la maison ce service est très utilisé et quasiment indispensable. Par contre hors de question d'utiliser cette méthode en entreprise ou une règle WAN_LOCAL avec la destination UDP 9993 devrait faire l'affaire (pas clair et à creuser). (ici pour pfsense avec ACL en prime, ce qui va aider en entreprise).

ZT Failover ?

Alors là on rentre dans le coté obscur. Tant qu'à avoir deux fibres autant qu'elles servent à quelque chose. Visiblement l'UPnP de l'UDM Pro est archi buggé. Je me suis donc dit que j'allais faire le failover directement dans le routeur Zerotier. J'ai donc ajouté une carte réseau virtuelle à ma VM ZT qui me sert au routage Lan to Lan (ici et pour monter ça) sur le VLAN 110 qui correspond à la box SFR. Les deux interfaces ont une passerelle par défaut avec le même poids. 

Ensuite on édite le fichier local.conf et on ajoute et on ajoute ces paramètres : 

{
  "settings":
  {
    "defaultBondingPolicy": "active-backup",
    "peerSpecificBonds":
    {
      "f6dd3a2db3":"active-backup",
      "1d20ff53f3":"balance-xor",
      "a92cbsd6fa":"broadcast"
    }
  }
}

Pour comprendre les différentes possibilités on ne trouve pas beaucoup d'information si ce ne sont deux docs officielles ici et ! A croire que ce sujet intéresse peu. Attention, j'ai eu pas mal de difficultés en éditant avec Nano ce fichier avec un copié / collé. Peut être une question de formatage qui m'aurait échappé. Par contre je n'ai pas réussit à associer dans ces paramètres le port secondaire.

Toujours est-il que si je débranche un interface l'autre prend le relais en mode active-backup avec une légère interruption que quelque secondes ou encore plus rapidement en mode broadcast. Mais ce dernier mode semble déconseillé car il génère pas mal de garbage...

Design

Si j'étais un cador en Visio ou d'autres outils en ligne comme draw.io ou autres, je pourrais vous faire un joli dessin, mais ce n'est pas le cas. Donc :

  • WAN1 : Freebox en mode bridge (je voulais tester la Freebox Pro mais elle n'a pas ce mode).
  • WAN2: Secours en NAT sur une box SFR. NAT également accessible sur les ports tagués en VLAN 110 sur un subnet dédié et isolé. Cela permet à mon fils de jouer et faire ses bricolages sans impact sur la sécurité du LAN principal.
  • VPN vers les sites distants accessible depuis le LAN principal. On verra plus tard comment profiter des fonctionnalités Multipath / Bonding de Zerotier qui vont nous permettre d'utiliser le lien de secours sans passer par celui de l'UDM.

Vieilleries...

Et dans tout ça que devient mon installation openMPTCP ? L'objectif de cette installation était d'agréger plusieurs lignes afin de fiabiliser et d'augmenter le débit disponible. Si la question du débit se pose en en xDSL elle ne se pose plus avec une fibre. Quant à la fiabilité il faudrait pour que ça ait du sens disposer d'un VPS puissant avec un lien 10 GB. Et encore on aurait malgré tout une latence dégradée. 

Mais je vais tout de même tenter la chose pour le sport. Pour ca il faut que je crée sur mon ESXi une nouvelle interface sur le VLAN 110 afin d'accéder au NAT de la ligne de secours et éventuellement le modem 4G. L'objectif n'est pas la performance, je ne toucherait donc rien coté VPS, mais juste d'éviter le lag qui se produit quand l'UDMP passe sur le lien de secours. Mais ça reste très rare et je ne sais pas si le jeu en vaut la chandelle. Peyt être pour l'IoT.

 

 

TailScale, VPN/SDN simplifié

Avant, il y avait les VPN (PPTP, IPSec, OpenVPN, etc...) qui ne sont pas toujours très simple à implémenter. Et puis arrivent les SDN, qui dans l'absolu sont des VPN, orientés réseaux étendus et très simples à mettre en œuvre. D'aucun le savent, je sus un fan de Zerotier que j'utilise au quotidien, tant pour interconnecter 4 sites à la place d'IPSec, que pour des machines distantes ou quand je suis en déplacement.

Entre temps les barbus nous ont beaucoup parlé de Wireguard, qui peu ou prou fait la même chose en un peu plus compliqué avec de soit disant meilleures performances. Et puis arrive TailScale qui lui est basé sur Wireguard et lui apporte la simplicité. Une sorte de Wireguard pour les nuls, enfin, pas que, car TailScale apporte à WireGuard la notion d'annuaire qui lui manque (WG-Dynamic en cours de dev.). Comme pour Zerotier, au delà d'un certain nombre de nodes il faudra passer à la caisse, mais les tarifs sont comparables, tout comme les possibilités offertes par la version gratuite suffisante pour un usage home.

Comme pour Zerotier, il est possible :

  1. D'accéder depuis internet à une machine particulière avec un client dédié (MacOS, Windows, Linux, IOS, Android).
  2. D'accéder depuis internet à un sous réseau dès lors que l'on installe un node Linux qui servira de routeur
  3. D'accéder depuis internet à internet de façon sécurisée en passant par un node Linux installé en mode Exit-Node, chez vous ou sur un VPS.
  4. D'accéder depuis chez vous à d'autres sous réseaux, bon là c'est plus compliqué et il faudra passer à la caisse et avantage à Zerotier (ou Wireguard, mais je n'ai pas testé).

Le gros avantage de Zerotier est que l'on travaille en Layer-2 sur un subnet dédié avec la possibilité de figer des IP là ou TailScale affecte des IP aléatoires et travaille en Layer-3. Mais les deux peuvent cohabiter, et ça peut être intéressant dans certains cas. Vous trouverez ici un comparatif des deux solutions.

Ce qui est certain, c'est que si moi j'y trouve des limitations, TailScale a pour lui une simplicité qui en fera un bon choix pour ceux qui débutent et veulent juste un usage limité. On va donc se consacrer aux trois premiers points d'usage.

Accéder depuis internet à une machine distante

Je ne vais pas vous expliquer comment créer un compte (il suffit d'aller sur leur site), ou comment se faire coucou entre deux machines clic clic (MacOS, Windows, IOS ou Android), il suffit de lancer l'installation et de faire un ping. Par contre je vais le faire pour la machine Linux qui nous servira dans les deux cas qui suivent.

On part du principe que la machine existe dans sa config minimale et qu'elle communique avec Internet. On en fait un client Tailsacle, ça se passe ici et c'est un peu différent selon les distributions. J'utilise Ubuntu et on commence par ajouter les clés et le repository :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add -
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list

On fait les mise à jour et on installe :

sudo apt-get update
sudo apt-get install tailscale

On lance le client et on copie l'url pour l'autoriser :

sudo tailscale up

Et voici notre IP :

ip addr show tailscale0

A ce stade si on a un autre client TailScale on peu faire un ping... A noter que sur la console d'admin on va pouvoir définir si la clé expire ou pas...

Si votre but est d'accéder à Home Assistant, il existe un addon qui fera le travail pour vous.

Accéder depuis internet à un sous réseau

Afin de ne pas devoir installer TailScale sur toutes vos machines, et surtout accéder à celle ou il n'est pas possible de l'installer (IoT par exemple), on va installer une machine en mode routeur. Pour l'instant ce n'est faisable que sous Linux, avec un petit RPI ou une VM par exemple... On continue sur la même machine.

Première chose on active l'IP Forwarding :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Ensuite on active le routage du subnet :

sudo tailscale up --advertise-routes=192.168.210.0/24

Et pour terminer on va dans la console d'admin indiquer que cette machine servira de routeur pour ce subnet (sous réseau) (les ... au bout de la ligne) :

A partir de là un client TailScale pourra accéder à ce sous réseau.

Accéder depuis internet à internet de façon sécurisée

Quand vous vous connectez en WI-FI sur un hotspot public tout le monde vous dira que ce n'est pas très sécure et qu'il faut utiliser un VPN. Ici plutôt que de payer pour un VPN on va utiliser notre propre connexion, à la maison, ou encore dans un VPS. Pour ça on ajoute la fonction Exit-Node à notre machine :

sudo tailscale up --advertise-exit-node

Et on la configure de facon idoine au même endroit

Ensuite dans le client on choisit l'option Exit-Node afin que tout le trafic transite par notre nouveau point de sortie.

A noter que si l'on veut combiner les deux fonctions, subnet + Exit-Node la commande sera plutôt celle ci :

 sudo tailscale up --advertise-routes=192.168.210.0/24 --advertise-exit-node --reset

Voilà, c'est pas plus compliqué, c'est gratuit et c'est sur. En parlant de gratuit sachez que Free a démarré une beta afin d'intégrer Wireguard dans les Freebox et que Wireguard tout comme Zerotier peut être intégré dans certains routeurs (Unifi, Asus, etc...) ce qui vous évitera la petite machine Linux. Mais ce n'est pas forcément aussi simple.

EDIT 03/03/2025

Si l'on souhaite que les hosts de destination ne voient pas l'IP du routeur de destination comme source mais bien l'IP source originale on ajoutera : 

--snat-subnet-routes=false

Mais dans ce cas, et sur certaines versions de Linux (en cours d'investigation) l'exit-node ne fonctionne plus, on ajoutera alors cette règle qu'il faudra rendre persistante :

iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -o eth0 -j MASQUERADE       # remplacer le nom de l'interface

Contrairement à Zerotier on ne peut pas faire coexister plusieurs réseaux Tailscale sur un même routeur. Il faudra si on veut le faire disposer de plusieurs routeurs locaux (et les routes qui vont avec) si on veut joindre plusieurs réseaux Tailscale. Mais dans ce ca il faut renommer les IP TS de chaque réseau en opposition au subnet TS d'origine qui est 100.64.0.0/10, par exemple :

  • Réseau Tailscale 1 : 100.100.0.0/16
  • Réseau Tailscale 1 : 100.120.0.0/16

Sources :

 

Home Assistant & Hygrostat

Longtemps j'ai utilisé l'intégration custom Hygrostat pour forcer la VMC lorsque quelqu'un prend une douche. C'est un détournement en ce sens qu'un hygrostat est plutôt fait pour fonctionner de façon contestante, comme par exemple dans une cave à vin. 

La dernière version de Home Assistant (2021-08) apporte dans son lot de nouveautés un hygrostat intégré. J'ai donc naturellement voulut l'utiliser. Mais celui ci, bien que plous évolué, ne me semble pas fait pour travailler sur un écart rapide d'humidité. Hors le niveau d'humidité dans une maison varie en fonction des saisons et de la la météo. Donc, à moins de l'ajuster manuellement tous les jours, si je règle la consigne sur une valeur arbitraire, le résultat sera aléatoire.

Mon idée, il y a surement d'autres façons de faire, est de calculer la moyenne de la valeur humidité sur les 8 heures passées et d'ajuster dynamiquement la consigne de mon hygrostat toutes les heures (ces deux valeurs restent à affiner).

Mise en œuvre

On commence par déclarer l'intégration dans le fichier de configuration (attention à bien supprimer le custom hygrostat si vous l'utilisiez avant car il a le même nom) :

generic_hygrostat:
  - name: "Hygrostat : SdB"
    humidifier: switch.ipx800_7_vmc
    target_sensor: sensor.rpi_mi_h_sdb
    min_humidity: 20
    max_humidity: 80
    target_humidity: 67
    dry_tolerance: 3
    wet_tolerance: 0
    device_class: "dehumidifier"
    min_cycle_duration:
      seconds: 5
    keep_alive:
      minutes: 3
    initial_state: true
    away_humidity: 35
    away_fixed: True
    sensor_stale_duration: 00:15:00

Pour les détails de sa configuration ça se passe ici.

Je ne me suis pas vraiment intéressé aux autres valeurs possibles, mais dans notre cas on veut déshumidifier, donc attention du device class...

Ensuite je vais utiliser l'intégration Statistics afin de calculer la moyenne du taux d'humidité de la salle de bain durant les 8 dernières heures :

    - platform: statistics
      name: 'Humidité Salle de Bain (moyenne)'
      entity_id: sensor.rpi_mi_h_sdb
      sampling_size: 700     
      max_age:
        hours: 8

Et pour terminer je vais créer une petite automation qui va ajuster la consigne en fonction de cette moyenne en ajoutant + 10 :de façon à ce que la VMC se mette en route si l'humidité monte lors d'une douche :

- alias: '000 : Set Hygrostat'
  trigger:
  - platform: time_pattern
    hours: '1'
  action:
  - service: humidifier.set_humidity
    target:
      entity_id: humidifier.hygrostat_sdb
    data_template:
      humidity: "{{ states('sensor.humidite_salle_de_bain_moyenne') | float + 10 }}"

Il ne reste plus qu'à tester... Et surement à affiner les valeurs.

Alternatives

L'objectif étant de forcer la VMC lors d'une douche il y a d'autres alternatives à explorer :

  • Détecter si quelqu'un prend une douche : ça pourrait se faire en détectant le débit de l'eau... un peu compliqué ! Ou encore avec un détecteur de présence dans la cabine de douche. A creuser.
  • Par un scénario : en hiver quand je dis à Alexa que j'ai l'intention d'aller me doucher, elle lance un script qui va lancer une play list sur Sonos et un radiateur soufflant, ensuite elle me dit (c'est bien la seule à répondre à touys mes souhaits !) quand la température est idéale pour me doucher. Je pourrait inclure la VMC.

Enjoy !

PS : idées et corrections bienvenues...

 

Renommer les dossiers et raccourcis OneDrive

OneDrive de Microsoft, tant en mode Business que grand public est maintenait à peu près à maturité et dans la plupart des cas utilisable, même s'il reste quelques bugs et bizarreries. Par contre il y a des cas de figure, certes pas très courants, qui ne sont pas pris en charge et vont dérouter l'utilisateur final dans le cas d'usage ou l'on installe plusieurs instances.

Si on installe deux instances sur deux tenant différents (on peut travailler pour plusieurs employeurs...), pas de problème et on va se retrouver avec deux répertoires dans le dossier utilisateur et deux raccourcis dans l'explorateur, en fait trois car il y a aussi le dossier OneDrive grand public dont on parlera plus loin :

  • OneDrive
  • OneDrive - Société Truc
  • OneDrive - Société Machin

Vous allez me dire, ou est le problème ? Jusqu'ici aucun. Par contre imaginons maintenant que notre utilisateur ait besoin de synchroniser deux instances sur le même tenant, donc la même entreprise, une assistante qui synchronise le drive de son manager, ou deux filiales qui partagent le même tenant, le cas d'usage n'est finalement pas si rare, et là c'est le bug car on se retrouve avec ça tant sur les répertoires que sur les raccourcis sur l'explorateur de fichiers :

  • OneDrive
  • OneDrive - Société Truc
  • OneDrive - Société Truc(1)

Microsoft vous répondra qu'il n'y a pas de bug et que ça fonctionne très bien, et c'est vrai. Sauf qu'à l'usage, bonjour la confusion. Microsoft vous dira également que ce n'est pas une bonne pratique et qu'il existe des partages de groupe, et ils auront raison. Mais la demande ici était précise et l'utilisateur voulait vraiment synchroniser deux deux instances vraiment séparées sur le même tenant, et vu que le client est roi, et surtout qu'il me fait manger, je vais répondre à sa demande plutôt que de lui expliquer les bonnes manières (je laisse cette tache à Microsoft). Et comme rien n'est prévu pour ce cas d'usage, je vais vous expliquer comment j'ai contourné.

Attention, ces manipulations ne sont pas sans risques, vous savez ce que vous faites et vous assumez vos responsabilités. Dans le cas contraire allez jouer dans le bac à sable. En tous cas ne venez pas pleurer.

Je part du principe que mes deux instances OneDrive sont configurées et actives.

  1. On quitte les deux clients OneDrive (icones bleus en bas à droite) et on s'assure que ça ne tourne plus dans le gestionnaire de taches.
  2. On renomme le dosser OneDrive concerné : OneDrive - Société Truc(1) par OneDrive - Société Truc Services.
  3. En option on peut aussi déplacer ce dossier sur un autre disque (local et pas de disque externe en USB, hein !)
  4. On lance regedit.exe et soit on cherche Société Truc(1), soit plus proprement on va modifier cette chaine dans les clés suivantes :

    Dans HKEY_CURRENT_USER (HKCU) (4 entrées)

    HKCU\Software\Microsoft\OneDrive\Accounts\Business2\UserFolder & DisplayName
    HKCU\Software\Microsoft\OneDrive\Accounts\Business2\ScopeIdToMountPointPathCache\(ID)
    HKCU\Software\Microsoft\OneDrive\Accounts\Business2\Tenants\(name)\(path)
    HKCU\Software\SyncEngines\Providers\OneDrive\(ID)\MountPoint

    Dans HKEY_LOCAL_MACHINE (HKLM) (2 entrée, mais je n'ai rien trouvé dans la première)

    HKLM\SOFTWARE\Microsoft\Security Center\Provider\CBP\(ID)\NAMESPACE
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager\OneDrive!(ID)\UserSyncRoots\(SID)
    Il faut un peu tâtonner et ne pas perdre de vue que l'on cherche à remplacer Société Truc(1) par Société Truc Services (la partie après de Onedrive - "(on fait attention aux espaces et aux tirets, quant à l'accent je n'ai pas testé mais ça devrait le faire).

  5. Ensuite on ouvre l'emplacement suivant : %UserProfile%\AppData\Local\Microsoft\OneDrive\settings\Business1
    On y trouve un fichier (ID).ini dans lequel on cherche la ligne commençant par LibraryScope, la première en général, et on change Société Truc(1) par Société Truc Services et on enregistre.
  6. On relance OneDrive et tout devrait bien se passer et on doit retrouver les fichiers dans le bon répertoire et les raccourcis avec les bons noms.
  • OneDrive
  • OneDrive - Société Truc
  • OneDrive - Société Truc Services

Si on n'obtient pas le résultat espéré on va redémarrer (comme souvent sous Windows) et si toujours pas on revient dans regedit.exe et on cherche les entrée Société Truc(1) que l'on aurait pu oublier.

Attention, danger : dans l'admin de Microsoft 365 il est possible de renommer le nom de société et je crois depuis peu (??) le nom OneDrive ailleurs. Ce renommage est à considérer au tout début car si on le fait plus tard ça impactera tous les client OneDrive et SharePoint qui risquent de perdre leurs petits et générer pas mal de support....

Bonus

Comme vous avez pu le remarquer le raccourcis OneDrive (Grand public) est toujours présent dans l'explorateur de fichiers alors qu'il ne sert à rien et prête à confusion en entreprise.

Pour supprimer l'icône OneDrive - Personne dans l'explorateur de fichiers, voici comment faire :

  1. Lancez regedit.exe et accédez à l'emplacement suivant : hkey_current_user\software\microsoft\windows\currentversion\explorer\desktop\namespace
  2. Recherchez la sous-clé pour OneDrive personnel. Habituellement, il s'agit généralement de {018D5C66-4533-4307-9B53-224DE2ED1FE6}. Mais ça peut être différent).
  3. Accédez à l'emplacement suivant : hkey_classes_root\clsid et recherchez la clé qui correspond à OneDrive personnelle que vous avez trouvé à l'étape précédente.
  4. Dans la sous-clé system.ispinnedtonamespacetree, modifiez la date de valeur de 1 à 0.
  5. Enregistrez la modification et relancez l'explorateur de fichier. L'icone de raccourcis OneDrive à du disparaitre, sans on tue les tache explorer dans le gestionnaire de fichier et on le relance...

Enjoy ;-)

Faites vous entendre

Tout come lors des élections, ne vous abstenez pas et allez voter sur UserVoice pour que tous ces bricolages se fassent en un seul clic :

Sources

 

 

Home Assistant, Zigbee, encore...

Alors, comment dire, dans la série jamais content, le Zigbee... Aujourd'hui ce protocole dispose d'une multitude d'approches plus ou moins simples à mette en œuvre, on résume :

  • Deconz / Phoscon : l'ancêtre toujours vaillant avec les clés Combee I et II ou le module RPI. Ca fonctionne, mais le développement est lent les nouveaux appareils tardent à êtres intégrés. De plus ça nécessite un addon et une intégration, le tout étant moyennement bien intégré. C'est ce qui assure la grande majorité de mes objets Zigbee depuis le début, d'abbord Sous Jeedom et ensuite sous Home Assistant.
  • ZHA (Zigbee Home Automation) : Totalement intégré à Home Assistant c'est la voie la plus simple qui supporte la majorité des clés du marché. Rien à redire, presque trop simple...
  • Zigbee2MQTT : La voie royale de geeks en tout genre, MQTT est à la mode, ce protocole est certes génial, mais franchement si vous débutez en domotique il est tout à fait possible de s'en passer en passant par ZHA.
  • Les passerelles des marques (Xiaomi, Ikea, Hue, etc...) : ça peut faire le job, mais ça restera lié aux équipement de la marque.
  • Les passerelles sous Tasmota, comme la Sonoof : pas testé, donc par essence ça me parait complexe et vaut mieux avoir un pote barbu habile du fer à souder. Idem pour la fameuse SLS dont certains ont du entendre parler.

Si la première des solutions (Deconz) fonctionne exclusivement avec la clé de la marque, ZHA et Zigbee2MQTT savent fonctionner avec toutes les clés disponibles. A commencer par la peu couteuse mais pas très performante cc2531. C'est pas cher et c'est une bonne option pour se faire la main, mais on se rendra rapidement compte que ça manque parfois de réactivité, une faiblesse qui ne sera pas gênante sur des sondes de température, mais qui le deviendra sur des interrupteurs, ou pire des variateurs. On va donc chercher à gagner du temps en explorant d'autres options.

Je vais explorer deux options en utilisant Zigbee2MQTT, mais j'aurais pu faire la même chose avec ZHA si j'avais voulut faire simple.

Clé USB à base de cc2652P

Si on commence à en trouver sur le net, il se trouve que j'ai un pote habile de ses mains qui sait souder et cherche à gagner sa vie en intégrant cette clé. Je lui ai donc acheté une des premières productions il il y a quelques semaines et je l'ai faite fonctionner sous Zigbee2MQTT en replacement de la cc2532.

J'ai un peu galéré sur la config à changer (pan_id) et surtout on passe en Zigbee 3.0 et le ré appairage des équipements est obligatoire, au final surtout fastidieux.

  serial:
  port: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
advanced:
  rtscts: false
  log_level: info
  pan_id: 231  ## Attention à ce point...

La réactivité est bien meilleure et dans l'absolu le nombre d'équipements supportés simultanément bien plus important

La passerelle Xiaomi V3

Là vous vous demandez ce que vient faire cette passerelle que je dénigras plus haut. En fait elle est là car je vais l'utiliser non pas en mode natif avec une liste de devices limitée, mais en remplacement de la clé USB avec Zigbee2MQTT (ou ZHA). La liaison se fait en WIFI, et je peux donc placer la passerelle ou je veut dans la maison. Et cerise sur le gâteau les devices BLE reconnus remontent nativement dans Home Assistant...

La mise en place est un peu plus compliquée car il y a plusieurs façon d'utiliser ça, mais je vais essayer de vous mâcher un peu le travail. D'abord il vous faut une Gateway Xiaomi v3 (ZNDMWG03LM (CN) ou ZNDMWG02LM (EU) et rien d'autre), on en trouve chez AliExpress (27 €) ou Amazon (35/40€), de plus ces temps ci il y en a pas mal en reconditionnées état neuf chez Amazon à 25 €, donc plus simple que d'attendre 3/4 semaines avec le risque que le tanker se mette en travers du canal de Suez...

Une fois que vous avez en main votre nouveau jouet, vous l'ajoutez à Mi Home sans faire les mise à jour proposées (serveur Chine, j'ai pas essayé en serveur Europe mais ça devrait fonctionner également, retour welcome). A partir de là il faut récupérer le token (Mi Home, ou ici par exemple.) et lui assigner une réservation DHCP pour ne pas la perdre.

Ensuite sous Home Assistant :

  • On installe cette intégration via HACS (si vous n'avez pas HACS ou ne savez pas ce dont il s'agit, repassez dans quelques semaines...).
  • On ajoute l'intégration Xiaomi Gateway 3 dans Home Assistant (choisir Host & Token) en renseignant le HOST et le TOKEN et sans toucher aux options Telnet. Si ça ne fonctionne pas c'est surement lié à la version du firmware, firmware qu'il est possible de downgrader via Telnet (et pour une fois sans rien à souder).

Je vous ai perdu ? Pas de panique, tout est expliqué dans le GitHub de l'intégration et Google Translate est notre ami !

Modes de fonctionnement

  1. Natif Mi Home : On remonte dans Home Assistant les devices associables à Mi Home en ZigBee ou BLE (modules Xiaomi, Aqara et quelques ampoules Ikea).
  2. ZHA : La passerelle devient le coordinateur de ZHA et on profite de tous les devices supportés par ZHA. Cette option n'est pour l'instant pas la plus stable.
  3. Zigbee2MQTT : La passerelle devient le coordinateur de Zigbee2MQTT et on profite de tous les devices supportés par cette option. C'est la voie que j'ai explorée.

En choisissant l'option 3 et en considérant que Zigbee2MQTT est bien installé avec son broker, il suffit de modifier la configuration de l'addon en remplaçant la clé USB par un port TCP :

serial:
  port: 'tcp://192.168.210.119:8888'
  adapter: ezsp

Et bien sur de refaire les associations... Et constater une excellente réactivité. Meilleure qu'avec la clé à base de cc2652P, il me semble mais ça reste vraiment très subjectif. En tous cas sans commune mesure comparé à une clé cc2531.

On fait ainsi d'une pierre deux coups avec du Zigbee déporté qui intéressera ceux qui font tourner Home Assistant dans une VM installée au fond du garage, mais aussi la remontée des capteurs BLE, ce qui permettra de faire le ménage dans les intégrations dédiées BLE, et dans mon cas me séparer de mon Home Assistant remote qui supportait les clés USB

Et si on fait l'impasse sur le BLE, je pense qu'une fois la passerelle configurée pour Zigbee2MQTT on peut même désinstaller l'intégration...

Cette solution basée sur du reverse engineering sera pérenne pour peu que vous ne fassiez pas les mises à jour depuis Mi Home, et pour ça il existe dans l'intégration une possibilité de blocage.

EDIT 21/05/2021 : J'observe quelque plantages qui nécessitent le redémarrage de Zigbee2MQTT. Le problème semble venir du driver EZSP et non de la passerelle. Et curieusement ces plantages sont différents selon le type d'équipements. J'ai constaté une certaine allergies aux télécommandes IKEA par exemple... Par contre parfait pour remonter des sondes en BLE. A suivre.

EDIT 01/07/2021 : En l'état pas d'amélioration et inutilisable avec ZHA ou Zigbee2MQTT. Par contre 100% fiable en mode natif Xiaomi Mi Home. Donc parfait pour déporter des devices reconnus dans Mi Home

 

Home Assistant & Unifi Doorbell

Ca faisait un moment que je voulais moderniser la sonnette basic du portail par quelque chose de plus moderne. Il existe bien des solution élégantes de type Ring ou Nest, voire des chinoiseries plus ou moins attrayantes, mais l'inconvénient de toutes ces solutions c'est qu'elles passent par le cloud et que je trouve ridicule une telle dépendance, sans compter qu'il faut passer à la caisse...

En étant déjà équipé Unifi Protect j'ai donc attendu la disponibilité du système Dorbell G4 EU. Ce système fonctionne en WI-FI et la version EU est fournie avec un transformateur au format DIN pour l'alimenter en 24 volts. Donc entre le portail et la maison nous n'aurons besoin que d'une paire en BT et bien sur d'un signal WI-FI convenable.

Le problème est que ce système d'origine US est prévu pour fonctionner en 24 V. AC, le standard US pour ce genre d'équipement. Hors les sonnettes européennes fonctionnent soit en 220 V AC soit en 8 V. AC. Je me suis donc mis dans un premier temps à la recherche d'un carillon fonctionnant avec la bonne tension comme expliqué ici, objet rare sous nos latitudes et avec des commentaires déplorables.

Et puis j'ai réfléchit un peu, le Doorbell G4 remonte dans Home Assistant et j'ai des enceintes connectées dans toutes les pièces, on devrait donc pouvoir se passer d'une antique sonnette...

Après quelques tentatives j'ai utilisé un BluePrint existant (et perfectible) qui va me permettre de notifier avec un message vocal (TTS) une enceinte Google et d'envoyer une notification sur mon mobile avec la photo de la personne qui sonne, ce qui dans la pratique est bien plus efficace que l'application Unifi qui se contente de notifier mais qui ensuite est longue à afficher l'image. De plus si j'avais un portail électrique je pourrais me servir d'une action sur la notification pour l'ouvrir à distance depuis Home Assistant.

Mais tout ça ne sera pas suffisant pour me sortir du lit quant un livreur sonne tôt. Il me faut donc aller plus loin et faire sonner plusieurs enceintes Sonos. Le problème étant que si vous envoyez simplement un son à une enceinte Sonos, ça va certes le jouer au volume en cours, mais également casser l'état et le groupage des enceintes ainsi que le programme courant. J'ai donc créé une automation en parallèle qui va :

  • Sauvegarder l'état courant du système Sonos
  • Ajuster le volume des enceintes choisies
  • Grouper les enceintes choisie pour cette notification
  • Jouer le mp3 de la sonnerie (large choix ici).
  • Restaurer l'état précédent...
- alias: "RC : Doorbell Call Sonos Sound"
  trigger:
    - platform: state
      entity_id: binary_sensor.doorbell_g4_doorbell
      from: 'off'
      to: 'on'
  condition: []
  action:
  - service: sonos.snapshot
    data:
      entity_id: all
  - service: sonos.unjoin
    data:
      entity_id: media_player.sonos_hall
  - service: sonos.join
    data:
      master: media_player.sonos_hall
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
  - service: media_player.volume_set
    data:
      volume_level: 0.5
    target:
      entity_id: media_player.sonos_hall
  - service: media_player.play_media
    data:
      media_content_id: https://ha.canaletto.fr:8123/local/iphone.mp3
      media_content_type: music
    target:
      entity_id: media_player.sonos_hall
  - delay: 00:00:08
  - service: sonos.restore
    data:
      entity_id: all

Voilà, tout ceci reste perfectible, mais comme on dit, ça fait le job et il me reste à fixer l'objet !

A noter que cet appareil comporte également un détecteur de présence qui pourra ainsi permettre de signaler une présence (facteur ?), et que ce détecteur peut également allumer un led sous l'appareil. Le problème étant qu'il sera fixé dans la rue à la portée du premier vandale venu...

 

 
 

 

 

Cloud Drives et sécurité

Au fil du temps nous avons pris l'habitude d'utiliser des Cloud Drives. S'ils ont tous été comparés et décortiqués il reste des aspects souvent laissés de coté. La vraie menace aujourd'hui n'est pas tant de perdre ses fichiers mais plutôt de se les faire chiffrer à ses dépends, et dans ces cas comment les récupérer, et surtout les récupérer rapidement.

La majorité des ces offres permettent la synchronisation sélective (ne synchroniser que ce qui est utile) et surtout le travail en ligne avec des web apps. L'avantage de travailler ainsi est qu'aucun crypto virus ne pourra venir vous chatouiller.

Je ne vais pas faire le tour de toutes les offres mais me concentrer sur celles que je connais bien et me pencher sur les environnements Windows et MacOS.

Microsoft OneDrive

Depuis SkyDrive cette offre a beaucoup évoluée. Il existe en fait deux offres, l'une grand public (qui fait partie de l'offre Outlook grand public) et l'autre à destination des professionnels et des entreprises (qui fait partie de l'offre tentaculaire Microsoft 365, et n'est pas achetable à part). Techniquement l'usine qui est derrière est différente, mais dans sa manie habituelle Microsoft les appelle du même nom, et cette pratique confuse n'est pas nouvelle. 

Dans la pratique les deux offres proposent un historique des versions de tous les documents, on peu donc considérer que si un document est vérolé par un crypto virus, il sera toujours possible de restaurer la version précédente. Cette opération peut bien sur être fastidieuse, et là ou Microsoft va plus loin c'est qu'il offre la possibilité de restaurer l'ensemble des fichiers à une date donnée. Ainsi il sera possible de restaurer rapidement tout le contenu. C'est un vrai plus.

Pour la version Entreprise le client permet également de synchroniser localement des librairies de groupe, par ailleurs accessibles via Teams. Et dans ce cas il est également possible de faire une restauration complète à une date donnée.

Google Drive

Chez Google il existe également deux offres. La première pour tout le monde (Google One) et la seconde à destination des professionnels et des entreprises (Google WorkSpace). Le client Sauvegarde et Synchronisation est utilisable sur les deux offres, il permet entre autre de synchroniser localement son drive, mais également de sauvegarder en continu des répertoires de l'ordinateur. C'est ainsi que ma fille, traumatisée par la perte d'une partie de ses cours sur OneDrive Business (sous Mac) les sauvegarde sur Google Drive... Une autre application réservée aux entreprise permet d'utiliser son drive comme un disque supplémentaire. Dans l'offre professionnelle il est également possible de créer des drives partagés qui pourront être accessible aux utilisateurs de la solution gratuite.

A ma connaissance il n'existe pas d'option permettant de restaurer l'ensemble des documents à une date donnée sur l'offre grand public. Par contre l'historisation des fichiers fonctionne sur les deux offres.

Attention : les des offres Google Drive sont en pleine mutation des de nouvelles fonctionnalités sont prévue pour fin avril début mai.

Infomaniak KDrive

Cette offre suisse est à considérer pleinement car full RGPD, US Cloud Act free et avec la garantie que vos données ne seront jamais exploitées. Plus jeune et encore perfectible elle propose comme les autres une offre gratuite et une offre payante plus complète. Une historisation plus ou moins évoluée est au rendez vous mais sans possibilité d'une restauration globale.

A noter que sur les offres de groupe il n'est pas possible à l'administrateur d'accéder aux drives des autres utilisateurs et ainsi les sauvegarder. Donc ok dans un groupe d'indépendants ou la confidentialité de chacun est assurée, mais pas en entreprise.

Un des gros plus de KDrive est toutefois d'être full compatible WebDav, donc accessible sans client et par un Synologie pour par exemple une sauvegarde... (One drive également, mais il faut passer par Internet Explorer, c'est fastidieux, antique et plutôt décourageant...).

Le produit est plus jeune mais vraiment prometteur.

Dropbox

Ca existe encore ? Oui bien sur, mais il y a longtemps que je n'ai pas testé.

Box

Idem

Ice Drive

Un petit nouveau prometteur que je suis en train de tester.

Synology Drive et autres...

Un simple NAS, si possible hébergé, peut constituer une possibilité de cloud drive full privé. Ca fonctionne très bien. Il existe d'autres offres dans ce genre, NextCloud par exemple, mais ce n'est pas l'objet de la réflexion d'aujourd'hui.

Apple Cloud

Un autre monde.

Sauvegarder son / ses cloud drives

Comme on l'a vu tous ces cloud drives offrent des garanties de moyens pour assurer la sécurité de vos données. Mais aucune de ces solutions n'est infaillible et en cas de désastre (un crypto par exemple) la restauration risque d'être fastidieuse. Donc s'agissant de données critiques ou d'utilisateurs exigeants il va falloir s'assurer coté IT d'outils de restauration rapides et faciles à mettre en œuvre. Il en existe une multitude, Par exemple Veeam propose une solution qui nécessite un serveur Windows pour l'exploiter, une autre alternative consiste à utiliser un NAS Synologie et Active Backup pour Office 365 ou GSuite. Ce NAS peut être dans l'entreprise, ou par exemple loué chez Infomaniak qui le propose et ou les débits seront en adéquation avec cet usage. Une sorte d'assurance anti stress pour le responsable IT.

Clients alternatifs

Toutes ces offres proposent leur client propriétaire. Avec le temps ces clients fonctionnent plutôt bien, même s'il reste des lacunes. Que dire de OneDrive toujours en 32 bits là ou Microsoft prône du 64 bits ? Que dire du client Mac OneDrive qui fonctionne enfin (je touche du bois) après des années pour le moins catastrophiques ?

Bref, si on a un usage particulier, ou si on utilise plusieurs services en parallèle, il est tout à fait possible de passer par des clients alternatifs comme MountainDuck (Mac et Windows) ou RaiDrive (Windows). Ce n'est pas un conseil, mais une alternative possible. Il en existe d'autres bien sur, et les plus barbus s'orienteront naturellement vers RClone.

 

Home Assistant & Planification, Schedy, la suite !

Encore, allez vous me dire ! Oui car d'une part mon dernier article sur Schedy était un peu fouillis, et surtout en relisant les réponses de son auteur à ceux qui tentent de créer une interface, je me suis aperçu que l'approche que j'avais, qui consistait à faire passer à Schedy des plages horaires, n'était pas la plus simple ni la plus adaptée. D'une part il faut transformer des input_time en sensor ou en input_number (les deux seules possibilité pour transmettre à Schedy un horaire de début et de fin de plage sous la forme du nombre de minutes écoulées depuis minuit). C'est lié à son fonctionnement interne, ce n'est pas très pratique. Son auteur n'a pas le temps de faire évoluer, et surtout c'est un barbu qui déteste les interfaces graphiques...

J'ai donc opté pour une autre approche plus simple et plus concise qui va consister à se servir des input_datetime: de début et de fin de plage pour actionner un binary_sensor: qui passera à ON si on se trouve dans la plage.

A partir de là dans Schedy, on change la température de consigne (input_number:) de la la plage, si la plage est activée (input_boolean:) et la période active (binary_sensor:).

Et bien sur on le fait en fonction des contraintes que l'on s'impose en fonction de la situation de chacun (jour de travail, demie journée de travail, week-end ou télétravail), et tout ça pour chacune des pièces que l'on gère auxquelles correspond un thermostat (climate:) ou un groupe de thermostats.

De cette façon on continue à faire une gestion horaire qui correspondra à la majorité des usages, mais avec ce "mode" binaire on peut très bien imaginer une gestion à base de géolocalisation. Par exemple, en été, si un des membres du logement travaille à une distance de 20 Km, on peut imaginer mettre en route la climatisation s'il se rapproche à moins de 10 Km... Le chauffage (convecteurs + climatiseur) ne se gérant pas comme la climatisation (climatiseur seul) j'y reviendrait prochainement.

Le script

Pour plus de facilité on va utiliser un script afin de créer l'ensemble des entités nécessaires. Dans ce script on crée les entités nécessaires à chaque pièce et le nombre de plages que l'on veut gérer chaque jour que l'on multiplie avec le nombre de jours particuliers à gérer ( jours de semaine, le samedi qui est travaillé le matin et les dimanches et fériés par exemple). 

Pour chaque plage on crée (à chaque plage correspond un fichier qui est stocké dans les pakages) :

  • Deux input_datetime: pour le début et la fin de chaque plage,
  • Un binary_sensor: pour savoir si on est dans la plage,
  • Un input_number: pour définir la température de consigne de la plage,
  • Un input_boolean: pour activer ou désactiver la plage.

On va également créer un fichier heating_global.yaml qui va contenir :

  • Un binary_sensor: s'appuyant sur workday: pour savoir si on est un samedi travaillé,
  • Deux input_number: pour définir la température de consigne pour les plages inactives (deux ou trois car ce n'est pas pareil pour une chambre vide ou un climatiseur),
  • Deux input_boolean: un premier pour activer un mode télétravail, et un autre pour activer / désactiver le bazard.

On pense à éditer les lignes 39 pour définir les pièces et 41 pour le nombre de plages par pièces. On est pas obligé de faite tout d'un coup bien sur (et je vous conseille de commencer light).

/bin/bash
test -d /config/packages || mkdir /config/packages
cd /config/packages
cat >heating_global.yaml<<EOF
input_boolean:
  heating_enabled:
    name: Heating Global
    icon: mdi:toggle-switch
  homeoffice:
    name: Home Office
    icon: mdi:toggle-switch
input_number:
  off_temperature:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
  off_temperature_ac:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
binary_sensor:
  - platform: template
    sensors:
      workday_saturday_working:
        friendly_name: "Samedi travaillé"
        value_template: >
          {% if now().isoweekday() in (5,) and states.binary_sensor.workday_sensor.state == 'on' %}
            true
          {%else%}
            false
          {% endif %}
EOF
for room in hall_ac
do
for period in {1..12}
do
cat >${room}_heating_period_${period}.yaml<<EOF
input_datetime:
  ${room}_heating_period_${period}_start:
    name: "Heating Period ${period} Start Time"
    has_date: false
    has_time: true
  ${room}_heating_period_${period}_end:
    name: "Heating Period ${period} End Time"
    has_date: false
    has_time: true
binary_sensor:
  - platform: template
    sensors:
      ${room}_slot_${period}:
        entity_id: sensor.time
        friendly_name: ${room}_Slot ${period}
        value_template: >
          {% set t = states('sensor.time') %}
          {% set start = states('input_datetime.${room}_heating_period_${period}_start') [0:5] %}
          {% set stop = states('input_datetime.${room}_heating_period_${period}_end') [0:5] %}
          {{ start <= t < stop if start < stop else (start <= t or t < stop) }}
input_number:
  ${room}_heating_period_${period}_temperature:
    name: Heating Period ${period} Temperature
    min: 18
    max: 25
    step: 1
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
input_boolean:
  ${room}_heating_period_${period}:
    name: Heating Period ${period} Enabled
    icon: mdi:toggle-switch
EOF
done
done
exit

On teste la configuration (check configuration) et on recharge ce qui est nécessaire (reload input booleans, reload input date times, reload input numbers, reload templates entities).

Les cartes Lovelace

Ici on a deux approches possibles. Un mode normal ou un mode compact. J'ai déjà évoqué le mode normal, mais quand on 12 plages par pièces on va essayer de compacter la chose. C'est un peu plus fastidieux pour saisir les valeurs, mais en général on ne change pas ces valeurs tous les jours.

type: entities
entities:
  - entity: input_boolean.heating_enabled
    name: Activation AC mode chauffage
  - entity: binary_sensor.heating_enabled
    name: Etat global du chauffage
  - entity: binary_sensor.workday_sensor
    name: Jour de semaine
  - entity: binary_sensor.workday_saturday_working
  - entity: input_boolean.homeoffice
  - entity: input_number.off_temperature
  - entity: schedy_room.schedy_heating_hall_ac
    name: Retour Schedy AC
  - label: SEMAINE
    type: section
  - entities:
      - entity: binary_sensor.hall_ac_slot_1
        name: false
      - entity: input_number.hall_ac_heating_period_1_temperature
        name: false
        unit: °
        format: precision1
      - entity: input_datetime.hall_ac_heating_period_1_start
        name: false
        format: relative
      - entity: input_datetime.hall_ac_heating_period_1_end
        name: false
    entity: input_boolean.hall_ac_heating_period_1
    name: Plage 1
    show_state: false
    toggle: false
    icon: 'mdi:calendar-range'
    type: 'custom:multiple-entity-row'
    state_color: true
# >>> Ici les autres avec un séparateur...
show_header_toggle: false
state_color: true
theme: teal
title: Schedy AC
footer:
  type: graph
  entity: sensor.daikin_inside_temperature
  hours_to_show: 24

Et voici le résultat...

Schedy

S'agissant de la configuration de Schedy il a bien sur fallut l'adapter. Vous dire que j'ai tout compris serait un mensonge et il y a certainement moyen de simplifier, et je suis preneur d'idées. Voici donc ce que ça donne (j'ai volontairement laissé quelques commentaires).

schedy_heating:
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat
  actor_templates:
    default:
      send_retry_interval: 15
      send_retries: 20
      supports_hvac_modes: true
      off_temp: 17
  
  watched_entities:
  - input_boolean.homeoffice
  - binary_sensor.workday_sensor
  - binary_sensor.workday_saturday_working
  - input_boolean.heating_enabled

  schedule_prepend:
  - x: "14 if is_off('input_boolean.heating_enabled') else Next()" # Le HorsGel... Possible aussi de créer un input_number...
  
  rooms:
    hall_ac:
      allow_manual_changes: true  # On autorise le changement manuel de consigne ou le passage en off
      rescheduling_delay: 90      # Délais après lequel Schedy repassera sur les valeurs prédéfinies
      actors:
        climate.thermostat_x:
          template: default
      watched_entities:
      # COMMON
      - input_boolean.homeoffice
      - binary_sensor.workday_sensor
      - binary_sensor.workday_saturday_working
      - input_number.off_temperature
      # ROOM SPECIFIC
      - input_number.hall_ac_heating_period_1_temperature
      - input_boolean.hall_ac_heating_period_1
      - binary_sensor.hall_ac_slot_1
      - input_number.hall_ac_heating_period_2_temperature
      - input_boolean.hall_ac_heating_period_2
      - binary_sensor.hall_ac_slot_2
      - input_number.hall_ac_heating_period_3_temperature
      - input_boolean.hall_ac_heating_period_3
      - binary_sensor.hall_ac_slot_3
      - input_number.hall_ac_heating_period_4_temperature
      - input_boolean.hall_ac_heating_period_4
      - binary_sensor.hall_ac_slot_4
      schedule:
      - rules:
        # WORKDAY
        - rules:
          - x: "Next() if is_on('binary_sensor.workday_sensor') else Break()"
          - x: >
              state("input_number.hall_ac_heating_period_1_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_1") and (is_on("binary_sensor.hall_ac_slot_1")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_2_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_2") and (is_on("binary_sensor.hall_ac_slot_2")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_3_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_3") and (is_on("binary_sensor.hall_ac_slot_3")))
              else Next()
          - x: "Break(2)"
        # WEEK-END
        - rules:
          - x: "Next() if is_off('binary_sensor.workday_sensor') else Break()"        
          - x: >
              state("input_number.hall_ac_heating_period_4_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_4") and (is_on("binary_sensor.hall_ac_slot_4")))
              else Next()
          - x: "Break(2)"

      # - v: 13 # On remplace par un input_number >>> Attention : v = valeur, x = expression
      - x: state("input_number.off_temperature") # Consigne entre les plages

A suivre...

Il existe dans Schedy un système d'events qui vont permettre de créer des dérogations ponctuelles. Par exemple un bouton ou une commande vocale quand je vais aller prendre une douche qui va lancer une dérogation pour augmenter sensiblement la température de la salle de bain pendant un temps défini ou jusqu'à ce qu'on lui envoie un contre ordre. On peu aussi imaginer chauffer une chambre d'amis lorsqu'on reçoit ou le boudoir lors d'une galante visite (encore que ces temps-ci la fonction ne servirait pas à grand chose...).

Et bien sur la gestion des ouvertures est gérée pour couper le chauffage... Plus tard...

Pour en finir...

Dans cet usage Schedy n'est plus vraiment le planificateur mais un moteur qui va surveiller (re planification) les thermostats et leur donner les bons ordres en fonction des évènements, états  et ordres venus de Home Assistant. Si Schedy peut également gérer des lampes (light:) et des actionneurs (switch:) c'est sans internet, sauf peut être pour superviser la machinerie d'une piscine...