One JSON endpoint, every platform
Home Assistant gets most of the attention — understandably, it's the most common home-automation platform out there, and we've written a whole guide to it. But the actual mechanism underneath is deliberately simple: one HTTP endpoint, GET /api.json, no authentication, plain JSON in return. Anything that can make an HTTP request and parse JSON can pull Pylontech battery data from it. That's Jeedom, Node-RED, Domoticz, openHAB, Grafana, a Python script, a cron job with curl — all reading the exact same data, none of them needing a vendor SDK or an API key.
Jeedom
Jeedom doesn't need a dedicated Pylontech plugin. Install the standard JSON plugin from the Jeedom store, point an equipment at http://<device-ip>/api.json, and map JSON paths to commands — summary>soc, summary>voltage, summary>state, net>rssi, and so on. A 30–60 second polling interval is plenty; battery telemetry doesn't change fast enough to need anything tighter.
Node-RED
Two options, and they mirror the Home Assistant choice almost exactly. Poll with an http request node (method GET, URL http://<device-ip>/api.json, return type "a parsed JSON object"), triggered by an inject node on a timer, and read fields like msg.payload.summary.soc downstream. Or, if MQTT is already configured on the device, subscribe directly to pylon-monitor/state with an MQTT-in node instead — updates arrive as they happen, no polling loop to manage.
Domoticz
Domoticz doesn't ship a native JSON-polling sensor type out of the box, but the standard workaround is well-trodden: a small script (Python, or Domoticz's own Lua/Blockly event scripting) fetches /api.json on a timer and pushes the values into Dummy/Virtual sensors via Domoticz's own JSON API. It's a few more minutes of setup than Jeedom or Node-RED, but it's a one-time task, and the sensors behave exactly like any other Domoticz device afterward — full history graphs, notifications, the works.
openHAB
openHAB's HTTP Binding handles this natively: define a Thing pointing at http://<device-ip>/api.json with a refresh interval, then map individual channels to JSON paths using a transformation (JSONPath) to pull out summary.soc, summary.voltage, and so on into separate Items. No custom binding needed — the generic HTTP one covers it.
Grafana, scripts, and anything else
If a tool has a "JSON API" or "HTTP" data source — Grafana's JSON API plugin, Telegraf's HTTP input, a Python script with requests, a shell one-liner with curl | jq — it can read this endpoint the same way. This is deliberately not a walled garden: the device doesn't care what's on the other end of the HTTP request, which means it doesn't become obsolete the day you switch home-automation platforms.
Polling vs. MQTT: which to use where
Most of the platforms above default to polling the JSON API on a timer, which is simple and works everywhere. If your platform also speaks MQTT (Node-RED and Home Assistant both do natively), subscribing to pylon-monitor/state instead means updates arrive the moment they're published rather than waiting for the next poll — and you also get the retained availability topic for free, so you know immediately if the device itself has gone offline rather than guessing from a stale value. Polling every 30–60 seconds is more than adequate for anything battery-related, though — this isn't data that benefits from sub-second latency.
Pylon-Monitor's JSON API and MQTT topics are open, documented, and platform-agnostic from day one — plug it into whatever you already run.
Order now — €39 One-time purchase, €39 incl. VAT — no subscription.