OH 3.1.0.M3 - Item with actual state suddenly listed as undefined in location card

[kjoglums (Stian Kjoglum)]

After upgrading to OH 3.1.0.M3 (running openHABian), some of my item states used in location cards are suddenly listed as undefined, even though the item state updates regularly. This was not an issue coming from OH 3.0.1 stable release.

So, for instance, for an item of mine: eBusVaillantMQTT_VaillantOutdoorTemperature. As the graph below shows, there are continuous updates for the item.

Regardless, when using the following yaml for the location card, the item is displayed as undefined. The line breaks are set default when saving.

           slots:
            glance:
              - component: oh-link
                config:
                  text: "='Outside:  ' +
                    items.eBusVaillantMQTT_VaillantOutdoorTemperature.displaySt\
                    ate"
                  iconF7: thermometer_snowflake
                  iconColor: white
                  color: white
                  style:
                    font-size: 12px

[rlkoshak (Rich Koshak)]

Are you sure that there are continuous updates? UNDEF doesn’t get saved to the database and I see plenty of stair steps and flat lines in that graph.

The MQTT binding will set the Items to UNDEF when the Thing determines it can’t connect to the device. There are two ways this might occur. If the Broker Thing loses connection to the MQTT Broker it will set all the Items that are linked to Channels on Things that work through that Broker to UNDEF. The other way is there are some LWT settings on the Things themselves. If the device is considered to be OFFLINE based on those LWT settings, all the Items linked to Channels on that Thing will be set to UNDEF.

Unless you’ve written some rules or have something else interacting with these Items, those are the only ways those Items can be set to UNDEF.

What do you see in openhab.log? What do you see in events.log?

[kjoglums (Stian Kjoglum)]

The behaviour of updates (ref graph) has not changed between OH 3.0.1 and 3.1.0.M3, and I believe this is the nature of the MQTT Thing channel based on the pub setup. So, I would call these continuous updates, despite some apparent flatlines.

Nothing is reported within openhab.log, and events.log reports item state changes (see example below for the last couple of minutes), however, item as presented from location card remains undefined.

2021-04-05 23:02:15.211 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eBusVaillantMQTT_VaillantOutdoorTemperature' changed from 0.5 to 0.4
2021-04-05 23:04:05.217 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eBusVaillantMQTT_VaillantOutdoorTemperature' changed from 0.4 to 0.438
2021-04-05 23:04:40.231 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eBusVaillantMQTT_VaillantOutdoorTemperature' changed from 0.438 to 0.4
2021-04-05 23:07:04.964 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eBusVaillantMQTT_VaillantOutdoorTemperature' changed from 0.4 to 0.438
2021-04-05 23:07:40.203 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eBusVaillantMQTT_VaillantOutdoorTemperature' changed from 0.438 to 0.4

[rossko57]

@kjoglums

item as presented from location card remains undefined.

So the Item and its state is fine,but there’s a presentation issue? What does it really display, “undefined”? That probably refers to something in the YAML.
I’ve seen something about line breaks in there recently.

[kjoglums (Stian Kjoglum)]

Yes, that is the case: The item state is being updated (as recognised from logs, as well as from UI Model), however, item as presented on location card is presented as “undefined”:

I would suspect some issue related to the line breaks, however, these are saved back to default (as shown in yaml code above) when trying to change.

[rlkoshak (Rich Koshak)]

In this context, “undefined” is not the state of the Item. When the Item is in the state UNDEF that will come across as -, not “undefined”.

In this context the “undefined” is coming from the expression in the widget. It’s telling you, for example, that items.eBusVaillantMQTT_VaillantOutdoorTemperature.displayState is not defined. Have you applied State Description metadata to this Item with a Pattern? If not, then this Item doesn’t have a displayState, just a state (which shows the state of the Item using the defaults). So when you try to use displayState it shows as undefined.

The line breaks are added by the UI and not a problem. You’ll find that happens to any long line in a widget definition automatically.

