During Startup: Tried to set invalid state 0.0 (DecimalType) on item <my_item> of type StringItem, ignoring it

Add-ons Bindings
1

I’m starting to see these errors in the log for most Items during startup. While they are on Items that are linked to channels in a binding that I’m working on, I don’t believe that bindings bundle has even been started at this stage.

Tried to set invalid state 0.0 (DecimalType) on item <my_item> of type StringItem, ignoring it

My best guess is that something it trying to restore some persisted channel states, and getting it very wrong.

The binding is generally using ASCII values to represent states [A-Za-z0-9], so the actual value in the string is the ASCII character code; i.e. 0 (0x30). For some reason it looks like it’s trying to restore the previous value, which was {(byte)0x30}, but it’s somehow parsed the string into a decimal, then it complains the decimal it converted it to is not appropriate for the String Item type, OR, whatever did the persistence incorrectly stored it as a decimal and then it fails to restore.

Plus, it’s wrong, {(byte)0x30,(byte)0x2E,(byte)0x30} is perfectly valid in a string, even if it is a corrupted non-sense value, it’s not a type violation.

Is this a known bug?

2

channel should be stateless. I would look in the first place at your general persistence setup, especially for “*” in xxx.persist files

3

Hm, well, what does it do out of the box - this is a Raspbian Image BTW, and, it’s running a v3 SNAPSHOT, which AFAIK is unstable - because I have not touched anything to do with persistence. In fact, I have no idea what you’re talking about so I’m going to need to go look it up.

4

There’s nothing like that anywhere on the filesystem

[09:27:30] root@openhab:~# find /. -name "*persist" -print
[09:27:48] root@openhab:~# touch /opt/test.persist
[09:28:41] root@openhab:~# find /. -name "*persist" -print
/./opt/test.persist
[09:28:46] root@openhab:~#
5

I don’t know where any of this stuff lives for oh3.
I do believe I have read that by default oh3 setup persists, don’t know if that defaults to restore everything (which I do not think is a good idea).

6

It seems to be coming from rrd4j. I found this directory structure which seems to be related. It appears to be trying to build rrd graphs for string channels… that will end badly. I’m not sure why, I didn’t explicitly enroll them AFAIK.

[09:41:48] root@openhab:~# ls -la /./var/lib/openhab/persistence/rrd4j
total 3764
drwxr-xr-x 2 openhab openhab   4096 Oct  7 19:48 .
drwxr-xr-x 5 openhab openhab   4096 Oct  1 14:04 ..
-rw-r--r-- 1 root    root    548176 Oct  6 22:14 JVCRS3000Projector_Colorimetry.rrd
-rw-r--r-- 1 root    root    548176 Oct 13 09:42 JVCRS3000Projector_ColorProfileSelect.rrd
-rw-r--r-- 1 root    root    548176 Oct 12 19:33 JVCRS3000Projector_Input.rrd
-rw-r--r-- 1 root    root    548176 Oct  6 01:28 JVCRS3000Projector_Model.rrd
-rw-r--r-- 1 root    root    548176 Oct 13 09:42 JVCRS3000Projector_Power.rrd
-rw-r--r-- 1 root    root    548176 Oct  7 19:48 JVCRS3000Projector.rrd
-rwxr-xr-x 1 openhab openhab     32 Oct  1 13:05 Readme.txt
-rw-r--r-- 1 root    root    548176 Oct  7 19:45 RS3000.rrd

I’ve seen where there are profiles which can enable tracking of channel stat changes, and I’ve seen graphs which show it. Since the v3 UI is different I’m not sure if I’m seeing something that has always been there or if this is something new. I suppose those errors only pertain to functionality I’m not using so they’re probably safe to ignore for now.

7

So far as I know OH3 persistence operates on Items and never on channels. There may be a terminology hiccup here.

8

Well, channels have a type, Items simply inherit that type. I don’t think you have String Items, you have String Channels linked to Items.

9

No, Items have it‘s own type.

10

Where does that get configure?

11

I think you’re splitting hairs over naming, encapsolation and inheritance. The channel “holds” a reference to a channel-type which in turn “holds” a references to an itemType.

Technically, the type has to exist before the Channel or the Item, in the form of a channel-type

	<channel-type id="lamp">
		<item-type>String</item-type>
		<label>Power</label>
		<description/>
	</channel-type>

Then a channel is created based on the channel-type

{
  "parameters": [],
  "parameterGroups": [],
  "description": "",
  "label": "Power",
  "itemType": "String",
  "kind": "STATE",
  "tags": [],
  "UID": "jvcProjector:lamp",
  "advanced": false
}

Then the binding implements the channel’s data type according to the channel-type definition.

Finally, an Item - which is just a virtual wrapper - inherits from the channel(s) it links to. An Item does not have a distinctly separate data type, the same type classes are used throughout.

