Sujet peu abordé jusqu’à présent sur ce blog mais ô combien important alors qu’il reste encore 13 jours tarif « rouge » pour les abonnés Tempo : le bon pilotage de ses radiateurs (et chauffe-eau) est primordial pour comprendre et maîtriser sa consommation d’électricité. En effet, en plus de « tirer » collectivement énormément et simultanément sur les producteurs d’électricité, au niveau d’un foyer le chauffage est bien souvent le principal centre de coût. Sans parler du décret 2023-444 qui rend obligatoire l’installation de thermostats intelligents dans les logements en 2027 2030.

Jeedom dispose d’un très bon plugin Thermostat pour cela, bien documenté, et efficace. On l’a déjà dit, une telle centrale domotique permet de mieux intégrer des équipements de différents types, connectés au sein de l’ensemble de votre maison connectée, et non pas uniquement au sein des différentes applications spécifiques que vous obtenez avec différentes marques non compatibles entre elles.

Nous testons ici l’intégration dans Jeedom d’un module Wifi Heatzy « Pilote » en remplacement d’un module Fil Pilote Qubino avec lequel un de mes radiateurs ne fonctionne pas correctement. Nous intégrons le tout ensuite dans le plugin Thermostat de Jeedom, de façon à contrôler ce radiateur de la même façon que d’autres, déjà présents, mais pas de la même marque et pas pilotés avec ce type de module. Enfin, nous couplerons le thermostat Jeedom, à un thermostat « physique » mural qui permettra à un invité d’agir facilement sur le chauffage de la pièce.

Nous allons auparavant expliquer un peu le principe du « fil pilote » qui me pose parfois problème sur certains radiateurs (pas tous). Et nous verrons en fin d’article une solution pour reproduire soi-même relativement facilement un module fil pilote.

C’est parti.

---

Le fil pilote à la française

Création

Fun fact: la France a (encore ?) créé une « exception culturelle », dans le monde de l’électricité, après le choc pétrolier de 1973. Pour réduire sa dépendance au pétrole étranger, la France lance le Plan Messmer : construction massive de centrales nucléaires, encouragement des citoyens à se chauffer à l’électrique, et anticipation du fait que si tout le monde chauffe en même temps, le réseau risque de sauter.

À la fin des années 70, les ingénieurs d’EDF collaborent donc avec le GIFAM (Groupement des marques d’appareils pour la maison) pour créer un système simple et robuste utilisant directement la sinusoïde du courant (50Hz) pour donner des ordres simples. Les premiers prototypes de radiateurs équipés de cette technologie voient le jour en 1980, le « Fil Pilote » est normalisé via la norme NF C 15-100 qui impose le passage d’un fil dédié dans les gaines électriques destinées au chauffage, et l’expansion réelle se fait à partir de 1990 avec la généralisation de la tarification « Heures Creuses / Heures Pleines » d’EDF.

Instant Cororico: d’autres pays ont créé et déployé des systèmes similaires (Suisse, Allemagne, Australie et Nouvelle Zélande), pour répondre à des problématiques parfois différentes, et aux solutions différentes. Nous y reviendrons dans un article sur les principes de l’effacement diffus. Mais, avec la mise en oeuvre du signal Pulsadis au niveau national (l’ancêtre direct du CPL et du Linky) entre 1950 et 1960, et le déploiement « Fil pilote« , la France est pionnière sur le fait de permettre une gestion massive, domestique, centralisée et standardisée du chauffage électrique, sans imposer de mode « on/off » électriquement brutal pour les équipements terminaux. Avec ces deux protocoles, la France et EDF ont généralisé l’ancêtre direct de la « Smart Grid » (réseau intelligent, du transport haute/moyenne tension, jusqu’au radiateur individuel).

Principe

Contrairement à un simple interrupteur « Marche/Arrêt », le fil pilote permet d’envoyer à un radiateur des ordres complexes (4 ou 6 ordres selon la génération : Confort, Éco, Hors-gel, Arrêt, puis éventuellement Confort -1°C, Confort -2°C) via un signal électrique modulé en 230V. Le thermostat du radiateur est toujours responsable de la gestion de la chauffe, mais elle se fait en fonction d’un mode reçu sur le fil pilote, donné par un « thermostat d’ambiance » ou une centrale domotique qui pilotent des zones avec plusieurs radiateurs. Sur la plupart des radiateurs récents, les 3 premiers modes peuvent chacun être associés à une température précise, la température de consigne.

Physiquement, le fil pilote est tout simplement un 3ième fil de couleur noire, qui complète les fils classiques de phase et de neutre d’un radiateur électrique.

Et les autres ?

Dans la quasi-totalité des autres pays le pilotage des radiateurs électriques fonctionne différemment :

1. Le « On/Off » (Tout ou Rien) : Le thermostat agit comme un simple relai. Eventuellement commandé à distance, il coupe l’alimentation électrique du radiateur quand la température est atteinte et la rallume quand il fait froid.
2. Thermostats intégrés autonomes : Les radiateurs sont gérés individuellement sans lien permettant une centralisation (de moins en moins fréquent).
3. Systèmes propriétaires : Certains fabricants étrangers ont leurs propres protocoles sans fil ou filaires, mais il n’y a pas de standard national équivalent au fil pilote.

Nous étudierons cela plus en détail dans un futur article sur l’effacement diffus.

---

Déballage & documentation du module

Déballage

Rien de bien spécial en ce qui concerne la boîte du module. On ne peut pas louper les QRcodes qui renvoient vers la documentation et l’application à télécharger, qui sera nécessaire pour la création d’un compte sur le site Heatzy et la configuration du module (détection et association au wifi domestique pour qu’il puisse envoyer ses données).

Documentation

Les documentations sont disponibles ici et notamment celle-ci Bible de l’installateur. Au cas où, et je les retirerai au cas où cela gène le constructeur, voici une copie locale, par précaution:

• Installation physique
• Le boîtier, ses 2 diodes et son bouton
• Le téléchargement de l’app et la création de compte
• L’appairage
• L’interface de l’application
• La programmation via l’application
• Le mode vacances via l’application
• Le verrouillage des touches du module via l’application
• Le mode Boost qui surcharge ponctuellement la programmation, via l’application
• La bible de l’installateur (codes d’erreur, etc.)

Je me suis fait deux remarques:

• D’abord que cela semble très complet et facile à comprendre (et c’est le cas).
• Je ne suis pas fan du fait d’avoir « éclaté » les manipulations nécessaires dans plusieurs documentations/fichiers. D’autant que sur le site Heatzy ces fichiers ne sont « visuellement » pas présentés dans l’ordre logique des opérations à réaliser : en lisant de gauche à droite et de haut en bas, on s’attendrait plutôt à trouver d’abord l’installation, puis le boîtier, puis la création de compte (qui fait télécharger l’app), puis l’appairage (qui utilise l’app), puis l’interface (de l’app).

