Hi there,
I’m pretty new to HA, but fully hooked already Did a lot of tests and play-arounds, have some integrations running and already filled my Energy-Dashboards with sensors. The learning curve is slow but steady.
Well, but when it comes to automation, I’m stucked. I have a binary_sensor, which switches between ‘on’ and ‘off’ correctly. Now I’ve tried to connect that to the state of a Tasmota switch, which I thought should be a pretty easy exercise, but I failed. From a schematic point of view, its nothing more than connecting an input of a system directly to an output. But I think, it doesn’t work like that in HA, or does it?
I don’t even know how to start correctly - is it best done by a template? helper? automation?
I assume that I can run the automation dialog and create one automation which does something like “when sensor switches from on to off then switch is off” and a second one which does the opposite. But I don’t like that, I think there must be a better way.
alias: Binary sensor to switch
description: ""
triggers:
- trigger: state
entity_id: binary_sensor.YOUR_SENSOR
to:
- "on"
- "off"
actions:
- action: switch.turn_{{ trigger.to_state.state }}
target:
entity_id: switch.YOUR_SWITCH
mode: single
New automation / create from scratch / three dots / Edit in YAML. Then paste the above in place of the default code, update the two entity IDs and save.
The to: on / off line is there to prevent confusion when your sensor goes unavailable.
(removed Template Switch suggestion: see Drew’s post below)
I’d probably use the automation just for familiarity, and because I write most stuff in YAML as I’ve been doing this since before the template switch was a thing.
The template switch won’t actually turn the real switch on and off based on the state of the binary sensor. The state template will make the template switch’s state reflect that of the binary sensor, but it will not fire the actions.
This is starting to sound like an XY problem. Can you clarify why exactly you need a binary sensor to reflect the state of a switch?
I’m asking because if you integrated the Tasmota switch into HA (via MQTT or the native Tasmota integration), you should see a switch entity whose state you can use directly. No binary sensor required at all because a switch has a binary state.
The reason I’m asking this is that the solutions above only work one way, since that is explicitly what you asked for. In the above examples, if your switch is toggled outside of HA, the state of your binary sensor will be out of sync with the actual state.
You’re running the risk of your automation failing because you think you’re turning a switch on, but it’s already in that state. Telling us your actual use case will help us help you avoid this before it becomes a problem.
Hi @ShadowFist ,
thank you for your input - and you are right, maybe I have made myself not clear enough, I thought the thing would be easier than expected.
I understand, that with this approach, I cannot guarantee a sync with the actual state in any case, for example when a trigger outside of HA occurs.
Well, my scenario is pretty simple: I have a small heat pump, which I cannot control directly over network, so I just switch its power supply on and off with a Tasmota plug. Therefore I use the native Tasmota integration for now. Beside that, I have a variable energy tariff, for which I can fetch the prices on a day-ahead basis. With this information, I have created a binary_sensor which indicates the two cheapest hours of the current day. I thought this is an easy task to use this binary signal to switch the Tasmota plug on and off.
For the synchronization: I don’t think that it is a common use case to toggle the plug outside of the HA-world, but of course it can happen rarely. I can think of a power outage or something might get the things out of sync. I dont know how to address that issue yet.
Assuming your binary sensor turns on and off reliably when the cheap hours start & end, then your solution might work.
Bear in mind that this will be a “good enough for now” approach while you get more familiar with HA. The sync issue will still be present in the scenarios above. However given you’re toggling the switch at least twice a day, any sync issue should adjust itself within 24h.
Start off with this and keep an eye on it the first few days to be sure it’s working as expected.
In future, you might want to revisit and improve this using a schedule/calendar event or a ready made blueprint which meets your needs.
Search around the forum too. There’s plenty of threads where people switch stuff on & off during cheap hours. I’m sure you’ll find some inspiration here.
Here is a way to do it in a blueprint, and it will work as long as your input object returns a state ‘on’ or ‘off’ and your output object supports turn_on or turn_off. If you get a bad input state, the script will error out (desired behavior) rather than just turning the output off.
This is a blueprint. You can edit into an automation if you don’t want to use the blueprint.
blueprint:
name: Boolean Follower
description: An entity with turn_on and turn_off follows the state of another entity with on or off states.
domain: automation
input:
to_follow:
name: Entity to Follow State
description: The entity with the desired state.
selector:
entity:
target_entity:
name: followed
description: The entity that should bept in sync with the entity to Follow State
selector:
entity:
mode: restart
triggers:
- trigger: state
entity_id: !input to_follow
actions:
- action: homeassistant.turn_{{ states(trigger.entity_id) }}
metadata: {}
data: {}
target:
entity_id: !input target_entity
Did a lot of tests and play-arounds, have some integrations running and already filled my Energy-Dashboards with sensors. The learning curve is slow but steady.