Nous avons précédemment relié un compteur Linky à une centrale domotique Jeedom via un modem Teleinfo/TIC en USB sur IP. C’était dans un appartement, avec un réseau wifi facilement utilisable depuis chaque pièce. Nous souhaitons maintenant remonter des informations depuis le compteur Linky d’une autre résidence, la particularité étant ici d’avoir le compteur situé dans une armoire électrique à environ 30 mètres (en extérieur, avec végétation abondante) de la centrale domotique Jeedom située, elle, à l’intérieur de murs épais, dans la maison. Le tout, sans passage de câble possible, et sans alimentation électrique dans l’armoire extérieure !

1. Objectifs & contraintes

L’objectif est d’obtenir une capacité de mesure plus précise et réactive que par l’interface d’EDF ou ENEDIS qui ne s’actualise pas en temps réel (au mieux toutes les 30 minutes), de pouvoir mesurer la consommation de chacune des phases de cette installation triphasée, de vérifier d’éventuels déséquilibres entre les puissances demandées sur chaque phase, de pouvoir déclencher des scénarios en fonction d’événements (délestage par exemple), etc.

Les difficultés sont donc:

1. De ne pas pouvoir utiliser une connexion filaire facilement
   • Empêche d’utiliser un Modem Teleinfo « classique » comme celui utilisé dans un précédent article (sauf en creusant une tranchée)
2. De ne pas avoir d’alimentation électrique dans l’armoire extérieure dans laquelle se trouvent le disjoncteur principal et le compteur Linky
   • Cela empêche actuellement d’utiliser un système avec Raspberry dans l’armoire, qui servirait de relai comme dans notre article précédent, et en supposant d’arriver à établir une liaison Wifi fiable vers la maison (ou filaire si tranchée creusée)
   • Note pour plus tard: c’est tout de même paradoxal dans une armoire électrique ! Il faudra clairement qu’on refasse cette armoire et qu’on ajoute une ou deux prises extérieures protégées par de petits disjoncteurs.
3. L’absence sur le marché de modules Teleinfo en ZWave (qui nécessiteraient par ailleurs d’être auto-alimentés par le le port Teleinfo du compteur Linky)
4. La distance et la végétation et intempéries
   • Peut affecter n’importe quelle technologie sans fil

Vis à vis de la connexion filaire (point 1), l’idée de la tranchée est pour le moment écartée. Par ailleurs, il existe un module Teleinfo Zigbee auto alimenté sur le marché (répond aux points 2 et 3). Mais, on atteint la distance théorique d’utilisation du Zigbee (point 4 à vérifier) …

Nous allons donc essayer d’ajouter le support du protocole Zigbee « hertzien » à la centrale domotique Jeedom de cette résidence, en utilisant un contrôleur Zigbee SMLIGHT SLZB-06M alimenté en POE par un switch auquel nous ajouterons un câble SMA supplémentaire pour déporter l’antenne à l’extérieur du bâtiment, et, sur le compteur électrique distant, nous utiliserons un module Lixee ZLinky lui aussi avec antenne extérieure.

2. Le matériel

La liste du matériel est précisée ci-dessus. Quelques détails néanmoins, en photo.

Sous réserve de fonctionnement (rappel: nous sommes ici en limite de fonctionnement théorique du réseau Zigbee en terme de distance à couvrir), ce système devrait nous permettre de « remonter » dans Jeedom un équipement Zigbee que nous nommerons « Compteur électrique », qui intégrera un certain nombre de commandes de type information, à partir desquels nous afficherons des informations de base. Comme dans mon précédent tutoriel, nous nous en servirons aussi pour alimenter en données un plugin spécialisé dans l’historisation et la visualisation des données de consommation électrique (plugin Teleinfo, gratuit).

3. Fonctionnement d’un réseau Zigbee

Parce que jusqu’à présent j’ai toujours équipé mes installations domotiques avec du matériel ZWave, que je trouve fiable, j’ai eu besoin de me documenter un minimum sur le Zigbee. Voici un résumé.

Zigbee est un protocole de communication sans fil conçu pour la domotique et  » l’Internet des Objets « (IoT). Il permet de connecter des objets entre eux dans un réseau local, en utilisant peu d’énergie et en offrant une grande flexibilité grâce à sa topologie maillée.

3a. Différences principales entre Zigbee et Z-Wave

3b. Avantages et inconvénients

Zigbee :

• Avantages :
  • Très grande capacité de maillage (nombre illimité de routeurs, jusqu’à 65 000 appareils).
  • Large choix d’appareils, multi-marques, standard ouvert.
  • Coût souvent plus bas.
• Inconvénients :
  • Utilise la bande 2,4 GHz, potentiellement sujette aux interférences Wi-Fi.
  • Des soucis d’interopérabilité entre marques (amélioré avec Zigbee 3.0).

Z-Wave :

• Avantages :
  • Bande de fréquence moins encombrée (868 MHz), moins d’interférences.
  • Certification stricte, meilleure compatibilité entre marques.
• Inconvénients :
  • Limité à 232 appareils par réseau.
  • Matériel souvent plus cher.
  • Moins de choix d’appareils, standard propriétaire.

Conclusion 1 : nous aurons besoin d'optimiser la configuration des réseaux et canaux WIFI et Zigbee pour minimiser le risque d'interférences entre ces deux protocoles. Cela fera l'objet d'un autre article sur ce blog.

3c. Architecture d’un réseau Zigbee : rôles et topologie maillée

Les trois types d’appareils Zigbee

1. Coordinateur
   • Il crée le réseau Zigbee, attribue les adresses et gère la sécurité.
   • Il n’y en a qu’un par réseau.
   • Exemple : SLZB-06M, clé USB Zigbee.
2. Routeur
   • Il relaie les messages Zigbee d’autres appareils.
   • Il étend la portée et la robustesse du réseau.
   • Alimenté en permanence (ampoule, prise connectée, SLZB-06M flashé spécifiquement pour faire routeur, …).
3. Terminal (end device)
   • Il ne relaie pas les messages.
   • Il communique uniquement avec son « parent » (coordinateur ou routeur).
   • Souvent sur batterie (capteur, télécommande…).

Topologie maillée (mesh)

Dans un réseau maillé, chaque routeur peut relayer les messages Zigbee d’autres appareils, ce qui permet de multiplier les chemins possibles entre les appareils et le coordinateur. Cela augmente la portée et la fiabilité du réseau.

Important : Les terminaux (end devices) ne participent PAS au maillage. Ils ne font que se connecter à un parent (coordinateur ou routeur) et ne transmettent pas les messages des autres. Seuls les routeurs et le coordinateur créent effectivement le maillage du réseau : ce sont eux qui relaient les messages. Plus vous avez de routeurs, plus votre réseau est robuste et étendu.

Conclusion 2 : le SMLIGHT SLZB-06M doit obligatoirement être configuré en mode contrôleur et non routeur, car s'il était en routeur nous aurions besoin d'un autre périphérique capable d'être contrôleur Zigbee.

4. Intégration du Zigbee à Jeedom via MQTT et Zigbee2MQTT

Nous l’avons vu dans les précédents articles: le grand intérêt d’une passerelle domotique comme Jeedom est de centraliser différents types de données, d’automatiser des actions et tout cela en étant « agnostique » vis à vis des protocoles utilisés. Mais, concernant l’intégration technique du protocole Zigbee à Jeedom, plusieurs possibilités existent.

4a. Quel plugin Jeedom ?

