Blue Series 2-1 Firmware Changelog | VZM31-SN

[Dan001]

Yes I don’t have a zsniffer but the switch definitely appears to only send an “on” command or at least that’s all the lights do because they don’t actually go to 100% they just do whatever the previous state was.

Ideally whatever the default_level_local is the switch should send that. 255/254 (100%) ) or 127 (50%) etc.

I have 1 switch with an individual bulb binding as it’s only 1 bulb and the same issue exists.

So it appears to be an issue for both group binding and individual. All Philips hue latest gen a19 bulbs.

1 switch 5 bulbs (1 group)
2 switches have 4 bulbs (1 group each switch)
1 switch 3 bulbs (1 group)
1 switch 1 bulb (individual bind)

Interesting for me using the light switch entity default_level_remote doesn’t seem to work either.
I saw the light entity go to 100% but the light itself only went to 1% and then the light entity refreshed ar 1% as well. So something weird is happening with both settings (default_level_local and default_level_remote) not being executed properly.

[mamber]

@terrence.bentley

Just an observation: the dimmers do appear to “pass along” the Command: Move to Level with OnOff (0x04) via bindings to the bulbs when you specify the level in a remote “On” command

@terrence.bentley

Here’s a screenshot showing my dimmer (0x5589) sending that command as a broadcast out to the zigbee bulb group when I specify the brightness in my remote call:

The Zigbee basic On and Off (cluster 6) commands do not have a level option. So if you’re “specifying a brightness in your remote call” then it sounds like you’re sending a Level Control (cluster 8) to begin with.

It has been my understanding (could be wrong) that what is happening is that if you send a basic on/off command to the switch, then is passes a basic on/off command to the bound devices. Since the basic command has no level option, each device is going to use its own internal method of determining what level to turn on at.

@Dan001

Yes I don’t have a zsniffer but the switch definitely appears to only send an “on” command or at least that’s all the lights do because they don’t actually go to 100% they just do whatever the previous state was.

That is how I’ve understood it to work. If you send an “on” command then each device will turn on at its own level. But if you set a Move_To_Level command then all devices should move to the same specified level.

[mtnbiker717]

@epow

@Eric_Inovelli

We are working on a 2.14 to address some trailing edge flickering (yes, trailing edge)

!!!

I thought it was just the bulbs I bought, haha, my wife (and I) will be excited when the bulbs don’t flicker when turning them on!

[Dan001]

Here’s the ZigBee spec for this.

3.8 on/off commands
3.19 Level Control

07-5123-08-Zigbee-Cluster-Library.pdf

[EricM_Inovelli]

@Dan001 I have been talking to the engineer about this. One concern I have is that an On / Off device may not respond to a “move to level with on/off” command. The current behavior is the intended behavior because of how the binding is expected to act. We can look at making an enhancement but it may have to be added as an optional parameter.

For my own knowledge, can you describe the

@Dan001

So if their previous brightness was 1% as I use an off transition they turn on to 1% if turned on at the switch rather than 100%.

part of it? I use group binding from several switches and haven’t ran into this problem. If you can help my test what you are doing it may help me in developing a solution.

[mamber]

@EricM_Inovelli

One concern I have is that an On / Off device may not respond to a “move to level with on/off” command. The current behavior is the intended behavior because of how the binding is expected to act. We can look at making an enhancement but it may have to be added as an optional parameter.

I was thinking the exact same thing. Adding an optional parameter is probably the best way to handle it.
Parameter XX = “convert on/off to move_to_level for bound devices”

[terrence.bentley]

I have the same experience so I can chime here.

If I send a command for a zigbee group of hue lights + blue switches to turn off with a transition parameter of say, 5 seconds via zigbee2mqtt:

payload: { "state": "OFF", "transition": 5},
topic: "zigbee2mqtt/Basement Stairs Group/set"

The behavior I see is that the bulbs consider their final state before turning off as 1% brightness instead of the actual brightness that they were at when that command was fired off. Therefore, when they later receive a simple On command via a tap of the physical blue dimmer, they return to 1% brightness.

If I send a regular off commands without a transition, everything behaves properly and the lights return to their actual previous brightness. My workaround has been to simply remove any off transitions in my automations as they aren’t critical to me, but I can understand the benefit of transitioning certain lights off over longer periods of time.

[grooves12]

Wouldn’t it be possible to only send the “move to level” command for dimmers? and “on” for on/off configuration?

[Dan001]

@EricM_Inovelli what @terrence.bentley described is exactly my issue.

With zha in home assistant I use an off transition for all of my light groups. Therefore their last state was 1% so when they receive an “on” command after a physical touch of the switch or using the switch light entity in home assistant they turn on to their previous state which was 1% and don’t follow what the defaults are set to which is 100%.

default_level_local and default_level_remote ideally would allow for the switch to also send the move to command which would send a brightness command with a value of whatever the value of those parameters are depending on if it’s a remote/local command.

[mamber]

@grooves12

Wouldn’t it be possible to only send the “move to level” command for dimmers? and “on” for on/off configuration?

The sending switch does not know what type of device its bound to. It only knows where to send the command

[grooves12]

The sending switch knows what the sending switch is though and Inovelli only needs to worry about the firmware fot their own switches. If an Inovelli switch is configured as a dimmer, I would assume all devices support dimming, and sending the set level command would work properly.

If it is bound to on/off devices, I would assume it should be configured as an on/off … in which case it could send on/off commands.

[avi]

@grooves12

The sending switch knows what the sending switch is

The sending switch knows what it is at all times. It knows this because it knows what it isn’t. By subtracting what it is from what it isn’t, or what it isn’t from what it is (whichever is greater), it obtains a difference, or deviation.

