File-based items and UI defined groups not playing nicely

Setup, Configuration and Use Items & Sitemaps
1

I am running Openhabian on an RPi having updated from 2.5. Actually I am running two Openhab installations side by side because I have had issues and a number of my systems are mission-critical to a happy wife!

One particular problem I am having is my old 2.5 setup mostly used .items files. My heating system has 23 radiator valves and thermostats each with several endpoints, set temperature, valve state, battery level, mode etc etc. I can set them up fine using a .items file with the addition of the modern metadata to link them to the new semantic model so I have House (UI) → Downstairs (UI) → Living room (UI) → Radiator (file - Equipment group) → Set temperature (file - Point).

All that works… until it doesn’t. Every so often, the living room just forgets that the equipment lives there. The thermostats etc still appear, just under the root of the model instead of in the room. The Living_room_radiator item has a clear (Living_room) parent group in the .items file and each underlying point item is a member of the Living_room_radiator equipment group. Living_room is set up as a location in the semantic model using the UI. The Living _room_radiator is an equipment group defined in the .items file.

I forget now how I do it but with a little fiddling about restarting Openhab it will correct itself without me making any adjustments to the .items file, so it is not the file that is at fault. Just reloading the items file doesn’t however fix things.

I know there are warnings that items defined in files and UI based items don’t necesarily play nicely but Openhab 3 has been around for a while now. Is this something that is fixable? I really don’t want to have to create the best part of 200 items through the UI (a laborious process) and moreover if/when I change my configuration as my setup improves, modifying many items in the same way with a bit of copying and pasting in the files is a lot easier than making changes through the UI.

Or are there workarounds that can make the UI more palatable that I’m missing?

2

It was and still is not recommended use both configuration methods in a mixed mode.
But If you have created your complete items files with the metadata, you can import them, so you won’t have the mixture like you have now.

And before somebody comes around asking, there are absolutely no plans to remove textual config, it can just cause issues if you run both configs side by side.

3

There is a general impression that creating items via the UI is time-consuming, but that’s really doesn’t have to be the case. hmerk has already pointed to one method, bulk import via text files, that is a big time saver. Plus, as you are already using the semantic model, recreating all your items from scratch using the model’s import point from thing feature also will not be very time consuming once you get the hang of it.

Yes and no. Making the changes is faster. Troubleshooting what went wrong when you’ve made bulk changes via items files can, on some occasions, push this process to be far longer (it’s just plain harder to make such errors with the UI, given that it does have input validation). But that aside, the UI created items are all stored in a json file and these can be bulk copy-paste edited if you know what you are doing. It’s slightly more of a hassle than with .items files because you can’t do it with the system live, so you have to stop → edit → restart, but as long as you’re not doing this on a very frequent basis it’s achievable.

Don’t take this to mean that I think you shouldn’t keep using item files. Again, as hmerk says, that will remain a perfectly viable configuration method and everyone’s needs are different. I just wanted you to know that the things you’ve listed as preventing you from converting to full UI based config might not be the large hurdles they appear.

1 Like
4

You could also go the other way and move your UI created Items into files…

5

Thanks for your reply Justin. I shall try the import from file route to avoid recreating (which will be quite laborious) when I already have all the items as I like them.

Don’t take this to mean that I think you shouldn’t keep using item files

Well that is why I asked the question. I’d love to be able to keep using item files but I can’t because it’s not reliable. If I could I would because as I say, my files work perfectly… until they don’t. If the problem where Openhab just forgets the links between my file-created items and my UI-created model could be fixed we would genuinely have the best of both worlds.

6

That’s a thought but if the world is heading towards the UI then perhaps I’m making more problems for myself.

7

Yeah, I was sort of curious whether this is anything that is going to be fixed or could be fixed or whether I’d be waiting indefinitely. It is theway to get everything want and I’m not sure I understand why it doesn’t or can’t work.

There are some use cases (like my heating items) where files are simply easier but I don’t want to restrict myself to just files when the UI has obviously been developed for its ease of use.

8

Maybe. The way I see it is that, because it’s fairly trivial to import from files into the UI, but there’s no feature for the opposite way round, I’ve kept everything in files for now as I, like you, find it much easier to manipulate en mass.

Then, when the day comes that I’ve perfected my setup and won’t ever tinker with it again I can easily import to the UI…

9

But there you are mixing methods. The “model” is nothing more than a hierarchy of Groups and Items, with fancy metadata.
I’d guess initialization is going wrong somewhere, creating an Item/Group at bootup before the Group it wants to be a member of exists, or suchlike.

1 Like
10

The other thing to ask yourself is, of course, do you even need the model at all. The model, at present only has a select set of uses, and using it is by no means compulsory. If you use Habot, have come to rely on the preconfigured tabs on the home page, or use rules that specifically call some of the semantic functions, then you do need to put the effort into reconciling your items and the model groups. If, on the other hand, you use all your own custom widgets, or habpanel etc. as your UI and don’t really need the semantic information, then just drop the model for now.

