Closed martindybal closed 3 years ago
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?
It might be related to this: https://github.com/home-assistant/frontend/issues/6453
A numeric counter is currently rendered in the HA frontend not as a line graph but as a state bar.
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.
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.
I add workaround with customization and unit of " " (space), but everytime I do it I feel it's something wrong with that approach ;-)
@spacegaier I do not agree. Defaulting to #
makes an assumption, which we should not. A unit should be configured instead.
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.
@martindybal "visitors", "people" or "persons" sound like a viable unit of measurement for those cases. Any reason why it could not be that?
Sorry I was too slow with my response. In my case is result of equation I can use workaround " ".
@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..
I confirm that workaround works for me.
@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.
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.
This is related: https://github.com/home-assistant/architecture/issues/469
There are cases for no unit...
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?
COP of heat pump is also without unit: https://en.wikipedia.org/wiki/Coefficient_of_performance
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.
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 bestring
orint
.