Yet another converter for items and things

Tutorials & Examples
1

Hi community :wave:

I have an oh instance with currently >90 things and >300 items. I want to go from UI definitions to text based defnitions, which requires a lot of work if you do it “by hand”. No way - we need automation :smiley:
(Reason behind: Mass update of item metadata - waaay easier if you have .items instead of JSONDB)

I eventually found JSONDB items to textual config which can convert items from the JSONDB. But it lacks 2 important features (at least for me):

  • it cannot convert things (I don’t want to create 90 things by hand…)
  • it cannot add item metadata for channels and widgets (I already put a lot of effort in widgets and have a lot of transforms by regex or MAP)

This was reason enough to create my own version of a things/items converter. Since I am a windows guy, it’s written in Powershell. It converts the JSONDB files to PS-usable objects using custom classes. Then it uses class methods to convert these objects to the string format required for .things and .items

If anyone finds it useful, feel free to use it. If you have comments about coding or have suggestions on my parameter selection, feel free to leave feedback upon. And if you are a windows guy like me, be invited to create a pull request :ok_hand:

As of now, it fully supports all type of things including bridges and thing configuration. And it fully supports all item data including metadata configuration with all metadata configuration properties (like defaut list/standalone widget parameters, transforms and everything else).

Currently I have 2 quirks I don’t know how to solve:

  • Thing channels reporting false default configurations

Until now, I configured everything through the GUI. In the JSONDB things file, I pick up the channel configuration. For one specific homematic device type, after importing my alltings.things I get

23:38:16.166 [WARN ] [nternal.handler.HomematicThingHandler] - Value for datapoint HmDatapoint[name=CONF_BUTTON_TIME,value=255,defaultValue=255,type=INTEGER,minValue=1,maxValue=254,options=null,readOnly=false,readable=true,unit=minutes,description=CONF_BUTTON_TIME,info=null,paramsetType=MASTER,virtual=false,trigger=false] is outside of valid range, using default value for config.

This specific Homematic thing has written this value of 255 on its own to the things JSONDB file for whatever reason… Excerpt from the Thing.json:

      "configuration": {
        "HMP_-1_CONF_BUTTON_TIME": 255,

It already tells me that the defaultValue seems to be 255 but the maxValue is 254 only :laughing:

How can I get around that? Stupid implemetation?

  • Shelly devices behave weird

I have two Shelly1 in my setup. Both are recognized as ONLINE after importing my custom alltings.things. Setup is kinda like

Thing shelly:shelly1:485519c90a33

In things of the OH UI, both things show up as online. But they also show up in the inbox wih a different ID:

Thing shelly:shellydevice:485519c90a33

If I edit the allthings.things and in the UID replace “:shelly1:” with “:shellydevice:”, the inbox gets empty, but both things now show up as ERROR_HANDLER_MISSING. If I then change back the UID to “:shelly1:”, the inbox stays empty, and both things show up as ONLINE. WTF?!?

Thanks for any hints about those 2 issues - although both are minor, I love code that works “completely” :smiley:

5 Likes
2

Nice work. Personally, I can see the argument for items being in text files, but I’m not as sold on things. I keep my MQTT things in text files, but every other device/service is discovered through the UI. Is there a particular reason you wanted to do this, or is just a “might as well” since you wanted to convert items with metadata?

Unfortunately, I will be of no help to you in improving your code. :wink:

1 Like
3

Main reason to do all with text files is “mass updating” - I have 12 rollershutters, 12 thermostats and 11 smoke detectors (along with some other things). And as a OH rookie, I often realize that I did something “the wrong way” in the first place. This applies to both things and items :grin:

Being able to convert not only items, but also full item metadata and things with configuration makes it easy to configure one sample thing/item in the UI and then apply the resulting configuration to all other items/things within seconds.

Example: I initially configured oh-slider-card for all thermostats. Eventually I stumbled over custom widgets and implemented 3 of them for temperature reading, temperature control and operation mode. Now I had to modify all 12 thermostats in the UI to use the custom widget. Bah… :sunglasses:

4

Yeah I think having custom widgets is good. The one I did if you auto create all things and items you just tell it the name of the thing and it will all be configured

5

I just want to reemphasize the use of custom widgets. Whether you are using text based or UI based Items, you should be using custom widgets pretty much any time you want to define a default widget for any Item. Then when you need to change something, you change it once and it applies everywhere the widget is used.

I touch on this a little bit in the Getting Started Tutorial but maybe need to get more in depth.

I’ll also note that since most Things are autodiscovered, it’s really hard to get them wrong. You just accept them from the Inbox. That’s why the general advice since OH 2 has been to keep most of the Things in the UI.

Also, there are some bindings that do not support all capabilities in text based Things so be careful you understand what you might be giving up in a move to text based Things. For example, you cannot set device properties on Zwave devices through text based Things.

6

This is what I was getting at. I’m with you on items, but there’s usually not much you need to do with things after you’ve added them, aside from connecting channels to items.

Given all the work that OH has to do to discover some Z-Wave devices, I wasn’t even sure if you can do text configuration of them.

7

A lot of that work is so that the binding can get at information that you likely just know because it’s printed on the device, such as the make and model of said device. Once you know that it’s all straight forward.

8

If I had to make any decisions about the UI, I would definitely take this one step further.

The UI would popup a nice red warning if you add a builtin widget to anything. This red popup would strongly recommend to not use a builtin widget but a custom one, and it would link to the current doc about custom widgets. It also would then say “Proceed anyway?”, and it would have a checkbox “Don’t remind me again”.

9

It’s always worth filing an issue.

10

Where and how exactly? I know “something” about GIT, but am not experienced. I am a complete newbie in openHAB. I also don’t know how many Git Repos OH uses or which Repo serves what purpose, so will possibly open that issue in the wrong repo. Do I anyway have a voice that will be heard? :smiley:

11

This would be in the openhab-webuis repo.

In this project, issues are, for the most part, judged by their merit and not who is posting the issue. But filing an issue is no guarantee that someone will volunteer to implement it or it might be a request that has other impacts that make it not attractive.

But I can guarantee that if you do not file an issue it almost certainly will never be implemented.

12

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.