Au-delà de Home Assistant : Pylontech avec Jeedom, Node-RED, Domoticz et openHAB

Un seul point d'accès JSON, toutes les plateformes

Home Assistant attire le plus l'attention — logique, c'est la plateforme domotique la plus répandue, et nous lui avons consacré un guide entier. Mais le mécanisme sous-jacent est volontairement simple : un seul point d'accès HTTP, GET /api.json, aucune authentification, du JSON brut en retour. Tout ce qui peut faire une requête HTTP et parser du JSON peut en extraire les données de la batterie Pylontech. C'est le cas de Jeedom, Node-RED, Domoticz, openHAB, Grafana, un script Python, une tâche cron avec curl — tous lisent exactement la même donnée, aucun n'a besoin de SDK propriétaire ni de clé API.

Jeedom

Jeedom n'a pas besoin d'un plugin Pylontech dédié. Installez le plugin standard JSON depuis le market Jeedom, pointez un équipement vers http://<ip-appareil>/api.json, et associez des chemins JSON à des commandes — summary>soc, summary>voltage, summary>state, net>rssi, etc. Un intervalle d'interrogation de 30 à 60 secondes suffit largement ; la télémétrie batterie n'évolue pas assez vite pour nécessiter plus serré.

Node-RED

Deux options, qui reflètent presque exactement le choix côté Home Assistant. Interrogez avec un nœud http request (méthode GET, URL http://<ip-appareil>/api.json, type de retour « a parsed JSON object »), déclenché par un nœud inject sur une minuterie, puis lisez des champs comme msg.payload.summary.soc en aval. Ou, si MQTT est déjà configuré sur l'appareil, abonnez-vous directement à pylon-monitor/state avec un nœud MQTT-in à la place — les mises à jour arrivent au fil de l'eau, sans boucle d'interrogation à gérer.

Domoticz

Domoticz n'a pas nativement de type de capteur à interrogation JSON prêt à l'emploi, mais le contournement classique est bien rodé : un petit script (Python, ou le scripting événementiel Lua/Blockly propre à Domoticz) récupère /api.json sur une minuterie et pousse les valeurs dans des capteurs Dummy/Virtual via l'API JSON propre à Domoticz. Ça demande quelques minutes de configuration en plus que Jeedom ou Node-RED, mais c'est une tâche à ne faire qu'une fois, et les capteurs se comportent ensuite exactement comme n'importe quel autre appareil Domoticz — graphiques d'historique complets, notifications, tout.

openHAB

Le HTTP Binding d'openHAB gère cela nativement : définissez un Thing pointant vers http://<ip-appareil>/api.json avec un intervalle de rafraîchissement, puis associez des channels individuels à des chemins JSON via une transformation (JSONPath) pour extraire summary.soc, summary.voltage, etc. dans des Items séparés. Aucun binding personnalisé nécessaire — le binding HTTP générique s'en occupe.

Grafana, scripts, et tout le reste

Si un outil dispose d'une source de données « JSON API » ou « HTTP » — le plugin JSON API de Grafana, l'entrée HTTP de Telegraf, un script Python avec requests, une ligne shell avec curl | jq — il peut lire ce point d'accès de la même façon. Ce n'est volontairement pas un jardin clos : l'appareil se moque de ce qu'il y a de l'autre côté de la requête HTTP, ce qui veut dire qu'il ne devient pas obsolète le jour où vous changez de plateforme domotique.

Interrogation vs MQTT : lequel utiliser, et où

La plupart des plateformes ci-dessus interrogent par défaut l'API JSON sur une minuterie, ce qui est simple et fonctionne partout. Si votre plateforme parle aussi MQTT (Node-RED et Home Assistant le font nativement), s'abonner à pylon-monitor/state à la place fait que les mises à jour arrivent dès leur publication plutôt que d'attendre la prochaine interrogation — et vous récupérez gratuitement le topic de disponibilité retenu, pour savoir immédiatement si l'appareil lui-même est hors ligne plutôt que de le deviner à partir d'une valeur figée. Une interrogation toutes les 30 à 60 secondes reste largement suffisante pour tout ce qui touche à la batterie, cela dit — ce n'est pas une donnée qui profite d'une latence inférieure à la seconde.