Item state description ignored when loading from InfluxDB

Setup, Configuration and Use Items & Sitemaps
, ,
1
  • Platform information:
    • Hardware: Raspberry Pi 4
    • OS: Ubuntu 22.04
    • Java Runtime Environment: OpenJDK 17
    • openHAB version: 4.0.3
  • Issue of the topic: Item state description ignored when loading from InfluxDB

Hello everyone,

I have a problem with an item that displays the state description incorrectly after restarting openHAB 4.0.3. Only when sending a command, the items state description will be displayed correctly.

My guess: when loading from InfluxDB, a float is parsed, but my state description defines integer.

Is my configuration incorrect or is this a bug?

Channel configuration:

UID: mqtt:topic:mosquitto:espaltherma
label: ESPAltherma
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mosquitto
channels:
  - id: espaltherma_smart_grid
    channelTypeUID: mqtt:number
    label: ESPAltherma Smart Grid
    description: ""
    configuration:
      commandTopic: espaltherma/sg/set
      min: 0
      formatBeforePublish: "%d"
      stateTopic: espaltherma/sg/state
      transformationPattern: JS:|parseInt(input)
      max: 3

Item configuration:

label: ESPAltherma Smart Grid
type: Number
category: settings
groupNames:
  - espaltherma
groupType: None
function: null
tags:
  - Setpoint

State description:

value: " "
config:
  options: 0=Free running,1=Forced OFF,2=Recommended ON,3=Forced ON
  pattern: "%s"
  readOnly: false

Command description:

value: " "
config:
  options: 0=Free running,1=Forced OFF,2=Recommended ON,3=Forced ON

Screenshot directly after restart of openHAB:

image
image760×566 19.5 KB

Screenshot after sending a command to the item:

image
image760×566 20.1 KB

Thanks
Daniel

2

No it doesn’t.

That means String.

Integer would be "%d".

You’ve configured the Thing to return integers with your transformationPattern and that’s probably why sending the command converts it to an integer. But persistence is always going to update the Item using a float.

I’m not sure how options work, whether it works on the state description transformed state or the raw state. So I don’t know switching to %d will work. But it’s worth trying.

3

Yes, but when I configure %d, the state description is ignored in every case.

4

Given you are not doing any math with these values, is there some reason you are not using a String in the first place? Or make the mapping between the number and the String through a transform on the Thing.

It looks like the pattern and the options fields used in this way are not compatible. It’s kind of an odd use case to use options with numbers anyway for this very reason. They are usually expected to work with Strings.

5

Basically the value is string from MQTT. It does not matter what transformation I use in the channel, it is never read when restarting openHAB as long as it’s not updated. The problem must be somewhere between the persistence and the thing. When looking at the InfluxDB the values are stored as integers or a string representation without floating point, so 0, 1, 2 or 3.

6

Your Item is a Number.

Persistence always restores the state of Number Items as floats.

Your MQTT Thing is configured to transform the string coming in to a Number.

Agreed, there is nothing you can do on the Thing that will change one bit about the value restored from Persistence. That happens completely independently.

Well of course. You’ve told it may times over you want a number. You convert the value in the Thing to a number: JS:|parseInt(input). You store is in a Number Item. type: Number. So Persistence is going to save and restore the value as a number in InfluxDB.

And as I’ve already mentioned, Persistence is always going to restore a Number Item using a float.

However, if you change the MQTT Channel Type to a String and the Item type to a String a String will be saved in InfluxDB and therefore it will be restored as a String. No decimal places will get added. Everything will be the same.

Furthermore, the MQTT Thing configuration will be simpler as you won’t require the formatBeforePublish nor the transformationPattern because it stays the same String from end to end.

You could furthermore use a MAP transform on the MQTT Thing to do the mapping between the “number” and the human readable string instead of as options on the State Description. Then instead of seeing “0” in your logs, rules, the Items page, in the database etc. you’ll see “Free running”.

7

When using a string Item for the same channel, things get even very strange. Here I’m using %s as state description format. The state renders as datetime…

image
image737×911 36.9 KB

8

@rlkoshak Ok, now I completely redid the channel and linked a new item, both string. That does the trick, thanks a lot. For some reason the configuration got damaged when changing item type.

But, now I have to redo all of my rules using item.rawState.intValue() as well as my Grafana dashboard. But that’s feasible. :slight_smile:

9

One problem with this solution: the charts are not rendering as expected.

Chart item=espaltherma_smart_grid label="Level" period=D refresh="60000"

…now gives me a Chart with only zero values. Is there a solution for that?

10

I don’t use sitemaps any more really but indeed charts are only going to chart numbers. If you need to chart this using the sitemap Chart element you have to keep it as a Number and you will probably just have to live with the fact that the Item doesn’t display the state you want after a restart until the next update.

Or you might be able to double the options and include 0.0, 1.0, and so on.

11

Unfortunately this does not work. Either the mapping is in conflict or it is not triggered during a restart.