I do not think so. There are two ways the situation can occur: the solar production increases while the car is charging, or the car starts charging while the solar production is already high enough to cover it. Maybe you could throw in HA restarts, that’s it.
Template triggers work by evaluating a template when any of the recognized entities change state.
Like I said, in my use cases it is working for me, maybe yours is different
Rather than a fixed interval just trigger when the excess sensor updates:
trigger:
- platform: state
entity_id: binary_sensor.car_charging
to: 'on'
- platform: state
entity_id: sensor.excess_solar
not_to:
- unknown
- unavailable
condition:
- condition: state
entity_id: binary_sensor.car_charging
state: 'on'
- condition: numeric_state
entity_id: sensor.excess_solar
above: 1000
action:
[script to increase charging power]
3 Likes
As said: this is harder to read -especially when you list of condition is bigger), and the automation gets triggered a lot (making checking what happened more difficult as it gives a lot of ‘traces’ when A or B happen a lot).
And also: when in the time between the triggered is fired, the conditions change (for example triggered from A and A becomes untrue when checking the condition -is this possible? in the framework is the thread of an automation first reading all the variable before applying the logic or is it only reading the variable when needed?), I might miss a ‘trigger’.
I can agree this is for the logic I want to implement not relevant (as I don’t care about short lived events here). But I believe formally
Trigger A
Trigger B
Condition A is true
Condition B is true
Action C
is not the same as
Trigger A AND B
Action C
(since as said A and B can change when we go to checking the condition).
It is rather the other way; of solar excess > 0W for 1 minute or so… then increase charging power.
Some of my power consuming machines have a very heratic behaviour that making it important that the excess has been ‘stable’ for some time.
I require anyway a logic because part of the logic of increasing the power (and the decrease) requires access to an integration that only allows a limited number of calls per day.
Walter
the actual logic is 'House Power < 0): it is not binary ;-).
Walter
ps: Is this forum having a flag to say my comment here was unimportant?
The HA automation setup might not be perfect, but changes have huge effects, so what you might see as a logic improvement will be step back for many others.
HA is open, so there are other options.
I think you can use something like pyscript for a writing in Python, or you could use NodeRed with a catch all event node connected to a function node where you are using JavaScript to write the code.
Note: just asking what is possible, not looking for a change
It describes what you want to do though. Imagine you’re doing it manually, sitting at a control panel with meters and switches. The triggers are things happening that prompt you to do something:
- new reading from the excess solar meter
- the car’s been plugged in
You then absorb the information and decide whether to increase the power based on the conditions:
- car is still plugged in
- solar excess is positive
It doesn’t matter if it triggers a lot. That’s fine.
It’s the concept of an “AND” trigger that doesn’t make sense, given the HA definition of “trigger”.
1 Like
That doesn’t mean there can’t be any usability improvements.
It would be nice to be able to simply list the conditions, and specify for the HA engine to automatically deduce all the necessary triggers for those checks.
Would be nice, and how do you expect it to figure that out?
Because of how these constructs work, those two things (trigger and condition) are only related by how your imagination works. Maybe I want something, say - a light on the front porch, on and blue when the little red wagon sensor senses cold. But the check is done only when i open the front door.
Yes, I just made that up, but the point is the same. There’s nothing that exists that says
when trigger for entity x happens check condition of completely different thing and the do something with yet another completely seemingly unrelated thing.
Not even the best AI would have a valid guess at it.
4 Likes
I don’t want to remove the current system that allows you to do precisely what you want.
But the significant portion of my automations are state based, not event based. I want to be able to simply specify conditions and tell HA to internally automatically generate the necessary triggers based on those conditions.
If you want something that’s state-based, you have two options:
- You either implement the solutions outlined above, OR
- You realise that HA is event-based and might not be a suitable fit for you.
To be fair, this isn’t the first time state-based automations were requested, but the linked post was pretty much resolved by the suggestions above.
1 Like
You are quite rude.
I’m willing to bet I have used HA far longer than you have, so it definitely is for me.
And I’m also pretty sure that state-based automations will happen at some point in the future, given that Home Assistant is moving towards better UX all the time.
Your belief is wrong. It is exactly the same.
2 Likes
I like to be corrected ;-). Can you confirm that HA reads first all the variables on an automation and then applies logic on triggers and conditions or only gets the variables when it needs the variables? In the latter case the 2 ways of formulating the logic is not the same.
I didnt understand this formally from the documentation that it reads all variables from an automation at the start of an automation.
I checked an automation and you are very wrong.
HA reads the values of the truggers first and reads the values of the conditions later.
I at least had some doubts… ;-).
What HA implemented.
Trigger A@now
Trigger B@now
Condition A@now + some time is true
Condition B@now + some time is true
Action C
And
Trigger A@now AND B@now
Action C
In the latter case you could still argue there might be some time between the moments of getting A and B, but normally in any computer system we assume the at least in the computer there was some moment where A and B where true.
In my automation the variable of power consumption of the house moved from -513W that fired the trigger to -503W at moment of evaluation of the condition.
I must say it suprised me; it was the first tracing I checked and it already confirmed variables in the condition are read after the trigger (what makes sense). Note that this variable is changed every second from the power meter. Maybe i should check once how long it takes HA to execute from trigger to condition.
Note; for my specifc UC case it wouldnt matter.
For another UC I was thinking of using HA to monitor something on one of my routers. Where I need to check 2 conditions that when they occur together they risks the stability of the router. I would use HA for this I have to keep this behaviour in mind. Or also; there I hit the limits of scope of HA ;-).
Yes, but the outcome is identical. We have been using this trick for years.
If you are going to split milliseconds, then
Trigger A@now
Trigger B@now
Also isn’t both guaranteed ‘now’ in home assistant… as a proof point, put this in dev-tools->template and you’ll see it returns false:
{{ now() == now() }}
Even if they are on the same template line trigger, one will be read slightly before the other…
The above will still end up
Trigger A@now
Trigger B@now + some time
Though granted that
Trigger A
Trigger B
Condition A
Condition B
Action
has extra checks so the time gap is a touch wider… but millisec.
1 Like