Missing 'state_class' attribute

[Klarstein]

A lot of the sensor readings are perfect to use with the statistics functionality of HA. Would it be possible to add the 'state_class: measurement' to the temperature values of the calculations group?

[Bouni]

I've never really looked into the advantage of the state_class attribute. Can you describe what it does more detailed? Maybe we can add the appropriate state_class to more classes than just temperature ones!?

[Klarstein]

The state_class is necessary to get long term statistics in HA. In the previous situation, all the sensor data flows into the recorder integration and is gone after the purge_keep_days value is reached. With long term statistics, the suitable sensor/meter readings get converted into an hourly min/max/mean and stored indefinitely with relatively low DB-use. In the past you needed a separate database (Influx for example) and a tool like Grafana to visualize them.

In order for statistics to work, HA needs to know if the sensor value is a real-time sensor value like a temperature sensor (state class: measurement, or if it's an amount that just increases/decreases in time (state class: total or state class: total_increasing) like the kWh heat production values. It is explained in more detail here.

Use cases for this component:

• Keep track over the source temperatures over the months, seasons and years. With a mean/min/max value (is my source OK or is it degrading?)
• Keep track over heat production (kWh) daily, hourly, monthly, yearly
• Keep track over compressor use
• etc etc

Especially for a component like this, long-term statistics are extremely useful. They can tell you so much about the health of your system. And the graphs just look cool ;)

[Klarstein]

@Bouni if you like I can provide a list of useful entities with their ‘state_class’

[Bouni]

So that means not every Celsius is automatically a state_class measurement, right!?

We need to decide that for everything measurement individually

[Klarstein]

True, I would only use it for real measurements and not the setpoints for example.

(so yes to ID_WEB_Temperatur_TWE (measurement) but no to ID_Einst_HzHKRANH_akt (setting))

[Klarstein]

EDIT:

Why not just add a CONF_STATE_CLASS option to `sensor.py’? In that way, people can configure themselves what sensors they want to use with long-term statistics. And that way not every sensor has to be configured/decided for in the code. ——— So I started a list:

state_class: measurement would be:

• id: ID_WEB_Temperatur_TVL
• id: ID_WEB_Temperatur_TRL
• id: ID_WEB_Temperatur_TA
• id: ID_WEB_Temperatur_TBW
• id: ID_WEB_Temperatur_TWE
• id: ID_WEB_Temperatur_TWA
• id: ID_WEB_Temperatur_RFV
• id: ID_WEB_RBE_RT_Ist
• id: Heat_Output
• id: ID_WEB_Temperatur_THG
• id: ID_WEB_Freq_VD
• id: ID_WEB_HZIO_PWM
• id: ID_WEB_Durchfluss_WQ
• id: Flow_Rate_254
• id: ID_WEB_LIN_HD
• id: ID_WEB_LIN_ND
• id: ID_WEB_LIN_ANSAUG_VERDAMPFER

and

state_class: total_increasing** would be:

• id: ID_WEB_Zaehler_BetrZeitVD1
• id: ID_WEB_Zaehler_BetrZeitImpVD1
• id: ID_WEB_Zaehler_BetrZeitWP
• id: ID_WEB_Zaehler_BetrZeitKue
• id: ID_WEB_Zaehler_BetrZeitBW
• id: ID_WEB_Zaehler_BetrZeitHz
• id: ID_WEB_WMZ_Heizung
• id: ID_WEB_WMZ_Seit
• id: ID_WEB_WMZ_Brauchwasser

I think it will be a great starting point if those are implemented.

** I chose total_increasing instead of a combination of total andlast_reset, because the latter isn't a stored and readable value in the Luxtronik as far as I know.

[Bouni]

Why not just add a CONF_STATE_CLASS option to `sensor.py’?

That sounds like a smart idea!

Maybe we do a combination of both, for known values we define the state_class, but leave the user the option to define one for any sensor via its configuration! And configuration overwrites preset in case a user wants another state_class than the preset!?

[Klarstein]

I think this pull request should work. Can you test it? It’s a quick fix and we could elaborate from this point on.

In my opinion it isn’t ideal to add a lot of fixed state_classes with no GUI or other option to disable them. Let’s say a user adds all the available sensors, then he is automatically building a substantial long term statistics database with values he might not need or want.

[Bouni]

What if we set state_class for all known sensors and if a user does not want a certain state_class he can set it via config to an empty string which we recognize as None!?

[Klarstein]

That would be even better, the list I provided before would be the starting point for that. But I don’t know how to wrap that in code. Would you have any time for that?

[Bouni]

I hope that I get a chance to test it today

[Klarstein]

Awesome. Can I help out in any way?

[WhistleMaster]

Sounds like that it would also help with #22

[Bouni]

Sounds stupid, but how do I check if the state_class is set for a certain sensor!?

[Klarstein]

Home Assistant > developer tools > entities > attributes. It should show there. A different method is to try to load it in lovelace in a statistics graph card.

[Klarstein]

I tried it by updating the integration in HACS to 0.1.24.

This is a configuration entry:

      - group: calculations
        id: ID_WEB_Temperatur_TWE
        state_class: measurement

The state_class option doesn't give an error, but I'm afraid it doesn't show up as a statistic in HA.

[Bouni]

I'll have to look into it tomorrow

[Bouni]

@Klarstein I realized that I somehow managed to fu***up the PR taht implements the state_class feature. In version 0.1.26 it is integrated and should work. Would be awesome if you could verify that for me 😉

[feibeck]

Hi! First off, thanks for this integration! I'm using 0.1.28 but the state_class attribute is not showing in HA. My configuration for one of the sensors:

      - friendly_name: Außentemperatur
        id: ID_WEB_Temperatur_TA
        group: calculations
        state_class: measurement
        icon: mdi:thermometer

And this is what the developer tools show.

Am I missing something in the configuration?

Thanks!

[feibeck]

I'm not good in writing Python and don't know the HA APIs but I managed to hack something to get the state_class attribute available in the developer tools, see https://github.com/Bouni/luxtronik/pull/41

It still does not work to use the sensor with statistics. So I don't know if this "fix" is actually useful but maybe someone can check it out…

[Bouni]

Hey, thanks for your PR! I think I need to read a bit more in detail whats necessary for a Long Term statistics sensor in order to get this working.

[Mehli12]

Thank you for looking into this. Actually I don't have any experience in python or any other language but mangled to get the Luxtronic working in HA. I updated to 0.1.29 but state_class for sensors seems not to work for me. I'm just not sure if I understand the laste update correct (and state_class for sensors should now work) or if my config is just wrong.