[ysc (Yannick Schaus)]

You can open the Developer Sidebar with Ctrl+Alt+D or the Developer Tools menu, go to the 3rd tab and type =items.eBusVaillantMQTT_VaillantOutdoorTemperature to see what you have.

Maybe you don’t have a displayState indeed in which case you’ll get only { "state": "something" }. If it’s okay to you change your expression to:
text: "='Outside: ' + items.eBusVaillantMQTT_VaillantOutdoorTemperature.state"

[kjoglums (Stian Kjoglum)]

@rlkoshak, @ysc
Appreciate your help.

Item eBusVaillantMQTT_VaillantOutdoorTemperature is in fact set up with Metadata: stateDescription, i.e. Pattern %.1f. And the item is linked to a MQTT channel which is created using yaml code, having unit: °C. And for OH 3.0.1, this setup enabled the item to display as x.x °C in the location card.

From Developer Tools Menu, I get the response as shown below, which would be according to stateDescription. Switching to .state rather than .displayState now gets me the number in the location card, but the unit, i.e. °C (as defined by yaml code for MQTT channel) is no longer being displayed.

Which made me realise: Changing stateDescription to pattern %.1f °C, thus disregarding unit already set for linked channel, I am back to the standard/desired display for the item, i.e. x.x °C.

Uncertain why the display “broke” during upgrade, as I have done no other changes.

[rossko57]

@kjoglums

And the item is linked to a MQTT channel which is created using yaml code, having unit: °C.

The MQTT unit= channel parameter is not currently working the way you think i.e. it is not adding unit to incoming data.
You can see this in your events.log extract.

That should have been done by your system default, metric/imperial - so that is the part that appears to have changed or got lost.
You might look back in your events.log before upgrade to see units there?

[mqtt] Faulty display of an linked item using Units of Measurement.

[kjoglums (Stian Kjoglum)]

The events.log from before upgrade, nor after the upgrade shows units for the MQTT items. So still confused what changed/got lost. Regardless, introducing the State Description pattern fixed the issue for MQTT items / using displayState for location card.

However, I do not seem to understand UoM and state vs displayState following the discussion above. For some of my Modbus items, after upgrading to 3.1.0.M3 (as discussed under Link), these are now also shown as “undefined” in location cards.

Having some Number:Temperature items (metric system), also set up with metadata State Description pattern %.1f °C, state updates are reported as x.x °C in events.log, and items are displayed correctly with decimal/unit according to State Description for item as shown in Model.

However, using either .state or .displayState for item in location card both displays the item as undefined.

[rossko57]

You’ll have to be more precise.
Modbus binding, like generic MQTT binding, will never provide units unless you force it in some way.
Maybe more relevant, some quantity types have system default units and some don’t. This affects how quantity type Items get updated when a non-unit value is posted to them.

@kjoglums

However, using either .state or .displayState for item in location card both displays the item as undefined.

Seeing “undefined” in MainUI tells you its having trouble with the requested format, not with the Item state of itself. Perhaps you are trying to treat a state like “22.0 kW” as a decimal number, or something.

[kjoglums (Stian Kjoglum)]

Following the discussion from above, my understanding was that .state would track incoming state, and .displayState would track item state based on State description pattern if defined. As mentioned, neither of these work for displaying item state in location card (displayed as undefined).

@rossko57

Modbus binding, like generic MQTT binding, will never provide units unless you force it in some way.

For the manual installed version of Modbus binding, I used a gain profile gain="0.1 °C", however no traces of the gain profile within jsondb files after switching to 3.1.0.M3 version and unlinking/re-linking items/channels. So besides the State Description pattern, i.e. %.1f °C, there are no forced units introduced.

So, the incoming value as received from the device comes in as e.g 20, transformed to 2.0 using JS:divide10.js, linked from Number item channel to Number:Temperature item, set up with State Description pattern %.1f °C (read-only item).

The result then being item gets an update 2.0 °C as logged in events.log. The item, as displayed in the Model is also displayed as 2.0 °C (as also would be the case for displayed item state when opening location card).

