White Dimmer Binding and Local Control

Product Support Hardware & Firmware Help
, , ,
1
  • Product Tag: VTM31-SN
  • Platform Tag: Home Assistant
  • Region: US/NA

I installed an Inovelli White dimmer to control the ceiling lights in a room at my home. I also configured Matter over Thread binding between the switch and a few lamps.

I want to retain remote control over the ceiling lights via home assistant, but I don’t want physical manipulation of the switch to control the ceiling lights (ie: I want the paddle to control the lamps but not the ceiling light).

The ceiling lights are/could not [be] smart bulbs that could themselves have a matter binding configured.

edit: however, the switch stops controlling the bound lamps whenever I disable local control of the electrically-connected load. (Must’ve removed this in a draft, sorry!)

I must be missing something, because I can’t imagine any scenario where it makes sense to make “outgoing” bindings inoperable when local control of the load is disabled. How do I configure the switch to achieve what I’m looking at here?

I could of course setup a Home Assistant automation, but that is significantly less reliable than binding because there would be no way to control the lights if either the border router or HA was down.

(It is forcing me to add the “vsd30k” tag)

2

I don’t have whites, and this may vary between product lines. What happens when you disable local control? Does it kill the binding commands?

PS, we’re working on getting rid of that goofy tag.

3

When I disable local control, the bindings just stop working (ie: the lamps stop reacting to manipulating the paddle). I can still see the bindings within the Matter controller container’s UI and whenever local control is re-enabled the bindings automatically begin working again without reconfiguring them.

Hopefully that makes sense, but I can try to be more elaborate if necessary.

4

This has been discussed here before and AFAIK there is no work around for it. That is how the feature is designed. The binding action is triggered by “seeing” the paddle click turn on/off the load and that action is disabled when you disable local control. I think the logic is that disabling local control prevents the paddle from controlling the light directly and hence should disable bound lights as well.

A theoretical case would be a kids room where you could disable paddle action with local control at certain times of day to prevent kids playing with the lights at night. In that case you would almost certainly want to disable bindings also.

5

This has been discussed here before and AFAIK there is no work around for it. That is how the feature is designed.

That would definitely be disappointing and if that is the case, it would be nice to get an official answer as to if it’s intentional and if there is a workaround.

I wasnt able to find discussion regarding the local control with the white switches, but I could just be bad at searching the forums myself. I do see some discussion about the blue and the red switches, now, though.

Ironically enough, today I woke up to my WiFi AP being down, so my thread BR couldn’t communicate with HA, so an automation-based setup would’ve made the light switch inoperable.

I think the logic is that disabling local control prevents the paddle from controlling the light directly and hence should disable bound lights as well.

I guess in my head I was expecting the “dimmer switch” cluster/paddle and the “dimmer light” cluster/load control to be like two separate things that happen to be in one box rather than two, with this option defining whether they interact internally or not.

A theoretical case would be a kids room where you could disable paddle action with local control at certain times of day to prevent kids playing with the lights at night. In that case you would almost certainly want to disable bindings also.

Definitely not a use-case that I’d have, but I guess I can see why someone else might want to achieve something like that. Notably, this use-case:

  • is already willing to accept that the light switch could be non-functional if the controller goes down when ‘local protection’ should be transitioned from off to on
  • could still be achieved AFAIK by automating the matter bindings instead of the local protections state. Though I am not aware of a system that has first-class support for this today, I don’t think it would be a huge jump to support such a thing externally if there was an actual need.
  • would still send press events to home-assistant and cause any automation-based events

Having gone back and looked at the option as presented in Home Assistant, I also see that is is called “Control of Switch Load” now, instead of “local protection”, like it is in the manual.

This probably also contributed to some of my expectations given that the options are labeled “Remote & paddle control” and “Remote control only”. The “outgoing” bindings aren’t triggered, by a remote control of the load, so it is unintuitive that disabling “paddle control” of the “control of load switch” would break the bindings.

As best I can tell, these labels are not a third party interpretation, but taken from what the switch itself publishes on Endpoint 22, Cluster 80, Attributes 0 and 2.

6

Actually the way it is written is intuitive to me. Binding is triggered by the paddle toggle action, the “Remote control only” does what “it says on the can” and disables the paddle, and so disables binding that is associated with it.

Having said that, I can see that applications like yours that can use the feature that way around.

However I believe the mode select option would need to be extended to have a “Remote control only with bindings” option so that either option could exist otherwise we break existing implementations that work based on how the feature is currently designed.

The big issue is how binding links into the rest of the code (since it runs before multi-tap detection etc.), how hard it is to re-factor the implementation and where this new feature would sit in the priority list for Inovelli development etc (which I’m sure is ever expanding).

I have copied your request for official confirmation of how the feature works to Inovelli support.

7

@Kaleb_Inovelli Kaleb, when you can a second can you confirm this for Bob (ie. binding is disabled when a switch is set to “Remote control only” mode)?

Thanks,

8

I find it actually hilarious how we can both read the same thing and walk away with the completely opposite conclusion. When I set the “control of switch load” to “remote control only”, I’m still expecting the bindings to operate exactly because I expect them to be “triggered by the paddle toggle action” and not the fact that the voltage on the terminals has changed.

