I know that is what the documents say but I tried NONE and “” but they didn’t work. Only empty single quotes did the trick. Did you set as “None” or None?
state_class: None
If you use quotes (single or double), it becomes a string. None and none are special identifiers. NONE won’t work either.
It will work in the sense that there will be no state class, but '' is an invalid state class and HA will complain about it in your logs.
Also make sure to run the repair after changing a state class.
1 Like
Are you sure that this integration allows to set state_class option ?
Thank you! This discussion is convincing me to look into changing state_class again.
Toward that end, and for anyone stumbling onto this thread in the future, could someone explain a few more things about the process?
Does this work for all entities, or only for certain integrations?
How would I change entities I didn’t define in YAML, but were added through an integration via the UI?
Is there a quick and easy way to see all the entities currently recording long-term statistics, short of running a query against the database?
You should be able to use customize to modify state_class where the integration doesn’t allow you to change it via the UI or YAML.
1 Like
Is there a quick and easy way to see all the entities currently recording long-term statistics
You can see this list in the UI at Developer Tools > Statistics.
1 Like
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?