[rossko57]

@kjoglums

Following the discussion from above, my understanding was that .state would track incoming state, and .displayState would track item state based on State description pattern if defined.

Seems right. Then what happens to it? i.e. if you get a state “2.0 °C” it won’t format with %.1f if that is applied afterwards.
Them what understands these things need to see the card that goes with -

@kjoglums

item gets an update 2.0 °C as logged in events.log

to get all the puzzle pieces.

[kjoglums (Stian Kjoglum)]

Glad you are walking me to the door step…

@rossko57

if you get a state “2.0 °C” it won’t format with %.1f

@kjoglums

However, using either .state or .displayState for item in location card both displays the item as undefined.

Even if wrong format is used for State Description, I do not see why .state would result in the item being displayed as “undefined” in the location card, as the format is applied as part of State Description (which then is said to be used for displayState).

Regardless, removing State Description completely (thus allowing the item to display without any decimals and unit in the UI Model), still using .state for location card, get the item displayed correctly on the location card.

[rossko57]

@kjoglums

Even if wrong format is used for State Description, I do not see why .state would result in the item being displayed as “undefined” in the location card, as the format is applied as part of State Description (which then is said to be used for displayState).

Me neither.

@kjoglums

removing State Description completely

So, can you clarify what the offending state description was, and what the real Item state was?
It seems possible that getting a unit where none is expected blows something up.

[rlkoshak (Rich Koshak)]

@kjoglums

However, using either .state or .displayState for item in location card both displays the item as undefined.

That almost always means there is a typo in your expression. For example, if the Item name is even one character off it won’t find the Item and therefore there is no Item to get .state or .displayState from so all you get is undefined.

If the expression is correct, there should always be a .state and as far as I know .state, if all else is correct, will never show “undefined” on the UI. It might show “-” or “UNDEF” but never “undefined”.

As Yannick suggests, test that specific expression in the developer sidebar expression tester.

[kjoglums (Stian Kjoglum)]

Beats me what was wrong. Coming from OH 3.0.1 release using Modbus manual install version, using profile gain="0.1 °C" for Number:Temperature item linked to Number item channel, State description pattern %.1f °C, both item state in events.log, item state display in UI model and item display for location card (using .displayState) worked as expected. Raw data input then being actual temperature reading as number multiplied by 10.

Then coming to OH 3.1.0.M3, having to change to Modbus 3.1.0.M3 version without gain profile, thus introducing JS:divide10.js to achieve correct transformation for the same/existing Number:Temperature item, State description pattern %.1f °C, and the item display for the location card “broke” (still having displayState).

Playing around, back and forth with .displayState and .state, then removing metadata (State description pattern), and I regained correct item display for the location card.

[lucasec (Lucas Christian)]

I think I may be experiencing this same issue—I’m somewhat convinced it is a bug, or a strange behavior change in what is an acceptable format for state descriptions.

For example, I have a “precipitation probability” weather item with a state description of

%.0f %%

OpenHAB used to correctly render this as “46 %” or something like that if the raw value reported by the weather driver was 46.002. The binding reports the value in a channel of type Number:Dimensionless. Now I get undefined.

If Iook at another “humidity” item reported by the HTTP binding (cast to a channel with plain Number datatype), the state description works fine.

[rossko57]

@lucasec

The binding reports the value in a channel of type Number:Dimensionless.

What type of Item have you linked that to?

Here is a curious report you might like to compare with -

Expressions Items not accessible

Thank you for this very useful workaround when .displayState is unavailable for whichever reason. One thing I don’t quite understand is the following: .displayState becomes unavailable when .displayState would return the same result as .state. See the following example: [Windboe1] [Windboe2] with “%.0f %unit%” applied as stateDescription How come .displayState does not return anything? Is this a bug?

[lucasec (Lucas Christian)]

The item type is also Number:Dimensionless. That report is interesting—let me follow up there.