For the same reason, I also expect the paddle to send events to the matter controller even when it is in “remote control only” mode (like it does).

I’d question how many people exploit the existing implementation and say we should just fix it to my correct implementation, but I guess you could say I’m biased :wink:

Thanks!

9

Also…
If the switch could control two “loads” (one physical via the load terminal, one virtual via bindings) which one should the LED status bar show?

10

If it wasn’t clear, it already can. Mine do right now.

In general, the devices that I bind are expected to behave in-unison with the load, so it wouldn’t typically matter. eg: Binding the kitchen and living room overhead lighting to the opposite switch in my open-plan home so that it’s like a three-way switch for all the of the lights.

But I also just have the brightness indicator turned off because I don’t need the bar to tell me how bright my lights are :man_shrugging:

Overall, I think that the only sensible choice would probably be the switch load:

  • A switch could have multiple targets bound to it, and they could all have differing levels of brightness.
  • Even if there was a single binding, I don’t think that the switch would actually be informed of any remote control sent to the target by something else.

Does the bar show anything when smart bulb mode is enabled?

11

Absolutely. It shows the status of the switch on/off etc.

12

I’ve run a lot of engineering groups of various types as well as product management and marketing over the years. I have to say it always works out badly when you take something that is working away from an existing customer. That’s why I say that if an option like this gets added it needs to be an option not a replacement.

13

For matter/zigbee/etc, binding is between two light endpoints. You’re looking for the switch events to be bound to a light entity from a different device, which is not possible in any of the ecosystems afaik. Not an Inovelli issue, but just the way matter/zigbee/etc works.

One potential solution could be for Inovelli to add a feature to both disable local control and create a dummy light endpoint that is controlled by the switch. From there you could bind the dummy light endpoint to the lamps and continue controlling your ceiling lights separately/remotely.

14

It would not… However if you bind light A to B and B to A (two separate bindings) then toggling the paddle to dim light A will dim light B (and the LED bar will reflect it) and vice-versa B to A.

If you want to effect multiple lights from a Hub (HA or whatever) then you need an automation to do it.

Andrew

15

Hmm, I don’t believe that is true.

When adding the matter binding, it is from the dimmer switch cluster (NOT the dimmable light cluster) on the switch to the extended color light cluster on my smart bulb.

edit: And again, manipulating the light via something external doesn’t cause the bound light to change; the commands aren’t “forwarded” between lights.

16

Which from my experimentation is not actually related to the brightness of the light when smart-bulb mode is available, because the expectation is that a device in smart-bulb mode would be controlled via more than just the switch, so the light could be off and the switch be on or v/v.

(therefore the problem posed regarding what the led bar would show is not novel to bindings working in “remote control only” mode)

17

That is certainly true. However what I said was the LED bar reflects the state of the switch. As far as the switch is concerned its load is on all of the time when it is in smart bulb mode, however the on/off/dimmer portion of the switch still behaves normally (as far as it is concerned it switches on and off and you can control brightness etc. What toggling the paddle actually controls is then dependent how you design binding and/or automations. It’s up to you to set up things with binding and automations if you want everything to match.

As a simple example I have a number of VTM30-SN switches. The switch in my office is in smart bulb mode and the load goes to a fan/light so the fan has power all of the time (Hunter wifi/homekit fan light combination using Homekit Device to integrate into HA and Homekit Bridge to push the fan and light to Homekit). I’m using a VTM30 in this case since it can support both a fan and a light load (the VTM31 cannot).

If I turn the VTM30 on on the wall (toggle up on the paddle), the bulb associated with the fan lights and a separate table lamp controlled by a MQTT driven switch also turns on driven by an automation. Also if I turn off the fan light directly (via HA or Homekit) the state of the switch will follow it (driven again by the automation). Same applies to the fan portion, there I use the config button for the fan and the state is reflected by the color of the LED bar. Whether I turn the fan on via the config button on the VTM30 or via Homekit the states will always match because the automation is coded that way.

Hope that this helps.

18

One other comment, bindings are essentially one directional.

A binding from A to B means that if you (say) turn on the switch at A, B will turn on (same for off). If you turn on or off B it turns on but A does not. For that to work bi-directionally you need a binding from B to A also. I have that configuration for a pair of VTM31s that form a “virtual three-way” (two seperate bindings). Toggling either switch will cause the other one to follow state.

I also have both VTM31s in a light group and it is the group that is pushed to Homekit so turning on the group from Homekit switches on (or off) both lights.

19

I think that we have the same understanding! I just wanted to make the point that the problem proposed by @SandyB is not actually a consequence of the bindings being available when the load control is set to remote only.

+1

I also have two VTM31s bound each direction into a virtual three way. It’s actually a virtual fourway with an aux connected to one of the two, but I’ll probably throw another VTM31s in it’s place at some point to get the light bar, then bind that switch to the two others that actually control the load (four bindings total: A->B, B-> A, C-> A, C-> B).

And because bindings are switch → light and not light → light, I still have the flexibility to control them individually via the home assistant interface (or HomeKit, since I have them setup in both) for more specific scenarios (eg: I only have the one come on when motion is sensed at night, so that it is dimmer).