• Le Plugin Zigbee officiel: il permet à Jeedom de dialoguer directement avec un contrôleur Zigbee (clé USB, passerelle Ethernet comme le SLZB-06M) sans intermédiaire supplémentaire. Il s’appuie sur la librairie open-source Zigpy pour assurer une compatibilité large avec de nombreux matériels Zigbee.
  • Avantages :
    • Intégration simple et directe,
    • Interface native Jeedom,
    • Pas besoin d’installer MQTT ou d’autres services.
  • Limites:
    • Moins de personnalisation avancée que Zigbee2MQTT,
    • Moins de support pour certains modules exotiques.

• Le plugin JeeZigbee fait l’interface entre Jeedom et le logiciel Zigbee2MQTT (aussi appelé parfois librairie Z2M) qui gère le réseau Zigbee et expose tous les objets Zigbee du réseau via le protocole MQTT en les « envoyant » sous forme de messages à un broker MQTT (ex : le logiciel Mosquitto). Le broker MQTT sert donc d’intermédiaire : il publie les messages provenant de Zigbee2MQTT et Jeedom (ou d’autres « clients ») les recevra en venant les lire sur le broker MQTT via le plugin Jeezigbee.
  • Avantages :
    • Très grande compatibilité avec de nombreux modules, y compris exotiques,
    • Interface web Zigbee2MQTT pour la gestion avancée du réseau,
    • Possibilité de personnaliser les convertisseurs pour des modules non supportés nativement.
  • Limites:
    • Installation et configuration plus technique (plusieurs services à faire communiquer),
    • Dépendance à MQTT.

• Le plugin ZigbeeLinker permet lui aussi d’intégrer Zigbee à Jeedom via Zigbee2MQTT et MQTT,  avec plusieurs modes d’installation possibles (tout local, antenne déportée, etc.). Il peut être utile si l’on souhaite une intégration Zigbee2MQTT/MQTT différente ou plus personnalisée, peut-être même plus poussée.

Tableau récapitulatif

Conclusion

Avant de choisir le plugin, nous devons d’abord choisir le type d’architecture: simplifiée sans MQTT, ou avec MQTT. Pour notre utilisation, notre choix se portera sur l’utilisation de MQTT pour les raisons suivantes:

• Indépendance et robustesse de l’architecture
  • Le coordinateur Zigbee (ex : SLZB-06M) se contentera de gérer le réseau radio. Zigbee2MQTT prendrea en charge l’interprétation, la gestion et la traduction des messages Zigbee en MQTT pour Jeedom,
  • Si Jeedom redémarre ou plante, le réseau Zigbee et ses communications persisteront via Zigbee2MQTT/MQTT. La résilience du système sera accrue, car la “passerelle Zigbee” continuera de fonctionner même si le moteur domotique central (Jeedom) devient indisponible.
• Universalité et interopérabilité
  • Zigbee2MQTT permet à plusieurs systèmes d’accéder simultanément aux informations des périphériques Zigbee : il rend tous les équipements intégrables simultanément par Jeedom, Home Assistant, Node-RED, OpenHAB, etc. Il suffit qu’ils sachent chacun lire les topics MQTT. Ce n’est plus une passerelle propriétaire associée à un seul système.
  • Cela permet de mutualiser un même réseau Zigbee sur plusieurs plateformes domotiques parallèles (ou en transition).
• Large compatibilité et évolutivité
  • Zigbee2MQTT gère des milliers de modules Zigbee, y compris ceux mal reconnus par les plugins natifs. Sa communauté contribue en permanence à l’ajout de nouveaux modèles.
  • Ajouter un module rare, personnaliser ses fonctions, tester rapidement les dernières intégrations est – d’après mes recherches – plus simple avec Zigbee2MQTT.
• Centralisation des messages (MQTT)
  • Architecture “loose coupling” : Grâce à MQTT, chaque composant (Zigbee, Z-Wave, automates, Jeedom…) dialogue indépendamment avec ses pairs via le broker. Cela facilite la supervision, l’analyse, l’automatisation, voire la redondance/réplication du système.
  • Séparation claire des responsabilités :
    • Le coordinateur gère le réseau radio,
    • Zigbee2MQTT gère la conversion protocolaire et la gestion logicielle,
    • MQTT centralise les échanges,
    • Jeedom orchestre l’ensemble et lit les informations qui l’intéressent sur MQTT.
• Découverte et intégration automatiques
  • Auto-discovery : Zigbee2MQTT publie dynamiquement sur MQTT la configuration complète des modules (noms, commandes, états, etc.), que Jeedom peut consommer pour générer automatiquement les équipements Zigbee associés, sans demander à l’utilisateur de tout paramétrer à la main.

Quant au plugin nous utiliserons JeeZigbee, le plugin officiel supporté par l’équipe Jeedom, qui permet par ailleurs une grande souplesse de configuration. A noter qu’il faudra débourser 6€ (idem que le coût du plugin ZigbeeLinker).

Il convient maintenant de faire un petit zoom sur l’architecture avec MQTT, car le plugin ZWave officiel l’utilise aussi.

4b. Architecture logicielle avec MQTT

Message Queuing Telemetry Transport (MQTT) est un protocole de communication M2M (machine to machine) de type messagerie qui permet aux appareils de communiquer de manière asynchrone à travers des réseaux sous contraintes vers des systèmes distants. Chaque client MQTT, application ou dispositif de traitement de données, producteur ou consommateur de données, doit se connecter à un serveur central (le broker MQTT) avant de communiquer avec d’autres clients MQTT via des messages publiés sur un sujet particulier. Le serveur accepte les messages publiés sur des sujets et les livre aux consommateurs intéressés à ces sujets selon un modèle d’interaction Publication/Abonnement. De nombreux clients, producteurs ou consommateurs, peuvent s’abonner aux mêmes sujets et utiliser les informations à leur guise.

Dans Jeedom, on pourrait décrire l’architecture logicielle pour l’utilisation du ZWave et du Zigbee, de la façon suivante.

Chaque protocole a son contrôleur matériel et son service logiciel qui “parle” MQTT – c’est le broker qui centralise toutes les communications vers Jeedom, via le plugin MQTT Manager.

                       +-----------------------------+
                       |           JEEDOM            |
                       |                             |
                       +-------------+---------------+
                                     |
                          +----------v----------+
                          | Plugin MQTT Manager |						 
                          +----------+----------+
                                     |						 
                               +-----v------+
                               |   MQTT     |    ← Broker, centralisateur
                               | (Mosquitto)|
                               +-----+------+
                                     |
                         +-----------+-------------+
                         |                         |
                  +------v-------+         +-------v-------+
                  |  ZWave JS    |         | Zigbee2MQTT   |
                  +------+-------+         +------+--------+
                         |                        |
                  +------v-------+         +------v--------+
                  |  Contrôleur  |         | Coordinateur  |
                  |    ZWave     |         |    Zigbee     |
                  +----+----+----+         +----+-----+----+
                       |    |                   |     |
                  objets... objets...      objets...  objets...
                  (ZWave)  (ZWave)         (Zigbee)   (Zigbee)

4c. Architecture générale de la future installation

J’ai essayé de représenter le plus simplement possible d’une part l’architecture fonctionnelle générale avec les composants utilisés pour arriver à surveiller ce compteur distant, et d’autre part les objets Jeedom que l’on va manipuler grâce à ces composants.

