Why do sensors using the -filter platform (and other template sensors) are not visualized as graphs but as if they are strings?

This is an example setup but I’ve noticed other sensors have this issue. It’s almost like HA thinks the output value is a string rather than a number but then how do I signify a number? Do I need to play with units somehow? Thank you!

- platform: filter
  unique_id: "fvd34mghSDgk34670yk32njghidjfg346ammcldf3GDkdsl34"
  name: "My Sensor (M-AVG)"
  entity_id: sensor.original_sensor
  filters:
    - filter: time_simple_moving_average
      window_size: "00:10"
      precision: 1

E.g. I’m expecting to see something like this

But instead I’m seeing something like this
image

NB: for a few more details why this is happening, also see Why do sensors using the -filter platform (and other template sensors) are not visualized as graphs but as if they are strings? - #8 by ncd

Check the values from the originating sensor, if it outputs non-numeric values other than unknown or unavailable the History menu will show the states as nominal values instead of a numeric graph.

Thanks - it outputs numeric values. I can confirm that by looking at its graph as well, which looks like a proper numeric graph (in fact, it’s the graph I used in my OP).

Perhaps add a unit of measurement?

this is kind of a unitless measure i think, so not sure what to add?
it’s an AQI level.

I also tried
state_class: measurement
since I noticed the original sensor has it but it’s not allowed in a filter platform, I’m getting a validation error from the developers tools.

So kind of stuck :frowning:

Add it via manual customization.

1 Like

Woah I didn’t know this existed. THANK YOU! Checking it out now.

A few other things I learned looking at the HA docs.


and also

For the original AQI sensor it has no unit_of_measurement but it does have state_class set to “measurement”.

So while the docs are mum about this, I have a feeling that setting state class is the more important bit. So if you set unit of measurement it also sets the state class to measurement, which utlimately conrtols the discreet vs numerical property and how the sensor is visualized.

So basically, the former doc is more fundamental than the latter but both are accurate.

I was able to fix this by adding
state_class: measurement
to the customize section (even though that doesn’t appear in the docs as a supported property).
As a bonus, I was also able to add
device_class: aqi
which was nice :).

If you find an error in the docs, they are easy to fix.

Sure but in this case there is an omission rather than an inaccuracy.
I definitely don’t want to assume that an undocumented feature was intended or would be officially supported so in this case I’d rather not.