MQTT reconnect loop with Mosquitto/Home Assistant after WiFi/Mesh interruption; saving MQTT settings restores connection

[MVS-JEB]

What happened?

In an installation with Home Assistant, Mosquitto Broker and OpenDTU MQTT Auto-Discovery, OpenDTU enters an MQTT reconnect/timeout loop after a WiFi/Mesh interruption.

The environment is essentially:

OpenDTU → WiFi / Mesh / Repeater → Mosquitto Broker → Home Assistant MQTT Integration

The issue is reproducible in the context of Home Assistant and Mosquitto Broker. OpenDTU is integrated into Home Assistant via MQTT Auto-Discovery.

After restarting the WiFi repeater or access point that OpenDTU is connected to, OpenDTU becomes reachable again via WiFi. The OpenDTU web interface is reachable and the WiFi connection appears active and stable in the OpenDTU interface.

Nevertheless, the MQTT connection to the Mosquitto Broker does not recover properly.

OpenDTU shows essentially:

• WiFi status: active
• WiFi quality: good
• IP address: available
• NTP: synchronized
• MQTT: active
• MQTT connection status: disconnected

In the Mosquitto Broker log, OpenDTU can be seen repeatedly connecting successfully, but then being disconnected after approx. 20–25 seconds with the following error:

Client OpenDTU- disconnected: exceeded timeout.

In Home Assistant, the OpenDTU entities created via MQTT Auto-Discovery briefly show valid values. Afterwards, they switch back to “unavailable”. The OpenDTU device status in Home Assistant switches accordingly between “connected” and “disconnected”.

The manual recovery is noteworthy:

If I open the OpenDTU web interface under Settings → MQTT, change any MQTT setting, for example the publish interval, and then save it, the MQTT client appears to be reinitialized internally. Immediately after saving, the repeated Mosquitto timeout messages stop. After that, the MQTT connection remains stable and Home Assistant receives values regularly again.

This suggests that the MQTT client may not be fully reinitialized after a WiFi/Mesh interruption, while saving the MQTT configuration triggers a working reinitialization.

To Reproduce Bug

1. Run OpenDTU with MQTT enabled.
2. Use Mosquitto Broker as the MQTT broker.
3. Use Home Assistant with the MQTT integration.
4. Integrate OpenDTU into Home Assistant via Home Assistant MQTT Auto-Discovery.
5. Let OpenDTU run normally until MQTT data is received regularly in Home Assistant.
6. Verify that the OpenDTU entities in Home Assistant provide current values.
7. Restart the WiFi repeater or access point that OpenDTU is currently connected to.
8. Wait until OpenDTU is reachable again via the web interface.
9. In OpenDTU, check under Info → Network whether WiFi is active again.
10. In OpenDTU, check under Info → MQTT whether the MQTT connection status is connected or disconnected.
11. Observe the Mosquitto Broker log.
12. Observe the OpenDTU device and entity page in Home Assistant.

Observed result:

• OpenDTU is reachable via the web interface.
• WiFi is active.
• MQTT is enabled.
• The MQTT connection status is “disconnected” or unstable.
• Mosquitto shows repeated new connections from OpenDTU.
• After approx. 20–25 seconds, Mosquitto disconnects the connection each time with “disconnected: exceeded timeout”.
• Home Assistant briefly receives OpenDTU values.
• Afterwards, the OpenDTU entities in Home Assistant become “unavailable” again.

Manual recovery:

13. Open OpenDTU → Settings → MQTT.
14. Change an MQTT setting, for example the publish interval from 5 seconds to 10 seconds.
15. Save the MQTT settings.
16. Observe the Mosquitto Broker log again.
17. The repeated “exceeded timeout” messages stop immediately after saving.
18. Home Assistant then receives OpenDTU values regularly again.

Expected Behavior

After a temporary WiFi/Mesh interruption or a restart of the access point/repeater, OpenDTU should:

1. restore the WiFi connection,
2. re-establish a stable MQTT connection to the Mosquitto Broker,
3. publish MQTT data regularly,
4. keep the Home Assistant entities created via MQTT Auto-Discovery available,
5. not enter a repeated MQTT reconnect/timeout loop.

If OpenDTU detects that the MQTT connection is interrupted or repeatedly disconnected by the broker due to timeout, the MQTT client should automatically be fully reinitialized.

The same recovery that is currently triggered by manually saving the MQTT settings should ideally happen automatically after WiFi reconnect or after repeated MQTT timeout.

Install Method

Pre-Compiled binary from GitHub releases

What git-hash/version of OpenDTU?

v26.3.30

What firmware variant (PIO Environment)?

generic_esp32s3_usb

Relevant log/trace output

