Any way of disabling it? I really, really don’t need it.
Exclude the event type
That’s the problem. Did this a while back (and think I posted the question), but if you disable the event type, then you also lose the actual sensor data in state table as it has the same envent type.
So disabling that event type means you collect no more data.
1 Like
I think @AleXSR7001 has a legitimate issue here. There’s an awful lot of data stored in the statistics and related tables, which are useless for anyone who doesn’t use that data. HA ran fine before that was added, and it seems letting the user choose whether or not to use that feature would be appropriate.
I don’t really have a horse in this race. I know how to manage my database and will continue to do so, with or without this enhancement. But I still want HA to be friendly to new users, who may not know they’re going down an unsustainable path until their SD card on their Raspberry Pi is either filled or crashes due to excessive I/O.
2 Likes
Anybody know what will happen with the Core 2022.4.8 (Milestone) since Beta testing of 2022.5.0 is now in full swing ?
We can maybe continue discussion on database/recorder handling of event_type: state_changed in how-to-keep-your-recorder-database-size-under-control
There’s nothing else to discuss, you’re already talking with the guy who made all the changes. He’s the one you need to convince. My only suggestion is to form your posts in a less combative way. If I was him, I’d ignore you.
Not my intention to sound combative, I apologize.
I’d just avoid trash talking the current implementation. Just make your requests.
It’s like delivering a insult before asking for a favor. Just keep in mind that these people are volunteers. They don’t have to do anything. Just my 2c. You’re welcome to ignore me, I’m just speaking from experience
1 Like
Not going to ignore you, no. Appreciate your recommendations and will try to be more aware of this.
I have to discuss a lot in my job and it is often important to make it clear why something is not good as it is because so many people resist making anything better. So many people just say “this is how we always did this”.
I often have this feeling here also, but that is no excuse for being rude.
So I will work on it. 
4 Likes
I can be an ass and don’t always take my own advice, so I completely understand. It’s hard to convey what you mean in text.
4 Likes
I’ve been switching my old groups to the new groups and there’s only one remaining: A group of automations (to turn them on or off as a group). Does anybody know whether the new-style group functionality will be added for automations, because the docs says one should stop using the old-style groups?
I have no plans on stopping using the old groups. Until a replacement for it has been created, keep using the old groups. It’s a suggestion after all and it has not been deprecated.
1 Like
Are you sure this is correct:
message: 'room temperature = {{states (' 'sensor.salone_temperatura' ')}} C' ?
I’d suggest to try using double quotes instead of two single quotes, i.e.:
message: 'room temperature = {{states("sensor.salone_temperatura")}} C'
double single quotes escapes characters and acts like a set of double quotes.
Are there plans to add additional group categories like a notification group?
Yes, it does. But under the new “Helper” groups it doesn’t. From my understanding they are working to get away from using the yaml files for groups.
So you mean via the UI?
Yes, it would be much easier and more convenient to have a notify group as part of the new helper groups.