MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.

MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.

MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.
MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.
2025-07-08 17:26:42 - last edited 2025-08-06 08:13:27
Model: Deco X50  
Hardware Version: V1
Firmware Version: 1.4.5 Rel 84587

The problem is that random ESP devices are causing up to 150 MQTT disconnects per 24 hours.

 

Configuration:
5x X50 Decos and 3x TP-LINK managed LAN switches, the DECO backhaul is via a Gbit LAN.
No Rx or Tx errors are visible on any TP-Link switch port.
The main DECO unit is operating as an access point.
Smart DHCP, Easy Mesh, Fast Roaming and Beamforming are disabled.
An external DHCP server running on Linux is used.

 

IOBroker is installed and there are 4x MODBUS/TCP devices and around 20x ESP IoT devices connected via Wi-Fi (ESP8266, ESP32, Shelly and Sonoff with original firmware, Tasmota, ESPEasy and older and newer firmware versions and TAPO Cameras 4x LAN, 2x via Wi-Fi connected)
IOBroker runs as a VM (it was also running as bare metal on a Raspberry Pi 4).

 

This situation can be created with most ESP devices.
Currently, no MQTT timeouts or reconnects are being reported on the IOBroker.

Rebooting one of the IoT devices does start the behavior, whether this is done by powering off/on via an HTTP request or disconnect/connect power source.

 

After rebooting a Wi-Fi IoT device, MQTT timeouts and reconnects will be reported on the IOBroker for this device or another on the same DECO within less than 24 hours.
- Rebooting IOBroker doesn't change anything.
- Rebooting the entire X50 mesh does not fix anything.
- There is no DHCP issue and rebooting doesn't fix anything.
- No Rx or Tx errors are reported on the TP-Link switches.

 

The only solution is to disconnect and then reconnect the main DECO from the power supply. Afterwards, the MQTT errors will be gone. 

I found that this behaviour is independent of the DECO setup and whether all functions such as Smart DHCP, Easy Mesh, Fast Roaming and Beamforming are enabled.

This behaviour was observed on the M4, P9 and X50.

 

Additionally, once the ESP device is connected to the strongest Wi-Fi signal, it will connect to the second strongest signal after rebooting or turning the device off and on again.

After the first reboot, the ESP device will not log in to Wi-Fi when locked to a DECO, but it will after a second reboot.

After a second reboot or power cycle, it will reconnect to the firstly connected DECO, mainly the one with the stronges Wi-Fi Signal.

 

However, there is a high chance that it will start reporting MQTT timeouts/reconnects in the IOBroker log after an IoT device has been rebooted. The only solution is to disconnect and reconnect the main DECO's power source.

 

The main DECO has also been replaced with an X50,P9. The entire mesh was originally built using M4's that exhibited the same behaviour.

 

To be honest, I think the problem lies with the DECOs Wi-Fi and on the main DECO.

 

Does anyone else have the same issues ?

 

Best Regards, Stefan

 

 

  0      
  0      
#1
Options
1 Accepted Solution
Re:MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.-Solution
2025-07-09 08:57:00 - last edited 2025-08-06 08:13:27

  @SteWa 

Hi, thank you very much for the feedback.

Before using Deco Mesh, have you ever tested with other WiFi systems?

 

I didn't have any other suggestions, but if you can consistently reproduce this issue, I'd like to follow up on your case via email and ask the senior engineer for further assistance.

Please check whether you can receive my email later.

Best regards.

Recommended Solution
  0  
  0  
#2
Options
1 Reply
Re:MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.-Solution
2025-07-09 08:57:00 - last edited 2025-08-06 08:13:27

  @SteWa 

Hi, thank you very much for the feedback.

Before using Deco Mesh, have you ever tested with other WiFi systems?

 

I didn't have any other suggestions, but if you can consistently reproduce this issue, I'd like to follow up on your case via email and ask the senior engineer for further assistance.

Please check whether you can receive my email later.

Best regards.

Recommended Solution
  0  
  0  
#2
Options