{
  "link": "http://my_domain:8080/rest/items/JVCRS3000Projector_Power",
  "state": "4",
  "stateDescription": {
    "pattern": "%s",
    "readOnly": false,
    "options": []
  },
  "editable": true,
  "type": "String",
  "name": "JVCRS3000Projector_Power",
  "label": "Power",
  "category": "",
  "tags": [
    "Switch"
  ],
  "groupNames": []
}

…and I don’t see how this relates to the rdd graphs deciding to graph strings as if they were floats or doubles.

12

General documentation under concept - items


and for textual config
configuration guide - items
13

I am not splitting hairs.
For example, you can link a channel of type switch to a switch item, to control the state and you can link it to a string item, just presenting on or off as a read only string in the UI.

14

A switch is not a data type. You’re mixing metaphors. … actually, the framework does that too. It started out with independent metaphorical abstraction, but I’m guessing it quickly became evident that wasn’t going to scale, so now it adopts string and numeric primitives along side something that is a whole different level of abstraction, which is awkward and confusing.

In this thread we’re talking about internals, so the openHAB type abstractions are not relevant. rdd should not be getting fed java strings to graph. rdd creates numeric times series. If you’re going to graph java strings you need to use an aggregate like count. There is something very wrong with it trying to convert java strings to doubles, and it knows it, hence the errors. I wasn’t prompted to set any of that up so something clearly went and made some decisions on it’s own, and I would expect it to fail the way it is under the circumstances.

15

I agree. But it’s working with Items. Items are freestanding, not an appendage of channels. Items can and often do exist entirely independently of any channel at all. Such Items still have types, like String or Number.

So what you are interested in here is how your copy of rrd4j is selecting Items to persist, and apparently try to restore.

Yes. New in OH3 is some kind of default setup, I don’t know what that is.

16

Items are not really anything concrete. They’re just logical identities. Mostly, they’re just names that make up a segment of the topics on the event bus. They’re mostly used just for routing payloads. They are noting without a concrete implementation like the Channel class and the payload types like stringType.

As you can see from the EventHandler.handleEvent(), the types are in the palyoad

topic=openhab/items/JVCRS3000Projector_NullCommand/statepredicted
type=ItemStatePredictedEvent
payload={"predictedType":"String","predictedValue":"","isConfirmation":false}

I found the problem. I was having other issues too which turned out to be caused by the same thing. Commands were not being sent to the device - the handleCommand() wasn’t being called for some channels.

Since I’m a developer I’m creating XML configurations for the binding, which define the channel-types and channels. But apparently that gets selectively copied into something called jsondb where it gets persisted across restarts - this framework has entirely too many competing, redundant, overlapping, and breaking configuration sources. What the framework appears to do is rehydrate all the classes from jsondb on startup. I’m not sure if or when it ever goes back to the original configurations.

I had to spend half the day in the debugger, and enable TRACE level logging on org.openhab.core.thing.internal.CommunicationManager to see that it was silently failing to convert a stringType to a string. The reason was that the Channel class has an attribute called acceptedItemType. While that was not being set by the thing-type.xml something had stored Switch in the acceptedItemType attribute in the jsondb, so, it had a stringType that is thought was a Switch type, and it couldn’t find a solution to convert it to a string, so it logged to a TRACE level event and otherwise silently returned having done nothing. I’m sure that was the same problem with rrd4j; whatever was trying to cover to a primitive was making a mess of it because the value wasn’t what the acceptedItemType said it was.

I just deleted the jsondb directory and restarted, and the bogus Switch entry was finally gone. So, it looks like jsondb accumulates garbage and gets corrupted over time.

17

When you create a thing in the ui than it makes an entry in the jsondb. If you then update the binding with new or changed channels it will not update the jsondb so you need to recreate the thing. Could it be you changed the binding channels and as a result the thing in jsondb was outdated?

1 Like
18

Yes, that is certainly part of it. However, you are able to edit Channels and Items, and the changes will be persisted to jsondb. But, you can’t edit everything, you can’t even see everything, and it doesn’t seem any edit checks get run, so you can break the channel if you change a Type in one place to something that’s incompatible with a Type you can’t change, or see, in another place, and then it very silently fails at run time.

19

And I was wrong about rrd4j, that problem is still there, but is coming from the same code that tries to do translations I believe.

20

I´m getting the same error in my minimal OH3 test environment on startup (build 1970) on a string item. (fresh setup on RPi4 with raspberryOS lite and openjdk 11.0.8)

Currently I´m only using the exec binding and transformation for testing purposes - nothing else changed. No additional persistence was installed (besides the preinstalled rrd4j)

Tried to set invalid state 123456789 (DecimalType) on item varSMS of type StringItem, ignoring it

After OH is up, I can set the string item to whatever I want, as expected, so its just an error in the log for now.

I was thinking that rrd4j doesn´t even try to persist string items?!

I can´t contribute anything on the technical part of your discussion, but maybe another case could help.