The use of the model is growing and I’m sure there are very interesting directions it can go in the future, but maybe by the time there’s a model feature you really decide you need this issue will also have been cleared up.

2 Likes
11

LOL does that day ever come?!

3 Likes
12

Yup - I guess that is the nature of the problem but that doesn’t unfortunately get us anywhere near the solution.

13

That is a good point. The model is a good discipline but perhaps it might be easier to create my model using item files. I would hope that everything would work reliably then. I expect I’ll be using custom widgets. I haven’t looked at the semantic functions of rules but I do most of my logic programming using node red so I expect I won’t be using them.

I’ll give that some more thought.

14

I think that the main point is using only .items files is reliable. Using only managed Items is reliable. Using a mix of .items files and managed Items is not reliable.

There is no event created when an Item is created, removed, or modified nor when the Group membership of an Item changes so it becomes really easy for things like the model view in MainUI and the like to become out of sync when you have a mix of text configured and .items file configured Items.

To further complicate matters the information contained in one .items file entry can actually result in three separate entries in OH’s memory: the Item, Links, and Metadata. Again, there is no event generated when any of these are created, modified, or deleted.

Most of these problems really are not an issue when using .items files because each time OH unloads a .items file, it deletes everything defined in that file from its memory. Then it recreates everything anew when it loads the .items file.

When using managed Items, each Item, Link, and Metadata is managed independently. The UI will usually prevent you from doing something foolish and it does a good job of cleaning up (e.g. clearing out the Lijnks when you delete the Item). And since it’s the UI that’s doing it, it know what it’s done and can keep track.

Almost certainly not. The easiest way to create the model is as follows:

  1. Discover the Things
  2. “Create Equipment from Thing”
  3. Select the Channels and fill out the information for the Items to create.

Trying to retrofit a bunch of already existing Items into the model through the UI is not worth it. It’s incredibly time consuming and painful.

Trying to retrofit a bunch of already existing Items in a .items file into the model is also not worth it. You’ll be spending all your time trying to remember what tags mean what, Group names (the model after all is completely represented through Group membership and tags), fighting typos, syntax errors, accidental cyclical links, etc. Even a relatively small model becomes too big for someone to keep in their mind while working on the model.

NOTE: I rarely have to do bulk edits to Items that are not all associated with the same Things. In the UI you can manage this by:

  1. Navigate to the Thing
  2. “Unlink all and remove Items”
  3. “Create Equipment from Thing” and see above.

You could bulk “update” dozens of Items this way in just a few minutes.

NOTE: “changing” the name of an Item is really deleting the old and creating a new Item. As such, your rules will need to be updated and you will lose any persistence data associated with that old Item (this is the same in .items files or managed.

1 Like
15

@SimonB27 this is of course Rich (and others’) opinion. I disagree with all of the quoted text. Your mileage may vary.

1 Like
16

Everything I say is always my own opinion. However, having done it both ways and helping a number of people do it both ways, the benefits of using the model at all simply is not enough to justify the amount of extra effort required to define the model in .items files and especially does not justify trying to mess with Item membership in MainUI to build the model that way. It’s too much work for too little benefit.

You’d be better off skipping the model entirely and defining your own MainUI pages instead (or using HABPanel or BasicUI). It’ll be less work in the long run and you’ll be happier with the result in the end. If you really want MainUI’s Overview page, then the benefits of having the option to “bulk update” doesn’t justify the extra work required to build the model that way, especially since there are several ways to do bulk updates through the UI too.

17

I had similar issue in the past and that was caused by wrong semantic model setup.

While one item can be part of multiple groups, you need to make sure that one item is only part of one semantic group and all other groups do not have sematic metadata.

Maybe that’s helpful for you.

1 Like
18

ahhh… really really??? does that day ever come?
I mean nothing really to add here, great discussion gents but…
me thinks the day I’ve perfected my setup and don’t ever intend to change it is the same day they are throwing dirt on top of my casket :joy: :rofl:

19

Thanks for the thought Matthias. I don’t think it’s that because the semantic model was built using the UI and each location or equipment is therefore under just one other location. I’ll look again though.

I had a play with it last night, testing the idea of building a file-based semantic model using group items with location metadata in their own file. That seemed to work well and it appeared in the UI as it should with a couple of test items from my heating system items file placed in that model.

Trouble is I seem to have broken everything else and the other heating items in that file that don’t have semantic metadata and worked perfectly before, now don’t appear anywhere in the Openhab items list and don’t trigger any events in the log. I’m going to have to spend some time tonight fixing that!

20

Have a look, because the UI is not preventing you too add one item to several sematic groups.