Passé ce petit puzzle mental à reconstituer, on peut lire: Prérequis pour l’appairage (Les 7 commandements et Réglages téléphone) :

• Le wifi domestique doit fonctionner sur la fréquence 2.4 GHz .. Et plus loin il est demandé de séparer les réseaux !
• Le téléphone doit avoir le Wi-Fi, le Bluetooth, et le GPS activés,
• Le radiateur doit avoir le fil pilote activé et être réglé en mode confort à 21°C pour la vérification.

Là encore, deux remarques:

• A l’heure où la plupart des box sont « bi-bande » 2.4Ghz et 5Ghz, souvent sur le même SSID car les périphériques « modernes » sont capables de choisir eux-mêmes leur fréquence, on peut s’interroger. A ce stade j’ai un moment de doute car clairement je ne vais pas dissocier mes réseaux wifi juste pour le pilotage d’un module radiateur. Je suspecte cependant que ça ne soit qu’un problème d’appairage initial : nous verrons cela plus loin.
• Bluetooth surement nécessaire pour transmettre le réseau wifi à utiliser au module lors de son appairage initial, mais pourquoi le GPS ? Il ne me semble pas que cela soit expliqué dans la documentation.

---

Branchement de test du module (sur ampoule)

Je teste la plupart de mes nouveaux modules, même ceux que je connais, sur un branchement basique avec une ampoule de façon à vérifier la bonne activation des sorties depuis Jeedom, avant de déplacer les modules à leur emplacement définitif.

Branchement physique

L’installation d’un module fil pilote est en général très simple sur un radiateur (le module est alimenté par le 230V tout comme le radiateur, et la sortie fil pilote du module se branche sur le fil pilote « entrant » du radiateur. Avec l’ampoule c’est légèrement différent mais pas bien compliqué non plus:

• La phase du 230V « mural » alimente la phase du module Heatzy
• Le neutre du 230V « mural » alimente à la fois le neutre du module Heatzy et une des bornes de l’ampoule.
• La sortie « Pilote » du module Heatzy alimente l’autre borne de l’ampoule.

Attention: toujours couper le courant avant de modifier le câblage, utiliser une ampoule 230V classique ou un petit voyant néon, et travailler dans un boîtier ou sur un montage isolé, le fil pilote « sortant » lui aussi du 220-240V.

Codage des 6 ordres fil pilote & résultat escompté

Pour tester un module fil pilote avec une ampoule, on exploite le fait que les ordres sont codés sur le fil pilote par la présence de 240 V sur certaines alternances, ce qui fait que l’ampoule s’allume différemment selon le mode (allumée en continu, éteinte, ou « moitié du temps » c’est à dire un clignotement dû à la demi-alternance).

Voici le tableau de correspondance théorique des signaux GIFAM ; en pratique, avec une simple ampoule, on ne distingue bien que les cas 0 V / 230 V et le « demi » mais on ne peut pas faire la différence entre « les » demis:

Mode radiateur	Signal entre fil pilote et neutre	Ce que donne typiquement une ampoule 230 V
Confort	0 V	Éteinte en permanence
Confort -1 °C	Alternances + et – périodiques (trames)	Léger clignotement / instable, difficile à interpréter sans oscilloscope
Confort -2 °C	Alternances + et – avec autre cadence	Clignotement différent, aussi difficile à distinguer visuellement
Éco (réduit / nuit)	230 V permanents	Allumée en permanence
Hors-gel	230 V sur une seule alternance (par ex. alternance négative)	Luminosité réduite (environ moitié) ou scintillements légers
Arrêt	230 V sur l’autre alternance (par ex. alternance positive)	Luminosité réduite (autre « demi »), visuellement proche du hors-gel

A ce stade, après alimentation du module sur le secteur, le seul test possible est d’utiliser le bouton physique du module (qui devrait toutefois déjà montrer le bon fonctionnement physique du module), donc on passe à l’étape suivante, l’appairage du module avec l’infrastructure Heatzy à commencer par l’application mobile, puis l’inclusion dans Jeedom pour le pilotage centralisé.

---

Appairage du module avec l’infrastructure Heatzy

Il s’agit ici de faire fonctionner le module avec son application mobile « classique » qui sert aussi à la configuration initiale du module pour sa liaison avec les serveurs Heatzy.

Les captures suivantes vous montrent l’ensemble du processus sur mobile Android (devrait être identique j’imagine sur iOS): au lancement, demande de localisation GPS (ça commence bien 🙂 ), puis création de compte, puis appairage avec le module (en bluetooth), appui 10 secondes sur le bouton physique du boîtier, demande d’autorisation de connexion au module (via bluetooth), saisie du mot de passe wifi, tentative de connexion.

Nous allons donc tenter une petite manipulation au niveau de la box …

---

Contournement de la restriction Wifi 2.4Ghz

Les opérations sont très simples, et nécessitent environ 10minutes: désactiver temporairement la bande des 5ghz pour forcer l’appairage de mon téléphone en 2.4ghz, retenter l’appairage du module via le téléphone, vérifier que le module fonctionne, rétablir le 5ghz et vérifier si le module fonctionne toujours.

1. Désactivation du Wifi 5Ghz sur la box/routeur

Sur une Freebox, l’opération se fait depuis l’interface d’administration: une case à décocher, et ne pas oublier d’appliquer en bas. Sur les box d’autres opérateurs, j’avoue que je ne sais pas, mais, de mémoire, sur une box Orange il est aussi possible de couper le 5ghz temporairement.

2. Réassociation téléphone & module en 2.4Ghz

Une fois le 5Ghz coupé, la deuxième étape est de réassocier le téléphone utilisé pour l’appairage du module, au réseau Wifi 2.4Ghz. Normalement quand le 5Ghz a été coupé, il a dû se réassocier automatiquement à la seule bande restante, mais un court passage en mode avion permet d’accélérer les choses.

Ensuite, on relance l’opération d’appairage du module. En images:

Effectivement, sans réseau 5Ghz, le téléphone envoi au module une configuration qu’il arrive à utiliser pour s’accrocher lui-même au wifi, de telle façon qu’il communique bien ensuite avec l’infrastructure Heatzy et « remonte » enfin dans l’application mobile.

Nous voilà donc rassurés, mais nous avons dû désactiver le réseau Wifi 5Ghz ce qui n’est pas satisfaisant, et je ne souhaite pas avoir à changer son nom/SSID, pour ne pas devoir revoir toute la gestion et association des périphériques dans la maison.

3. Réactivation du réseau 5Ghz & validation fonctionnement

Pas besoin de capture d’écran ici, il suffit de:

1. Réactiver le réseau 5Ghz sur la box/routeur (cf. étape 1 plus haut sur une Freebox : on recoche la case et on valide),
2. Vérifier que des périphériques diverses (téléphone par exemple) se réassocient bien sur le Wifi 5Ghz.

Une fois ces deux opérations réalisées, je constate que, sans débrancher/rebancher le Heatzy, l’application mobile continue à piloter module et ampoule. C’est positif.

On redémarre alors le module pour forcer un réappairage Wifi alors que les deux réseaux 2.4Ghz et 5Ghz sont actifs avec le même nom/SSID, et après quelques instants, le contrôle redevient possible, y compris après reconnexion manuelle dans l’application mobile au compte Heatzy. C’est à nouveau positif car c’est le fonctionnement cible alors que la documentation officielle indique clairement de ne pas nommer les réseaux 2.4 et 5Ghz avec le même nom/SSID.

En regardant les périphériques connectés sur le réseau 2.4Ghz après avoir réactivé le réseau 5Ghz, on voit ceci:

A noter le nom ‘espressif’ qui apparait sur le serveur DHCP qui correspond à un fabriquant de modules ESP32. Et que son adresse MAC n’est pas inscrite sur le module lui-même ou son emballage, en revanche elle correspond à la référence qui remonte dans l’application mobile.

---

Intégration du module à Jeedom

1. Installation du plugin Heatzy

Nous utilisons le module gratuit. Sa documentation se trouve ici et semble plus ou moins supportée par le constructeur puisque référencé sur son blog.

Une fois le plugin actif, il est nécessaire de remplir le login et mot de passe configurés lors de la création du compte sur l’application mobile Heatzy.

Durant la synchronisation du plugin avec les serveurs Heatzy, l’ampoule réagit. La page de configuration doit aussi évoluer, une fois le jeton d’authentification reçu. On constate la valorisation des trois champs. Laissons les valeurs par défaut.

Par habitude, je vérifie dans les logs ce qu’il s’est passé. Ici (en niveau de log par défaut), on constate que la séquence de synchronisation avec les serveurs a permis de remonter un module. Tant mieux, le contraire aurait été inquiétant.

2. Configuration du module

Puisqu’un module a été remonté dans Jeedom depuis l’infra Heatzy, allons le configurer. On accède pour cela à l’interface du plugin par son entrée dans le menu adhoc.

On remarque au passage que ce plugin est joignable par le menu « Objets connectés » alors que les autres plugins liés au chauffage (plugin Cozytouch, ou le plugin « standard » Thermostat de Jeedom) sont dans le menu « confort ». Pas un problème en soit, vous me direz sûrement que je suis tatillon, et c’est vrai, mais personnellement je ne trouve pas l’ensemble très cohérent.

Bref, une fois arrivé dans la page « de configuration fonctionnelle » du plugin, on constate bien la présence d’un module, portant comme identifiant l’adresse MAC précédemment rencontrée dans l’interface d’administration/wifi de la Freebox, et correspondant aussi du coup à l’identifiant remonté dans l’application mobile Heatzy lors de l’appairage. Là, c’est cohérent 🙂

Encore un détail, pas très grave, mais il manque une petite traduction des labels en anglais. Allons faire un tour dans l’onglet « Santé ».

On y trouve quelques informations qui peuvent être importantes, notamment le statut connecté ou non, et quelques dates clés sur les remontés d’information, création, etc. Allons maintenant configurer notre nouveau module.

Ici rien de bien sorcier, on renomme le module, et on l’affecte à la pièce dans laquelle il va se trouver. On constate que les mêmes informations que celles de l’onglet « Santé » sont affichées, ici spécifiquement pour ce module alors que la page « Santé » permet de voir tous les équipements d’un coup.

On va maintenant dans l’onglet « Commandes » (should be: « Commands » 8) ) et fort logiquement on y retrouve:

• Des informations qui sont cascadées depuis l’infrastructure Heatzy,
• des commandes qui permettent d’influencer le module (via Internet), au même titre que l’application mobile.

A noter l’onglet « Paramètres », intéressant aussi car il permet:

• De lier des capteurs de température et d’humidité au module: a priori pas pour piloter directement le radiateur en fonction de ces paramètres, mais plutôt pour les afficher sur le widget du plugin, et déterminer une tendance concernant l’évolution de la température, et en la rendant consultable via la commande info « Tendance Température« , ce qui nous décharge de réaliser nous-même ce genre de calcul
• De simuler une détection d’ouverture de fenêtre dans une pièce, via la chute de température configurable de X °c en moins de Y minutes, et de rendre accessible cette information par la commande info « Fenetre Ouverte« , et ainsi de déclencher très simplement une alerte sans détecteur d’ouverture physique, et sans scénario de calcul complexe.

Merci au développeur pour ces attentions !

Pour ma part, je configure un capteur de température dans la même pièce, mais je ne compte pas utiliser ces informations du module Heatzy car je vais plutôt coupler le module au plugin Thermostat de Jeedom que j’utilise déjà, et qui me permet d’unifier le pilotage de mes radiateurs quel que soit le module technique de pilotage de chaque radiateur (fil pilote, on/off, on/off avec diodes, autre plugin type CozyTouch, etc.).

Enregistrons tout ça, et allons voir le widget sur le dashboard.

3. Affichage, test et installation finale du module

Le widget est relativement classique, et il affiche par défaut beaucoup de commandes.

On peut largement simplifier cela, en masquant les commandes unitairement depuis l’onglet « Commandes » de la page de configuration fonctionnelle du module, ou en modifiant l’affichage du widget depuis le dashboard et en décochant la case « visible ».

A nouveau, je procède à un tests, via les boutons du widget du module:

• Mode off → ampoule scintille ✅
• Mode confort → ampoule éteinte ✅
• Mode confort -1 et -2 → pas testé, seule la version « Pro » de ce module gère ces deux ordres, et honnêtement avec Jeedom et son plugin Thermostat, ce n’est vraiment pas nécessaire …
• Mode éco→ ampoule allumée ✅
• Mode hors gel → ampoule scintille ✅

Bilan à ce stade:

• On arrive à contrôler l’ampoule via Jeedom, et son plugin Heatzy, qui envoient les ordres à l’infrastructure Heatzy distante, laquelle met à jour le module physique par communication inverse.
• On constate un délai parfois de quelques secondes entre le moment du click et la prise en charge par le module et la réaction sur l’ampoule. Possible impact sur le WAF (Wife Acceptance Form): quelques secondes, c’est suffisamment long pour avoir le sentiment que ça ne fonctionne pas bien, et cliquer plusieurs fois sur plusieurs boutons. C’est la conséquence du mode « connecté » passant par Internet (et peut-être de l’implémentation de l’API dans le plugin, je ne sais pas je n’ai pas encore testé, mais j’en doute).