On retrouve ici les composants listés précédemment et on constate que malgré l’empilement logiciel et hardware nécessaire, au final il n’y a que deux objets Jeedom qui seront réellement utilisés: le compteur électrique « jardin » vu par le plugin JeeZigbee (aussi appelé Z2M) et le compteur électrique « Teleinfo » vu par le plugin Teleinfo, qui produit un dashboard consultable par l’utilisateur final.

5. Installation concrète

Dans notre cas, c’est à dire un serveur domotique central, tous ces composants logiciels s’installent et se configurent en réalité de façon simple via des plugins Jeedoms qui prennent en charge la gestion des dépendances au niveau du système d’exploitation. Tout tourne sur le même ordinateur: Jeedom, le broker MQTT, la passerelle Zigbee2MQTT, et on relie à cet ordinateur le Coordinateur Zigbee.

5a. Dépendances: Broker MQTT & Plugin MQTT Manager

Cette installation Zigbee est en fait simplifiée car … Le plugin Jeedom ZwaveJS que l’on utilise déjà (et qui déploie le logiciel ZwaveJS), utilise lui aussi un broker MQTT. Par conséquent, quand le plugin ZWaveJS a été installé, il a automatiquement installé le plugin MQTT Manager, qui a lui même déployé un broker Mosquitto local sur la machine !

5b. Déploiement du coordinateur SLZB-06M

Branchement

Un des avantages du SLZB-06M est de pouvoir fonctionner en Wifi, ou en Ethernet ou en USB. Dans le cas d’une utilisation Wifi, il nécessite aussi une alimentation externe, en USB. En Ethernet, il supporte l’alimentation PoE (Power over Ethernet).

Considérant qu’un réseau filaire est plus fiable qu’un réseau sans fil, le choix est vite fait: nous relions le switch PoE à notre box Internet, à Jeedom qui était précédemment directement relié à la Box Internet, et au SLZB-06M.

L’antenne du SLZB-06M est remplacée par une extension de câble SMA dont l’autre extrémité débouche à l’extérieur de la maison, du même côté que le compteur électrique que l’on souhaite raccorder. A ce stade, je n’ai aucune assurance que ce premier test en conditions « idéales » fonctionne et permette d’appairer à distance le module Lixee.

Interface de configuration

Le module se déclare sur le réseau (par mDNS) et est théoriquement directement accessible à l’adresse http://slzb-06m.local . Nous irons dans tous les cas changer et fixer son adresse IP sur le routeur Internet (qui fait aussi serveur DHCP) et au pire, nous pourrons accéder à son interface directement par son adresse IP.

On vérifie d’abord si des mises à jour sont disponibles. On remarque au passage l’interface utilisateur, très claire, explicite, agréable à utiliser.

N’oubliez pas d’activer l’authentification HTTP et de choisir un mot de passe d’une longueur appropriée. Point négatif: je n’ai PAS trouvé comment activer un point de terminaison d’administration HTTPS à la place du HTTP configuré par défaut.

Sur l’onglet « Mode » nous pouvons vérifier qu’il est bien configuré en mode coordinateur. C’est important, car il peut aussi être configuré en mode Routeur, ce qui ne fonctionnerait pas dans notre cas (il faut d’abord un coordinateur).

5c. Plugin JeeZigbee/Zigbee2MQTT

Depuis l’interface d’administration de Jeedom, aller sur le Market puis installer le module JeeZigbee (aussi appelé parfois Zigbee2MQTT). Nous allons l’installer en version Stable.

Ensuite, nous vérifierons les dépendances à installer. Il s’agit d’une étape très importante.

Nous allons maintenant configurer le plugin afin qu’il puisse communiquer avec le coordinateur SLZB-06M. Nous aurons besoin de l’adresse IP et du port que nous avons vus précédemment lors de la configuration du coordinateur. Notez que nous utiliserons le dernier protocole recommandé pour Zigbee : Ember.

Cette configuration est conforme à la configuration suggérée dans la page SLZB-06M Z2M :

Nous allons aussi ajouter un paramètre spécifique transmit_power pour forcer la puissance d’émission à son maximum 20 (versus 5 par défaut) directement dans un fichier de configuration du plugin JeeZigbee/Z2M dans Jeedom, car l’interface de la page de configuration du plugin ne permet pas de le saisir. Pour cela, on se sert de l’éditeur de fichier embarqué dans l’onglet & Menu Settings/System/Configuration.

Vous devrez redémarrer le démon sur la page de configuration pour que ces paramètres soient pris en compte. Une vérification rapide dans le fichier journal Z2md, en cliquant sur le petit bouton bleu en haut à droite, devrait montrer qu’il n’y a pas d’erreurs et que le protocole Embed est utilisé.

5d. Branchement du contrôleur au compteur & inclusion

Le module Lixee utilisé ayant lui aussi une antenne déportée, il va falloir percer l’armoire électrique et sécuriser le passage d’antenne pour écarter toute possibilité d’intrusion d’eau. Donc, avant de faire cela, nous allons réaliser un premier test « armoire ouverte » de façon à vérifier si le module Lixee_TIC et le contrôleur se « voient » et si l’inclusion du module au réseau Zigbee arrive à se faire à distance.

Le Lixee Zlinky_TIC passe automatiquement en mode inclusion dès qu’il est branché au compteur électrique Linky, aucune manipulation supplémentaire n’est nécessaire côté module; donc la seule chose que nous ayons à faire, est de passer le contrôleur en mode inclusion:

• Soit depuis la page de configuration du plugin Zigbee2MQTT de Jeedom

• Soit directement depuis le dashboard de Zigbee2MQTT accessible depuis la page de configuration du plugin JeeZigbee/Zigbee2MQTT de Jeedom (en utilisant l’ID indiqué sous le bouton).

Maintenant, nous branchons physiquement le Lixee Zlinky…

Cette étape est absolument cruciale dans notre processus, car elle montre que malgré la distance, l’inclusion du module Lixee depuis le compteur électrique jusqu’au contrôleur s’est bien déroulée. C’est de bonne augure pour la suite: en général l’étape d’inclusion est la plus sensible et capricieuse. Nous vérifierons par la suite la qualité de la connexion, son évolution, voire son optimisation dans un autre article.

Paramétrons maintenant le module détecté, dans Zigbee2MQTT: remontée d’information toutes les 30 secondes (on peut le baisser un peu mais évitez de surcharger le réseau et le MQTT), compteur en mode standard (à vérifier chez vous), compteur et installation en triphasé dan s cette maison, pas de production d’électricité, abonnement TEMPO.

Surtout, passez la précision des KWh à 3 !

Vérifions maintenant is une mise à jour est disponible, dans le menu « OTA ».

Lançons la mise à jour.

Maintenant nous retournons voir notre Jeedom, et normalement un nouveau périphérique a dû être automatiquement remonté dans le plugin Z2M, grâce à l’envoi de messages MQTT d’auto-découverte par la librairie Zigbee2MQTT sur le topic « zigbee2MQTT », et la récupération de ces messages par le plugin Jeedom JeeZigbee/Z2M abonné au topic ‘zigbee2mqtt’ visible en configuration.

Maintenant, nous allons aller voir les commandes disponibles sur ce nouveau périphérique que nous avons rebaptisé « Compteur Electrique » (important de s’en rappeler pour la suite), et qui va nous servir de base de travail dans Jeedom. Ces commandes devraient correspondre aux données « exposées » par la librairie Zigbee2MQTT et visibles dans son interface de configuration.

