:: in item declaration crashes openHAB REST API

Setup, Configuration and Use Items & Sitemaps
,
1

Accidentally, I made a typo when defining an OH3-item in a textual file by adding an extra “:” in the channel field:

DateTime LocalNTPDateTime "Datum & Zeit" {channel="ntp:ntp:local::dateTime"}

In the log file there are warnings and error messages

[WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: Last segment must not be blank.
java.lang.IllegalArgumentException: Last segment must not be blank.
[....]
[ERROR] [ore.common.registry.AbstractRegistry] - Cannot inform the listener "org.openhab.core.thing.internal.ChannelLinkNotifier@b559c2" about the "UPDATED" event: Last segment must not be blank.

If you overlook or do not understand these warnings (as I did) the openHAB REST API crashes for items as can be seen e.g. here:

(1) Output of

curl -X GET --header “Accept: application/json” “http://192.xxx.xxx.xxx:8080/rest/items?recursive=false”

ends with

{\"error\":{\"message\":\"Last segment must not be blank.\",\"http-code\":500,\"exception\":{\"class\":\"java.lang.IllegalArgumentException\",\"message\":\"Last segment must not be blank.\",\"localized-message\":\"Last segment must not be blank.\"}}}

(2) The items explorer in the Main UI

http://192.xxx.xxx.xxx:8080/settings/items/

loops and shows no result at all

(3) The openHAB Addin for Visual Studio Code shows this error message:

Could not reload items for HoverProvider
---
    Error:
        Error while connecting to openHAB REST API.
    Message:
        TypeError: e.data.forEach is not a function
---

The simple solution is to correct the erroneous “::” in the items declaration and restart the system “clean-cache”.

Suggestions:

  • Provide additional information about this erroneous item definition in the log files (e.g. item file name, channel and/or item)
  • Ignore incorrect item declarations in the REST API

Kind regards,
Joachim

openHAB 3.3.0 Release Build
Raspberry / Linux/5.10.103-v7l+ (arm)
Java Raspbian 11.0.16
2
  • use the UI

The question behind is: how relevant is your demand after all?
While some input file format errors might be caught this way, other similar ones won’t.
Why to start and where to stop with this sort of development activity ?
Thing is, OH has moved to UI based provisioning long ago. Text based provisioning has been available since OH 1.X, the parsing code is probably many years old and not subject to any ongoing development like is the UI.
All OH developers are volunteers, probably noone’s familiar with that old code, and all devs decide for themselves what they want to invest their time into. As parsing has been working for years and it’s not a bug in the system (provision is working whenever the user corrects his error) and a superior alternative to take care of this exists (UI provisioning), there’s essentially nothing to be won here … this is an example for a bad effort-to-benefit ratio so likely no developer is interested in spending his time on this.

3

Just because it’s superior for you doesn’t mean it’s superior for everyone.
Other people have other requirements and different things work differently for everyone.
If the UI works for you that’s fine but please stop these generalizations.
There are people consciously decide to use file based definition.
Yes, the parsing code is old and yes, there is currently no maintainer putting any effort into the parsing code. These are known facts.
Since Joachim mentioned the MainUI I’m sure he is aware that he can create items there.
But somehow he still chose not to.
So with your comment you are neither contributing nor helping.

1 Like