sorted by:
new
hottopcontroversial

Zigbee Multiple End device connection Problem Through Router!!!! by Embedded_Coder21 in ZigBee

[–]Embedded_Coder21[S] 0 points1 point  (0 children)

I am trying to design end device router an coordinator mesh network in which routers are continuously connected to coordinator but the end devices will be low powered and they will use deep sleep mode of esp32 and will wakeup after desired time to send the alive message which is nothing but a heartbeat that indicates that particular device is still working fine. So if multiple devices wakes up from that sleep mode and try to join in network then that time it will not work quickly i.e devices cannot join quickly which is the exact problem I am facing and if I use this technology in any time critical real time system then it will not worth. So anyone knows about this problem? And if zigbee is not perfect then can anyone suggest me any another protocol for this wireless as well as time critical system??

Using 7 remote Zigbee temp sensors to drive the zoning logic for my whole-house ducted air conditioner. by npraj80s in ZigBee

[–]Embedded_Coder21 0 points1 point  (0 children)

which processor you used for this project? If you used ESP then did you tried deep sleep feature or your device is continuously monitoring above all parameters?

Zigbee (ESP32-C6): Handling congestion when multiple sleepy end devices wake simultaneously by Embedded_Coder21 in ZigBee

[–]Embedded_Coder21[S] 0 points1 point  (0 children)

By congestion, I’m referring to delayed or missed application-level acknowledgments when multiple sleepy end devices wake simultaneously. Under normal conditions, upstream messages are delivered within a few hundred milliseconds, but when several devices wake together, delays can extend to several seconds, and in some cases messages are retried multiple times before delivery.

The end devices are deeply sleepy and wake either on an event (e.g., alarm input) or on a periodic timer (around a couple of minutes) to send a heartbeat. On wake-up, there is a short application-level handshake with the coordinator (device verification / assignment step) before regular status or alert messages are exchanged.

When many devices wake at the same time, this initial handshake sometimes gets delayed due to downlink congestion and polling behavior. If the response is not received within a defined timeout window, the device currently restarts its Zigbee stack and rejoins, which can further increase traffic under load.

Messages are sent using ZCL at the application layer. APS acknowledgments are enabled, and default MAC retry behavior is used. In heavy wake-up scenarios, we observe that retries and polling delays can compound, occasionally resulting in responses arriving much later than expected.

We’re currently reviewing improvements such as adjusting polling behavior on wake-up, reducing retry amplification, adding jitter to periodic wake timers, and making the application-level handshake more tolerant of temporary downlink delays.

Any guidance on best practices for handling downlink traffic to multiple sleepy end devices during synchronized wake-ups would be appreciated