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.
The only bulbs I can find on there are A19, no other shapes/bases, and don’t seem to be available in commerce. They’re not available from any retailers, and only seem to exist on the ZWA website. I’d love / prefer to have an option, but the things don’t seem to be available to be bought.
Most popular ZWave light switches have indicators, either as a simple on/off, or on dimmers, they have lightbars or LED segments to show the current dimming level.
Yeah, and it’s not great! When it’s got to maintain bidirectional state, it’s actually even messier, because it’s pretty easy to get an automation that can loop indefinitely as it triggers updates on one device from a sync. The WTH is an ask to make this kind of task, when the user has devices that should be linked, but have no native support (generally due to a mix of protocols) easier to manage, and not require setting up an automation for each light/switch pairing.
Oh, I’d need/use A19 bulbss, too, but those aren’t available for sale anywhere, either. I shouldn’t have confused the point by noting that the products that aren’t sold anywhere also only come in one size/shape/base type.
Amazon.com : z-wave bulb in the US, this search returns only bulbs that are non z-wave, mainly zigbee. The filters don’t even offer the ability to filter for Z-wave… The choices are “Matter”, “WiFi”, and “Zigbee”. A search for “zwave” does not produce anything different. The major home improvement chains also don’t return any results that are actually z-wave products when looking for light bulbs.
I do have some ZWave bulbs, from Inovelli, but they long stopped offering those. (Again A19 only, but there hasn’t been availability for years, and they are old Zwave, so to have them synced at the zwave level with a switch requires downgrading the switch to not use security, they don’t support S2.)
In my case, this is a zwave-specific problem, but it’s really an issue for anyone who already has smart switches/bulbs and for whatever reason needs or wants to pick bulbs/switches of a differing protocol (like transitioning to matter from BT/WiFi/zigbee incrementally rather than all at once, or the required form factor not being in the ‘right’ protocol.)
Syncing a bunch of lights with light groups is already mostly great! There’s nothing built in for managing the relationships between lights and switches, though, if the devices in question can’t manage it natively outside of H-A.
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
- action: "switch.turn_{{ trigger.to_state.state }}"
target:
entity_id: switch.desklampsdevice
data: {}
mode: single
I’m quite sure you can remove the delay also but you need to test that
