Dear community, dear Klinki,

unfortunately my PV projects have come to a bit of a standstill for work-related reasons (lack of time). Sadly, this is still the case at the moment, which is why it’s difficult for me to become more active again here in the forum and on my projects.

@Klinki I only just noticed that you’ve apparently been putting time into further development. That’s why I’d like to share a few findings, because I think they could fundamentally change the approach we need to take.

When I tried to integrate my Deye into openEMS at the beginning of this year, I asked Deye support whether the inverter could be controlled simply via an external energy manager, like a battery storage system. The reason was that I had found a Modbus document online describing registers for “Remote Mode” starting at register 1100, which suggested that such a function was intended.

Support replied fairly quickly that this would be possible via a firmware update to the latest version. On **17/02/2025**, support installed the firmware remotely. Since then, I’ve been able to operate the Deye very easily as a “pure battery” via a Modbus register and charge/discharge it using a +/- power value. It works exactly the way I had hoped in my last post.
In addition, there is a configurable watchdog that resets the value to **0** if no external updates are received.

My device: **SUN-15K-SG05LP3-EU-SM2**

**Important note:** In this mode, the battery limit values configured in the Deye apparently do not take effect. Minimum/maximum SOC and protection mechanisms would then need to be implemented in openEMS.

I also had the issue that when the Deye stays in standby for a longer time, it continuously draws power from the battery for its own operation. I noticed this because my temporary balcony PV system didn’t generate enough surplus to charge during winter. As a result, the BMS eventually shut down due to undervoltage. After that, the Deye also went into an “Error” state, and the battery had to be charged externally to bring the Deye back online. (At the time, I also had the impression that the Deye would continue drawing power even while in the error state, but I can’t confirm that reliably at the moment.)

As mentioned before, I’m not very experienced in programming. However, based on **Rayleigh3105’s** project and with the help of ChatGPT, I managed to integrate my Deye far enough to control it via openEMS (manual power control as well as via the ESS Balancer Controller). In my test environment, though, I ran into the problem that Modbus values eventually were no longer read/written reliably: the Deye did respond to the power values, but the status updates no longer arrived consistently in openEMS. I spent quite a while looking for the cause (system resources, the Waveshare Modbus adapter, openEMS cycle time, etc.), but then had to drop the topic due to lack of time.

It’s also possible that my handling of combining high/low words for values that the Deye does not provide as consecutive registers causes issues for openEMS — I can’t say for sure. Since my implementation is probably not particularly “clean,” I haven’t posted it publicly so far. If there’s still interest, feel free to send me a PM.

If anyone is interested in the **Modbus document V105.4** that I received from support back then, feel free to send me a PM as well.
**Note:** My information reflects the status as of **February 2025** — I don’t know what may have changed since then.

I hope these findings are helpful!