Hi, I’ve been searching for a couple hours now and haven’t found a documentation or example on how to achieve what I want.
All I basically want is a single automation that acts like a time switch/clock timer, where you define certain time spans in which one or more entities are turned on/off. I know that it’s easy to do with f.e. two separate automations for on and off, but this will become a nightmare to maintain when you have multiple time spans since you end up with dozens of automations that basically perform the same thing for the same entity. I was really surprised that HA doesn’t support such a IMO basic use case out of the box in an easy to configure way.
My particular demand is to turn on/off two water circulation pumps within 3 time frames throughout the day (morning, noon, evening). I wouldn’t mind a separate automation for each pump, but I really don’t want to end up with 12 automations for such a basic task.
If there really is no way doing this with automations I’ll write a custom AppDeamon script for it, but I prefer using builtin HA features wherever I can.
oh wow, thanks for the link. A weekday scheduler would be a nice feature for HA in general, but that’s a bit over the top for my more basic demand with time frames “from X to Y”. I’ll study your code and see what I can use from that.
Glad you got a solution.
Though …
The fact that you think it simple to do and yet couldn’t do it yourself shows that it’s not actually a simple thing to do. (HA provides lego bricks, maybe components but not whole buildings)
If you have (as Tom’s case shows) a 15 minute run time it’s a bit easier but what if you need a time on and a time off.?
What happens if you restart HA at some point ? The valve would stay open until the next scheduled shut off time (so maybe 2 days and 15 mins ) Tom is aware of this and will take appropriate steps, but will everyone?
It those circumstances it’s better to have set on and off times and if HA is able to respond, it will happen.
As for the complication, well, stick it all in a package, everything it needs is in there and when you need another widget switch timer thingumy, copy the package, edit it to make the entities unique and you are flying.
@Mutt I don’t have a solution as of yet - still investigating/trying things. And like you described I’m not looking for a start time + duration but for a start time + end time solution.
And I already noticed that it’s not simple to do with current feature set of HA, but this IMO should be. So there is room for improvement on HA side.
@Burningstone I prefer using HA since this is what HA is supposed to do. If I rely on third party applications for all my logic why should I use HA at all then?
I see your point, I agree it is not a built-in HA feature but I would not really call AppDaemon a third party application. You use HA for tying all the different devices from different manufacturers together and for the frontend as well, AppDaemon is “only” for the automation part. I moved all my automations to AppDaemon a long time ago for multiple reasons and it was one of the best decisions of my home automation journey
Pretty much everything that is now core HA was once a third party integration.
I sort of disagree with @Burningstone on appdaemon (we’ve had this discussion before) I have seen enough threads discussing issues with appdaemon issues/failing to start/memory leaks etc. For me to not to plunge in, (others, like burning, swear by it) (Note:he only got in to it cos he thought normal HA was a bit intimidating, now he’s a regular and valued contributor ). I only use vanilla HA and when I come across something I NEED to do that I can’t, then my next choice will be Appdaemon. (not needed it yet)
You ‘can’ use a single automation to trigger at (say) 6 different times in the day, but then you need conditional logic in the action to determine “what the hell should I be doing now ?” This is also possible but it is complicated and not for most newbies to be forced to navigate.
Clean simple automations are usually more succinct and easier to maintain.
Why is it a problem having 6 automations instead of 1? It’s not like there’s a tax on them or they clutter your interface.
Did not see a lot of them recently and I think with HACS it now is even easier for new users to get started with AppDaemon, however I agree with you that it’s not yet made for beginners and still has a steep learning curve. As far as I know the AppDaemon team is working on something like an “App Store” for AppDaemon apps with a GUI, which should make it easier for new starters.
Very True, but as I said, I don’t need it yet.
I have some quite complicated automations all run vanilla.
Speakers that have upto two slots per day, or a just stay on for the next “12 mins” or manual on now AND they go off when the house is unoccupied AND come back on (if they should be on) when someone returns.
Lights that are grouped according to usage and type that vary brightness through the day.
Timers for all lights according to room for how long they should stay on
Heating that changes according to doors, occupancy, time of day or just whim
Etc.
All controlled by elements from the front end.
What I want to do next is temp burning to do his next automation entirely within native HA (it’d be a sort of challenge)
I already use AppDaemon to control HUE bulbs (brightness and color) via my KNX switches which I very likely would not have been able to do with stock HA features (or let’s say it might have been a nightmare of scripts and templates which is now a rather simple python class).
They clutter the automation management “UI” and it’s way harder to keep track of the “dependencies” to each other. So I rather have one automation for one “feature” instead of splitting one feature into multiple automations. If there would be a way to easily group them, I probably wouldn’t mind.
I also think most if not all of my automations would be doable with native HA automations, I just hate repeating code and creating entities only as helpers for automations and find it way easier to do things in AppDaemon.
Here an example of my notification system:
A message can have the levels “emergency” and “home”, and be “repeating” or “single”.
“Emergency” notifications are sent always.
“Home” notifications are sent if at least someone is home and at least one person is awake. If this is not the case, the message gets added to a briefing list and as soon as someone wakes up or arrives home, this person receives the items from the briefing list. When the notification that should be sent is a task or any other actionable notification and is “repeating”, the message will only stop repeating once someone pressed the button on the notification or if some other condition is met (e.g. empty the vacuum trash can, once the trash can is put back in and HA sees it is empty, the message stops repeating). Would this be doable with native HA automations? If yes, I assume it would need hell a lot of code?
I’m currently setting up TTS automations in AppDaemon. Might be something to test my Jinja/HA automation skills . For the beginning I want to add TTS messages to a queue when a message is currently playing and then play the next message in the queue once the currently playing message has been finished. You have any good idea how to tackle this with native HA automations? I already have this working In AppDaemon and it’s only a few lines of code.
Not sure how often these change, but seems like it could be done fairly simply with a couple of automations to trigger a few scripts?
Automation #1 for Pump #1.
3 Trigger - Time = 8am, 2pm, 8pm
Condition (whatever you want)
Script #1 - Turn on pump, delay for xx minutes, turn off pump
Do same thing for Pump #2 w/ a different automation / script. w/out more details around when / if duration of pumps running changes or such, a little harder to specifically code - but doesn’t seem to outside of core HA functionality?
Yep, I’m guilty of the assumption that he’d want 3 different things at 3 different times.
Well spotted and stated.
Though he does want 1 automation not only to turn on but also to turn off,
So a template in the action to see if one of 3 turn on times, else turn off
Doable
Yeah, without more clarity, tough to specifically describe. Could be one automation and one script potentially, really depends on the variability surrounding start times and durations needed for each pump to run.
Do they both start at the same times during the day?
Do they both run the same length of time?
Is this dependent on time of day?
Do these lengths change (daily, weekdays/weekends, monthly, seasonally, based on weather, …)?
Do the times change (daily, weekdaily, etc…)
etc…
If both same time and always same duration, one automation and one script could do, if not, then either creating multiple automations/scripts and/or templating could both work.
At the end of the day, sometimes having MORE scripts/automations isn’t always a bad thing. KISS (keep it simple stupid…). Could even put in a package if you want to isolate from other files - lots of ways to skin a cat w/ HA
I wanted to start with a simple approach without any variation depending on day of week. So something like:
Turn on pump
from 6 to 8 am
from 11am to 1pm
from 6pm to 8pm
It’s coincidence that it’s always a two hour span atm - but this could change after some time. And both pumps have different schedules, so I will need two automations.
So really nothing fancy with any conditions. A simple software replacement for this https://www.amazon.com/Timer-Switches/b?node=6291360011
and I was kinda surprised that there is no “simple” solution for such a basic thing in HA. I mean, yes, you can create multiple automations, but as already mentioned, this IMO should be possible with just one automation from a usability POV.
Yep again, but I think here you wouldn’t need the script.
@da-anda, you mentioned about managing your scripts and automations
This is just what I do but you could adapt for your needs
I use packages (not 100% relevant but) I also use vsc (visual studio code) with the HA plugin (others are available (like rainbow brackets and rainbow spacing, both highly recommended)) the point is you tell it where your config folder is and it reads all your yaml files. It knows your entities and as you type it will suggest auto completes, just keep typing and select when it comes up or scroll through the whole list.
So I need an input boolean, it was from the occupancy package and it was regarding me.
So I type input_b… And it will suggest input_boolean, type a dot then ib_ (all my input booleans start with ib_), then I type oc and it then lists all input boolean in the occupancy package and before you know it “input_boolean.ib_occu_mutt_force_evict” is handed to me
The same is true for all my entities, it also means when I’m going through an alphabetical list I can jump to the section I need to find the entity I need (the search operates pretty much like vsc does too
It’s not for everyone, especially if you have a large store of ‘other’ entities, but if you are moving to packages it’s worthwhile planning ahead.
@Burningstone, I re-read what I said about you and (I’m glad you took it the right way), it could have read that you were “useless until recently”. But what I meant and am clarifying now is that “you ‘were’ intimidated by yaml, but now you offer advice on yaml, automations, scripts and templating (the very things that intimidated you) to anyone who needs it” I think that’s paying back, which is what I’m trying to do because of all those guys who did (and still do) help me on a regular basis.
speaking of packages. What’s the real use case for those? Earlier today I stumbled across them and I didn’t really see how I could make use of them to ease up my life. I already split my config files, so all my entities are nicely grouped. Moving those into a package doesn’t seem to bring any benefit. So how are packages supposed to be used? Do you create a package for more complex automations where you need “fake entities” which you specify in the package config files?
Yeah, but you saw how it was, Tom gave you one of his and that one was too hot, the next one too cold, so you end up making your own because you run out of adjectives to describe the thing it’s not.
Give me the names of your input datetime’s your switch entity and I’ll show you what I ‘think’ you want.
But as mark99 says it isn’t very well specified originally so it was hard to tell.
From my code you can copy to the second instance, it will be written for a package but that’s easy to split out if you want. The front end is down to you, I don’t do front end stuff, I just use plain entities on entity cards.
Packages,
Say you want an alarm clock, I send you one file, you drop it in the packages folder (or sub folder thereof) and its done, I could send you a card for the front end but it’d be too smooth or too lumpy (you get my drift)
Packages allow you to create 1 file that handles one thing be it a light or a whole room or a heating system or an alarm system.
All the binary sensors, input booleans, input datetime, automations, scripts all in the one file (you don’t have to edit 12 files to do one thing)
I have several packages that are virtually identical (once you’ve invented the wheel…) I just change the names (search and replace, easy too given my naming conventions) and I then have 4 packages for my speakers but I only wrote one.
Same for my lights, they all turn on, they all have to set a brightness, the brightness changes etc etc.
My configuration.yaml is 25 lines long (2 of them comments) I also have a ui-lovelace.yaml. Everything else is in packages
) Tom is aware of this and will take appropriate steps, but will everyone?
). I only use vanilla HA and when I come across something I NEED to do that I can’t, then my next choice will be Appdaemon. (not needed it yet)
. For the beginning I want to add TTS messages to a queue when a message is currently playing and then play the next message in the queue once the currently playing message has been finished. You have any good idea how to tackle this with native HA automations? I already have this working In AppDaemon and it’s only a few lines of code.