In my case I’ve tried both but I have mostly just tested out a switch in On/Off mode with a single light. I’m wanting a double tap up event to trigger an HA automation but it almost never works without first turning on the switch first via single tap up.
I am seeing the same behavior here. Button presses (such as double paddle up) don’t seem to register unless the switch is already turned in to the on position.
@tigers @dan4 can you try something for me? Enable local protection with the load on. Then see if you get consistent delivery of events.
Thanks for the suggestion. I Gave that a try but no change after setting enabling local protection with the load on.
1 Like
Latest HA w/ ZHA, v2.05 firmware, good batch switch, smart bulb mode, no local protection – I seem to have better luck getting LED and “Opening” event updates, but the up, down, double up, etc events are still inconsistent.
I do have two switches bound together and I seem to consistently get events from those two. I have multiple single switches controlling smart bulbs that do not fire events all the time.
Edit: No difference with local protection on. I have to toggle it a bit to get the events to start firing, then it works great until I walk away for a few minutes and come back to try it again.
1 Like
What coordinator are you using?
Conbee II
I’m not using bindings; these switches are the only Zigbee devices in my network. I plan on using them to control LIFX lights and other devices through HA automations.
I’m currently testing with a switch that I’ve wired up outside the wall (in a free gang box wired into a plug, no actual load connected). The switch was just reset and paired so it has all default settings (OnOff mode, SmartBulb mode off, etc.). The switch is on v2.00 firmware, HA is 2022.10.5. My coordinator is an Electrolama ZZH with a TI ZNP CC2652R. I’m sitting in Developer Tools listening for zha_event events and also monitoring my HA docker container’s logs. Here’s what I observe:
- When the switch’s state is off, no
zha_eventevents fire no matter which button I press or number of times I press it. The includes a single tap up; that changes the switch’s state to on and I get the corresponding state change events for the light entity, but there’s no actualzha_eventevent. - For every missed button press event, in the HA logs I get an error and a few warnings like the following:
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | 2022-11-07 15:32:47.532 ERROR (MainThread) [zigpy_znp.uart] Received an exception while passing frame to API: TransportFrame(payload=GeneralFrame(header=CommandHeader(id=0xB1, subsystem=Subsystem.ZDO, type=CommandType.AREQ), data=b'\x40\xBA\x2F\x12\x66\x00\x01\x00'))
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | Traceback (most recent call last):
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | File "/usr/local/lib/python3.10/site-packages/zigpy_znp/uart.py", line 72, in data_received
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | self._api.frame_received(frame.payload)
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | File "/usr/local/lib/python3.10/site-packages/zigpy_znp/api.py", line 810, in frame_received
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | command = command_cls.from_frame(frame, align=self.nvram.align_structs)
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | File "/usr/local/lib/python3.10/site-packages/zigpy_znp/types/commands.py", line 433, in from_frame
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | raise ValueError(
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | ValueError: Frame GeneralFrame(header=CommandHeader(id=0xB1, subsystem=Subsystem.ZDO, type=CommandType.AREQ), data=b'\x40\xBA\x2F\x12\x66\x00\x01\x00') contains trailing data after parsing: b'\x01\x00'
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | 2022-11-07 15:32:47.536 WARNING (MainThread) [zigpy.zdo] [0x0000:zdo] Unknown ZDO cluster 0xfc31
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | 2022-11-07 15:32:47.537 WARNING (MainThread) [zigpy.zdo] [0x0000:zdo] Unknown ZDO cluster 0xfc31
Nov 07 15:32:47 bryanNAS docker[2832]: homeassistant | 2022-11-07 15:32:47.539 WARNING (MainThread) [zigpy.zdo] [0xba40:zdo] Unknown ZDO cluster 0xfc31
(I captured a larger chunk of these in the gist I linked above: gist:c19a4037644cd0996deb566858f57aad · GitHub)
- Immediately after switching on (from a single tap up) and at least for some amount of time, usually but not always,
zha_eventevents will fire as expected for any button or number of presses. There are also no errors in the HA logs like above if azha_eventsuccessfully fires. - If I wait some amount of time with the switch on, button presses no longer result in
zha_eventevents. - Events will also sometimes not fire immediately after switching on. I haven’t been able to discern any clearer pattern here yet.
- Whatever the pattern, every single missed event does correspond to an error+3 warnings in the HA logs like the above.
I haven’t tried this with debug logging on yet; I’ll try that next.
Edit: One last note; none of my switches have IEEE addresses matching the manufacturing issue. They all have 04:0d:84 or 94:de:b8 prefixes.
1 Like
Here’s what I see with debug logging enabled. I’m grabbing chunks of logs here by attempting clicks multiple times and taking snippets when the errors don’t collide with other obviously unrelated logs, since the HA logs are very noisy (from other devices) with debug logging enabled.
Note that I did actually get a successful zha_event event with the switch state off while trying this! That example is in the middle of the gist.
Also, here’s the device diagnostics for this switch, in case that’s useful: gist:10e7728477e41389f7990a12f9824ba3 · GitHub
3 Likes
Good thought, but local protection works as expected and disables anything from going through the switch. Just tested it.
1 Like
I’m seeing the same error here as well.
data=b'\x40\xBA\x2F\x12\x66\x00\x01\x00') contains trailing data after parsing: b'\x01\x00'
A colleague just pointed this out. This appears to be caused by a firmware bug. The events are being sent to destination endpoint 0 which is invalid as it’s the ZDO endpoint. These should be sent to a non zero endpoint id.
The reason some folks work and some don’t is because the SI stack allows us to see the source endpoint and we can kind of hack it to fix it. The TI stack does not provide the source endpoint so the packet is interpreted as ZDO (which is what it is sent as unfortunately) and things fail.
Thanks to puddly for the cap!
4 Likes
I’m using a Sonoff Zigbee 3.0 USB Dongle Plus-P which is a TI CC2652P chip so perhaps that explains the erratic behavior I observe that almost always requires a tap up to turn on the switch before any other tap events will be sent.
I have the same setup - and didn’t notice at first because I only tested after turning on the switch.
But going back and testing it after it was off for a period of time. I saw the same results. No events sent until I did a single tap back on again.
Cross-posting this here since it may be relevant to the current discussion: Blue 2-1 - Z2M, Groups, Binding, and Multi-Press Actions Troubleshooting
*Sonoff 3.0 P-dongle with latest z-stack firmware
*Bulbs on shipped firmware
*Running most recent Z2M release
*Switch wired to smart bulbs and Aux switch, in Smart Bulb mode
Signal quality to the switch is strong and reliable. However, whenever it is bound to a ZigBee light group, actions are not received by Z2M even if I “wake” up the switch with other presses beforehand (no messages in the log for the switch_name/action topic, only what appear to be state change messages for the switch). The switch still reliably controls the bound lights however. I’ve tested with some Juno ceiling wafers and recent Hue bulbs with the same results.
If unbound and removed from the group, actions reliably are received by Z2M with no “waking” necessary.
Based on this, at least in my case it does not seem to be a signal quality issue, but some conflict with ZigBee binding.
1 Like
I’ve got a feature request for 3-way setups involving a Blue 2-1 and an White Aux switch. I have a couple White Aux switches that I purchased with my Blue 2-1 10pk, and I’m still planning out locations for all of them. In most scenarios, I want the behavior that exists today and is documented, i.e. that presses on the Aux switch behave the same and send the same events as the same press on the main switch (“double-tap down on the Aux/Add-On switch, the 2-1 switch will send a, “Button 2 - Held” event to the hub”).
However, I have at least one 3-way circuit where it would be useful to configure the Blue 2-1 to send different events for button presses on the Aux switch. That’s assuming the Blue 2-1 has the ability to differentiate in the first place, but that seems likely. Any chance of getting a new feature and config parameter for this?
Not sure if if this is a bug or as intended. I think it used to work differently.
DefaultLed[1-7]IntensityWhenOn is limited at whatever the Synchronized value is. Meaning, if I manually set the value below the Synchronized value it will visually change. But, if it is set higher it will only visually go to the Synchronized value never higher.
IntensityWhenOff works as expected where is will use the manually set value no matter what the Synchronized is.
This is fixed in the latest firmware release. The events were being sent to the group.
2 Likes
Awesome! I’ll have to get that updated ASAP.
Edit: Based on the changelog, sounds like the most recent beta firmware does fix the endpoint destination, but introduced a bug that prevents group binding and requires individual binding instead. Might wait for that bug to resolved before upgrade, but good to know it’s in the works.
The activePowerReports parameter doesn’t seem to be doing anything for me. All my switches seem to be reporting for every 0.1W change, which is causing a lot of zigbee traffic…
debug 2022-11-12 10:25:50:832: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:25:56:804: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:00:789: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:06:791: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:08:762: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:10:763: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:18:724: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:22:713: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:24:713: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:26:715: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:34:689: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":177}' from endpoint 1 with groupID 0
debug 2022-11-12 10:26:36:660: Received Zigbee message from 'Laundry Light', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":176}' from endpoint 1 with groupID 0
1 Like