Les « compteurs » et les données correspondent entre les deux interfaces, c’est parfait. Maintenant, nous pouvons historiser les données, choisir de les afficher sur le dashboard, réaliser des calculs dessus, déclencher des scénarios en se basant sur leurs valeurs ou certains événements, par exemple en choisissant de délester certains équipements en cas de pic de consommation, ou envoyer une alerte en cas de surcharge d’une phase par rapport aux autres (cette installation est en triphasé).

La liste des données exposées est disponible ici sur la page du module du site Zigbee2MQTT.

6. Configuration d’un widget sur le dashboard

Créons maintenant un widget d’affichage simple à partir de l’équipement « Compteur Electrique » de base qui a été configuré par le plugin JeeZigbee/Z2M de Jeedom. Ce widget va nous servir à afficher:

• La qualité de la connexion Zigbee,
• La puissance totale souscrite/admissible,
• Le tarif en cours (heure pleine, heure creuse, etc.),
• La puissance instantanée totale (en Volts.Ampères (VA)),
• Pour chaque phase: sa puissance instantanée (VA), son voltage (V), l’intensité délivrée (A)

Pour cela, nous avons tout d’abord besoin de sélectionner quelles informations on veut afficher sur le widget. Cela se passe dans la configuration de l’équipement, onglet « Commandes ».

Ensuite nous allons configurer le mode d’affichage du widget de cet équipement via le bouton « Advanced Setup » en haut à droite de la capture précédente: nous définissons un affichage de type tableau, et nous affectons dans les différentes cellules, soit les informations à afficher, soit du texte pour introduire l’information affichée.

Ne pas oublier de sauvegarder, et maintenant allons voir ce que ça donne sur le dashboard de Jeedom …

Nous voyons ici que la mise en page n’est pas encore terrible; mais c’est normal il nous reste un peu de configuration à réaliser. Cette fois-ci cela se passe directement dans le mode « édition » du dashboard principal de Jeedom, accessible par la petite icône en forme de crayon, tout en haut à droite.

Le mode édition se matérialise par le bandeau bleu en haut de l’écran, et par les 3 petits points verticaux qui apparaissent en haut à droite de chaque widget sur le dashboard. Ces widgets sont aussi redimensionnables et déplaçables sur le dashboard. Cliquons sur les 3 petits points.

Nous allons maintenant configurer les commandes que nous avons choisi d’afficher, pour masquer leur nom et ne garder que leur valeur. C’est très simple, prenons l’exemple de la première commande « Qualité connexion », il suffit de décocher « Show name » puis de cliquer sur « Apply ».

Il n’y a plus qu’à faire de même pour les autres informations affichées par le widget, et voilà, plus qu’à fermer cette popup de configuration, redimensionner éventuellement le widget, et re cliquer sur le crayon en haut à droite pour enregistrer la disposition et sortir du mode édition.

Un dernier petit raffinement pour la fin de cette section … Nous allons afficher en fond de widget, la courbe générale de la puissance délivrée par le compteur électrique, pour avoir un aperçu très rapide d’éventuels pics. Retournons dans la configuration du module Zigbee, et dans sa configuration avancée, mais cette fois-ci dans l’onglet « Display ».

Nous choisissons d’afficher l’information SINSTS, sur une période d’une journée, en mode courbe.

Notez que comme nous avons aussi choisi d’historiser certaines données, en plus de les afficher, certaines des données affichées peuvent être « cliquées » de façon à afficher leur historique.

7. Utilisation du plugin Teleinfo

7a. Installation depuis le market

Prochaine étape: utiliser ce plugin gratuit qui va nous permettre de garder en mémoire l’historique des consommations, de faire des statistiques basées sur le type de tranche horaire (heure pleine, heure creuse, etc.), de comparer les consommations de l’année précédente avec l’année en cours (sans pouvoir les deviner: le plugin ne peut faire des statistiques que sur les données qu’il a « vues passer »), d’estimer les coûts, etc.

Direction le market pour obtenir le plugin, et ouvrir sa documentation.

7b. Création manuelle d’un équipement Teleinfo

La méthode que je vais maintenant dérouler n’est pas la méthode standard documentée. En effet, ce plugin est normalement capable de « s’alimenter » à partir de données au format TELEINFO d’ENEDIS récupérées soit par un modem TIC Teleinfo branché en USB (cf. article précédent sur le sujet avec un tel modem) ou à partir de données toujours au format TELEINFO standard d’ENEDIS, mais arrivant par une file de messages MQTT.

Problème: le module ZLinky que nous utilisons dans cet article pour de la transmission Zigbee « longue distance » et la librairie Zigbee2MQTT ne formatent pas les messages MQTT au format standard TELEINFO, de ce fait le plugin TELEINFO n’arrive pas, de lui-même, à détecter les informations remontées par le module, il ne crée donc pas automatiquement d’équipement « compteur teleinfo » à partir des informations reçues, et il ne sait donc pas non plus, en cascade, mettre à jour automatiquement ses propres valeurs de consommation reçues et nécessaires pour ses opérations.

Toutefois, parce que ce plugin procure un dashboard très utile, nous allons bien chercher à l’utiliser, mais:

1. En créant le compteur et ses commandes manuellement => contournement du problème de messages MQTT non standards qui empêchent le plugin TELEINFO de détecter tout seul notre compteur électrique et de créer sa version de compteur « Teleinfo »,
2. En alimentant les commandes du nouveau compteur « Teleinfo » à partir d’un scénario plutôt basique que nous allons configurer => contournement d’un autre problème du module Zlinky vu par Zigbee2MQTT qui est de remonter des valeurs de consommation en kWh plutôt qu’en Wh comme attendu par le plugin Teleinfo.

Commençons par créer manuellement un nouveau compteur dans le plugin Teleinfo.

Notez ici que vous pouvez utiliser le nom et l’ID que vous souhaitez (en rouge sur la précédente capture d’écran); alors que si le plugin était destiné à s’alimenter à partir d’un modem USB ou de messages MQTT, l’ID ici correspondrait à celui qui remonte dans les trames lues. De la même façon, nous n’avons pas besoin de cocher la case de création automatique des commandes (en vert).

J’ai appelé ce nouvel équipement « Compteur Teleinfo » et l’ai placé dans la pièce « Bureau », pour le distinguer facilement du « Compteur Electrique » situé dans le « Jardin ».

Notez aussi que j’ai valorisé (en bleu) le coût en euros du kilowatt.heure, selon mon abonnement (ici, abonnement EDF TEMPO).

Sauvegardez, puis allez dans l’onglet des commandes. Vous constaterez qu’un grand nombre de commandes sont déjà présentes, ce sont celles qui servent à l’historisation des valeurs et à la production de statistiques. Elles seront utilisées et affichées par le dashboard du plugin, et calculées par des opérations automatiquement et régulièrement exécutées, à partir des données de consommation recueillies sur les différents index que le plugin lit normalement en MQTT ou par USB, mais que nous allons devoir ici manuellement remonter au plugin.

7c. Création manuelle des commandes de consommation

Comme nous l’avons vu, des commandes sont automatiquement créées, mais pas celles qui permettent d’alimenter le plugin avec les données de consommation de notre équipement « Compteur Electrique » de JeeZigbee. Nous allons tout d’abord procéder à leur ajout.

De quelles données avons-nous besoin ? L’identifiant du compteur, toujours utile (donnée ADSC en trame TELEINFO standard), les consommations par index (données EASF01 à EASF06 dans notre cas d’abonnement TEMPO), la consommation totale (EAST), le type d’abonnement souscris (NGTF), la tarification en cours dans l’abonnement souscrit (LTARF), et le courant « débité » sur chaque phase et au total (SINSTS1 à 3 et SINSTS). Soit, 14 données, donc 14 commandes à créer dans le compteur Teleinfo.

