Auto-Reconnect Zigbee Devices That Drop Off The Network

Share your Projects!
,
1

I retrofit Sonoff MINI-ZBRBS roller shutter modules into my exterior blinds. Sometimes one of these randomly drops off the network. No other type of zigbee device ever does this - only the roller shutters. I haven't figured out why.

Anyway, its a serious pain to reconnect them so I asked Claude to help with this. We came up with an automation that triggers on mqtt event device_leave. When that happens, it sends a notification that a device dropped off the network, then it permits join. It turns out that the device does attempt to reconnect, and allowing it to do so actually works. Then the automation tests if the device is on or off the network and sends another notification with success/failure.

This works. It's not a daily thing where this happens, but after waiting several days it did happen again and the automation worked. And even if it doesn't work, I still get the notification when a device drops off. But, yeah, its much better when it automatically reconnects.

alias: Zigbee device left network
description: ""
triggers:
  - topic: zigbee2mqtt/bridge/event
    trigger: mqtt
conditions:
  - condition: template
    value_template: "{{ trigger.payload_json.type == 'device_leave' }}"
actions:
  - variables:
      dropped_device: >
        {{ trigger.payload_json.data.friendly_name |
        default(trigger.payload_json.data.ieee_address) }}
      battery_devices: []
      is_battery: "{{ dropped_device in battery_devices }}"
  - action: notify.persistent_notification
    data:
      message: "⚠️ Zigbee device left the network: {{ dropped_device }}"
  - if:
      - condition: template
        value_template: "{{ not is_battery }}"
    then:
      - action: mqtt.publish
        data:
          topic: zigbee2mqtt/bridge/request/permit_join
          payload: "{\"value\": true, \"time\": 254}"
      - delay:
          minutes: 2
      - action: mqtt.publish
        data:
          topic: zigbee2mqtt/bridge/request/permit_join
          payload: "{\"value\": false}"
      - wait_for_trigger:
          - trigger: mqtt
            topic: zigbee2mqtt/{{ dropped_device }}/availability
        timeout:
          seconds: 30
        continue_on_timeout: true
      - variables:
          device_available: |
            {{ wait.trigger is not none and
               (wait.trigger.payload_json.state | default('offline')) == 'online' }}
      - if:
          - condition: template
            value_template: "{{ device_available }}"
        then:
          - action: notify.persistent_notification
            data:
              message: ✅ {{ dropped_device }} rejoined the Zigbee network successfully.
        else:
          - action: notify.persistent_notification
            data:
              message: >-
                ❌ {{ dropped_device }} did NOT rejoin. Manual intervention required.
mode: queued
max: 5

One thing to note is battery_devices: [] is an array of friendly names of devices to exclude.

2

Where do you put a script like that, and is script the correct term?

3

Every event from every Z2m device will hit this trigger and fire that automation. Are you sure you want to do that?

4

Its an automation. Just create a new automation and dump the yaml.

No, I'm not sure. I really don't know enough to say one way or another. Claude helped me get through it. I looked at traces and the last time the trigger was hit was yesterday, so it doesn't seem to be a problem. The one in the screenshot failed the template condition: {{ trigger.payload_json.type == 'device_leave' }}, so obviously it did not run. But there doesn't appear to be a ton of traffic hitting the trigger.

Screenshot 2026-06-22 134230
Screenshot 2026-06-22 134230963×592 59.4 KB

5

Just a disclaimer I should have put in the OP. I have no idea if this will work with any other ZigBee devices other than the Sonoff shade module. Obviously, it depends on whether the the device attempts to pair immediately after dropping off the network. I can only confirm this with the MINI-ZBRBS because (so far) that's the only thing that's ever dropped off my network, and the only thing that this automation reconnected. Additionally, I suspect only router devices will work, for obvious reasons. Probably other Sonoff devices behave the same way as the MINI-ZBRBS, but I can't say for sure.

But IF the device attempts to immediately reconnect after dropping off, then this automation should work to allow it to reconnect.

6

Well I'm sure you probably don't want to do that, and Claude just guesses based on training it steals from everyone's posts, including the wrong ones.

Friendly_name is also a parameter that is being phased out, so you don't want to use that either.

7

I really don't know what the issue is. Can you please explain?

8

Does this also works with zha? Does anyone has an experience with zha connected devices?

9

Claude says that bridge events ONLY include the following:

device_joined
device_leave
device_announce
device_interview
device_removed
device_renamed
device_options_changed
device_network_address_changed

No sensor data is sent and most of those items require initiation by me. That explains why there was only one triggering in the screenshot above. There simply are hardly any bridge events until I intervene with new devices or whatever.

10

No, but if you feed it to AI, it can make appropriate changes to make it work with ZHA.

11

I like the logging idea, even without auto-rejoin. I have a few devices that will drop off the network from time to time and by checking the logged messages after a while maybe there's even a pattern.

But then again, one of them is the Zigbee rainsensor and it probably just melted in the current weather :sweat_smile:

Will check how much traffic this creates but the trigger didn't fire yet in the first 15 minutes.

12

Yeah, very little traffic. Only 2 times firing in over a week, which is a little surprising considering we had a very short power outage yesterday.

Screenshot 2026-06-28 081314
Screenshot 2026-06-28 081314962×563 61.5 KB

[edit - not sure how complete that traces drop down box is, but either way, its not getting hammered]

13

If there's no power going to your coordinator & your devices, then you're not going to get messages that devices left the network. Your devices will simply be marked as offline after 10 minutes*

*10 minutes is the default for most mains-powered devices (routers) if you have enabled device availability in Z2M. Battery devices (end-devices) take up to 25 hours to report.

You can change the availability timeout globally or per-device as explained in the docs I linked, but be aware that reducing the availability for battery devices will lead to increased battery drain.

EDIT: @palinkas-jo-reggelt I'm starting to think that the cause of your issue is that the MINI-ZBRBS don't report every 10 minutes, which is why they're dropping off the network.
What happens when they drop off? Do you see them as offline in Z2M, or are they simply missing from the device list?

14

What I meant was that I thought I would get some bridge event messages when the power came back on. Maybe nothing occurred because my zigbee coordinator is on a UPS along with the rest of my networking gear and HA box? But I understand what you mean. No power, no message.

The outage was only 5 minutes. 5 < 10. That could be the reason too.

15

They are missing from the device list. Once they re-pair, the previous settings are retained (friendly name, calibration, etc). I assume they are re-pairing because allowing them to join actually works. But I thought re-pairing was equivalent to resetting. Not really sure one way or the other.

16

Yep, definitely.

Then they're actually leaving the network, not failing to report.

Had a look at the reviews & it seems to be a common problem. That's besides other issues, like the relays not actually closing when reaching the end (0 or 100%) & the fact that they only support a 1A load, which might be an issue if your motor doesn't have built in limit switches & the relay keeps running.

image
image870×385 39.4 KB

If this happened to me, I'd consider that device defective & send it back or trash it. While your automation may work, you're trying to fix the symptom rather than the cause.

17

Negative ghost rider, it's retains its identity. I have two Osram bulbs that consistently drop if I don't allow re-pairing. I'm using z2m but the same was true a few years ago in my prior system. Those two stupid bulbs. Disable rejoin and they'd always fall off and not come back. Allow rejoin and they are rock solid. I can only guess the connection is borderline. They lose connection then ask permission to join back when they see the network again.

18

Yes, and device_leave does work as a trigger.

Motor specs are good. 0.6A with mechanical limits. FWIW, auto calibration worked fine on all of them.