Say you’ve got ZWave switches or dimmers, and later want to add smart bulbs. Unfortunately, zwave bulbs effectively don’t exist, so the bulbs will most likely be unable to be paired at the protocol level.
Keeping the switch state in sync with the bulb state regardless of where changes are made (at the physical switch, or directly against the bulb entity.) is a lot more difficult than it probably needs to be!
It would be great if there were built-in functionality for this rather than requiring complex scripts / automations.
I’m not sure if I follow what you mean. So you have a switch, which is a physical device, that has an ‘on’ and and ‘off’ state. So it looks something like this (not really the same necessarily but it has a recognizable state)?
But then you switch the smart bulb via some other means, and the switch’s indicator is no longer the same as the state of the light. What exactly do you want HA to do about that?
If the switch is simply a toggle with no further indicators, wouldn’t it make more sense to just include this logic in the automation that you use to process the signals from the switch? So use ‘toggle’ instead of ‘turn on’ or ‘turn off’?
BTW, you haven’t voted for your own proposal. Not sure if there is a WTH about that but I find it quite ridiculous that this is necessary. Maybe it’s meant to be a test if you read the call for WTH proposals well enough.
It would be a smart switch, meaning that there’s no “physical” state that can be discerned by position, but it has an indicator for the brightness level of the attached bulb (because it is a dimmer switch.)
It’s not possible to only ever interact with the switch entity, because a wall switch doesn’t have controls for color temperature or RGB.
If it were a dumb bulb and a smart switch, the switch’s power state would always match the bulb. If it were a switch and bulb of the same protocol, they’d also likely always match (pairing devices at the zwave/zigbee/matter level.)
Ah, so it’s not just about binary states. Since ‘binary’ was in the name of the blueprint you linked I sort of assumed that was what it was about.
Basically what you want is an automation that automatically updates the state of the remote (let’s call it a remote since it can do more than switching) when the state of the light changes? And for that automation to be built in to the integration that drives your remote, so you only have to click a checkbox and select a light on the device page?
It’s something useful, sure. But probably a bit niche, since most remotes don’t have indicators.
Fortunately for me, I only need to follow the off-and-on of my switch and my light doesn’t have any controls. But I know what you mean. Here is my automation YAML The switch bulbs comes from the ISY994i and the desklampsdevice is Tasmota.
alias: Desk Lamps
description: Turn desk lamps on or off depending on the state of the ISY scene Desk Lamps
triggers:
- trigger: state
entity_id: switch.bulbs
conditions: []
actions:
- delay:
milliseconds: 25
- if:
- condition: state
entity_id: switch.bulbs
state: "off"
then:
- action: switch.turn_off
target:
entity_id: switch.desklampsdevice
data: {}
else:
- action: switch.turn_on
target:
entity_id: switch.desklampsdevice
data: {}
mode: single
Yeah, pretty convoluted, but that’s the nature of HA
In your case, you’d have another trigger which would be a change that occured at the light. Then in actions you’d have an if statement to select the actions to take depending on the trigger. (see: here)
Your automation would be just more than double mine. Again, nature of the beast.
