Add Sensor state type

[martindybal]

Context

For Sensor Entity I can specify unit by unit_of_measurement which also changes history chart type. I need a sensor without unit, but number style chart.

Proposal

Add state_type property which will be string or int.

[frenck]

For Home Assistant itself, that makes no sense. If there isn't a unit to measure, what would it measure?

Could you provide a more concrete example that justifies such a change?

[spacegaier]

It might be related to this: home-assistant/frontend#6453

A numeric counter is currently rendered in the HA frontend not as a line graph but as a state bar.

[frenck]

Well in the linked case, the unit of measurement should be added (not a UI fix), so that issue is actually in the wrong repository at this moment.

[spacegaier]

I quite like the proposed idea there that the frontend defaults to "#" if no unit is provided, because for a counter for example I don't want a unit. It should just count.

[andriej]

I add workaround with customization and unit of " " (space), but everytime I do it I feel it's something wrong with that approach ;-)

[frenck]

@spacegaier I do not agree. Defaulting to # makes an assumption, which we should not. A unit should be configured instead.

[martindybal]

In my case is sensor value is result of equation defined by user. But I can imagine other cases. For example, the number of visitors.

[frenck]

@martindybal "visitors", "people" or "persons" sound like a viable unit of measurement for those cases. Any reason why it could not be that?

[martindybal]

Sorry I was too slow with my response. In my case is result of equation I can use workaround " ".

[andriej]

@martindybal "visitors", "people" or "persons" sound like a viable unit of measurement for those cases. Any reason why it could not be that?

UI doesn't handle that well all the times, especially if in native language that can be longer word..

[martindybal]

I confirm that workaround works for me.

[spacegaier]

@martindybal "visitors", "people" or "persons" sound like a viable unit of measurement for those cases. Any reason why it could not be that?

@frenck That would look weird in the UI: E.g. an entity row: You have a counter named "Visitors today" and then the value is "3 visitors"? That is redundant and requires for screen space than needed to convey the info to the user.

But I get your point about not making assumptions, but I think we should then have a way to tell HA that a sensor is numeric, but does not carry any further unit text, so that users do not have to use empty units which feels error-prone. Which brings us back to the original proposal from OP to allow "int" or perhaps more generic "number" or "#" as valid units in the backend.

Then the HA frontend can use that to decide if a graph should be shown. And it might also help with external rendering integrations, such as Grafana, where I remember also seeing issues on GitHub if no unit was present.

[frenck]

Stays the same, You can specify # as a unit of measurement if you'd like. That requires no frontend changes and no assumptions are made.

[dgomes]

This is related: #469

There are cases for no unit...

[dkagedal]

My Sensative Strip device defines 6 sensor entities without units (mirroring what's exposed in the zwave protocol) and i don't see how they could be given reasonable units. Is anyone arguing that those sensors should be defined differently?

[kukulich]

COP of heat pump is also without unit: https://en.wikipedia.org/wiki/Coefficient_of_performance

[emontnemery]

I think this would be a good change, there are many examples of unitless quantities, and we shouldn't rely on the unit being a non-empty string to decide if the sensor's data should be rendered as a line graph or not.

Strictly speaking % - which we do support - is not a unit, it's just a common way of writing fractions which often are unitless.

I'm not sure we should have a state_type property which will be string or int, we'd like to say that the state is numerical, potentially restricted to continuous, or not to decide how to treat the data.

[frenck]

I think the biggest feeling against this for me personally, is not caused by the reason for this proposal.

The reason is to have graphed data, even if there is no unit of measurement set. 👍

Add state_type property which will be string or int.

👎 That is what buggers me.

The point is, is what we basically are doing here is compensating for the fact state is always a string; thus storing the scalar type of separately (instead of using actual types). Although it is a quick/fast solution for the problem at hand maybe...

It becomes even weirder considering state attributes do have a type (they can be a native int for example).

[fsaris]

@frenck if I understand you correct currently state/value is always string so we do not know the real type?

So we adjust HA persisted state values in the native value like currently done for all attributes.

Is that doable?

Or is adding a additional state_type property to tell us what type of value we have a valuable solution.

But now that we have the state_class can't we just combine these 2 to "solve" this issue?

If unit_of_measurement or state_class is set we know we have a measurement value. And show graphs etc. No need for the " " anymore then.

[ThomDietrich]

I wonder if the title of this issue/discussion already solutionizes for a problem that was not properly understood.

Looking around I found quite a few tickets and discussions about the topic. They are mostly related to

• unexpected frontend behavior (In my opinion just a symptom of the actual issue)
• unitless sensor data (unknown or irrelevant)
• the infamous " " space unit_of_measurement hack (and related issues like with the influxdb integration)

I think this discussion goes beyond the most prominent side-effect, the line/discrete graph. The problem is often discussed and people add the " " space unit as a hack but the underlying issue is that the UI currently does not have a better way to identify continuous measurements.

---

Proposal

Here are two alternative suggestions:

1. I propose a probably simple solution for the most prominent cause of confusion: A unitless continuous measurement unit. Sounds silly but it's not that far-fetched if you think about it. Any clearly documented unit_of_measurement is defined and henceforth identified as the identifier of a unitless continuous sensor. An empty string could be used and could internally be represented by any kind of proper enum/object that satisfies the need for code quality. It enables a clear differentiation between no unit "" and no continuous measurement None. The solution is

   • intuitive for a user-defined template sensor ("The sensor has no unit to show")
   • probably easy to implement in core
   • easily adapted in existing integrations
   • solving the frontend discrete/line graph issue
   • explicit and can therefore be considered in other components, like the influxdb integration
   • stops people from using the " " space hack

   Obviously, this does not solve all the issues and special cases, but it does solve the most prominent ones with minimum breaking change, while other more thorough metadata can be added over time to reduce the need for it.

2. @MartinHjelmare proposed here to extend and use device classes more actively. Sounds reasonable to me (even though the name confuses me). This solution is an alternative and proper way to characterize measurements. It probably also takes a long time to be adopted everywhere, which is why I would suggest to consider both solutions in parallel

I hope this is helpful and am looking forward to discuss!

[ThomDietrich]

Pinging this topic again, is anything related to this discussion going on in other places? Any comments or news? Thanks!

[fsaris]

I would propose a is_measurement property on the sensor entity and use this in the frontend.

The core could set it bases on the current properties we already have unit_of_measurement, state_class and maybe even device_class instead of only relying on unit_of_measurement.

[frenck]

We are currently introducing state_class (for e.g., the energy dashboard and statistics) which already indicates if something is a measurement. This will become the base for solving this issue in the near future.

[fsaris]

Okay first steps look to be merged home-assistant/frontend#9879

[balloob]

Adding a state class now shows a line graph