Le volume du module étant assez significatif, il ne rentre dans aucun boîtier encastré, et il ne peut pas non plus s’insérer entre le mur et le radiateur (de toute façon déconseillé à cause de la chaleur du radiateur). Il est tout simplement « posé » sur le module de commande du radiateur, qui reste relativement épargné par la montée d’air chaud.

De cette façon sa diode d’état est bien visible, ce qui permet de faire une rapide vérification visuelle de l’état du module, indépendamment de l’état du radiateur (cette possibilité manque énormément avec les petits modules fil pilote qu’on encastre dans un mur, quand le radiateur ne chauffe pas alors qu’on pense que le module lui dit de chauffer .. mais qu’on ne peut pas « voir » son état pour confirmer.

Après branchement, tout a très bien fonctionné: le radiateur priorise les ordres du fil pilote, quand le module reçoit l’ordre de chauffer, le radiateur se met en chauffe, etc. C’est une installation réussie.

En revanche, après quelques jours d’utilisation, et comme je le fais régulièrement sur d’autres plugins, j’ai eu la curiosité d’aller voir les logs du plugin. Et là, ô surprise, de nombreuses erreurs génériques de type « Bad Gateway » (HTTP 502) qui signifient en général une erreur réseau ou une surcharge. J’ai donc passé les logs en DEBUG et voici ce que l’on peut y lire.

[2026-01-25 11:50:01][DEBUG] HttpGizwits::Bindings: erreur http 502
[2026-01-25 11:50:01][WARNING] heatzy::Synchronize : HttpGizwits::Bindings - impossible de se connecter à : https://euapi.gizwits.com
[2026-01-25 11:50:01][DEBUG] heatzy::cron: Synchronize cron5 = 
[2026-01-25 11:52:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 11:53:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 11:55:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 11:56:02][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 11:58:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 11:59:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 12:00:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 12:02:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 12:03:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 12:05:00][DEBUG] heatzy::cron: Arret du cron car Synchronize en cours ...
[2026-01-25 12:06:02][DEBUG] heatzy::cron: Réinit du cache Heatzy_Synchronize car > 600s (=1769338200)
[2026-01-25 12:06:02][DEBUG] heatzyCmd::execute : Commande execute : Chauffage Heatzy - refresh (3449)Langage du code : PHP (php)

Cette erreur est préoccupante, car en temps normal on voit bien dans les logs qu’il y a des mises à jour toutes les minutes, alors qu’ici une fois que cette erreur apparait à 11h50, on constate qu’il ne se passe rien jusqu’à 12h06; soit 16 minutes sans refresh des informations sur Jeedom. Il est probable en revanche qu’un changement d’ordre via Jeedom initie une nouvelle connexion vers l’infrastructure Heatzy et que cette erreur n’apparaisse pas (sauf réel problème sur l’infrastructure distante), mais je n’en suis pas certain, il faudrait pour cela que j’arrive à tester cela au moment où je constate une telle erreur, chose que je n’ai pas eu le temps de faire depuis.

A noter aussi que Gizwits est une plateforme IoT cloud chinoise, sur laquelle s’appuie donc Heatzy pour la communication avec ses modules. Cela soulève la question de la souveraineté de nos données personnelles.

En attendant, j’ai passé de 10 à 30 secondes le temps avant timeout, dans la page de configuration technique du plugin.

Nous verrons avec le temps quel effet cette modification a eu. Je tiens à préciser que malgré cela, globalement nous n’avons jamais eu à nous plaindre d’un défaut de passage d’ordre depuis Jeedom, sur ce radiateur.

Update une semaine après (03/02/2026): toujours des erreurs présentes dans les logs. Certaines identiques, d’autres probablement liées à des maintenances côté infrastructure (équipement non trouvé).

[2026-01-28 18:05:13]WARNING heatzy::Synchronize : HttpGizwits::Bindings - impossible de se connecter à : https://euapi.gizwits.com
[2026-01-29 10:05:12]WARNING heatzy::Synchronize : HttpGizwits::Bindings - impossible de se connecter à : https://euapi.gizwits.com
[2026-01-29 15:50:11]WARNING heatzy::Synchronize : HttpGizwits::Bindings - impossible de se connecter à : https://euapi.gizwits.com
[2026-01-30 03:02:00] ERROR  heatzy::updateHeatzyDid : OrW30xxxxxxx - 9014 - device not found -
[2026-01-30 03:03:38] ERROR  heatzy::updateHeatzyDid : OrW30xxxxxxx - 9014 - device not found -Langage du code : PHP (php)

J’ai passé maintenant le timeout sur les connexions à 60 secondes. Passons maintenant à « l’homogénéisation » du pilotage de nos radiateurs, en intégrant celui-ci au plugin Thermostat.

---

Intégration au plugin Thermostat

Le plugin Thermostat est un plugin supporté par l’équipe Jeedom, payant, 8€. Cela peut sembler élevé, mais, il permet comme déjà dit, d’unifier le pilotage de différents types de radiateurs, dans une interface commune. Il permet aussi :

• Une gestion complètement personnalisée de différents modes,
• Un apprentissage dans le temps des capacités de chauffe (fonction du radiateur, de la pièce, température extérieure, inertie) de façon à même anticiper le moment de déclenchement de la chauffe en fonction de l’heure à laquelle on veut une certaine température (quand il est couplé au plugin agenda),
• De tenir compte de détecteurs d’ouverture pour réaliser différentes actions entièrement paramétrables (alertes, arrêt de chauffe, etc.),
• De gérer des alertes sur plusieurs types d’événements.

1. Installation du plugin

Passons rapidement sur l’installation/activation du plugin depuis le market Jeedom.

Remarquez sur la précédente capture, qu’il y a déjà un certain nombre de thermostats configurés. Ceux des pièces Bureau, Chambre Parentale, Grande Chambre, pilotent des radiateurs munis de modules Qubino. Trois autres radiateurs équipés d’un bridge Cozytouch (et du plugin Jeedom associé) vont bientôt compléter la famille.

2. Ajout d’un thermostat

Nous allons ici créer le thermostat associé à notre radiateur piloté par le module Heatzy, dans la pièce « Entrée ».

Sur le premier onglet, que des options « de base »:

• Nom du thermostat bien sûr, et la pièce dans laquelle il se trouve, son statut activé ou pas et le fait qu’il soit visible sur le dashboard,
• Mode de fonctionnement temporel. C’est le mode le plus précis, capable d’apprendre, mais il nécessite une sonde de température intérieure et extérieure (dans mon cas ce sera … le plugin Météo et sa commande info « température » !),
• Ensuite, de la configuration somme toute assez basique et évidente:
  • Mode « chauffage seulement » et on constate au passage que le plugin sait aussi gérer la climatisation,
  • Les températures de consigne minimale et maximale acceptées par le curseur de réglage sur le widget du thermostat,
  • Les deux sondes de température intérieure (ici un oeil Fibaro) et extérieure (le plugin météo).
  • Les deux cases permettant de spécifier la température minimale et maximale sous la sonde de température intérieure, servent à déclencher des alertes dans le plugin.

L’onglet Actions est ensuite très intéressant, on rentre dans le cœur du sujet: les commandes liées à la chauffe, ou à l’arrêt de la chauffe.

Les choses sont très simples: on appelle les commandes « Mode Confort » (celle qui chauffe théoriquement le plus fort sur notre radiateur) et « Mode Off » exposées par le plugin Heatzy préalablement configuré. Notez qu’on peut ajouter une commande pour refroidir (si clim .. ou ouverture automatisée d’une fenêtre ou porte par exemple).

L’onglet Mode nous permet ensuite de définir nos propres consignes et de leur affecter un nom.

Ici j’ai créé trois consignes personnalisées, mais l’on peut en créer autant que l’on veut et les nommer comme on veut:

• Confort, avec une température cible de 19°c,
• Eco, avec une température cible de 14°c,
• Hors Gel, pour les longues absences hivernales, avec une température cible de 6°c.

Il est capital de comprendre que ces températures de consigne dans Jeedom, vont littéralement remplacer celles qui sont éventuellement programmables sur votre radiateur, à partir du moment où celui-ci est piloté à distance par Jeedom. S’il y a besoin de chauffer pour atteindre une de ces températures cibles (en fonction de ce qu’indique la sonde de température intérieure configurée), alors Jeedom va demander au radiateur de se mettre en mode Confort, car c’est ce qu’on lui a dit de faire dans l’onglet « Actions » précédent. Si la température de consigne de Jeedom est atteinte, alors Jeedom arrêtera le radiateur (en tout cas il exécutera ce qui a été configuré commande d’arrêt dans l’onglet « Actions »).

Par conséquent il est important de bien configurer le mode « Confort » du radiateur cette fois-ci, sur la température la plus élevée possible, supérieure à celles configurées ici, pour que le radiateur chauffe à pleine puissance quand il reçoit l’ordre par Jeedom de se mettre sur son propre mode confort, et pour déléguer à Jeedom la régulation de la chauffe grâce au mode d’apprentissage du plugin.

L’onglet suivant permet de gérer les ouvrants.

Il n’y a aucune obligation de déclarer vos éventuels capteurs d’ouverture ici. Néanmoins, si vous le faites, cela permettra au plugin d’adapter votre chauffage en fonction des événements liés à ce capteur. Par exemple, ici, au bout de 2 minutes d’ouverture détectée sur le capteur de la porte d’entrée, il demandera au radiateur de s’arrêter. Il recommencera à chauffer 3 minutes après que la porte se soit refermée.

L’onglet suivant permet de gérer d’éventuelles défaillances.

On a ici la possibilité de réaliser des actions spécifiques, en cas de:

• Défaillance détectée (ou supposée) sur la sonde de température, en fonction du temps maximum qui doit théoriquement s’écouler entre deux mesures différentes de température quand le radiateur change de mode (cf. onglet « Avancé »),
• Anomalie liée à une température relevée dans la pièce inférieure ou supérieure aux températures respectivement minimales et maximales précédemment configurées dans le premier onglet, augmentées ou diminuées des marges prévues (cf. onglet « Avancé »).

Comme vous le constatez, je n’ai pas mis d’actions particulières.

L’onglet « Avancé » permet d’agir finement sur certains réglages.

A ce stade, pas la peine de toucher à quoi que ce soit ici. Sachez qu’on y retrouve tout de même certains des paramètres permettant notamment d’agir sur les défaillances. La documentation du plugin décrit plutôt bien l’ensemble des paramètres ainsi que ce très bon sujet sur le forum.

Une fois sauvegardé, notre thermostat apparait à deux endroits.

3. Widget & dashboard du plugin

On a tout d’abord accès à un widget sur le dashboard principal de Jeedom.

Cette tuile est parfaitement fonctionnelle: elle permet de régler finement la consigne (boutons +/-) ou de se positionner sur une de nos consignes/modes pré-établis dans la configuration du thermostat. Le bouton de verrouillage permet d’empêcher toute mise à jour, soit via mauvaises manipulations sur le widget (click inopiné pendant un scroll, etc.) soit par des automatismes mis en place (il peut être plus simple par exemple de verrouiller ses thermostats lors d’un départ en congés, que de changer des scénarios ou agendas).

On trouve aussi un dashboard spécifique au plugin, accessible via le menu principal et le sous-menu Thermostat.

Sur ce dashboard, on retrouve la liste de nos thermostats sur la gauche, et quand on sélectionne un de ces thermostats on a davantage de détails :

• Le widget associé,
• Un graphique présentant le cumul du temps de chauffe par jour (chez moi en minutes, devrait être en heures d’après la documentation),
• Un graphique présentant simultanément la température de consigne, la température mesurée dans la pièce, la puissance « virtuelle » demandée au radiateur par le thermostat (résultat d’un calcul sur nombre de cycles de chauffe/arrêt), la température extérieure.

On peut ainsi voir de façon assez simple l’influence d’un changement de consigne sur la puissance demandée au radiateur, et le temps mis pour chauffer, ou encore l’influence de la température extérieure sur la chauffe.

Encore une fois, ce plugin est adaptable à tout type de radiateur quel que soit son mode de pilotage, puisqu’on constate que seuls un ordre de chauffe et d’arrêt sont nécessaires, ainsi qu’au moins une sonde de température interne pour la régulation (et une externe si l’on souhaite utiliser le mode temporel et son apprentissage automatique).

Les commandes exposées par le plugin pour chaque thermostat permettent aussi d’agir dessus par scénario (exemple concret ci-dessous), ou via le plugin alarme par exemple (passer le thermostat en mode hors-gel si activation de l’alarme en mode « longue durée » ).

---

Couplage avec un thermostat Z-Wave SRT-321 mural

Dans mon cas, pour plus de praticité quand on reçoit du monde, j’ai couplé au thermostat « Jeedom » de certaines pièces, un module physique SRT-321 équipé d’une sonde de température, d’une molette de réglage, d’un afficheur, et qui fonctionne sur piles/batteries.

Conséquence du fait qu’il ne soit pas raccordé au secteur: il n’est pas tout le temps « online » et le push de valeurs depuis Jeedom vers ce module nécessite un peu de temps avant de se répercuter, nous y reviendrons. Ce module est réellement capable d’agir comme thermostat autonome, en l’associant directement .. à un module ZWave qui gèrerait un radiateur, ce qui n’est pas notre cas ici avec le module Heatzy. Et même avec un module Zwave, le couplage est possible tout en gardant l’intégration via Jeedom active.

Avec le module Heatzy dans notre entrée, le thermostat mural servira via sa molette, de réglage manuel d’une nouvelle consigne, de thermomètre visuel (en appuyant sur la molette il affiche la température de la pièce), et de sonde de température intérieure à laquelle Jeedom aura accès.

1. Inclusion du module au réseau ZWave & configuration

L’inclusion de ce module est un peu particulière. En effet, après avoir retiré son support arrière (qui sert aussi de fixation murale, très pratique et robuste), on voit un micro interrupteur DIP à 8 switchs.

• Les 2 derniers switchs servent à configurer le mode « temporel » du thermostat (même mode optimisé que celui du plugin Thermostat de Jeedom) et notamment le nombre de cycles de chauffe par heure. Dans notre cas, peu nous importe car nous ne nous servirons pas de ce module en mode thermostat par association directe.
• Le switch n°1 est celui à positionner sur 1 (en haut) pour mettre le module en mode configuration, puis tout se fait avec la molette, avant de repositionner le switch 1 sur 0 (en bas).

Dans Jeedom, on passe le plugin ZWave JS en mode inclusion, puis la gymnastique continue sur le SRT321 (en étant très proche du contrôleur):

• Avec la molette on passe l’écran du module sur « L » (mode auto-apprentissage), on appuie sur la molette,
• Jeedom devrait réagir et trouver le module, l’écran affiche « LP »
• Il est fortement conseillé de réveiller plusieurs fois le module: basculer la molette jusqu’à ce que l’écran affiche « n », appuyer sur la molette, l’écran affiche nP, répéter 1 ou 2 fois.

Normalement à ce stade, votre Jeedom devrait afficher ceci (pour les plus assidus: en effet, l’identifiant du Jeedom en haut à droite n’est pas le même que précédemment, j’ai réalisé la procédure d’appairage sur un autre Jeedom que celui utilisé jusqu’à présent, mais ça ne change rien au tuto 8) ).

