Deye Inverter Data Every Minute: Local Monitoring Without the Cloud

The problem with cloud monitoring

This project uses a single-phase Deye SUN-06K-SG05LP1-EU 6 kW hybrid inverter with a battery and a Solarman Wi-Fi logger. The standard data path looks like this:

Inverter → Wi-Fi logger → Solarman/Deye cloud → mobile app

The logger uploads data to the cloud in batches every few minutes. The data then has to be processed and displayed by the app. As a result, the screen may show a state that is five minutes old or even older. That is acceptable for checking daily production, but not for real-time monitoring or automation.

Fast events matter for a hybrid inverter:

• the grid goes down and the house switches to battery power;
• the battery discharges faster than expected;
• a peak load appears;
• the grid returns and battery charging begins.

The history also remains in a third-party cloud. Without a private API, it is difficult to build custom charts, combine the telemetry with other systems, or send Telegram alerts.

What the standard Wi-Fi logger can do

A Solarman LSW-3/LSW-5 is a small bridge between Wi-Fi and RS485. Internally, it talks to the inverter over Modbus RTU. It uploads data to the cloud, but it also listens on TCP port 8899 inside the local network.

This port uses the Solarman V5 protocol: a Modbus frame wrapped in a header containing the logger serial number. Python already has a suitable library, pysolarmanv5. The connection requires:

• the logger's local IP address, available in the router's client list;
• the logger serial number, not the inverter serial number;
• port 8899, which can be tested with nc -z <ip> 8899.

The Deye cloud and app continue to work normally. I do not flash or disable anything; I simply add a second local client.

First test: a small Python script

Before building the complete pipeline, I verified that the logger responded and that the register map matched the inverter. This is a sanitized version of the working deye_read.py; replace the local IP and serial number with your own values.

import sys
from pysolarmanv5 import PySolarmanV5

LOGGER_IP = "192.168.x.x"
LOGGER_SN = 29XXXXXXXX


def s16(v):
    return v - 0x10000 if v >= 0x8000 else v


def main():
    inv = PySolarmanV5(
        LOGGER_IP,
        LOGGER_SN,
        port=8899,
        mb_slave_id=1,
        socket_timeout=10,
    )
    try:
        a = inv.read_holding_registers(59, 42)   # registers 59..100
        b = inv.read_holding_registers(108, 84)  # registers 108..191
    finally:
        inv.disconnect()

    r = lambda n: a[n - 59] if n < 108 else b[n - 108]
    states = {
        0: "standby", 1: "self-check", 2: "normal",
        3: "alarm", 4: "fault",
    }

    print(f"Status: {states.get(r(59), r(59))}")
    print(f"PV1: {r(109)*0.1:.1f} V  {r(110)*0.1:.1f} A  {r(186)} W")
    print(f"PV2: {r(111)*0.1:.1f} V  {r(112)*0.1:.1f} A  {r(187)} W")
    print(f"PV today: {r(108)*0.1:.1f} kWh")
    print(f"SOC: {r(184)} %")
    print(f"Battery: {r(183)*0.01:.2f} V, {s16(r(190))} W")
    print(f"Grid: {r(150)*0.1:.1f} V, {r(79)*0.01:.2f} Hz")
    print(f"Import/export: {s16(r(169))} W")
    print(f"Load: {r(178)} W")
    print(f"DC/AC temp: {(r(90)-1000)*0.1:.1f} / {(r(91)-1000)*0.1:.1f} °C")


if __name__ == "__main__":
    sys.exit(main())

The complete inverter state fits into two requests. Reading each register separately is a bad idea because the logger does not handle many small, frequent requests well. I read two continuous blocks and decode the values locally.

The first run returned a plausible snapshot: battery SOC and voltage, current load, grid import, and charging power. I also checked the energy balance: grid import was approximately equal to the load, battery charging, and the inverter's own consumption.

Architecture: logger → NAS → server

The key architectural decision is that the NAS sends data out; the public server never connects back into the home network. There is no need to expose ports, configure DDNS, or publish the NAS on the internet. The home network only makes outbound HTTPS requests.

Running the collector on an old Synology

The project uses a DS415play with a 32-bit processor, roughly 700 MB of RAM, and DSM 7.1. Docker is not available for this model, so a container stack with Home Assistant, Grafana, and InfluxDB was not an option.

The standard system features were enough:

The script lives in the service user's home directory rather than a web directory because its configuration contains an API key.

Making a 24/7 collector reliable

A collector must survive real failures, not merely decode registers correctly.

1. The logger does not respond

   Wi-Fi loggers occasionally time out or return a malformed frame. The collector makes one retry after three seconds and writes the error to its log.

   timeout · retry

2. The server is unavailable

   The reading is appended to spool.jsonl. After connectivity returns, pending data is sent in batches of up to 500 records. The buffer is limited to two weeks.

   offline buffer · JSONL

3. A batch is delivered twice

   The server performs an upsert using the device serial number and measurement time as a unique key. Repeated delivery does not create duplicates.

   idempotency · upsert

4. Runs overlap

   If the previous cycle is still active, the new one exits immediately. A lock file and flock enforce this rule.

   flock · single process

5. The log keeps growing

   The log file rotates after reaching 1 MB.

   log rotation

Securing local Modbus access

Port 8899 has no authentication. A device on the same network may be able not only to read registers but also to write them, changing operating modes and charging parameters. Therefore:

• place the logger and other IoT devices in a separate guest network or VLAN where possible;
• allow access to the logger only from the collector;
• never expose port 8899 to the internet;
• use register reads only unless writing is a deliberate and validated part of the project;
• assign the logger a stable IP through DHCP reservation.

Some recent logger firmware versions close the local port or make it unstable. A fallback option is a direct RS485 connection through an adapter such as an ESP32 running ESPHome. It requires additional hardware but can be more reliable than the Wi-Fi logger.

Result

I did not change the firmware, buy additional equipment, or abandon the Deye cloud. I simply added a second local client to the existing logger. The result is:

• fresh data every minute instead of delayed cloud updates;
• a privately owned measurement history;
• an API for widgets and external services;
• charts for inverter and grid state;
• a foundation for Telegram outage alerts and other automations;
• a solution that runs on an old NAS that was already online around the clock.