List of valid "unit_of_measurement" options?

Configuration
21

And if you want graphs, but there simply isn’t a unit of measurement for the data (ratio’s, dimensionless numbers, …), you can add a blank unit of measurement:

unit_of_measurement: “”

2 Likes
22

this answer does not seem to be valid anymore with 2023-05 they “assume” a numeric value and cast it to decimal, what causes an exception, what causes the sensor to dispaly “unknown”.
There seems to have been a breaking change

1 Like
23

Not sure what you’re talking about. The solution is still valid as is the information in this post. If your value is numeric, add a unit_of_measurement and the information will be graphed.

24

Since 2023.5.0, several people have reported that their Template Sensors now indicate unknown (as opposed to previous versions). It appears that the rules for how unit_of_measurement is handled have become more strict. Given that Template Sensors are no longer behaving like they did in the past, it’s effectively an undocumented breaking change.

Another user believes this may be the PR responsible for the new behavior (tagged as a ‘Code quality improvement’) :

1 Like
25

Right, but that doesn’t change the solution to this thread, which is what I’m referring to. If you put a unit_of_measurement on a sensor, it will turn it into a graph. The original question was “what do I place on a voltage sensor” and the answer was “v”. None of that has changed…

Also, if you output None instead of 'unkonwn' or 'unavailable' in your template sensors, then you’ll avoid this strictness. That’s the proper way to set a sensor to unknown or unavailable. The other option is to use availability templates (which sets None under the hood).

We ended up finding a series of issues in Beta with this change. Properly created template sensors would be unaffected. When you explicitly set a numeric sensor to a string state, you’ll get this error.

26

I’m not disputing the Solution, just pointing out that 2023.5.0 does appear to handle unit_of_measurement differently from previous versions. It wasn’t documented in the Release Notes so CybDis has reason to speculate “There seems to have been a breaking change”.

Perhaps the Release Notes should have said something like:

In previous versions, unit_of_measurement allowed for non-numeric values (even though it should not have) but that loophole has been closed. Only numeric values are permitted.

2 Likes
27

Hi all, this seems like the right place to ask a follow-up question to this

Usecase: I have made a scale for my watersoftener with loadcells, a HX711 amplifier, an ESP32 running Tasmota. It’s integration creates these 3 values in HA:

image

While the weight is fine as it has a UOM (kg), I’d like to be able to graph the two others, WeightRaw and AbsRaw. Editing the entity in HA does not allow me to add a UOM, thus its reported as a history:

image

TLDR; short of creating a derived template sensor off this one, is there a way to add a missing UOM to a sensor from an integration, or does this have to be done by the integration, in this case Tasmota?

28

you can add a uom via customize.yaml

1 Like
29

Perfect! That did the trick
For reference, I added the below to my customize.yaml, reloaded the Location & Customizations in Dev.Options, restarted the Tasmota integration, and now there’s this guy named Bob claiming he’s a relative :slight_smile:

sensor.garage_controller_ne_hx711_weightraw:
  unit_of_measurement: "raw"
sensor.garage_controller_ne_hx711_absraw:
  unit_of_measurement: "raw"
30

I don’t know how to keep my UoM “Entitäten” because the sensor rendered “unknown” once updated to HA Core 2023.5.

Any chance to restore that former behavior?

Usually I don’t care, it’s just because InfluxDB can not connect the dots anymore (UoM changed from “Entitäten” to “” (nothing)) as the very first emergency task because of this undocumented breaking change (… few words of frustration here…) was to simply remove the UoM: