[Device Support Request] ZBMini-L delayed response after minutes of pairing. Workaround found on Zigbee2MQTT

[pulento]

Context

ZBMini-L is Zigbee 3.0 switch which does not need neutral line for power. It seems to work fine at the beginning but after minutes ZBMini-L switch is paired it shows a delayed response that seems to get worse with time.

To Reproduce Steps to reproduce the behavior:

1. Pair the ZBMini-L with ZHA
2. It responds fast at the beginning
3. Wait 30 minutes or more
4. Switch it ON/OFF and note the delay
5. It gets workse with time

Expected behavior No delay. But it seems to be a workaround for this behavior since it was fixed in Z2M on this commit:

https://github.com/Koenkk/zigbee-herdsman-converters/commit/ac7a095463c8b4dec3d6a6b34eb1e221a0f37d90

Bug was reported here:

https://github.com/Koenkk/zigbee2mqtt/issues/11676

Device Signature

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4742, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=11264, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0002",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0007",
        "0x0020",
        "0xfc57",
        "0xfca0"
      ],
      "out_clusters": [
        "0x0019"
      ]
    }
  },
  "manufacturer": "SONOFF",
  "model": "ZBMINI-L",
  "class": "zigpy.device.Device"
}

TIA

[hevili]

also experiencing this issue

[MattWestb]

Very likely is not one problem with the host system more the device not working as intended. Read little of the problem our Z2M friends is having and all reclamations of devices they have doing to SonOff. https://github.com/Koenkk/zigbee2mqtt/issues/10282

[Hedda]

If the Zigbee2MQTT developers could implement a workaround for this slow delay problem in a Zigbee converter for zigbee-herdsman-converters then maybe it is also possible to do the same in a ZHA Device Handlers quirk for the ZHA integration too?

https://github.com/Koenkk/zigbee2mqtt/issues/11676

Sound as if as a workaround they chose to unbind genPollCtrl to prevent the device from sending checkin message which causes Sonoff Zigbee End-Devices poll slower about 1-hour after powering the device?

https://github.com/Koenkk/zigbee-herdsman-converters/commit/ac7a095463c8b4dec3d6a6b34eb1e221a0f37d90

[Hedda]

Very likely is not one problem with the host system more the device not working as intended.

ITead SONOFF Product Manager @Daniel-zhan-itead confirmed that their SONOFF engineer analyses found that the root cause for Sonoff ZBMINI-L delays and slow response in Home Assistant is a firmware issue, but hope problem can be worked around in application.

"Our engineer analyzes the reason for this may be: After ZBMINI-L joins HA, HA will configure the Check-in message of the device. When HA receives the Check-in message from the device, it will modify the wake-up time of the device to 6S, which will cause the device to receive the control command delay. And our check-in period is 1 hour, so the control delay problem will occur after one hour. Is it possible for HA to handle polling time for ZBMINI-L especially?"

For reference; the Sonoff ZBMINI-L is a Zigbee End Device, (not a Zigbee Router ). Still, the product is a switch with a relay so it needs to respond quickly to control commands sent by the Zigbee application.

[MattWestb]

One Zigbee 3 end device shall supporting pull control for not loosing messages the host system like sending it with out pulling its parent in short intervals all the time but doing check in to the host system..

Fast pull shall timing out if the hoist is not sending one fast pull stop that ZHA is sending but its looks the device is not being Zigbee compatible and / or not tested of the manufacture.

Its looks like TI have implanting many nice buts in the SDK and the companies need learning how to working then around or getting TI fixing then.

Disabling chicken is not recommend but if the manufacture cant fixing the bug i think its the last resort for getting the device working or returning them to the seller (at least EU it shall being no problem if the seller cant fixing the device working OK) and perhaps some manufactures is learning how to do working devices and not only selling components in one plastic box with firmware that is not working.

[caroku]

I have the same problem, my ZBMINI-L shows a delayed response after 1 hour, then appears offline the next day. I am from Chile and i bought the product from aliexpress, and returning to China is not an option. Great customer service. Hope you can help us.

[DieserKirsche]

Expierencing exactly same problem with HA, ConBee II and ZHA integration. After initial setting up everthing works fine and later some strange behavior of ZBMINI-L switch. All other devices (in same automation) work as expected. ZBMINI-L as itself is perfect device for my purpose, as long as this issue will / can be fixed with my setup (HA, ConBee II and ZHA).

[pulento]