Nous allons nommer chacune des nouvelles commandes, par le nom du champ normalement reçu dans la trame TELEINFO, et dans la colonne « Data » indiquer de quel type de donnée il s’agit, pour que le plugin sache s’y retrouver.

Retournons dans l’onglet « Equipement » pour faire correspondre les commandes de consommation aux INDEX Teleinfo que nous souhaitons utiliser pour les calculs du plugin. Le nommage des index et leur association aux commandes créées précédemment dépend ici encore une fois du type d’abonnement souscrit à votre fournisseur d’énergie.

• Heures creuses en tarif BLEU = index/commande EASF01
• Heures pleines en tarif BLEU = index/commande EASF02
• Heures creuses en tarif BLANC = index/commande EASF03
• Heures pleines en tarif BLANC = index/commande EASF04
• Heures creuses en tarif ROUGE = index/commande EASF05
• Heures pleines en tarif ROUGE = index/commande EASF06

7d. Scénario d’alimentation ZLinky JeeZigbee vers Teleinfo

Notre équipement « Compteur Teleinfo » du plugin Teleinfo est maintenant configuré, il nous reste à l’alimenter en données. Nous allons pour cela créer un scénario qui va mettre à jour dynamiquement les commandes que nous venons de créer, à partir des données de l’équipement ZLinky de JeeZigbee/Z2M.

Le scénario est de type « provoqué », c’est à dire qu’il sera exécuté à chaque fois qu’une des valeurs derrière une des commandes indiquées dans les déclencheurs évoluera. C’est donc très simple, dans l’onglet « General » du nouveau scenario, nous positionnons en déclencheurs toutes les commandes permettant de surveiller les index de consommation (EAST* et EAST), mais aussi celles relatives à la puissance instantanée délivrée (SINST*).

Enfin, dans l’onglet Scenario, nous affectons à chacune des nouvelles commandes de l’équipement « Compteur Teleinfo », les valeurs des commandes équivalentes de l’équipement « Compteur Electrique ». Petite subtilité: nous convertissons les données en kWh des index EAST et EASF, vers des Wh. Il suffit pour cela de les multiplier par 1000.

On n’oublie pas de vérifier que l’on a coché la case « actif » dans l’onglet Général, et l’on sauvegarde. A partir de maintenant, chaque remontée de valeur du Zlinky impactera d’abord l’équipement « Compteur Electrique » du plugin Z2M, puis notre scenario ira mettre à jour les données de l’équipement « Compteur Teleinfo », lequel les historisera et produira des satistiques utilisées sur son dashboard.

On peut vérifier l’activité du scénario en allant d’abord vérifier ses logs.

Puis, on peut aller vérifier les valeurs associées aux commandes de l’équipement « Compteur Teleinfo », qui normalement devraient être les mêmes (au delta près du temps qu’il y a eu entre mes captures d’écran).

On constate que les données sont identiques, à l’exception de EASF02 qui a légèrement augmenté entre les deux captures d’écran. C’est parfait.

7e. Dashboard du plugin Teleinfo

J’ai laissé passer quelques jours depuis la configuration du scénario d’alimentation en données, pour présenter le dashboard du plugin Teleinfo, avec les premières statistiques. On peut déjà comparer les consommations et coûts sur quelques jours, et cela permet de détecter les principaux postes de consommation (en fonction des appareils consommateurs que l’on allume ou pas), et les déséquilibres entre phases, qui peuvent s’avérer problématiques.

Pour accéder au dashboard vous devez l’avoir activé dans la configuration du plugin. Ensuite, il suffit d’accéder au menu Home / Téléinfo.

La première figure est un tableau permettant de visualiser le détail des consommations à J, J-1, Cumul du mois en cours, Mois -1, Cumul de l’année en cours, Année -1, tout cela par période tarifaire, et en reprenant les libellés des périodes tarifaires que nous avons configuré dans l’équipement.

Ensuite, nous voyons l’historique de la puissance délivrée (en Volts Ampères), par phase. On voit par exemple ici que sur les dernières 24h (quasiment sans activité dans la maison), la phase 3 de l’installation est globalement 2 à 3 fois plus chargée que les autres. Ce n’est pas bien grave à ce stade car les intensités délivrées restent faibles, aucun gros équipement ne consomme, mais ce sera à surveiller.

Le deuxième graphique fait apparaitre une notion intéressante que nous n’avons pas exploitée: le plugin est aussi capable d’intégrer la production d’électricité, dans le cas d’installation personnelle raccordée au réseau domestique via le fournisseur d’électricité (revente de son électricité produire). Ce n’est pas notre cas ici, pas de telle installation, donc pas de notion d’électricité produite sur les statistiques.

Ensuite nous pouvons comparer les consommations quotidiennes, puis les coûts associés, et suivre leur évolution dans le temps, toujours en fonction de la période tarifaire. Ici aussi si nous étions producteur d’électricité, les informations correspondantes apparaitraient.

La même chose de façon mensuelle.

ET enfin, la même vue mais annuellement.

A terme, cela permet un véritable suivi comparatif dans le temps. Par exemple, voici la vue de ce même plugin, dans mon appartement (installation réalisée en mai 2024):

8. Qualité de la connexion entre le Lixee et le contrôleur

8a. Indicateur de suivi

Un indicateur de qualité de liaison existe avec le Zigbee, il s’agit du LQI, qui signifie Link Quality Indicator.

Entre deux nœuds du réseau Zigbee, la valeur du LQI reflétera la qualité du lien radio. Le LQI ne mesure pas la puissance brute du signal (c’est le rôle du RSSI, pour Received Signal Strength Indicator), mais plutôt la fiabilité de la communication — c’est-à-dire la proportion de bits reçus sans erreur. Ainsi, une liaison peut présenter un RSSI correct mais un LQI faible si elle subit beaucoup d’interférences.

A noter que différents chipsets peuvent estimer le LQI différemment, selon leurs algorithmes internes de calcul, mais théoriquement les formules doivent rester proches.

La plage de valeurs du LQI est comprise entre 0 et 255 :

• 200 à 255 : liaison excellente et stable,
• 150 à 199 : bonne qualité, à surveiller,
• 100 à 149 : qualité moyenne, communication possible mais intermittente,
• 0 à 99 : qualité mauvaise, souvent cause de pertes de paquets ou de déconnexions ; il faut rapprocher l’appareil ou ajouter un routeur Zigbee pour améliorer le maillage.

8b. Surveillance

Dans le widget précédemment configuré, nous avons justement pris soin d’afficher le LQI (quelle coïncidence !), car il est remonté par l’équipement « compteur électrique » Zigbee2MQTT.

Surtout, nous avons aussi pris soin d’historiser ses valeurs, de façon à ce que l’on puisse vérifier la progression du LQI dans le temps.

8c. Analyse

Jetons un oeil à l’historique complet, via le menu « Analyse > Historique ». Comme j’ai mis quelques mois avant de publier cet article, l’avantage est d’avoir pas mal de recul sur l’évolution du LQI, justement 🙂

Comme nous le voyons, depuis son installation jusqu’au 23 aout, le LQI était en moyenne de 110, ce qui est moyen, mais correct.