2026-05-15 12:30:04: New connection from <opendtu-ip>:61421 on port 1883.
2026-05-15 12:30:04: New client connected from <opendtu-ip>:61421 as OpenDTU-<client-id> (p4, c1, k15, u'<mqtt-user>').
2026-05-15 12:30:26: Client OpenDTU-<client-id> [<opendtu-ip>:61421] disconnected: exceeded timeout.
2026-05-15 12:30:36: New connection from <opendtu-ip>:61422 on port 1883.
2026-05-15 12:30:36: New client connected from <opendtu-ip>:61422 as OpenDTU-<client-id> (p4, c1, k15, u'<mqtt-user>').
2026-05-15 12:30:58: Client OpenDTU-<client-id> [<opendtu-ip>:61422] disconnected: exceeded timeout.

After restarting the WiFi repeater / access point:

2026-05-15 15:32:20: New connection from <opendtu-ip>:63961 on port 1883.
2026-05-15 15:32:20: Client OpenDTU-<client-id> already connected, closing old connection.
2026-05-15 15:32:20: New client connected from <opendtu-ip>:63961 as OpenDTU-<client-id> (p4, c1, k15, u'<mqtt-user>').
2026-05-15 15:32:42: Client OpenDTU-<client-id> [<opendtu-ip>:63961] disconnected: exceeded timeout.

After saving the MQTT settings in the OpenDTU web interface:

2026-05-15 15:44:52: Client OpenDTU-<client-id> [<opendtu-ip>:<port>] disconnected: session taken over.
2026-05-15 15:44:52: New client connected from <opendtu-ip>:<new-port> as OpenDTU-<client-id> (p4, c1, k15, u'<mqtt-user>').

After that, the repeated “disconnected: exceeded timeout” messages stopped and MQTT remained stably connected.

Anything else?

MQTT configuration:

• MQTT enabled: yes
• Home Assistant MQTT Auto-Discovery: enabled
• MQTT broker: Mosquitto Broker
• Port: 1883
• TLS: disabled
• Base topic: solar/
• Publish interval tested with: 5 seconds, 10 seconds, 30 seconds
• Current publish interval: 10 seconds
• Clean Session: enabled
• Retain: enabled
• LWT topic: solar/dtu/status
• LWT online payload: online
• LWT offline payload: offline
• LWT QoS: 0
• Home Assistant Discovery prefix: homeassistant/
• Home Assistant Discovery retain: enabled
• Home Assistant Discovery expire function: enabled

Additional observations:

• The issue was observed and reproduced in the interaction between Home Assistant, Mosquitto Broker and OpenDTU MQTT Auto-Discovery.
• Other MQTT clients on the same Mosquitto Broker continue to work.
• Mosquitto initially accepts the OpenDTU connection.
• The connection is only disconnected after a short time due to timeout.
• Home Assistant correctly detects the OpenDTU status changes.
• Home Assistant marks the OpenDTU entities created via MQTT Auto-Discovery as “unavailable” as soon as the OpenDTU MQTT connection fails.
• OpenDTU remains reachable via the web interface after the WiFi/Mesh interruption.
• WiFi signal and IP connection appear stable after reconnect.
• NTP is synchronized.
• The OpenDTU radio modules are configured and connected.
• The issue seems to affect the MQTT client state after a WiFi/Mesh interruption.
• Manually saving the MQTT settings appears to reinitialize the MQTT client and restores the connection stably.

Similar existing issues that were checked before creating this report:

• OpenDTU-Wifi does not reconnect after a network WiFi failure #2366 OpenDTU-Wifi does not reconnect after a network WiFi failure
• ESP32 does not reconnect to Wifi #2400 ESP32 does not reconnect to Wifi
• MQTT not connecting to server anymore #2787 MQTT not connecting to server anymore
• WiFi issue still exists #2202 WiFi issue still exists

This case seems to be slightly different because OpenDTU remains reachable via the web interface after the WiFi/Mesh interruption. Only the MQTT client remains in a reconnect/timeout loop until the MQTT configuration is saved again.

Privacy / anonymization:

Real IP addresses, SSID, hostnames, MQTT usernames, passwords, inverter serial numbers and private device names were intentionally replaced with placeholders.

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU, 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.

[vaterlangen]

I also had issues with HA and MQTT (sensors stucking as unavail) after network interruptions and updated the MQTT handling on OpenDTU side - at least my issues could be resolved. Maybe this also helps with your issue bugfix/mqtt_disconnects_with_ha (merged the updates from my OnBattery branch - as I do not have a test instance right now, I could not test the branch by my self)

[forrestfunk]

Just chiming in to say I have the EXACT same problem. After working flawlessly for about 6 months my openDTU - or rather mqtt - suddenly out of the blue started this behavior. This was about 4 weeks ago - just when OP posted this issue. Back then the first thing I did was updating to the latest version of openDTU, which did not help. The trick with changing mqtt settings in the openDTU did not work for me. What worked for me was deleting the openDTU device in the home assistant mqtt "app" and let it automatically rediscover. This resolved the issue for another 4 weeks - until today. Did not change anything in my setup and now I aigain have the constant reconnects. Sorry if this post is not of much help.