Items change Semantic Class when rebooting

Setup, Configuration and Use Items & Sitemaps
1

Good evening,
since I configured my current Openhab3 Setup, I did watch a strange behaviour that I don’t understand and could not find described anywhere in this forum.
I have a few temperature Sensors and other sensors, connected via Conbee II and the Deconz Binding.
All Things and Items in general do work flawlessly when the system is up and running.
Everytime I restart the Openhab Service or the used Pi, the Semantic class of some of my items changes from Point>Measurement to Point>Control.
Before Restart:

screen1
screen1740×77 2.98 KB

After Restart:
screen2
screen2737×77 2.85 KB

Because of this change, all the badges at the Location Page stop working as they are only triggered by Point>Measurement Items.

All my items are configured with a text file xxx.items like shown below.

Number:Temperature   rBalconyTemperature   "Temperatur Balkon"   <temperature>   (gBalcony)    ["Temperature"]     channel="deconz:temperaturesensor:homeserver:tBalconyTemperature:temperature"}

The only workaround I could find until now was

  1. Change something in .items file (for example delete the icon definition) and save File
  2. Undo the Change in .items file and save File again.

Even this way, only the changed item is corrected, so just reloading the complete File does not seem to solve the problem.
Is anyone famliar with this behaviour by any change or has an idea how to diagnose the issue further?
Thanks in advance!
Justus

  • Platform information:
    • Hardware: Raspberry Pi 4, 8GB
    • OS: Raspbian 11 (Bullseye)
    • Java Runtime Environment: Java 11
    • openHAB version: 3.3.0
2

Well don’t restart your system, OH is supposed to run 24/7 anyway :slight_smile:

My guess is you have configured that item twice: via Main UI and in .items.
On restarts, it’s coincidence which one is loaded last, overriding the other one.
To check, check jsondb directly or comment it out in .items, when it’s still there a after a restart, delete it, and put the one in .items back in.

3

This is one of the reasons why I say that trying to use the semantic model with text Items files is simply not worth it.

And frankly the behavior you are seeing here is not wholly unexpected. You’ve only supplied one tag. Point Items must have at least a Point tag and can optionally have a Property tag. “Temperature” is a property tag. So what’s the Point tag?

It looks like the system randomly picks from among the list of possible Point tags.

  • Alarm
  • Control
  • LowBattery
  • Measurement
  • OpenLevel
  • OpenState
  • Point
  • Setpoint
  • Status
  • Switch
  • Tampered
  • Tilt

Notice Temperature isn’t there. Temperature is a Property. You might have an “Alarm, Temperature” for a sensor that alerts when the freezer gets to warm. You might have a “Setpoint, Temperature” to control your HVAC. A thermometer reading would usually have a “Measurement, Temperature”. But “Temperature” all by itself is, for the most part, meaningless.

What does this have to do with UI vs. text files? This stuff doesn’t have to be explained in the UI. All the possible tags and only those tags that are possible are presented to you. It won’t let you define a Point without a Point tag. It’s all pretty much self explanatory and difficult to get wrong even if you don’t read the docs. With text files you have to look everything up because there’s nothing to help you avoid pitfalls like these. It’s just not worth the effort.

That was my first guess too but then I noticed the tag OP was using and I’m thinking OH is just randomly assigning the required Point tag given it has a Property tag without a Point (I made a pun :rofl: ).

4

This was exactly what happend, thank you very much for the detailed information.
You are probably right, I should change to the UI-driven configuration, especially since the semantic model (which is great btw) is still new to me.
Coming from OH2 I still think I can do things faster and better in the text editor myself, but you made a pretty clear point. :sweat_smile:
Thanks again and have a nice evening.

5

If you do make the move you have two good options.

  1. Use the “add Items from text definition” where you can paste the contents of your .items files to import them in big batches. However with this approach you’ll have to go in and mess around with Group membership and tags individually which can be tedious.

  2. Recreate your Items using “create equipment from thing” and “create points from thing” which lets you create a bunch of related Items and situate them into the semantic model (location and equipment) all in one step. But if you’ve a lot of other stuff that depends on those Items you have to be careful to use the same names, or go around and fix everything else that uses them.

I found 2 to be the least amount of work for me, but I was also porting my rules over one by one at the same time and abandoned the use of sitemaps so I actually didn’t have anything else using these Items in place when I recreated the Items.

One other tidbit, make good use of custom widgets. Even if you have only two Items that are represented the same way, create a custom widget for that to apply to those Items. That will give you way more flexibility and ease your work in the long run. Related to that, also consider grouping a bunch of related Items into one widget (e.g. put all the control and status Items for a Chromecast onto a single widget, apply that widget to one of the Items and use visibility to hide the rest).