Le 23 aout, il chute brutalement jusqu’à 80, puis, jusqu’au 3 octobre, le signal fluctue énormément, mais progresse globalement à la hausse pour revenir à 100 (on se croirait dans une analyse de marché boursier/crypto à forte volatibilité …).

Le 3 octobre, il rechute ensuite brutalement jusqu’à 60 voire 50 le 3 novembre, et remonte progressivement en fluctuant énormément jusqu’à, aujourd’hui 22 novembre, environ 80.

D’un signal de qualité correcte, nous avons donc maintenant un signal plutôt médiocre. Néanmoins, la remontée de valeurs fonctionne bien, les index de consommation sont bien mis à jour. Mais la transmission n’est pas optimale et il est vraisemblable que des retransmissions soient nécessaires sur le réseau Zigbee pour arriver à un résultat finalement viable, dans le plugin Teleinfo. Merci aux algorithmes de retransmission dans les protocoles réseau et couches OSI supérieures.

Je précise que pour le moment, puisque cela fonctionne tout de même bien vu de Jeedom, je n’ai pas cherché à analyser plus en détail ce phénomène. J’ai tenté un reboot du contrôleur Zigbee mais cela n’a rien changé. J’ai aussi vérifié si le paramètre power_transmission 20 ajouté dans le fichier configuration.yaml du plugin était toujours présent a^rès quelques mises à jour du plugin. Je pense que c’est tout simplement parce que l’antenne extérieure reliée au SLZB-06M n’est pas vraiment fixée au mur et est du coup plutôt … mobile en fonction du vent. L’analyse et j’espère la correction de ce phénomène fera partie soit d’une update de cet article, soit d’une section spécifique dans un article à venir sur l’arrangement des réseaux Zigbee & Wifi.

Voilà, l’article est (presque !) fini, merci aux lecteurs qui ont tenu jusqu’ici <8)

9. Conclusion

Ce tutoriel, un poil long, a permis de se familiariser avec le protocole Zigbee, d’installer un Coordinateur/Contrôleur efficace permettant la surveillance « longue distance » d’un compteur électrique EDF Linky (en France), et d’utiliser les données remontées dans un plugin permettant un suivi « longue durée » de la consommation électrique, sous plusieurs vues.

Il ne reste plus maintenant qu’à suivre régulièrement les consommations, les couts, et de façon générale agir sur les principaux équipements et habitudes de consommation pour tenter d’être plus efficaces et réduire l’utilisation de l’électricité, et donc les coûts (et pollution) associés. En apprenant aussi comment est constituée l’installation électrique dans le détail, notamment dans notre cas quels sont les appareils connectés à quelle phase, on peut envisager d’automatiser des actions immédiates de délestage si nécessaire quand on détecte un trop grand déséquilibre entre phases (ce qui peut nuire à certains équipements alimentés directement en triphasé notamment des moteurs/compresseurs dont la rotation pourrait être déséquilibrée), et des actions « de fond » de rééquilibrage en réaffectant des équipements d’une phase à une autre (par re-câblage).

A noter qu’un autre plugin existe, Suivi Conso, disponible à 8€ sur le Market Jeedom, et aux possibilités encore étendues par rapport au plugin Teleinfo gratuit utilisé ici, mais je trouve sa configuration plus complexe et, dans mon cas, son utilisation pas forcément justifiée à ce stade.

Annexes – Différentes méthodes utilisées pour alimenter le plugin Teleinfo avec des données

Cette annexe traite de mes différentes tentatives avant d’arriver à faire fonctionner le plugin Teleinfo à partir des données du Zlinky.

Annexe 1: Configuration du plugin Teleinfo avec MQTT

A1.1. Configuration de base

Première configuration : la remontée des informations par MQTT. Nous allons d’abord indiquer que nous souhaitons utiliser MQTT, via le bouton « General plugin information » puis configurer le MQTT via le bouton « Configuring the MQTT part ».

La configuration du MQTT nécessite d’aller récupérer l’identifiant et authentifiant pour accéder au broker, ainsi que le topic (ou sujet) utilisé par Zigbee2MQTT pour publier les messages du Lixee Zlinky.

Essayons maintenant tout cela: retour dans la configuration du plugin Teleinfo.

Analyse: le problème est en réalité assez complexe. On voit dans le log capturé ci-dessus, que le message transmis sur MQTT par la librairie Zigbee2MQTT ne contient pas les champs « standards » normalement remontés par le protocole TELEINFO d’ENEDIS. On le voit aussi en allant consulter les logs du côté de la librairie Zigbee2MQTT directement.

Là où le plugin TELEINFO s’attend par exemple à récupérer un champ ADSC pour identifier le numéro de série d’un compteur (ce qui permet au plugin de créer automatiquement un nouvel équipement dans Jeedom), le message MQTT publié contiendra ce numéro de série dans le champ meter_serial_number (source).

On comprend donc que:

• Le plugin JeeZigbee/Z2M de jeedom réalise une transformation quand il reçoit des messages provenant d’un équipement ZLinky_TIC, de façon à créer un équipement contenant les informations au standard inconnu. On peut voir dans le détail de l’équipement JeeZigbee, onglet « Raw Information » que cette translation s’opère vraisemblablement via les champs « label » ou « name », et « property ».

• Le plugin Teleinfo de jeedom va chercher les données attendues directement à la source (message MQTT), ne bénéficie donc pas de la transformation réalisée par le plugin JeeZigbee, et il ne sait visiblement pas réaliser cette transformation lui-même (il faudrait qu’il sache le faire pour chaque type de modem TIC/Teleinfo).

Nous allons donc devoir faire nous-même une nouvelle transformation, sur les champs qui nous intéressent uniquement, et nous allons pour cela utiliser le module MQTT Manager de Jeedom, déjà installé sur notre instance (car utilisé par le plugin ZWave JS que nous utilisions déjà avant cet article).

A1.2. Transformation des données via MQTT Manager

Nous nous basons sur le post d’un utilisateur sur le forum Jeedom, très utile dans notre démarche. Tout d’abord nous ajoutons un équipement dans le plugin « MQTT Manager » de Jeedom.

Dans cet équipement, nous allons ajouter une commande, qui aura pour effet de « poster » un message via le broker MQTT. Ce message est construit avec une structure JSON, au format reconnu par le plugin teleinfo, c’est à dire en associant au chaps teleinfo, les valeurs déjà remontés par le Zinky via le plugin JeeZigbee/Z2M. Dans la chaine de caractère que nous allons poster sur MQTT, nous allons donc aller chercher des informations exposées par l’équipement Zlinky remonté via l’autre plugin JeeZigbee/Z2M.

La chaine associée est la suivante (vous pouvez copier tel quel, cela fonctionne).

json::{
	"TIC":{
		"ADSC":"Compteur Jardin Teleinfo",
		"NGTF":"#[Jardin][Compteur Electrique][NGTF]#",
		"LTARF":"#[Jardin][Compteur Electrique][LTARF]#",
		"SINSTS":"#[Jardin][Compteur Electrique][SINSTS]#",
		"SINSTS1":"#[Jardin][Compteur Electrique][SINSTS1]#",
		"SINSTS2":"#[Jardin][Compteur Electrique][SINSTS2]#",
		"SINSTS3":"#[Jardin][Compteur Electrique][SINSTS3]#",
		"EASF01":"#[Jardin][Compteur Electrique][EASF01]#",
		"EASF02":"#[Jardin][Compteur Electrique][EASF02]#",
		"EASF03":"#[Jardin][Compteur Electrique][EASF03]#",
		"EASF04":"#[Jardin][Compteur Electrique][EASF04]#",
		"EASF05":"#[Jardin][Compteur Electrique][EASF05]#",
		"EASF06":"#[Jardin][Compteur Electrique][EASF06]#",
		"EAST":"#[Jardin][Compteur Electrique][EAST]#",
		"DATE":"#[Jardin][Compteur Electrique][DATE]#"
		}
	}

