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
3 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
Re:MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.
2 weeks ago - last edited 2 weeks ago

  @David-TP 

 

I'm having the same issue with Model: BE11000

Firmware Version: 1.1.7 Build 20250324 Rel. 32980

 

Nothing will stay connected with espressif or even tplink own older wifi loght switches. Basically anything eufy ip cam, 3d printer with the espressif wifi chipped.  Cheap wifi chips etc won't work. 

They connect, then move to the furthest satellite or just won't connect at all. Forcing them to connect to the proper satellite and turning off mesh results in no connection ever.

 

They all connect fine to my Galaxy S24 Hotspot and my older Google Mesh system.

 

It's about to go back to Costco.

 

  0  
  0  
#3
Options
Re:MQTT timeouts and reconnects with different IoT devices and Mesh DECOs.
2 weeks ago

@Element2050 

 

Hi Element2050,

 

Your behavior differs from what I experienced.

 

There is a simple test for this, when the ESP device is connected to the WLAN, reboot the ESP device.
It should then connect to a different satellite. If you reboot it again, it will again connect to a different satellite or to the previous one. Of course, if there are no nearby satellites, it will not connect.
If it doesn't connect, switch it off, wait five minutes, then turn it on, it should then connect to the same satellite.

 

In my experience, connecting a device to the satellite WLAN caused delays in the whole WLAN, which resulted in MQTT disconnecting, but the WLAN was not disconnected. However, when there is a WLAN device with a weak signal or other issues, the satellite disconnects all connected WLAN devices in an attempt to recover. I assume that @David-TP will answer this as well, though.

 

I received a beta firmware update that resolved my issues. Hopefully, you will find the solution, or @David-TP will be able to assist you.

 

Regards, Stefan

  0  
  0  
#4
Options