OH3 rendering Number:Temperature state in Web UI Marker Expression

  • Platform information:
    • Hardware: RPI 4
    • OS: Raspbian
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version: 3

I have zwave multi env sensors that have correctly installed and show temperature, humidity and battery levels.

I have set the sensor items up to have the correct semantic types, I think. Like so.

image

This displays well, charts fine and all seems happy, except when I come to create a floor plan and want to do an icon colour driven by the current temperature. The use of expressions took me a while to figure out, but in the end I got something working, but I then came across an odd behaviour that I’m unsure what to do with.

I couldn’t get anything to work regarding the current item “state” value, until I dumped out the item JSON structure into the tooltip to inspect it and it came out like this (apols, can’t post another image, apparently!)

{ “state”: “18.01 °C”, “displayState”: “18.0 °C” }

As you can see, the state isn’t the raw temperature, but a formatted version with a bit more accuracy than the display. If I change the semantic type of the Item from “Number:Temperature” to Number then the expression can then work properly driven off the numeric value, but as Number:Temperature, it doesn’t

I tried splitting and using parseFloat, but that doesn’t seem to be included in the expression context (as per (openhab-webui/widget-mixin.js at b0bdefe5b5dc2d7068f58fd93413ef4ced6ce973 · openhab/openhab-webui · GitHub)

I’m interested to know in which direction I should take this, either fixing semantically somehow (more items? different type?) or if it could be fixed in the UI expressions.

There really is no “correct” types. However, I think “Measurement (Humidity)” and “Measurement (Temperature)” would be more meaningful since that is what those Items represent. Conversely, if you had a setpoint for a heater, I’d use “Setpoint (Temperature)”. There really isn’t a great pair of tags for battery levels. I tend to use “lowBattery (Power)” for mine. But this isn’t about correct and incorrect. It’s about providing meaning in the model.

The state is as it is because this is a Number:Temperature Item. Number:X type Items come with a unit and will convert between units for you automatically. But it also includes the units when you output the state.

But you have control over this to some degree. You can set how the state get’s formatted using the “State Description” Item metadata. That will let you configure the “displayState”. You can definitely use that to control the precision and which units are used. But I don’t know if there is a way to exclude the units entirely that way.

According to [wiki] Building Pages in the OH3 UI: documentation draft (2/3), you have access to JS Math and JSON and any method that is already on the object (e.g. split). But not any of the parsing functions.

So I think your options are:

  • use a Number if you can so it doesn’t use Units of Measurement (UoM) and therefore include the unit, but even then, is the state provided as a string or do you really get the number value?
  • consider whether this matters, I think you can do > and < type comparisons between strings and it will give you the result alphabetically. If your temp is pretty much always two digits this could potentially work just fine.
  • if you need the UoM elsewhere you could create a proxy Number Item to hold the value without the UoM to use in the expression

Those are really just work arounds though. I also think you should file an issue .The question is where though as I can see two approaches to solve this.

  1. Modify openhab-core to provide a way to define a label format in such a way that the unit can be excluded. With that you can use the displayState to format the state without the units.

  2. Modify the UI code (if it’s even possible) to let us access some more parts of JS so we can extract the units and parse the number in the expression.

This might help you:

1 Like

Thank you @rlkoshak and @ysc!

I’ve combined your suggestions, fixed the types and used the Number.parseFloat in the page and that works as I hoped.

1 Like