V3.0.2: Item not updating in openHAB UI

[Rob_Clark]

• Platform information:
  • Hardware: arm71hf
  • OS: debian 9
  • Java Runtime Environment:

openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Zulu11.45+27-CA (build 11.0.10+9-LTS)
OpenJDK Client VM Zulu11.45+27-CA (build 11.0.10+9-LTS, mixed mode)

• openHAB version: 3.0.2
• Issue of the topic: I have an item being updated by a REST call
  • The events.log file shows the item updating
  • The ANALYSE plot shows the values
  • but the UI Cell is not updating (V3.0.1 = OK)

Here is the REST update call:
curl -u RESTuser:2613 -X PUT --header 'Content-Type: text/plain' --header 'Accept: application/json' http://localhost:8080/rest/items/LocalHost_Disk0Used/state -d 29

Here is what appears in event.log at the same time
[INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LocalHost_Disk0Used' changed from 30 to 29

Here is the thing

UID: mqtt:topic:d57a0d76ab:f3d828759b
label: Local Host
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:d57a0d76ab
channels:
  - id: localHost_disk0
    channelTypeUID: mqtt:dimmer
    label: Disk0 Used (%)
    description: ""
    configuration:
      stateTopic: tele/local_host/disk0used

Here is my OpenHAB UI cell

component: oh-label-cell
config:
  title: test
  item: LocalHost_Disk0Used
  action: analyzer
  actionAnalyzerItems:
    - LocalHost_Disk0Used

Here is the ANALYSE plot

But … here is the UI Cell … that never updates

Messages on openhab.log?

• None

Interestingly … this config worked in V3.0.1, and indeed was created as below:
V3.0.1: openhab-cli backup my.zip
V3.0.2: openhab-cli restore my.zip

Any ideas?

[Rob_Clark]

And just checked that the item value is correct

[Rob_Clark]

Same problem with a generic MQTT Thing - getting normal MQTT messages

Thing

UID: mqtt:topic:8e0a883eb8:6a0b5d8898
label: Bolto Shelly
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/tasmota_bolto/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:8e0a883eb8
channels:
  - id: Temp
    channelTypeUID: mqtt:number
    label: Temp
    description: ""
    configuration:
      stateTopic: tele/tasmota_bolto/SENSOR
      transformationPattern: JSONPATH:$.DS18B20.Temperature
      unit: C

[rlkoshak (Rich Koshak)]

I’m confused.

@Rob_Clark

I have an item being updated by a REST call

If the Item is updating through REST, what’s the MQTT Thing doing? You don’t need both. Given you are using curl to update the Item MQTT isn’t even involved.

Furthermore, that Thing is subscribing to a topic for updates too so if there does happen to be something publishing to that topic, that too will update the Item independently from what ever you are doing with curl.

What type of Item is LocalHost_Disck0Used?
What is the State Description metadata for this Item?

Given that the Items appears to have the right value, the problem is almost certainly the UI configs somehow.

I’ve not used oh-label-cell so don’t have much to offer beyond there potentially being something up with the State Description or you need to define the label parameter or something like that.

[Rob_Clark]

Rich: Thanks for the feedback.

My most recent post is for a totally different Thing (no curl/REST involved) that is only updated with a normal MQTT message. It has the same issue with the oh-label-cell not updating - even though the underlying data value is correct.

I have reached a deadend with this. Everything (except updating the oh-label-cells) is working very well in V3.0.2 for me.

Maybe if someone else reports a similar problem … then this can be investigated.

Thanks

Rob

[rossko57]

Your Item type is Dimmer, and should I think be a Number. The MQTT channel type is number.

[Rob_Clark]

Thanks for that … but the 2nd item (MQTT/temp sensor) is a number … and it has the same problem displaying in openHAB UI.

UID: mqtt:topic:8e0a883eb8:6a0b5d8898
label: Bolto Shelly
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/tasmota_bolto/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:8e0a883eb8
channels:
  - id: Temp
    channelTypeUID: mqtt:number
    label: Temp
    description: ""
    configuration:
      stateTopic: tele/tasmota_bolto/SENSOR
      transformationPattern: JSONPATH:$.DS18B20.Temperature
      unit: C

[rossko57]

That doesn’t tell us about the Item involved. Can we see the JSON for that, like before? It is helpful and heads off questions.

@Rob_Clark

unit: C

Note that doesn’t look like a valid unit so far as openHAB is concerned.
I don’t think that matters though, as the binding does not currently use it for incoming data.

Take a step back here - you’re telling us you can’t see the value in the UI, and then show us screenshots of (part of) the UI showing the values you do expect. MQTT Things and REST aren’t of much interest here, the Item state gets populated correctly.

As Rich says, the Item metdata pattern controls how the Item state is presented - what have you got there?

[Rob_Clark]

@rossko57

Changed Units as below. Did not fix anything

UID: mqtt:topic:8e0a883eb8:6a0b5d8898
label: Bolto Shelly
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/tasmota_bolto/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:8e0a883eb8
channels:
  - id: Temp
    channelTypeUID: mqtt:number
    label: Temp
    description: ""
    configuration:
      stateTopic: tele/tasmota_bolto/SENSOR
      transformationPattern: JSONPATH:$.DS18B20.Temperature
      unit: °C

you’re telling us you can’t see the value in the UI
RC> YES. The UI shows just ‘-’

and then show us screenshots of (part of) the UI showing the values you do expect.
RC> YES … Inspecting the ITEM shows that it is getting updated with new values. It is just the LAYOUT page that is not updating

MQTT Things and REST aren’t of much interest here, the Item state gets populated correctly.
RC> Correct

“The Item metdata pattern controls how the Item state is presented - what have you got there?”
RC> There is nothing set for the metadata of the item.

[Rob_Clark]

SUCCESS!!

Found the fix in Settings > API Security

GOOD

BAD

THIS WAS THE CLUE
Using Chrome browser, pressing F12 brings up a diagnostic panel. Saw that one REST call was failing.

Why that one REST call failed … but many others succeeded is a mystery.

Bug? I don’t know but the http://openhab:8080/rest/events/states call seems the issue. Where as others (e.g. http://openhab:8080/rest/sitemaps) succeeded.

Maybe the the devs might check why /rest/events/states is behaving differently.

Thanks for all those that tried to help on this one.