OH4.0.2 displayState inconsistency - sometimes "undefined"

[Mark_VG (Mark)]

Hi All

I have been using OH4 for some time so have my UoM pretty much sorted (I think). I have however just run into a weird issue with displayState that I do not recall seeing before.

The symptom is that occasionally the value for displayState becomes undefined.

As a test I have created a dummy item as follows:

label: ZZ Test display State
type: Number:Frequency
category: ""
groupNames: []
groupType: None
function: null
tags: []

with Metadata as follows:

Unit: Hz
State Description: %.1f Hz

Which from my understanding and past experience should display the item with a single decimal place, as follows:

This works correctly for some values, however occasionally goes to undefined as can be seen in the following widget:

uid: Test_displayState
tags: []
props:
  parameterGroups: []
timestamp: Aug 23, 2023, 8:47:59 AM
component: f7-block
config:
  style:
    margin: 0
    padding: 0
  title: Test displayState
slots:
  default:
    - component: f7-block
      config:
        popupClose: .sunSynk-pop-test
        style:
          --f7-popup-tablet-height: 720px
          --f7-popup-tablet-width: 360px
          background-color: rgb(220,220,220)
          border-radius: 30px
          text-overflow: ellipsis
          width: 360px
      slots:
        default:
          - component: Label
            config:
              style:
                font-size: 25px
                font-weight: 500
                padding-left: 50px
                width: 100%
              text: Test displayState
          - component: f7-block
            config:
              style:
                --f7-popup-tablet-height: 300px
                --f7-popup-tablet-width: 326px
                background-color: rgba(232,232,232)
                border: 1px solid black
                border-radius: 10px
                margin: 0
                padding: 0
                position: absolute
                top: 45px
                width: 326px
            slots:
              default:
                - component: Label
                  config:
                    style:
                      font-size: 18px
                    text: ="STATE -  " + items.ZZ_Test_displayState.state
                - component: Label
                  config:
                    style:
                      font-size: 18px
                    text: ="DISPLAY STATE - " + items.ZZ_Test_displayState.displayState

I used the API Explorer to assign values to the item, results as follows:

I can’t work out why some values are undefined, surely they should be displayed correctly with 1 decimal place?

Thanks
Mark

EDIT: More detailed table

[higgers (Steve Higton)]

Not all numbers can be converted exactly to floating point. Try changing the state description to %.1d Hz instead.

[Mark_VG (Mark)]

@higgers

Not all numbers can be converted exactly to floating point. Try changing the state description to %.1d Hz instead

Thanks for the hint. Unfortunately does not change the displayed value

[higgers (Steve Higton)]

What do you see if you change it to %s?

[Mark_VG (Mark)]

The UoM are not displayed, as follows:

[higgers (Steve Higton)]

What if you change the state to just %.1d and leave off the Hz since the item is defined as Number:Frequency?

[Mark_VG (Mark)]

Then displayState is always undefined even for values that work with the unit included.

[higgers (Steve Higton)]

I’ve never used the API explorer to set values, does it allow you to pass the UoM to the item at the same time as the value?

Are you able to try any of the above tests with the real item that has it’s value updated from a thing channel that (I assume) passes the UoM too? What sort of thing is the real item linked to? Which binding, etc?

[Mark_VG (Mark)]

@higgers

I’ve never used the API explorer to set values, does it allow you to pass the UoM to the item at the same time as the value?

It does allow setting the Units. Doing so however does not make any difference.

the item to 50.3 Hz produces:

@higgers

Are you able to try any of the above tests with the real item that has it’s value updated from a thing channel that (I assume) passes the UoM too? What sort of thing is the real item linked to? Which binding, etc?

The real THING does not have units passed to it. It is a Modbus register value - so just a 16 bit signed integer value. Using the ModBus binding

That is why I noticed the issue - with the displayState switching between a correct value and undefined

[Mark_VG (Mark)]

I have now also tried this with the item as Number and Number:Dimensionless and see the same results.

Also, I see this with other UoM types as well.

[rlkoshak (Rich Koshak)]

@higgers

Not all numbers can be converted exactly to floating point. Try changing the state description to %.1d Hz instead.

That won’t work. d mean integer. You can’t have an integer with a decimal place.

Show the actual YAML of your Item and State Description metadata.

Do you see anything in openhab.log when it’s showing undefined?

If it’s a 16 bit integer, how are you ever getting values with decimal places at all? Are you applying a transform or the gain profile or something like that? Note that you can add units using the modbus gain profile according to the docs.

[JustinG]

This has been true since the beginning of MainUI. In order to optimize the amount data being set to widgets, the displayState for an item will only ever be defined if it is different from the actual state. The devs decided it would be too resource intensive to send redundant data like that.

Take a look at the pre-fabbed widget code that pops up when you start a new widget:

content: =items[props.item].displayState || items[props.item].state

Something like this is always necessary if you want the display state because this data optimization means that there are virtually guaranteed to be times when the display state is undefined.

(the @ widget expression operator does the same thing as the above code for the same reason).

[Mark_VG (Mark)]

Thank You…

@rlkoshak

Show the actual YAML of your Item and State Description metadata.

Unit:

value: Hz
config: {}

State Description:

value: " "
config:
  pattern: "%.1f Hz"

@rlkoshak

Do you see anything in openhab.log when it’s showing undefined?

Nothing is logged to openhab.log

@rlkoshak

If it’s a 16 bit integer, how are you ever getting values with decimal places at all? Are you applying a transform or the gain profile or something like that? Note that you can add units using the modbus gain profile according to the docs.

For my production system the is a transform to divide by 10 or 100 depending on the item.

However in these tests I have been doing since noticing the odd behavior I have used the API Explorer to assign values such as 50.2 or 50.123 etc

@rlkoshak

Note that you can add units using the modbus gain profile according to the docs.

The Units seem to be working fine by just assigning the Unit metadata. The same however happens with no units (So Number or Number: Dimensionless)

[Mark_VG (Mark)]

@JustinG

In order to optimize the amount data being set to widgets, the displayState for an item will only ever be defined if it is different from the actual state.

Thanks Justin. I now remember reading that… But have never seen it be a problem before. Makes sense now though.

EDIT: Confirmed that the following works:

text: ="DISPLAY STATE - " + (items.ZZ_Test_displayState.displayState||items.ZZ_Test_displayState.state)

[Mark_VG (Mark)]

@Mark_VG

Makes sense now though.

That said, it is strange that 50.0 produces 50.0 Hz, and only the others are an issue?

[ssalonen]

Ohh… I have been suffering from this for quite some time. Now I know better