homeassistant

14104 readers

29 users here now

Home Assistant is open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server. Available for free at home-assistant.io

founded 2 years ago

MODERATORS

GreatAlbatross@feddit.uk

greatalbatross@lemmy.world

Simple light automation question (lemmy.world)

submitted 4 hours ago by root@lemmy.world to c/homeassistant@lemmy.world

9 comments fedilink hide all child comments

I currently have a lot of my light automations setup by first having an automation that turns the light on at a certain time, then another that turns the light off at another time. This works, and it has for years, but I'm imagining there must be blueprints or other methods to do this on/ off behavior in a single automation rather than having them in pairs (this is not scaling very well).

Anyone have suggestions? The image is a blueprint I have for turning lights on/ off based on a time window which is very handy, and I'm hoping there's something similar out there for my needs.

top 9 comments

sorted by: hot top controversial new old

[–] Damage@feddit.it 2 points 43 minutes ago

It's possible but honestly it's a bit off-putting to me.
For scheduled actions I use the Scheduler addon: It's mostly for covers and awnings, I don't schedule lights on and off, I enable their motion sensors depending on the time of day, but that's a more complex automation and I wrote it in Node-RED, which to me is a cleaner approach than the automation system in HA.

The Scheduler has the advantage of being wife-accessible too!

[–] madjo@feddit.nl 1 points 1 hour ago* (last edited 1 hour ago)

I use scenes and automate those scenes. That way, if I ever get a new light or have to replace a bulb, I only have to update the scenes.

Don't even think about bipartisanship.

[–] vk6flab@lemmy.radio 6 points 4 hours ago (1 children)

Before you start consolidating, consider what might happen if the switch is in an unexpected state. For example, someone turned off the heater or pump and you were expecting it to be on.

In other words, you need to consider what a "safe state" is for each thing and how your code, when it fails, reverts to that state. This is an example of "failsafe".

Note that I said "when it fails". This is true for all software, even on mission critical systems.

Source: I write software for a living.

[–] root@lemmy.world 1 points 2 hours ago* (last edited 2 hours ago)

Yes, definitely. That's one of the reasons I've implemented this way. If a light (for example) had the physical switch turned off and back on, a lot of smart bulbs will go to the on state, even if HA had previously set (and expects it to be) off. The next execution may turn it off in an off state, on in an on state, on from an off state or off from an on state, but either way that truth table will resolve after an iteration

[–] node815@lemmy.world 3 points 4 hours ago

This is what I use and it's quite impressive.
https://community.home-assistant.io/t/simple-scheduler-addon/174326

I've had it for a few years and it never has failed to run on time every time. Can automate more than lights with it and it's really just a point/click set and forget type of thing. My setup for my lights. :)

[–] jrke3ok2@lemmy.world 3 points 4 hours ago (2 children)

In fact there is the option. What I do is: I set two triggers, for example, tine to turn on the lights and time to turn the off. There is an option called name ID or soemthing like that and I set a name for each trigger.

When you then set the actions, in the advanced actions there is an action called "choose" if you select this action, on the conditions you can choose your trigger base din the ID name and the action you want to perform once the trigger is activated.

[–] mhzawadi@lemmy.horwood.cloud 1 points 2 hours ago

Look for the new if, then if on turn on light. Else turn the light off.

[–] echutaaa@sh.itjust.works 3 points 3 hours ago

This is usually the best method, but just beware if you’re trying to get performant on demand execution the larger decision trees will cause issues. If you find the automation taking too long to trigger/execute you’ll want to break up the automation into smaller ones and just group them.

[–] Zwuzelmaus 1 points 3 hours ago

Just to provide a different point of view:

My general strategy is to decentralize these simple condition-action things.

Where only one sensor controls only one action/state, the function should run on the device itself, not on HA. Either the sensor or the switch or both is "smart", and it is good that HA knows and shows the state, and you can switch it on/off there in the HA app, but it should not depend on HA. It should still work when HA is down.

In my case, Tasmota runs on all the light switches and a rule in Tasmota does the job.