[SamJWard]

Currently running:
60 Blue Series switches all on Firmware v2.10
Sonoff P-Series (TI chipset) Zigbee 3.0 Dongle
Home Assistant + Z2M, both latest stable releases
Multiple 4-way switch and 3-way switch scenario’s.

… and not a single issue with Zigbee Binding. Have yet to have it fail even once.

The only issues noticeable:
-Dimming speeds are intermittently different and use one setting or another instead of doing what they should as I mentioned previously.

Now onto Hubitat…

I’ve setup the same exact environment as above except for with a C7 Hubitat Hub. Constant disconnections, constant Zigbee bindings failing.

I have no idea why, I was using both single and group binding on both Hubitat and Z2M.

It seems the more devices that route through an individual switch, the worse that switch routing performance and overall performance becomes, so I’m not sure if making the routing table larger will fix the problem with binding, I would think it would make it worse with the current z stack.

As for network flooding, on v2.10 I don’t see too much of it. Although, I have a few of the power reporting settings disabled in the firmware. The switches still do report wattage power when the switches are on every few seconds, but that doesn’t seem to cause any problems.

I think we are starting to see that some coordinators just can’t handle too many devices, and I believe some of the manufacturer’s just don’t want to admit it. For example, I used a Conbee II with Home Assistant and Z2M in the beginning and had terrible performance as well with the switches, but after switching to the Sonoff P (Texas Instruments chipset), everything is stable. I hope this helps someone, because this made a giant difference between wanting to rip my hair out vs having a functioning stable setup, and not having to worry about “will the switch work this time?”.

Do you guys allow testers? I have a smaller test setup of 15 switches where I’m modifying the EEPROM manually via direct board communication. If there is a better way to make changes and test just let me know.

[Dan001]

Were you or the engineer able to come up with a solution for how to approach this?

[hydro311]

It may be helpful to Eric if you edited your post to explain what your reference to “this” is…

I’m guessing he is getting pulled in a lot of different directions right now, so he likely isn’t going to immediately recognize what exactly you’re referring to.

[terrence.bentley]

It’s not intuitive, but if you click the little “reply icon” in the top right of a post (only shows when a user specifically uses the “reply to a specific post” function), it will take you to the original post that is being replied to for the context behind it:

[Eric_Inovelli]

@SamJWard

… and not a single issue with Zigbee Binding. Have yet to have it fail even once.

The only issues noticeable:
-Dimming speeds are intermittently different and use one setting or another instead of doing what they should as I mentioned previously.

Now onto Hubitat…

I’ve setup the same exact environment as above except for with a C7 Hubitat Hub. Constant disconnections, constant Zigbee bindings failing.

I have no idea why, I was using both single and group binding on both Hubitat and Z2M.

Very interesting – how did you get Group Bindings to work on Hubitat? I’ve only ever seen Individual, but I also haven’t looked too much into it.

@SamJWard

It seems the more devices that route through an individual switch, the worse that switch routing performance and overall performance becomes, so I’m not sure if making the routing table larger will fix the problem with binding, I would think it would make it worse with the current z stack.

As for network flooding, on v2.10 I don’t see too much of it. Although, I have a few of the power reporting settings disabled in the firmware. The switches still do report wattage power when the switches are on every few seconds, but that doesn’t seem to cause any problems.

Yeah I’m not sure how to answer from a technical side as that’s not my background, but anecdotally, I noticed a huge change between 2.11 and 2.13. You may be right though as when I tested 2.12, the bindings still didn’t work and that’s when he doubled the size. It wasn’t until 2.13 when the memory function was added when my bindings started to work all the time. So, idk if it was the simple memory function that fixed it or the combination of the two.

I don’t remember what version it was at this point, but he cut down on the, “Many to One” (MTO) commands that were reporting as there seemed to be a lot.

@SamJWard

I think we are starting to see that some coordinators just can’t handle too many devices, and I believe some of the manufacturer’s just don’t want to admit it. For example, I used a Conbee II with Home Assistant and Z2M in the beginning and had terrible performance as well with the switches, but after switching to the Sonoff P (Texas Instruments chipset), everything is stable. I hope this helps someone, because this made a giant difference between wanting to rip my hair out vs having a functioning stable setup, and not having to worry about “will the switch work this time?”.

Yeah this is what I’m thinking too. The only hub/gateway I’ve ever heard there being a limit on is Philips Hue which has a disclaimer that it can only handle 50 devices. However, in talking to the engineer, there is a difference between what the hub can handle in terms of devices connected to it and what is being processed in the tables at one time. Again, I’m not too well versed on the technical side, but that’s my high level understanding.

@SamJWard

Do you guys allow testers? I have a smaller test setup of 15 switches where I’m modifying the EEPROM manually via direct board communication. If there is a better way to make changes and test just let me know.

Yeah certainly, can you shoot me and @EricM_Inovelli a PM? I appreciate your willingness to help!

[hans.gelpke]

Has something been officially released? Z2M still shows 2.08 and no update available in OTA

[hydro311]

Nothing new released yet - 2.08 is still the current general-availability release.

[SamJWard]

I used the Inovelli app in Hubitat to do group bindings.
Master endpoint just has to be 2, while all slave devices are 1. (Multiple slave devices)

Unless the term “group bindings” means something different like an actual group ID.

In Z2M I created a group, then linked the binding to that group. Hubitat was different, but the commands it was sending were almost the same as group bindings when selecting more than 1 slave endpoint so I think it’s basically the same thing. Correct me if I’m wrong.

And yes, I’ll send a PM out.