Strangely I changed my coordinator to a Sonoff Dongle USB 3.0 from a ZBBridge and I've no experiencing big delays.

But what I'm having now is randoms turn off of the ZBMini-L not random turn on just random turn off on all of my 4 switches. I noted that other people reported the same problem on iTead page.

[Daniel-zhan-itead]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

[dmulcahey]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

[Daniel-zhan-itead]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

After ZBMINI-L is added to ZHA, ZHA will enable the device poll control cluster function, and then the device interval of sleep & wake-up will be set to 6 seconds as default, We will disable the poll control function in the device firmware so the interval will be kept at 500ms as default.

[jds11111]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

After ZBMINI-L is added to ZHA, ZHA will enable the device poll control cluster function, and then the device interval of sleep & wake-up will be set to 6 seconds as default, We will disable the poll control function in the device firmware so the interval will be kept at 500ms as default.

Will this also fix the random shutdowns?

[DieserKirsche]

Expierencing exactly same problem with HA, ConBee II and ZHA integration. After initial setting up everthing works fine and later some strange behavior of ZBMINI-L switch. All other devices (in same automation) work as expected. ZBMINI-L as itself is perfect device for my purpose, as long as this issue will / can be fixed with my setup (HA, ConBee II and ZHA).

I had the same problem with the random turn off, not very often, sometimes after half an hour and sometimes immediatly after turning on (10s).

[dmulcahey]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

After ZBMINI-L is added to ZHA, ZHA will enable the device poll control cluster function, and then the device interval of sleep & wake-up will be set to 6 seconds as default, We will disable the poll control function in the device firmware so the interval will be kept at 500ms as default.

Why Is this cluster even part of this device? This is really meant for battery powered end devices that may need to accept configuration commands from an application so that they don't go to sleep while they are in the middle of being configured no? It seems odd to me that this cluster is on a mains powered relay that should always be capable of accepting commands.

Why not remove the cluster altogether rather than hacking a default poll rate into it?

[pulento]

Maybe powering without Neutral hasn't much power either. If not why iTead didn't implemented it as Router devices ?

[Hedda]

Why Is this cluster even part of this device? This is really meant for battery powered end devices

Maybe powering without Neutral hasn't much power either. If not why iTead didn't implemented it as Router devices ?

IIRC believe someone in Home Assistant community forum posted a link reference to a technical article that explained why power to non-neutral devices is unreliable/unstable or should at least not be assumed to be guaranteed, and therefore they should at least not be Zigbee Router devices.

[Daniel-zhan-itead]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

After ZBMINI-L is added to ZHA, ZHA will enable the device poll control cluster function, and then the device interval of sleep & wake-up will be set to 6 seconds as default, We will disable the poll control function in the device firmware so the interval will be kept at 500ms as default.

Will this also fix the random shutdowns?

Yup, this random shutdown issue will also be fixed together, Pls wait for the new firmware release. Thanks for your understanding

[pulento]

Great news 👍

Now we have to figure how to apply OTA on these with HA

[MattWestb]

Im having one tuya TS110F _TZ3000_92chsky7 its one dual dimmer switch without neutral that works great and is one router device so its depends of the hardware implementation and its no need having external capacitor for making it working stable. If getting one OTA files from Sonoff / itead its only configure local OTA in HA and putting the file in the folder and restarting HA https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates if the original firmware have implanting working OTA function.

Also if its shall being one end device (not real sleeper) is better deleting the poll control cluster then making some crazy half implanting then its need pulling its parent very oft for not getting delay then sending commands to it. If it shall being one sleeper it shall having working pull control as one Zigbee 3 device for not loosing commands sent to it like all battery powered remotes is doing (that is Zigbee certificated).

Or the best is fixing the bug in the TI SDK or in the code made of the manufacture as shall being done before releasing the product if it was good tested.

[Hedda]

Now we have to figure how to apply OTA on these with HA

@Daniel-zhan-itead FYI, if you can add images to a public repo then an Itead Sonoff OTA provider for it could be added to zigpy:

https://github.com/zigpy/zigpy/blob/dev/README.md#zigbee-device-ota-updates

https://github.com/zigpy/zigpy/tree/dev/zigpy/ota

https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates

Once your OTA provider is in zigpy then OTA support in Home Assistant's ZHA can be extended to support Itead Sonoff devices:

https://www.home-assistant.io/integrations/zha#ota-firmware-updates