Nous voyons ici:

• Que nous « forçons » le nom du futur équipement à « Compteur Jardin Teleinfo » via le champ ADSC (car il sera créé automatiquement par le plugin Teleinfo lors de la réception du premier message),
• Que les autres champs (NGTF, SINSTS*, LTARF, EASF*, EAST, DATE) seront valorisés par appel aux informations de l’équipement « Compteur Electrique » exposé par le plugin JeeZigbee/Z2M
• Que nous réalisons une conversion d’unité: les données EASF* et EAST concernant l’énergie soutirée au fournisseur, sont remontées en kWh, alors que le plugin Teleinfo les attend en Wh. Nous allons donc les multiplier par 1000. Pour ne pas perdre en précision, il ne faut pas oublier d’augmenter de 3 la précision des valeurs en kWh dans la librairie Zigbee2MQTT (onglet Settings (Specific)).

Réalisons un test de premier message, via le bouton « Test ».

Allons voir dans les logs Mqtt2 de MQTT Manager, que nous aurons au préalable (et temporairement) passé en mode DEBUG.

La ligne complète est :

[2025-07-25 16:19:49] DEBUG  : Message received without plugin support : {"jeedom":{"teleinfo_linky":{"TIC":{"ADSC":"Compteur Jardin Teleinfo","NGTF":"TEMPO","SINSTS":495,"SINSTS1":197,"SINSTS2":8,"SINSTS3":284,"LTARF":"HP BLEU","EASF01":15058.833,"EASF02":28107.727,"EASF03":919.3,"EASF04":1720.797,"EASF05":181.925,"EASF06":101.808,"EAST":46090.406,"DATE":"E250725161935"}}}}

Cela semble bon, mais il faut maintenant que ces messages soient automatiquement envoyés à chaque mise à jour d’une de ces valeurs, sur l’équipement « d’origine » exposé par JeeZigbee/Z2M. Pour cela, nous allons créer un scénario, qui se déclenchera sur modification d’un des index EASF* ou EAST.

N’oubliez pas d’enregistrer. Maintenant, nous testons manuellement le scénario à l’aide du petit bouton orange « Exécuter » en haut à droite, nous vérifions ses journaux (comme expliqué si vous laissez votre souris sur le bouton orange, CTRL+clic permettra d’enregistrer/exécuter/ouvrir le journal), et nous vérifierons également le fichier journal mqtt2 dans le plugin MQTT Manager. Contrairement à moi, n’oubliez pas d’activer le mode débogage dans MQTT Manager avant votre test (et de le désactiver après) !

La ligne complète du fichier journal mqtt2 est indiquée ci-dessous. Il est intéressant de noter que le champ EASF02 a la même valeur que celle que nous avons observée dans notre journal de scénario lorsqu’il a été lancé automatiquement par le déclencheur EASF2, et non par nos tests. Donc… Il semble que cela fonctionne bien.

[2025-07-26 08:26:36] DEBUG : Message received without plugin support : {« jeedom »:{« teleinfo_linky »:{« TIC »:{« ADSC »: »Compteur Jardin Teleinfo », »NGTF »: »TEMPO », »SINSTS »:538, »SINSTS1″:89, »SINSTS2″:15, »SINSTS3″:433, »LTARF »: »HP BLEU », »EASF01″:15077.176,« EASF02 »:28110.779, »EASF03″:919.3, »EASF04″:1720.797, »EASF05″:181.925, »EASF06″:101.808, »EAST »:46111.766, »DATE »: »E250726082621″}}}}

Maintenant que nous avons créé notre convertisseur de messages MQTT « Zlinky » en messages « TELEINFO », nous pouvons reprendre la configuration du plugin Teleinfo.

A1.3. Configuration du plugin : lecture du MQTT « nouveau format »

Nous pouvons reprendre maintenant la configuration du plugin Teleinfo et lui demander d’aller scruter les messages du topic jeedom/teleinfo_linky dans lequel notre convertisseur (le couple « objet MQTT Manager » + scenario d’automatisation) poste ses messages.

Vérifions maintenant les équipements dans le tableau de bord du plugin Teleinfo. Nous devrions voir un « Compteur Jardin Teleinfo » avec toutes les nouvelles commandes et informations créées automatiquement par le plugin (celui-ci stockera ces données afin de fournir des statistiques sur son tableau de bord).

Nous avons nettement progressé: l’équipement du compteur a été créé, ses commandes ajoutées par le plugin. Il convient maintenant de configurer plus précisément ses sources d’information dans l’onglet « Equipment » pour lui indiquer à quelles valeurs correspondent les champs des messages qu’il lit dans la file MQTT.

Et après quelque temps, on commence à voir apparaitre de premières statistiques sur le dashboard … Mais il semble qu’il y ait un (nouveau) problème …

En effet, on remarque que les valeurs remontées sont très basses … La consommation quotidienne est proche de 0 ce qui est anormal. La solution est toute simple et était en réalité détectable en faisant un peu plus attention à une chose : les unités attendues par le plugin Teleinfo et celles remontées par le module Zlinky: le premier attend des mesures de consommation en Wh (Watts par heure) et le second remonte des valeurs en kWh (kilo Watts par heure). Il nous faut donc réaliser une simple conversion quelque part, de façon à multiplier les kWh remontés par le Zlinky par 1000 et qu’ils soient envoyés « convertis » dans le message MQTT.

A1.4. Conversion des unités de consommation de kWh en Wh

Par conversion dans le JSON

La première méthode que j’ai tentée est de modifier le JSON utilisé pour envoyer un message MQTT au format Teleinfo, dans l’équipement créé dans le plugin MQTT Manager.

json::{
	"TIC":{
		"ADSC":"Compteur Jardin Teleinfo",
		"NGTF":"#[Jardin][Compteur Electrique][NGTF]#",
		"LTARF":"#[Jardin][Compteur Electrique][LTARF]#",
		"SINSTS":"#[Jardin][Compteur Electrique][SINSTS]#",
		"SINSTS1":"#[Jardin][Compteur Electrique][SINSTS1]#",
		"SINSTS2":"#[Jardin][Compteur Electrique][SINSTS2]#",
		"SINSTS3":"#[Jardin][Compteur Electrique][SINSTS3]#",
		"EASF01":"#[Jardin][Compteur Electrique][EASF01]#*1000",
		"EASF02":"#[Jardin][Compteur Electrique][EASF02]#*1000",
		"EASF03":"#[Jardin][Compteur Electrique][EASF03]#*1000",
		"EASF04":"#[Jardin][Compteur Electrique][EASF04]#*1000",
		"EASF05":"#[Jardin][Compteur Electrique][EASF05]#*1000",
		"EASF06":"#[Jardin][Compteur Electrique][EASF06]#*1000",
		"EAST":"#[Jardin][Compteur Electrique][EAST]#*1000",
		"DATE":"#[Jardin][Compteur Electrique][DATE]#"
		}
	}