On peut aller voir les commandes disponibles et notamment les 3 commandes qui vont nous intéresser:

• La commande info « Consigne-Chaud » qui renvoie la température de consigne paramétrée sur le SRT via sa molette (et qui se met à jour dès que la molette est utilisée sur le SRT: le module se réveille),
• La commande action « Action-Consigne-Chaud » qui sert à mettre à jour la température de consigne sur le SRT, depuis Jeedom (ce qui nécessite que le module se réveille pour récupérer et afficher la nouvelle température, étant donné qu’il est sur piles),
• La commande info « Température » qui contient la température mesurée par la sonde interne du SRT321.

Nous devons trouver un compromis concernant l’intervalle de réveil du module. Cela se règle facilement, mais un intervalle court va rapidement vider les piles. Dans mon cas, je le positionne sur 5mn pour mes tests (= 300 secondes), puis je le repasse à sa valeur par défaut 15mn (= 900 secondes).

Remarque: dans la suite de ce tutoriel, l’équipement a été renommé « SRT321 » et associé à l’objet parent « Entrée » dans lequel se trouve aussi le radiateur que l’on souhaite piloter via son module Heatzy.

2. Scénarios de liaison Jeedom ↔️ SRT321

Zoomons maintenant sur le premier scénario, qui doit détecter un changement de consigne sur le thermostat Jeedom de la pièce « Entrée », pour le reporter sur l’afficheur du SRT321 associé à la même pièce.