PS: OTA support is by the way also similar in Zigbee2MQTT which will need a new OTA provider for zigbee-herdsman-converters:

https://github.com/Koenkk/zigbee-herdsman-converters/tree/master/lib/ota

https://www.zigbee2mqtt.io/guide/usage/ota_updates.html

[DieserKirsche]

We will optimize the firmware to fix the delay issue of ZBMINI-L running on ZHA and release the OTA update image for you. The firmware is under testing, once the test is completed, it will be published.

Is the issue caused by something we are doing?

After ZBMINI-L is added to ZHA, ZHA will enable the device poll control cluster function, and then the device interval of sleep & wake-up will be set to 6 seconds as default, We will disable the poll control function in the device firmware so the interval will be kept at 500ms as default.

Will this also fix the random shutdowns?

Yup, this random shutdown issue will also be fixed together, Pls wait for the new firmware release. Thanks for your understanding

Do you have any updates about the timeschedule or much better a pre-release? Otherwise I have to refund my devices today.

[Daniel-zhan-itead]

We have raised the pull request for the OTA update image on github https://github.com/Koenkk/zigbee-OTA/pulls. Once it is approved, you can download the image and update the ZBMINI-L devices.

[MattWestb]

Use https://github.com/Koenkk/zigbee-OTA/blob/a26ec426d0c744f63e6ee534bcee7875434d1008/images/Sonoff/zbmini-l_v1.1.1.ota and clicking on download and putting the file in your OTA folder you have reconfigured in Z/HA and restart HA and it shall being possible updating the device firmware. Configuring and triggering OTA updated is in the wiki https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates.

Edit: Then the PR is merged the URL for the firmware shall being https://github.com/Koenkk/zigbee-OTA/raw/master/images/Sonoff/zbmini-l_v1.1.1.ota.

[dmulcahey]

We have raised the pull request for the OTA update image on github https://github.com/Koenkk/zigbee-OTA/pulls. Once it is approved, you can download the image and update the ZBMINI-L devices.

Do you have release notes for the firmware?

[pulento]

OTA is aborting on my case:

2022-05-20 09:34:16 DEBUG (MainThread) [zigpy.zcl] [0xF9E4:1:0x0019] OTA query_next_image handler for 'SONOFF ZBMINI-L': field_control=0, manufacture_id=4742, image_type=1, current_file_version=4101, hardware_version=None, model=ZBMINI-L

2022-05-20 09:34:16 DEBUG (MainThread) [zigpy.zcl] [0xF9E4:1:0x0019] OTA image version: 4353, size: 131086. Update needed: True

2022-05-20 09:35:12 DEBUG (MainThread) [zigpy.zcl] [0xF9E4:1:0x0019] OTA upgrade_end handler for 'SONOFF ZBMINI-L': status=Status.ABORT, manufacturer_id=4742, image_type=1, file_version=4353

2022-05-20 09:35:16 DEBUG (MainThread) [zigpy.zcl] [0xF9E4:1:0x0019] OTA query_next_image handler for 'SONOFF ZBMINI-L': field_control=0, manufacture_id=4742, image_type=1, current_file_version=4101, hardware_version=None, model=ZBMINI-L

[m2r57700]

Hi First time I tried an OTA from ZHA and finally seems ok.

Previous Firmware: 0x00001004 Now : Firmware: 0x00001101

FYI

I used the following commands

I hope response delay will disappear.

[pulento]

Hi First time I tried an OTA from ZHA and finally seems ok.

Previous Firmware: 0x00001004 Now : Firmware: 0x00001101

FYI

I used the following commands

I hope response delay will disappear.

My fault. I needed to upgrade latest HA, surely had mixed dependencies.

Now I see OTA file being uploaded. Will report if the firmware fixed the problems.

[m2r57700]

I did the update 21h ago and device seems working without response delay.

[jds11111]

For anyone seeking more details on accomplishing the OTA flash, I found this link the most helpful (also mentioned by Hedda): https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates. It worked fine for me, and took several minutes.

[Daniel-zhan-itead]

We have raised the pull request for the OTA update image on github https://github.com/Koenkk/zigbee-OTA/pulls. Once it is approved, you can download the image and update the ZBMINI-L devices.

Do you have release notes for the firmware?

Feature: Added Poll Control Cluster private attribute 0xFF00 (enable/disable configuration), the default Poll Control Cluster initial configuration is disabled Bugfix: Random shutdown issue