Cela ne fonctionne pas, l’instruction de multiplication n’est pas interprétée et est envoyée telle quelle dans le message MQTT, ce qui va par conséquent probablement gêner à l’avenir les calculs de statistiques du plugin Teleinfo ==> Quand nous aurons une cinématique fonctionnelle, nous supprimerons l’équipement créé par le Plugin Teleinfo pour en créer un nouveau, avec un historique « propre » de valeurs.

Par multiplication dans chaque commande Teleinfo

La deuxième méthode employée, est d’appliquer une règle de conversion directement sur chaque commande EASF* et EAST de l’équipement du plugin Teleinfo.

A ce stade on constate que les valeurs ont bien été multipliées par 1000. Donc, l’unité est maintenant le Wh et non le kWh initial. Le problème va maintenant être dans l’historique des valeurs déjà remontées et stockées dans l’historique du plugin Teleinfo.

Alors oui, on pourrait aller réinitialiser tout l’historique en base de données, mais ce n’est pas très industriel.

On pourrait aussi décocher l’historique le chaque commande, sauvegarder (ce qui supprime l’historique enregistré), puis recocher l’historique. Mais ce n’est pas très industrialisé non plus.

L’idéal est de pouvoir s’appuyer sur des données saines dès la création de l’équipement par le plugin Teleinfo, et c’est l’objectif de la 3ième solution.

Par équipement virtuel

J’ai davantage confiance en le fait que cette solution fonctionne: c’est de créer un nouvel équipement virtuel (via le plugin « Virtuel » de Jeedom, gratuit et supporté par l’équipe Jeedom).

Cet équipement virtuel sera le clone de l’équipement Zlinky exposé par le plugin JeeZigbee, et intégrera une multiplication par 1000 des valeurs de consommation. Nous modifierons ensuite le scénario de détection de modification des valeurs de consommation pour faire pointer ses triggers sur l’équipement virtuel, et nous modifierons le JSON configuré dans l’équipement du plugin MQTT Manager, pour qu’il aille chercher les données à utiliser sur l’équipement virtuel, celles multipliées par 1000. Une fois que nous aurons testé la bonne conversion des valeurs et leur bonne réception par le plugin Teleinfo, nous supprimerons l’équipement actuel qui a un mauvais historique de données du fait de nos différentes tentatives, et nous en créerons un nouveau, avec un nom différent, pour nous assurer de la création d’un nouvel équipement vierge de toute donnée.

Maintenant on va modifier le scénario de détection de changement, et ses déclencheurs, pour pointer vers notre nouvel équipement virtuel.

Et l’on modifie le contenu du JSON dans l’équipement « MQTT Manager » qui met des messages MQTT, pour utiliser les valeurs en Wh de l’équipement virtuel, plutôt que les valeurs en kWh de l’équipement JeeZigbee « source ».

json::{
	"TIC":{
		"ADSC":"Compteur Jardin Teleinfo",
		"NGTF":"#[Jardin][Zlinky - Virtual][NGTF]#",
		"LTARF":"#[Jardin][Zlinky - Virtual][LTARF]#",
		"SINSTS":"#[Jardin][Zlinky - Virtual][SINSTS]#",
		"SINSTS1":"#[Jardin][Zlinky - Virtual][SINSTS1]#",
		"SINSTS2":"#[Jardin][Zlinky - Virtual][SINSTS2]#",
		"SINSTS3":"#[Jardin][Zlinky - Virtual][SINSTS3]#",
		"EASF01":"#[Jardin][Zlinky - Virtual][EASF01]#",
		"EASF02":"#[Jardin][Zlinky - Virtual][EASF02]#",
		"EASF03":"#[Jardin][Zlinky - Virtual][EASF03]#",
		"EASF04":"#[Jardin][Zlinky - Virtual][EASF04]#",
		"EASF05":"#[Jardin][Zlinky - Virtual][EASF05]#",
		"EASF06":"#[Jardin][Zlinky - Virtual][EASF06]#",
		"EAST":"#[Jardin][Zlinky - Virtual][EAST]#",
		"DATE":"#[Jardin][Zlinky - Virtual][DATE]#"
		}
	}

Vérifions maintenant les logs « mqtt2d » en mode debug du plugin MQTT Manager:

[2025-07-28 20:26:17] DEBUG  : Publish message on topic : jeedom/teleinfo_linky => { 	"TIC":{ 		"ADSC":"Compteur Jardin Teleinfo", 		"NGTF":"TEMPO", 		"LTARF":"HC BLEU", 		"SINSTS":2598, 		"SINSTS1":2086, 		"SINSTS2":88, 		"SINSTS3":414, 		"EASF01":15094812, 		"EASF02":28129192, 		"EASF03":919300, 		"EASF04":1720797, 		"EASF05":181925, 		"EASF06":101808, 		"EAST":46147781, 		"DATE":"E250728222559" 		} 	} with options : {}

Tout semble OK, les valeurs sont bien en Wh … Maintenant, désactivons le scénario 2mn, changeons le nom du compteur dans l’équipement MQTT Manager (le champ « ADSC ») et supprimons le compteur existant dans le plugin Teleinfo puis réactivons le scénario. Normalement, un nouveau compteur devrait etre créé automatiquement par le plugin Teleinfo, en étant alimenté directement cette fois-ci par des valeurs exprimées en Wh.

Après avoir laissé tourner cette solution quelques heures et en particulier après avoir attendu l’exécution des cron d’archivage et de calcul des statistiques quotidiennes, on peut conclure que cette solution fonctionne bien. Les valeurs des commandes sont mises à jour correctement et fréquemment, le niveau de détail dans les historiques est bon, et le dashboard permet bien de voir l’évolution de la consommation, des coûts, et le tout ventilé par type de tarification, selon l’abonnement souscrit.

Cette solution permet de rester dans le cadre d’utilisation standard du plugin Teleinfo, mais je la trouve « un poil » compliquée, car elle oblige à reformater les messages MQTT via un équipement supplémentaire dans MQTT Manager, à avoir un scénario de déclenchement, et à avoir un équipement virtuel de conversion des kWh en Wh. Je regrette aussi que l’on sollicite plusieurs fois le broker MQTT pour, in fine, le même objectif: la transmission des valeurs remontés par le Zlinky.

Annexe 2: par commandes Teleinfo alimentées par scénario de conversion

C’est en fait la solution la plus simple, mais elle nécessite la configuration manuelle du compteur dans le plugin TELEINFO, ce que je cherchais jusqu’à présent à éviter.

Cette solution est élaborée après interaction avec le développeur du plugin sur le forum Jeedom:

• Créer manuellement un compteur de test : le plugin crée les commandes d’historisation/statistiques mais pas les commandes « de base » permettant de suivre les index de consommation,
• Ajouter manuellement 14 commandes supplémentaires (ADSC, EAST, EASF*, LTARF, NGTF, SINSTS*) et leur champ donnée associé,
• Association des champs de télé information aux commandes,
• Création d’un scénario qui trigger sur EAST, EASF*, SINSTS* et qui alimente les 14 commandes supplémentaires avec au passage un x1000 pour EAST et EASF*.

C’est une solution qui fonctionne et qui permet elle aussi d’obtenir un dashboard 100% fonctionnel. Certes elle sort du cadre standard d’utilisation du plugin TELEINFO, car il n’obtient pas lui même les données via un modem TIC USB ni par MQTT et que l’on doit créer des commandes et les mettre à jour « manuellement ». Mais, elle a le mérite d’être relativement simple, elle ne nécessite pas 3 composants différents, et elle fonctionne.

C’est donc la solution qui est détaillée « par défaut » plus haut dans l’article et non ici.