Hi, I’m newbie. So sorry if I’m writing wrong section.
My question is about the automation.
I would know if an automation start with the verify of trigger and wait for the condition, or start only when the trigger is verified during the condition event.
In both cases how to get the other way working?
For example:
I want that a trigger is considered only after 2 hours of working condition, and the working condition is when deumidifier is above 200Watt.
So, i want to shut down my deumidifier socket (Shelly) only if, after 2 hours of working condition above 200watt, it fall under 50watt.
It would mean that the sensors of full-tank switch off the compressor and it is beeping noisly in the night (so only between 00:00 and 08:00)
So only in the case it worked for at least of 2 hours and it stop working doing only noise, I want to shoot it off.
Any suggestions on how to concatenate trigger and/or/waiting/ conditions?
Thanks you very much! and sorry for my bad english.
Not 100% understanding your English, but I believe your desired automation , is:
When operating power >= 200W then start a timer
When operating power <200W then stop timer.
When timer has been running for >= 2 hours then turn off socket.
something like this…
(change with the sensor you are using to measure power)
(change with the switch you are using to turn on/off)
input_boolean:
failsafe:
initial: false
automation:
- alias Switch off after 2 hours at >= 200W
trigger:
platform: template
# assuming that 200 is 200W ; change if needed.
# note use of quotes: ' and "
value_template: "{{ states('<your-power-sensor>') >= 200 }}"
for:
hours: 2
minutes: 0
seconds: 0
condition:
- condition: state
entity_id: input_boolean.failsafe
state: false
# you can add a further conditions here if needed,
# but use 'conditions:' under 'condition:' above
action:
- service: switch.turn_off
entity_id: <your-socket-entity-id>
- service: input_boolean.turn_on
entity_id: failsafe
This will turn on the failsafe (sets it to true/on/1) , and turn off the device until the failsafe entity is turned off by you, somehow, setting it to false/off/0 either via automation or perhaps using a card on the front end.
p.s. not checked for syntax - use the syntax checker in lovelace.
I haven’t tested it since I don’t have the same equipment as you but I think it will work.
The only thing that might be an issue is that it will only trigger if the power consumption has stayed above 200 for 2 hours continuously. If it falls below 200 at all it will reset the timer. So make sure that the setting you pick will be sure to be above that for the full two hour time.
Hi Ninjadog, sorry again for my english, an tnx a lot for your support but this:
When operating power >= 200W then start a timer
When operating power <200W then stop timer.
When timer has been running for >= 2 hours then turn off socket.
is not what i’m triyng to achieve.
instead is more likely this:
Label: “Start”
if: operating power >= 200W for at least 120min
then: goto “check when operating power <50W”
else: goto “Start”
Label: “check when operating power <50W”
if: operating power <= 50W for at least 10sec
then: turn off socket
else: goto “check when operating power <50W”
tnx a lot for your support, i think this is more likely what i’m searcing for.
Answering your question: yes it’s far above 200w, it’s about 450.
but to be clearer with you:
imagine you have a heater that you turn on in the night, and you want it to stay on as long as you put it on in the night, but to turn off as soon as it consumption fall below the 50W (because in that case is doing only noise because he reached the temperature) in the same time you want to be secure that it has done his job for at least 2 hours. hope this can clarify.
For me to understand more:
input_boolean:
humidifier_on_for _2_hours:
here is invoked boolean function “input_boolean”
here an arbitrary name for it “humidifier_on_for _2_hours” in that case i can name it shorter?
As you want to pursue @Finity solution, I will cease posting here - pointless having two people posting different solutions and engaging in duplication of effort. Waste of time. Good luck !
Not exactly, i already tnx you before, but i clarify that your solution did not match my need, and i clarify that with example because your first solution “turn off my socket after 2 hour regardless of the condition”. Sorry again and tnx again also to your effort.
It was an example, I’m not going to write is automation system; he needs to learn by example and that is what I am doing.
Your’s is ridiculously overkilled. It may well work, it may not, I’m not wasting time checking your syntax, but it is inefficient nonetheless.
There’s many ways to cook the soup , no right and wrong provided the solution implements the requirement successfully.
As I said, I’m not contributing to a multiple solution thread dialogue, so I will leave him in your hands .
The guy just joined 20 hours ago and politely asked for help. So I helped.
He was even so polite about it that he clarified what he wanted and even thanked you for the incorrect implementation you offered.
I’m sure he will start to figure stuff out soon enough. If not then we can go from there. But it looks like he should do OK. He managed to modify my suggested code and modified it to his needs so that’s a start.
Ridiculously…? Really?
Please enlighten me on how I could have done exactly what he wanted and made it “ridiculously more efficient”.
Guys, calm down.
The aim here is to help the OP
I agree that breadcrumbs are best as they lead and get the OP to find answers but I doubt that will be sufficient in this case.
He has difficulty expressing himself in English and we need to cover ALL the requirements.
Having 2, 3 or even 4 responders is a good thing.
I would add my contribution here but it would probably be a complex template frankenstein thing. Not appropriate to a beginner to learn from both of yours so far have been spot on)
This also shows him different approaches and points of view, trying to get away from his weird syntax and more toward pseudocode or better still a complete list of conditions and intended actions based on events.
There is not a win here apart from the op
Please both continue and pick the best of everyone’s ideas
TIA
It was not my intention to offend anyone. I just wanted to explain that given my poor English, one had better interpreted my question than one other. I again apologize for the incomprehension and take this opportunity to thank everyone for the excellent work and timely support.
You have ZERO need to apologise.
You have done nothing to cause offense.
Today is the first time you have posted, so WE should apologise to you.
(it’s normally a lot friendlier than this )
I know how badly google translate can cause simple things to be garbage, so we understand
mate, you’re asking questions on two solutions to two different responses.
Stick with @finity and his code. Send you down a rabbit hole. So when you get nowhere, post a new question on the forums and I will reply to that. Here , on this thread, you talk to @finity not me
the first is using a “numeric_state” trigger and uses the value_template to get the value to compare to (in this case comparing it to less than 200). It uses the power attribute of the entity_id provided.
the second just uses a straight up value_template that contains all of the required information inside the template itself - entity_id, attribute and compare value.
So yes, you can change the trigger to use the same syntax as the one in the condition by using a template trigger instead of a numeric_state trigger:
yes, you can create as many input_booleans as you need as long as you name them uniquely as you have there.
But the one problem I see is that all of your automations have the same alias. That won’t work as you expect. They all need to have unique aliases as well.
You can’t really use the template the way you have it written because the numeric_state condition requires at least an “above:” or “below:” entry to compare the value_template result against. I don’t think you can have the comparison inside the template.
But you can use the same syntax as the numeric_state trigger above for the condition.
Either way is OK it’s just that the way it’s written in the original line 18 is more compact.
There is nothing special about the input_boolean you have listed there. It is just simply another input_boolean created and named just like you named the others “one”, “two” or “three”.
the “initial: false” just means that whenever you restart HA the the state of the “input_boolean.failsafe” will always be off until you turn it on later. If you don’t use the “initial:” option then the state of the boolean is maintained thru restarts - if the boolean is on before you restart HA it will still be on after HA has finished restarting.
You can use that option for any other input_boolean that you create.
I hope I understood your questions and answered them OK.
Also, remember to look at the docs for information too.
)