Comme on le voit le principe est très simple mais il y a une petite subtilité: ce scénario sert à la mise à jour de plusieurs modules SRT dans la maison. Donc, on va « scruter » les changements de consigne de plusieurs thermostats Jeedom, et répercuter un changement de consigne d’un thermostat précis, sur le « bon » SRT, celui dans la même pièce:

• 1ière capture à gauche : le scénario se déclenche sur changement de valeur de la consigne de deux thermostats Jeedom,
• 2ième capture : on vérifie le déclencheur avec trigger(), et en fonction, on affecte la valeur du thermostat Jeedom de la pièce, au thermostat SRT321 correspondant.

La logique est globalement la même pour l’autre scénario, mais, on va vérifier si les températures de consigne des deux thermostats sont bien différentes avant de mettre à jour la consigne du thermostat Jeedom avec celle du SRT321 (pour éviter une boucle infinie entre les deux scénarios : on met à jour volontairement la température sur le thermostat Jeedom , cela met à jour le SRT avec le 1ier scénario, cela déclenche le 2ième scénario, qui met à jour le Thermostat Jeedom, cela déclenche le 1ier scénario, etc.

Avec notre vérification dans ce scénario, il y aura bien parfois un petit effet « ping-pong » (quand on change la consigne via le SRT en premier), mais qui s’arrêtera très rapidement.

Au niveau des déclencheurs, c’est la même chose qu’avec le 1ier scénario: on scrute les deux SRT321 que l’on a dans la maison. Dans les actions, il y a maintenant deux conditions: la première pour déterminer quel SRT321 a déclenché le scénario, la deuxième pour vérifier si la consigne du SRT est différente de celle du thermostat Jeedom, et si oui, on la met à jour avec celle du SRT.

Une petite remarque: quand on change la consigne sur le SRT, cela réveille instantanément le module, et Jeedom récupère tout de suite le changement de valeur, donc le scénario n°2 se déclenche immédiatement, et met à jour la consigne sur le Thermostat Jeedom, qui adapte donc la température de la pièce via le radiateur qu’il pilote. En revanche, quand on met à jour la température de consigne via le thermostat Jeedom, la température affichée sur le SRT321 ne se mettra à jour que lors du prochain réveil du module, car il est sur pile/batteries, et n’est donc pas connecté en permanence au réseau ZWave.

D’où la nécessité d’adapter en fonction de vos besoins, comme on l’a fait plus haut, le paramètre wakeUpInterval, pour trouver le bon compromis entre réveils fréquents pour des mises à jour plus rapide au détriment d’une consommation plus importante sur les piles du module, et réveils moins fréquents, mais une durée de vie plus longue des piles du module.

A ce stade, nous avons donc intégré un module fil pilote Heatzy sur un vieux radiateur récalcitrant au module qubino, nous l’avons intégré dans Jeedom via un plugin spécifique à ce constructeur, puis intégré au plugin générique Thermostat. Enfin, cerise sur le gâteau, nous avons permis une interaction avec un thermostat physique pour plus de praticité au quotidien.

---

Analyse

Résumons nos observations. Une fois n’est pas coutume, on va aller du plus précis au plus général.

1. Constats spécifiques au module Heatzy et au plugin

Commençons par les points positifs :

• Documentation assez abondante, même si elle mériterait d’être rangée dans le bon ordre sur le site Heatzy 🙂
• C’est français ! Cocorico ! Théoriquement, un bon support de la « norme » fil pilote …
• Et justement, fonctionnement jusqu’à présent (depuis plusieurs mois) sans soucis du point de vue « interopérabilité » avec ce radiateur, qui comprend bien les ordres reçus par le fil pilote du module, ce qui n’était pas le cas avec mes modules Qubino ZMNHJD (qui fonctionnent bien avec certains autres radiateurs cependant).
• Wifi qu’on arrive non sans mal à faire fonctionner sur la bande des 5Ghz, mais sans garantie de pérennité (d’ailleurs aujourd’hui je constate que le module est bien pilotable par wifi, mais pour autant je ne le vois pas dans la liste des périphériques wifi de ma Freebox …).
• Diode apparente pour un contrôle visuel de son état et détection rapide d’un problème entre le module et l’état de son fil pilote, et l’état réel du radiateur (en chauffe ou pas).
• Module wifi sûrement plus simple à installer pour un néophyte et ne nécessitant pas de réseau ZWave et de centrale domotique.

A noter aussi le fait qu’Heatzy fait partie des constructeurs compatibles avec les offres « Zen » et « Liberté » de la société Survoltage qui vous propose, contre réductions à l’achat voire légère rémunération, de réguler automatiquement pour vous et à distance vos temps de chauffe, en fonction des heures nécessaires de délestage pour soulager le réseau électrique, et en utilisant vos équipements connectés.

Ce sont des offres qui pour nous particuliers permettent de mieux amortir l’acquisition de matériel, et qui contribuent à la régulation des pics de charge sur le réseau électrique. C’est ce que l’on appelle l’effacement diffus (cf. article à venir sur ce sujet pour résumer mes recherches, car je ne connaissais pas).

Maintenant, quelques points négatifs.

• Besoin impératif d’une connexion Internet pour fonctionner, pas de mode « local ».
• La géolocalisation, pourquoi ? Je pense que c’est en liaison avec les capacités de délestage à distance, qui doivent pouvoir se faire par zones géographiques en relation avec les capacités de production locale. Mais ça n’est pas dit, ou en tout cas je n’ai pas trouvé où, et cela m’interroge grandement sur les données collectées, et par ricochet la façon dont elles sont hébergées, sécurisées, etc.
• La non compatibilité avec d’une part la bande des 5Ghz, mais aussi avec le bi-bande si le SSID est le même. Probablement rédhibitoire pour quelqu’un qui ne s’y connait pas suffisamment. Un upgrade matériel (mais probablement couteux) du module permettrait peut-être au fabriquant de gérer à la fois le 2.4 et 5Ghz.
• Taille du module physique, qui pourrait bien le rendre apparent dans votre installation (ça a aussi son avantage pour la diode comme déjà dit).
• L’utilisation d’une plateforme IoT chinoise, sachant que des informations assez personnelles y sont a priori stockées (localisation …).
• La latence parfois constatée … La double gestion par l’interface mobile Heatzy et par l’interface Jeedom est, je pense, à proscrire: soit l’un, soit l’autre, pour minimiser les possibilités de désynchronisation et d’affichage pas à jour.
• Les erreurs dans les logs ! Cf. partie spécifique ci-dessous dédiée au mode connecté.
• Constats sur le widget du plugin Jeedom : rien qui ne peut se corriger facilement.
  • Quand on le désactive (pour afficher celui du plugin thermostat plutôt), il se réactive tout seul.
  • L’ordre des boutons ne semble pas customisable.

Enfin, notons qu’il sera préférable -contrairement à ce qui a été réalisé dans ce tuto- d’inclure ce module Wifi à un réseau spécifique « IoT » dans lequel vous regrouperez vos capteurs Wifi, et pour lequel seront positionnées des règles de filtrage entrantes et sortantes très strictes et contrôlées, en face de comportements documentés par les constructeurs (flux & ports utilisés pour des usages précis).

2. Fil pilote: interopérabilité & limites

J’utilise quotidiennement des modules ZWave Qubino « Fil pilote » mais avec certains radiateurs, le pilotage ne fonctionne pas, ou mal. C’est le cas actuellement sur deux sèche serviettes « soufflant » dans mes salles de bain, et d’un radiateur Thermor, pour lequel nous avons justement testé dans cet article si le remplacement par un autre module améliore les choses.

Impédance et courant de fuite

Certains modules utilisent des composants électroniques (Triacs/Optocoupleurs) pour générer le signal « pilote » et ces composants laissent passer un infime courant résiduel même quand ils sont censés être à « 0 » (c’est un courant de fuite).

L’entrée fil pilote de certains radiateurs est très sensible (haute impédance). Elle détecte ce petit courant de fuite et « croit » recevoir un ordre (souvent l’ordre ECO ou un signal mal formé), alors que le module essaie d’envoyer l’ordre CONFORT (qui correspond techniquement à une absence de tension).

Contournement n°1 : module fil pilote + résistance additionnelle

Pour corriger le courant de fuite d’un module fil pilote, on peut ajouter une résistance de charge de 220kΩ ou 100kΩ) entre le fil pilote et le neutre (8€ les 10). Cette résistance sert à « absorber » le courant de fuite pour que le radiateur voit bien un « vrai » 0V. C’est ce que j’ai fait sur mes deux sèche serviettes.

