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.
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.
*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.
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.
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
In Smartthings, when 2-in-1 is set to on/off mode the driver still displays dimming level which is adjustable and sticks. I’m not certain if it is actually adjusting the output but I would assume it should not be availible when the switch is set to on/off or at minimum the user should not be able to adjust it.
New feature request: toggle mode. I use this on every Zooz switch in my zwave mesh… I like to just slap at the wall without precision and have the light change state, regardless of which part of the paddle I actually hit.
I’ll see if I can get the driver to change the profile based on a specific setting. For reference though, adjusting the level when the device is in on/off mode doesn’t actually adjust the level (unless you set the level to 0 I believe, which will turn the switch off).
I second that. It only make sense for a dimmer to allow its users to:
Turn the lights on and off
Set the desired level
Easily jump to full brightness.
Easily jump to the a pre-determined level for that room (call it comfort level, relaxing level, night light, or whatever that might be).
It already does 1 to 3 and 4 should be a firmware change so… an easy one?
From an user experience perspective, that can provide complete lighting control through an intuitive and simple “user interface” that is consistent across the home (all switches) and will work regardless of hub support.
I can tell from experience. My family started adopting these same features from Zooz switches through the house hours after I installed them a while back. And as expected, it was their number one complain when I moved to the RED series and they lost it.
I’m having a hard time understanding the question. Can either of you re-phrase it a different way so its easier to understand the issue State the specific parameters you are using and even better if you can post some screenshots.
It already does all 4. Set Param 13 to the desired ‘comfort’ level. If light is off just turn it on and it will go to that level. If the light is on at a different level a quick tap of down/up will set it to the ‘comfort’ level
state: on
brightness: 1
defaultLed7IntensityWhenOn: 100
(This does not work as expected, led7 should overrides the sync value and go to 100%. However it never goes higher than the sync value)