I’ve taken this concept to the extreme. I only keep 4 days in Recorder. And even there, I exclude the majority of my entities, especially those which are “chatty” and experience frequent state changes.
For me, the ideal would be to be able to set the appropriate retention period for each entity individually, but unless and until that happens, I find it convenient to just save the data I want to keep long-term in a text file in CSV format which I can store, analyze and otherwise use external to HA.
I appreciate the motivation behind the repair message and the acknowledgement that a little refinement is required. It’s never straightforward to parse SQL without a tokenizer or parser… People may have aliased the table name too
Looking forward to be able to use these sensors again. The entities appear to have vanished from my setup since the repairs were added.
I marked the repairs as fixed. I reloaded the integration but the entities have not become available.
The performance advantage is pretty much moot now.
However there are still some advantages to having the DB decoupled from HA. You don’t have to wait for the DB to initialise when restarting HA as it runs in its own container. Also you can stop it before making a full backup to ensure there is no chance of data corruption.
Another thing is that I have more than one database in the MariaDB add-on. As well as Home Assistant it keeps my centralised Kodi DB too.
I’m doing exactly the same (already got my SSD). Slightly complicated as my HA is on a Pi4 but running 32 bit and I intend to go to 64 bit as part of my move to an SSD.
You assume ios is the app. I talk about Safari. Safari supports multiple tabs so I personally use that mostly on my iPad. On my iPhone the app is the preferred.
the issue in that post was to prevent it from triggering wasnt it?
not so much have more than one trigger.
with your solution we can do:
trigger:
platform: state
entity_id:
- person.marius
not_to: &un
- unavailable
- unknown
not_from: *un
condition:
- >
{{trigger.to_state is not none and trigger.from_state is not none}}
- >
{{trigger.to_state.state != trigger.from_state.state}}
but, with an actual state to be triggered on, the not_to: is no longer possible, and we still need to use something like this:
trigger:
platform: state
entity_id:
- person.marius
- abc
to: home
condition:
- >
{{trigger.to_state is not none and trigger.from_state is not none}}
- >
{% set x = ['unavailable','unknown'] %}
{{trigger.to_state.state not in x and trigger.from_state.state not in x and
trigger.to_state.state != trigger.from_state.state}}
unless I am missing the point entirely there. these 2 conditions save a lot of trouble in many automations, and even with the latest developments in the syntax, still have their value.
Really not liking the way the UI is going. I don’t mind the look of the new stuff, but hiding functionality behind extra clicks is just terrible for usability. I don’t see why we cant make it pretty and keep it functional. Pretty doesn’t have to be “white space”
I dont mind the new UI, what I do mind is that history is no longer part of the default view in the more info panel. I think if history was added back to the default view it will make many power users happy.
Sorry if it has been already mentioned, searched and could not find an answer… how one knows the DB upgrade / migration finished so I can safely restart HA?
I see this message in the logs:
“Database is about to upgrade from schema version: 35 to: 41”
and then messages about the upgrade to 37 to 41 being done.
But, well after that last upgrade to 41 done message I see messages from recorder about indexes being dropped and to be patient and the last message what about 20 hours ago but no indication if the whole process completed… any way to find out for sure?