Contournement n°2: micromodule relai/interrupteur classique + diodes

On peut générer les ordres « Pilote » avec du matériel simple et sans grandes connaissances:

• Pour générer 2 ordres (Confort / Éco par exemple) →1 module relai simple sortie (exemple Fibaro FGS‑214) + 1 diode 1N4007,
• Pour générer 4 ordres (Confort, Éco, Arrêt, Hors‑gel) → 1 module relai double sortie (exemple Fibaro FGS‑223) + 2 diodes 1N4007.

Sur un module double, les diodes vont « filtrer » la demi alternance positive ou négative sur les deux sorties du module:

• Sortie Q1 : anode (côté sans trait) de la Diode 1. L’autre extrémité reliée au fil pilote du radiateur.
• Sortie Q2 : cathode (côté avec le trait blanc) de la Diode 2. L’autre extrémité aussi reliée au fil pilote du radiateur.

Par conséquent, en jouant dans Jeedom sur les ordres On/Off des deux sorties, on aura le tableau de combinaisons suivant:

Ordre souhaité	Q1 (Relais 1)	Q2 (Relais 2)	Signal sur le Fil Pilote
CONFORT	OFF	OFF	0V (Rien ne passe)
ÉCO	ON	ON	230V (Les deux demi-alternances se rejoignent)
ARRÊT	ON	OFF	Demi-onde Positive (via la diode 1)
HORS-GEL	OFF	ON	Demi-onde Négative (via la diode 2)

