Blue Series 2-1 Switch - Enhancements/Bugs Thread

[dan4]

Good thought, but local protection works as expected and disables anything from going through the switch. Just tested it.

[tigers]

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'

[dmulcahey]

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!

[tigers]

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.

[Esh]

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.

[jcharles42]

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.

[sbrocket]

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?

[mike789]

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.

[nathanfiscus]

This is fixed in the latest firmware release. The events were being sent to the group.

[jcharles42]

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.

[dantidote]

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

[sdbigio]

@EricM_Inovelli New driver bug report (I think)…

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.

[epow]

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.

[EricM_Inovelli]

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).

[CodeMaster]

@sdbigio

Add double tap to minimum brightness locally (same as double tap for maximum). This would avoid the need for the hub to process a rule.

I second that. It only make sense for a dimmer to allow its users to:

1. Turn the lights on and off
2. Set the desired level
3. Easily jump to full brightness.
4. 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.

[BlueBulb]

My installer just installed our first Blue switch this last weekend. We have a couple of red ones.

The first thing he mentioned was the non-professional screws.

It’s his preference when working on a large job to just use the square bit with an electric drive for electrical work all day long.

[Bry]

@BlueBulb

square bit

The Reds have Robertson screws. Future releases of the Blues will as well.

Blue Series 2-1 Switch - Enhancements/Bugs Thread

We’ll get this added, great call-out. I honestly never heard of this until today, but it makes a lot of sense. Ironically, as @Bry mentioned, we had it on our Red Series (I had no idea!) so it shouldn’t be too hard to add to either our next batch or the following one depending on what’s been sourced already. Today I learned! Thanks Hopefully this will be fixed by adding the Robertson screw mentioned above, but just out of curiosity, are you using an impact driver or something?…

[mike789]

@EricM_Inovelli Just checking if this is a bug or how the switch is intended to work?

Blue Series 2-1 Switch - Enhancements/Bugs Thread

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.

[jhstroebel]

Chiming in that I also had this happen on a switch, but you only do it once! Now I check for it when wiring my ground.

[mamber]

@mike789

Just checking if this is a bug or how the switch is intended to work?

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.

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.