Sonoff Button Quirk

Have a question around configuring Sonoff Zigbee buttons (SNZB-01) …

Have one button which I’ve had for ages, previously used on Z2M, and now use with ZHA no issues (paired via SkyConnect). Bought a second button a couple of days ago, added it to HA yesterday with no problem pairing, but it’s working differently.

Looking at the diagnostics for the buttons, the existing one shows a quirk automatically applied of “zhaquirks.sonoff.button.SonoffButton”, whereas the new one is just “zigpy.device.Device”. This is meaning that the new button isn’t getting the “normal” press, double press, and hold events as the first one.

The quirk isn’t something I manually did on the existing one, so I presume it should be automatic? But then what’s the difference with the new one that it doesn’t pick up the quirk? Alternatively, how do I get HA to apply the correct quirk?

I have already tried restarting HA, as well as removing and readding the new button more than once all with the same result. Both buttons are a similar straight-line distance from the dongle with similar RF obstruction between (plasterboard). I even moved the SkyConnect onto a longer extension so it’s now a good distance away (~2m) from anyhing generating interference.

Debugging this a little more, it seems to be failing to match the Sonoff quirk based on…

“Fail because output cluster mismatch on at least one endpoint”

[0x9034] Read model 'WB01' and manufacturer 'eWeLink' from <Endpoint id=1 in=[basic:0x0000, identify:0x0003, power:0x0001] out=[on_off:0x0006] status=<Status.ZDO_INIT: 1>>
[0x9034] Discovered basic device information for <Device model='WB01' manuf='eWeLink' nwk=0x9034 ieee=00:12:4b:00:2a:55:0f:9f is_initialized=True>
Device is initialized <Device model='WB01' manuf='eWeLink' nwk=0x9034 ieee=00:12:4b:00:2a:55:0f:9f is_initialized=True>
Checking quirks for eWeLink WB01 (00:12:4b:00:2a:55:0f:9f)
Considering <class 'zhaquirks.sonoff.button.SonoffButton'>
Fail because output cluster mismatch on at least one endpoint
Considering <class 'zhaquirks.xbee.xbee_io.XBeeSensor'>
Fail because endpoint list mismatch: {232, 230} {1}
Considering <class 'zhaquirks.xbee.xbee3_io.XBee3Sensor'>
Fail because endpoint list mismatch: {232, 230} {1}
Considering <class 'zhaquirks.tuya.ts0201.MoesTemperatureHumidtySensorWithScreen'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.smartthings.multi.SmartthingsMultiPurposeSensor'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
Fail because endpoint list mismatch: {11, 13} {1}
Creating cluster handler for cluster id: 0 class: <class 'homeassistant.components.zha.core.cluster_handlers.general.BasicClusterHandler'>
Creating cluster handler for cluster id: 3 class: <class 'homeassistant.components.zha.core.cluster_handlers.general.IdentifyClusterHandler'>
Creating cluster handler for cluster id: 1 class: <class 'homeassistant.components.zha.core.cluster_handlers.general.PowerConfigurationClusterHandler'>
Discovering entities for endpoint: 00:12:4b:00:2a:55:0f:9f-1
'button' component -> 'ZHAIdentifyButton' using ['identify']
'sensor' component -> 'Battery' using ['power']
'sensor' component -> 'RSSISensor' using ['basic']
'sensor' component -> 'LQISensor' using ['basic']
[0x9034](WB01): starting availability checks - interval: 60
device - 0x9034:00:12:4b:00:2a:55:0f:9f entering async_device_initialized - is_new_join: True
device - 0x9034:00:12:4b:00:2a:55:0f:9f has joined the ZHA zigbee network

It looks like the reported “output_clusters” are different between the old and new buttons, with the old reporting:

"endpoints": {
        "1": {
          "profile_id": "0x0104",
          "device_type": "0x0000",
          "input_clusters": [
            "0x0000",
            "0x0001",
            "0x0003"
          ],
          "output_clusters": [
            "0x0003",
            "0x0006"
          ]
        }

and the new reporting:

"endpoints": {
        "1": {
          "profile_id": "0x0104",
          "device_type": "0x0000",
          "input_clusters": [
            "0x0000",
            "0x0001",
            "0x0003"
          ],
          "output_clusters": [
            "0x0006"
          ]
        }

Im guessing this is a difference in firmware between the old and new buttons? Is there some way to get the two buttons to be consistent???

1 Like

I have the same problem, with the new SNZB01 switches.
I have no idea how to solve the problem.

I too have the same issue with a button that arrived this morning. I have a ticket open with Sonoff for a faulty button (#530452) will email them back about this issue.

First Batch:

image

New device

image

This means these options are not available:

Sonoff R&D have replicated the issue and are working on it.

I have this problem as well. Devices bought last year work flawlessly and 2 new ones which I received last week don’t work out-of-a-box. I agree this is because of these devices signatures differ in output_clusters:

The old one (working):

{
  "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=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=0, 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": "0x0104",
      "device_type": "0x0000",
      "input_clusters": [
        "0x0000",
        "0x0001",
        "0x0003"
      ],
      "output_clusters": [
        "0x0003",
        "0x0006"
      ]
    }
  },
  "manufacturer": "eWeLink",
  "model": "WB01",
  "class": "zhaquirks.sonoff.button.SonoffButton"
}

The new one (not working):

{
  "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=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=0, 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": "0x0104",
      "device_type": "0x0000",
      "input_clusters": [
        "0x0000",
        "0x0001",
        "0x0003"
      ],
      "output_clusters": [
        "0x0006"
      ]
    }
  },
  "manufacturer": "eWeLink",
  "model": "WB01",
  "class": "zigpy.device.Device"
}

Quirk for these buttons requires 2 values in output_clusters: zha-device-handlers/zhaquirks/sonoff/snzb06p.py at 9ccb69ad64da9bcbaae28201cc9efa6589565300 · zigpy/zha-device-handlers · GitHub

I’m not sure what Sonoff can do for owners of “faulty” units. If I had to e.g. flash a new firmware, I’d probably break the device, because of how its built.

Meanwhile, as a workaround, it’s possible to use the “old-fashioned” way of working with these devices, via zha_event events. They map:

  • toggle: single click
  • on: double click
  • off: hold button

I’m using this blueprint to avoid writing a custom yaml: ZHA - Sonoff SNZB-01

Good find, will give the blueprint a try.

I have updated firmware on some of these devices via their app. So it should be possible.

To be fair to them, they have always been surprisingly good support wise. I bought some of their gear very early on and had lots of firmware issues mainly with their wireless implementation.

So somewhere along the line, both of my buttons have now changed over to a different quirk “zigpy.quirks.v2.CustomDeviceV2” which now give them “Short Press”, “Double Press”, and “Long Press”. They’re still showing different output_cluster values, but they’re now otherwise acting the same.

I’ve just updated to HA Core 2024.4.0, but have to admit that I haven’t checked the buttons in a while so don’t know if it was this or an earlier change!

I got it working :slight_smile:

I added this to configuration.yaml:

zha:
enable_quirks: true
custom_quirks_path: /config/custom_zha_quirks/

and then added the quirk for the button:

[core-ssh custom_zha_quirks]$ wget https://raw.githubusercontent.com/jeverley/zha-device-handlers/ts0601_energy_meter_do_not_use/zhaquirks/sonoff/button.py

not ideal but it works