OpenDTU loses inverter connection after Dynamic Power Limiter target is changed via Home Assistant/MQTT

[DatJakob]

What happened?

I am using OpenDTU-OnBattery with two Growatt batteries connected to a Hoymiles HM-1500 inverter.

Before integrating Home Assistant, the setup worked perfectly. The Dynamic Power Limiter was configured for 0 W grid consumption and the system ran reliably with zero feed-in and no communication issues.

After setting up Home Assistant, I started reading the battery SOC from the Growatt batteries and integrated OpenDTU via MQTT. I then created an automation that changes the Dynamic Power Limiter target depending on the battery charge level:

Battery SOC > 99% → set target to -100 W
Battery SOC drops below 99% → set target back to 0 W

Since introducing this automation, OpenDTU regularly loses communication with the inverter.

When this happens:

The OLED display appears to freeze (OLED protection/screensaver no longer updates).
The web interface remains accessible.
No communication with the inverter is possible anymore.
A restart from the web interface does not restore the connection.

The connection can only be restored by:

Changing and saving any setting in the OpenDTU configuration, or
Power-cycling the OpenDTU.

To Reproduce Bug

Set up OpenDTU-OnBattery with a Hoymiles HM-1500 inverter.
Connect Growatt batteries and verify normal operation.
Integrate OpenDTU into Home Assistant via MQTT.
Create an automation that changes the Dynamic Power Limiter target:
SOC > 99% → target = -100 W
SOC < 99% → target = 0 W
Let the automation run normally.
After some time, OpenDTU loses communication with the inverter and appears to freeze.

Expected Behavior

OpenDTU should continue communicating with the inverter normally when the Dynamic Power Limiter target is changed via MQTT/Home Assistant.

Changing the target value between 0 W and -100 W should not cause the inverter connection to be lost, the OLED display to freeze, or require a configuration save or power cycle to recover communication.

Install Method

Pre-Compiled binary from GitHub releases

What git-hash/version of OpenDTU-OnBattery?

2026.03.31

What is your inverter firmware version?

2.0.1

What firmware variant (PIO Environment)?

generic_esp32s3_usb

Relevant log/trace output

Anything else?

No response

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU-OnBattery, not something specific to my installation.
• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.
• I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported.

[gnome4711]

same here,
I usually set the target depending on time of the day. However this configuration worked for weeks.

I changed 2 things:

1. The grid-consumption was used to arrive every second. Then I changed that to 10 seconds assuming to reduce stress to the controller.
3. There was only a new setpoint send via mqtt. Then I simultaneously added a change of the target_power_consumption (also via mqtt). target_power_consumption and upper_power_limit at the same time.
   I don’t know if any of this caused this behaviour.

[AndreasBoehm]

How often/in which frequency do you send the target_power_consumption via mqtt @gnome4711 and @DatJakob ?

[gnome4711]

The setpoints were sent once. But as mentioned in 2. target_power_consumption and upper_power_limit simultaneously. When I'm back from vacation next week, I can try to reproduce.

[gnome4711]

And btw. : rebooting the DTU doesn't make it reconnect! @DatJakob Am I right?

[ChaotenKurt]

I have exactly the same problem. For weeks now, I've been getting by by simply turning Ground off and on again via a relay after Home Assistant detects that OpenDTU is unreachable. It's absolutely exhausting right now.

[ali-baba-de]

sounds like a long existing issue, at least if you set multiple values, see e.g. here and here. With a short (e.g. 3s) delay between multiple commands the freeze should disappear.

[DatJakob]

@AndreasBoehm sorry for the late answer.
I send target_power_consumption via mqtt twice a day, one time around lunch time and in the evening.

And rebooting doesnt fix the Problem. I need to cut off the power or I can change a setting in the DTU Tab to fix it.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[martenevcc]

I can confirm this issue with a similar setup.

Setup: OpenDTU-OnBattery on an ESP32-S3 board (generic_esp32s3_usb), 8 inverters total, including one Hoymiles HM-1500, one HERF-800-2T and six HMT-2250 units. Dynamic Power Limiter target is frequently updated via MQTT by a Home Assistant automation.
Symptoms observed: OLED display stops updating (screensaver/pixel-shift frozen), web UI stays reachable but shows no fresh data, no further MQTT messages with inverter/power data are published by the device, no further entries appear in the console log and recovery requires a power cycle — a reboot triggered from the web UI does not restore function.

Data collected across multiple occurrences:

Firmware versions tested: 2026.05.18 and, after downgrading, 2026.03.31. The freeze occurred on both versions with the same symptom pattern.
Log excerpt at freeze time, showing an incoming MQTT command and a radio fetch call at the same millisecond timestamp:

[09:35:01.612] dynamicPowerLimiter: [MQTT] Setting target power consumption to: -50 W
[09:35:01.612] hoymiles: Fetch inverter: 116190624903

No further log lines followed after this point until manual power-cycle.

Test with NRF24 polling disabled: I disabled data fetch and command sending for both NRF24 inverters (device settings, "Daten abrufen" / "Befehle senden" both off) to see whether the freeze still occurred. It did. In that state, the last log lines before the freeze showed Middle missing / All missing retries on a CMT2300A inverter, followed by either an MQTT target command or a DPL-issued limit command to a CMT2300A inverter.

System status at freeze time (via /api/system/status): free heap between 100–150 kB across all captured occurrences, IDLE task stack watermarks unchanged from the values seen shortly after boot.

I have about seven documented occurrences with timestamps, firmware versions, and system status captured at freeze time, happy to share more if useful.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.