A noter pour les moins bricoleurs, qu’il existe aussi des blocs prêts à l’emploi (par exemple sur Domadoo) et qui se branchent en sortie du module relai.

Ouverture

On touche aux limites du système Fil Pilote :

• Les fabricants français (Heatzy, Delta Dore, Legrand/Netatmo) testent sûrement leurs produits directement sur le parc de radiateurs français (Atlantic, Sauter, Thermor, Noirot…). Ils savent calibrer leur électronique pour gérer les tolérances de ces marques,
• Des fabricants étrangers comme Qubino (Slovénie, racheté par Shelly) ont implémenté la norme « théorique » (les tensions 230V, les demi-alternances). Idem pour les fabriquants de radiateurs qui exportent leurs produits en France.

En France, choisir une solution conçue par une entreprise française pour le fil pilote (comme Heatzy), c’est théoriquement :

• Éviter les incompatibilités électroniques (courants de fuite mal interprétés par le radiateur), et avoir une garantie supposée de fonctionnement « Plug & Play » sur la majorité des radiateurs du marché hexagonal, car le produit a plus de chances d’avoir été validé sur ces appareils spécifiquement,
• S’épargner du bricolage électrique (ne pas avoir à rajouter des résistances ou des diodes dans une boîte d’encastrement déjà étroite).

Vouloir utiliser le pilotage Fil Pilote, c’est donc accepter -aujourd’hui- de faire ses courses dans un rayon plus petit. En effet, cette spécificité française agit comme un filtre naturel sur le marché : elle n’incite pas les constructeurs domotique à supporter la norme uniquement pour un « petit » pays (il n’y a par exemple plus actuellement de modules fil pilote Zwave sur le marché), et elle écarte de facto la multitude de produits génériques à bas coût conçus pour le standard mondial (le On/Off ou thermostat local).

Nous (résidents français) sommes donc contraints de consommer dans un écosystème ‘franco-centré’. Si cela limite la concurrence et maintient des prix parfois plus élevés, c’est aussi la seule garantie d’avoir un matériel qui respecte nativement les subtilités de nos radiateurs sans bricolage hasardeux.

Ce n’est pas forcément « mauvais »: d’une part consommer dans ce cercle restreint favorise souvent l’innovation locale (la French Tech) et le support client en français, contrairement à un module générique acheté sur une méga plateforme e-commerce; d’autre part comme on le verra dans un article sur l’effacement diffus, cela permet de participer à un effort collectif d’économies d’énergie et de gains écologiques évidents, concrets, le tout au niveau national.

3. Mode « connecté » : limites & avantage

On entend ici par mode connecté, le fait qu’un module a besoin pour fonctionner d’une connexion Internet pour communiquer avec une infrastructure tierce, laquelle doit aussi être joignable depuis l’application mobile et/ou Jeedom. On est donc très loin d’un mode « local » à votre domicile comme avec certains modules Zwave ou Zigbee (qui se font de plus en plus rares pour les radiateurs) et un certain nombre de questions se pose, et des conséquences sont à comprendre et à accepter :

• Dépendance à un fournisseur tiers (que ce soit Heatzy ou n’importe quel autre)
  • Quels niveaux d’engagement sur la qualité et disponibilité de son service ?
  • Quels recours en cas de non respect de ces engagements ?
  • Que se passe t’il si défaillance de la société, les serveurs s’arrêtent et le module ne sert plus à rien ?
  • Risques accrus sur la confidentialité
    • A la fois vis à vis des opérateurs de ce fournisseur, et plus généralement de piratage/fuite de données (il ne se passe pas une journée sans qu’on apprenne de nouvelles fuites)
    • Pour rappel l’appairage via l’app mobile nécessite la géolocalisation !
• Dépendance à des réseaux et hébergeurs tiers (pour joindre et héberger le service) et à leur fiabilité/redondance.

A propos de la qualité de service, justement:

• On a vu plus haut que l’on pouvait parfois constater une légère latence entre le moment où un ordre est envoyé par l’interface Jeedom, et le moment où il est renvoyé par l’infrastructure Heatzy, au module,
• On a aussi constaté des avertissements et erreurs récurrents dans les logs: cela pourrait ne pas être gênant mais comment être sûr que ces erreurs n’ont pas impacté le fonctionnement du plugin thermostat ? Dans le cas de simples « refresh » périodiques du plugin cela n’est pas rès grave, mais, sans reprise sur erreur codée dans le module (et il semble qu’il n’y en ait pas), certains ordres peuvent aussi ne pas être envoyés par Jeedom pendant ces périodes d’indisponibilité du service ou de la connexion.

En revanche, comme on l’a aussi vu, ce type de module connecté à une infrastructure « maître » permet de s’intégrer dans un processus de pilotage et régulation de la consommation énergétique au niveau national: l’effacement diffus.

---

Conclusion

Mission accomplie : ce radiateur est désormais piloté sans problème depuis plusieurs mois.

En résumé, ce montage associant module Heatzy Pilote Wifi, le plugin Heatzy de Jeedom, le plugin Thermostat de Jeedom et un thermostat mural SRT321 permet de tirer pleinement parti du fil pilote tout en homogénéisant le pilotage de radiateurs hétérogènes dans une interface unique. Malgré quelques limites (dépendance à Internet et au cloud Heatzy, erreurs HTTP 502 récurrentes, latence liée au modèle connecté et à l’usage de modules sur pile), l’ensemble reste stable, efficace et suffisamment souple pour s’intégrer dans une domotique avancée orientée confort et optimisation énergétique.

Au passage, cette installation répond aux exigences du décret 2023-444, reporté à 2030, sans investissement massif (voire même remboursé grâce aux aides de certains opérateurs d’effacement – article sur le sujet à venir) et en gardant une maîtrise complète via Jeedom.

Me concernant, le point de vigilance majeur reste la dépendance à Internet et à l’infrastructure Gizwits, qui rappelle que pour un pilotage critique et 100% local, une solution Z-Wave reste préférable quand la compatibilité le permet. Cette remarque ne serait plus valable si une API pour contrôle local existait, en supplément à ses capacités Cloud.

Et la suite ?

• A venir, pour automatiser son délestage électrique : article sur l’utilisation du plugin « RTE Ecowatt Tempo« , un scénario de notification « couleur du lendemain » et un scénario de coupure automatique des gros consommateurs électriques, en cas de jours rouges,
• A venir, parce que je ne connaissais pas réellement : article sur ce qu’est l’effacement diffus, et son fonctionnement,
• Réaliser un module fil pilote local à bas prix à base d’ESP32 (et d’autres modules en projets).