OK, I guess I was hoping to see the state_class of each one, but at least that’s a starting point. I can ignore all the ones I’ve excluded (they show up with an “issue” saying they’re excluded.)
Turns out you can go to Developer Tools > States and in the Attributes column filter by state_class. You can see the attribute value there. I’m not sure if viewing the list that way includes entities with state classes set implicitly though.
Thanks for the clarification. Haven’t noticed any issues but will do some more testing on this.
If I compile with None or none it gives the following error. This is where I got the 2 single quotes from.
c:\esphome>esphome run athom-plug3.yaml
INFO ESPHome 2024.8.1
INFO Reading configuration athom-plug3.yaml...
Failed config
sensor.wifi_signal: [source base/athomplugdev.yaml:51]
platform: wifi_signal
name: WiFi Signal
update_interval: 60s
Unknown value 'none', valid options are '', 'measurement', 'total_increasing', 'total'.
state_class: none
Changing to null gives the following;
c:\esphome>esphome run athom-plug3.yaml
INFO ESPHome 2024.8.1
INFO Reading configuration athom-plug3.yaml...
Failed config
sensor.wifi_signal: [source base/athomplugdev.yaml:51]
platform: wifi_signal
name: WiFi Signal
update_interval: 60s
string value is None.
state_class:
You never mentioned this was ESPHome until now. HA isn’t ESPHome, even though the two projects live in the same camps.
As the ESPHome docs say:
- state_class (Optional, string): The state class for the sensor. See Sensor entity | Home Assistant Developer Docs for a list of available options. Set to
""to remove the default state class of a sensor.
Now we’re back to square one.
Why are you setting a state class in the first place? It’s optional. Just don’t set it.
1 Like
Sorry, why am I at fault? The discussion was about database size and most of my data comes from esphome devices. It may be a subcomponent within HA but it is HA recording the data.
I have never set a state_class in my code but HA automatically sets one. The only way I’ve found to prevent this is as I described.
Yeah, I’m having trouble following the discussion, too. It would be good to clarify when we’re talking about templates, ESPHome entities, or entities added by various integrations. Part of why I’ve been ignoring state_class as an option for limiting DB bloat is that it’s not really clear how it’s established, what is impacted by changing it, and where to change it. As I said, for me it’s easier to write a one-line SQL hammer and run it every so often.
A fault is too strong a word in my view, but the burden is on you to provide accurate information in order to get accurate answers. Being upset about this will not lead to more or better help.
Sure, that’s just true for you, but usually when people speak about the state class, it will be on the HA side (as the common denominator), because there’s a variety of devices and integrations people can use. With non-ESPHome devices, people have less control over this, which is why it then gets overridden on the HA side.
Inaccurate. ESPHome is a project in its own right and can be used independent of HA. Both are merely under the Open Home Foundation.
Inaccurate. Integrations would typically set it, and only for select entities. In the case of ESPHome it is not the integration. I’ve never seen this done automatically for any of my ESPHome devices.
Back to my question though:
If you set it before (i.e. even setting it to '') you now have a state class (from HA’s point of view), even if you remove it from config now. That said, your repairs dashboard should pick up this discrepancy (you had it before, and you have none now). Do you not see a repair?
-
ESPHome may be standalone, and I use that often, but the storing of data is done by HA.
-
You obviously know my system and code but I repeat that I had never set any state_class for my sensors. All data is ending up in LTS because a state_class was being assigned. I only went down this path because I wanted to stop saving useless data for all time.
Code for a temp sensor;
- platform: dallas_temp
address: 0x4000080104f4eb10
name: "Outside Temperature"
accuracy_decimals: 1
update_interval: 60s
From Developer Tools\States
To prevent state_class being assigned;
- platform: internal_temperature
name: "Internal Temperature"
state_class: ''
Once this is done I then get an option to remove data from Developer Tools\Statistics.
It does seem that the platform you are choosing in esphome is perhaps dictating the state class in home assistant.
I do not know esphome well at all, but I do know that you can use customize on the resulting home assistant entities in order to remove the state class.
I tried to tone down your previous message, but you keep trying to provoke for some reason. I never said you set it for a fact. I merely stated that if you did, then there is a certain way out of that situation. It’s because I have done this before where I did passing a state class, but then later changed my mind.
This is new information. Previously, it was the WiFi signal sensor. I don’t see that for either platform a state class is set by default. All I can say is that the core (base) sensor config won’t do that. As the docs state, the state class is optional. Perhaps you found a bug in these platforms or something that is undocumented. You should search the ESPHome issues on GitHub or log a new issue. I cannot say whether this behaviour is intentional.
As I said, you’d get a repair message.
It appears that any sensor that returns a numerical value is assigned a state_class. I do have an Android device which shows this. I do use Customize to correct state_class for some energy sensors.
1 Like
I guess I need to do some homework. It’s not clear to me what functionality I lose if I null out state_class on all my entities. It’s not clear to me where this setting is established across all the different platforms and integrations, or how it’s used for anything besides LTS.
A targeted search turned up lots of very specific errors, problems and complaints, but not much general information about what state_class really is and how it works.
Is there a quick reference somewhere?
1 Like
Hey friends,
seems like I found the right thread. Any advice how I can purge all history from an sqlite database? My disk is 99% full and recorder.purge seems to not like that.
I am running a HAOS setup and can’t easily stop home assistant and manipulate the database file on disk (would need to connect the eMMC card to a different PC and I’m not physically there).
Any ideas?
Got this resolved by recklessly deleting the database file while HA was running. The details are in the linked ticket for those interested 
Actually, it’s not reckless (unless you didn’t make a backup in case you realised you needed something), as your HA config isn’t stored in the DB. Only your sensor and other data. Since the DB usually only stores recent data (the default recorder setting is 10 days), people with corrupt DBs will often delete it. You’d lose your LTS too though, so that’s something to remember. The yanking you referred to in the linked topic on a running instance: Well, now that might be frowned upon. 
1 Like
That statement is true and false at the same time. Well, after a repack followed by a purge I notice significant lower system load for some time (until the DB starts to grow again). So buying that faster system response during the day (when HA is needed) for a precisely planned load situation during the night (when HA is not needed that much) is a rather great deal for me.
2 Likes
I can’t find an entry in the recorder manual that the vaccum is only done monthly.
can you please show me the entry? Thank you!
Thanks to some help from this thread, I was able to prevent my entities from recording LTS data, and clearing these data from the database. It made a huge difference. My database is 35% of the size it was before I started this effort.
I posted more info on another thread, here.