inner kite
I have automation if no motion is detected for 12 hours then... And it works as it should. But if the Home Assistant was restarted within 12 hours, it does not work as it should. Is there any simple method to ignore such an unknown state as it is for those few minutes when HA restarts? Method without Helper - only using IF in automation.
HA restart also change sensor last_changed value so I guess I can't use that too? Or there is option to disable changing this value on HA restart?
hollow sage
Whenever the motion goes to "off" - set an input datetime to be now() + 12 hours. Then trigger your current automation with time = that input datetime
inner kite
Hmm... Yes, this is some kind of solution. But maybe some solution without creating a helper? I have a lot of such automations and I wouldn't want to create helper for every.
It has no sense to me that sensor.last_changed value changed after Home Assistant restart. Is there option to change this?
Also no sense that in automation condition 'unknown' is not detected as no motion and not detected as motion - so every restart break all automations.
hollow sage
There's no way I can think of doing it that doesn't involve an additional entity at some point
Assuming a state when it's explicitly unknown is a very flawed approach, I'm glad they don't do that
inner kite
Assuming a state when it's explicitly unknown is a very flawed approach, I'm gla...
In my opinion, there should be an option to choose alternative options in yaml automation, i.e. ignoring such a state, i.e. treating it as if it were not there.
hollow sage
As for last_changed resetting on a restart. I agree with you, but understand why it is the way it is.
inner kite
As for last_changed resetting on a restart. I agree with you, but understand why...
And in this case, I think there should be an option for the user to choose whether the restart should overwrite these values.
hollow sage
In my opinion, there should be an option to choose alternative options in yaml a...
Meh. It's a very niche issue and would add a lot of overhead to every state trigger. I compeletely understand why it exists
hollow sage
And in this case, I think there should be an option for the user to choose wheth...
Then make a PR to implement it or a feature request for it. I think it would be much more work to get working than it would be for you to make half a dozen datetime helpers
bright quest
Feel free to add your vote
https://community.home-assistant.io/t/retain-last-state-change-data-of-a-sensor-after-reboot/125148
inner kite
Feel free to add your vote
https://community.home-assistant.io/t/retain-last-st...
Voted! 👍
If I were to do it using helper, I think it would be more easy to do so that when the motion is "on", it will save datetime input to now(). And then in automation - if the current time timestamp minus saved input time timestamp < 12 hours then... But still searching for way without helper.
bright quest
You won’t find a way without another entity, because the information you need isn’t available in the state object. You need somewhere to save the info you want (the timestamp of the change you care about). And the only place you can store info in HA that persists restarts is an entity.
inner kite
You won’t find a way without another entity, because the information you need is...
I'm afraid you're right. Therefore, I support the idea that last_changed should not be changed by restarting HA. Because then I could do it without a helper.
bright quest
Now, there are methods to use a single entity to store all the info you want for hundreds of different sensors. So you don’t necessarily need one helper per entity.
inner kite
Now, there are methods to use a _single_ entity to store all the info you want f...
I didn't know. I have to get acquainted with it.
But I also think that in automation there should be an option similar to the continue_on_error option - you can add this for every step. only that this option would be like ignore_restart to add for IF.
bright quest
Yes I agree some type of implementation would be extremely useful. How it gets implemented in the UI is probably the least of the concern to the developers. The main problem is that it requires saving the timestamp and state (let’s call it last_communicated_timestamp and last_communicated_state just for the sake of argument). This has to be done for every entity, or there has to be a way to select whether to store this info for each entity (which would be very different from any decisions made in the past). So if you store it for everything, you’ve drastically increased the size of the database and the state object. I don’t think it’s feasible to ignore unavailable/unknown states and timestamps as that would be a gigantic breaking change and not desirable in many ways.
So, it’s not as simple as adding an option to the UI.
inner kite
Ok. Thank you both for your help. I know that at the moment it is not possible to get what I want without using a helper. I hope that one of the two solutions discussed will be introduced and it will be possible without a helper in the future.
trail bay
Feel free to add your vote
https://community.home-assistant.io/t/retain-last-st...
regardless how many votes that gets, the one person who is in control is against it. It will likely never happen.
just an FYI
At most, we will be able to retain values for things that we know happened. I.e. trigger based template entities and helpers
bright quest
My opinion is that linked FR would be satisfied if entities were updated to add exactly that: retain values for things we know happened.
It’s not exactly what the FR request states (it is asking for a change in behavior, which I agree will never happen). But if we add new capability rather than change existing functionality, doesn’t that make everyone happy?
hollow sage
If I were to do it using helper, I think it would be more easy to do so that whe...
This is a significantly worse way to do it. A template trigger that behaves this way refreshes every minute rather than just triggering at the time you want it to. You're adding a lot of overhead for no gain
trail bay
My opinion is that linked FR would be satisfied if entities were updated to add ...
Still has to get approvals. But if you’re just looking for an attribute, it would probably be easier. However getting that into a trigger, unlikely
E.g. look at last reported and what you can do with it
bright quest
Right. That’s the next issue. The new parameter would need to be available in triggers, dashboard cards, everywhere else that last-reported is available. Otherwise it doesn’t achieve much. Assuming it’s available in templates it is still somewhat useful, but all those other subsequent changes are what really add value for most people.
trail bay
yes, well this is what mr owner isn't really keen on
inner kite
I have automation that is trigered every hour. And in this automation I have: IF no motion for 12 hours THEN set generic thermostat mode to away. This is very elegant and simple solution for me. Only problem is if HA restart.
If I were to use a helper, I would still have to create second automation to save the state of this helper when the sensor detects movement and it turns out that instead of one simple automation I would have complicated automation, helper and second automation.
trail bay
no, you could do it all in 1 automation
with a helper
if there's a will, there is a way
inner kite
I don't understand why just can't check in the automation when the last motion detection was. After all, even after restarting HA, the history of sensor changes is available.
trail bay
There's really nothing to understand, the person who runs the show, want's last updated to update when HA restarts. They have final say. That's all you need to understand. So at this point, you can either be upset about it or find some way to work around the problelm
I've been working around it for 9 years now
I recommend you just work around the problem too
inner kite
ATM easiest way I think is create helper - history stats - there count how many times state was 'on' during last 12 hours. If more than 0 then we know that there was motion.
trail bay
The easiest way is to do what hilburn suggested at the beginning
you can go the history stats route but the calc may not provide the info you really want, especially if the motion is on for a long time and then goes off for 12 hours. You might get the notification a couple hours early or late depending on how history stats counts the values
inner kite
Feel free to add your vote
https://community.home-assistant.io/t/retain-last-st...
I just found another argument so that last_changed does not change when restarting HA. In automations, in condition 'IF FOR some time', value of last_changed is used in code to check whether the condition is met.
So it simply check two things:
I have seen the ideas of creating additional variables such as last_on, but I think it would only complicate the system and not solve all the problems - e.g. with automation.
So… making last_changed persistent or the possibility of choosing (persistent or not) should solve all problems, also with automations.
trail bay
I just found another argument so that last_changed does not change when restarti...
last changed is also used for the for in triggers as well.
it's basically used for many aspects of HA, this is largly why adding a new property isn't going to do much other than give you a timestamp
The trigger likely cannot be changed to account for a restart without major rewrites either. As it creates a listener at the time the state change occurs then watches the time.
inner kite
it's basically used for many aspects of HA, this is largly why adding a new prop...
Yes, here I fully agree. The best and probably the only sensible solution is that user to choose whether last_change changes when restarting or not
trail bay
and as I said many times before
the person who owns HA, is not on board with this change
so, I strongly recommend, not holding your breath
many have tried to add PRs, all have been closed.
inner kite
the person who owns HA, is not on board with this change
Yes. Only I don't mean to change behavior, but give the user a choice to choose - current behavior or new
trail bay
yeah, no, I really don't think you're understanding what I'm saying
H e is 100% against this
regardless if it's a choice or not
inner kite
😢
hollow sage
Regardless of if it's a choice, the same underlying changes need to be made. Making it optional is actually just more work and more prone to failure
inner kite
Regardless of if it's a choice, the same underlying changes need to be made. Mak...
It seems different to me. In many places, the system uses last_changed to read, for example, in automation. And that wouldn't change. It would change only in one place - where the system overwrites this value at the time of restart.
hollow sage
The system doesn't overwrite anything at time of restart
That's what people have been trying to tell you. The data does not persist through restart, it's stored in a data structure that is discarded when home assistant turns off
When that is rebuilt as it turns back on, it uses the current time because well what other choice does it have? A null update time would cause even more issues
inner kite
Ok, I understand. But what I mean is that a change would be required in one place - so that last_change would be saved at restart. The rest of the code, for example, where last_change is read, would remain unchanged. Petro wrote earlier that he had already did PR so that last_change would be written, but it was closed, perhaps because it changed the current behavior. So I suggest that it does not change current behavior - only give the user the opportunity to choose - as it is now or save last_change before restart.
In my opinion, last_changed should show the actual last change in the state of the device, not time of HA restart. And the number of votes and posts on this subject testifies that many people think similarly.
hollow sage
"I suggest it does not change current behaviour, it just does something different to what it currently does"