Problems with Items/Location and Model in OH3

The quoted contents actually hasn’t really changed for 3.X in substance, it’s been valid for 2.X already.

The documentation clearly states that “It would work to mix these” (mix files and GUI) but it is not recommended. But as reported here in this thread and also here it does not work. It would be nice to get some feedback, if this is a bug which should get fixed or if it will stay that way.

Well, although people like to read it that way, docs don’t say that any form of mixing will work, does it ?
It does work if you always strictly use only either text or UI for a specific item but that you didn’t do when you started applying the model (via UI) to text-defined items.
So it is not a bug. Because of that and because it has been like that in years, in all likelihood it will stay.

EDIT: created a PR against the docs to clarify

Thanks for clarifying the docs! I’m still not sure I understand it though. You write: “You must not create an item using files and then make use of it in the model using the UI”
What is meant by “make use of it in the model”? I didn’t find any way to change items in the UI if they were created by file. And that is not the issue I have.
I create one item (including semantic tags) in file and one in UI. If the one from UI is a child of the one from file it works, but the other way round does not work. My current understanding from reading this thread and others is, that it it pure happenstance that one way currently works and the other does not, this could change at any time. If that is true I would expect something like this in the docs: “When using the semantic model, the whole model and therefore all items used in it must be created either in the UI or with files. Using both is not supported.”

You didn’t state your issue [it’s a bad habit to jump into ongoing threads] so I cannot comment on it.
And I don’t understand your statement at the end.
It’s right the same what my docs PR states, in other words.

But maybe the following explains it to you and others.

An item is dynamically created on startup, using either .items files or the system database as the source. Only this object in memory is being used in OH.
When you now apply the model via UI, that will store the tags and group membership in system database (jsondb), independent of where the basis (the item they belong to) was defined. When that was previously entered via UI, fine: model related changes will go to the same jsondb that the item went to when it was provisioned so on next startup the dynamic copies will both be reinstantiated from the jsondb at the same time.
But if you used a .items file to define the base item, tags will NOT be written back there.
This is the whole underlying point in text vs UI: OH is not capable of WRITING config to text files.

As the startup order is coincidential (is jsondb read first or is it the .items file ?), tags, when being read from jsondb, can be applied when the item was read before (either when it’s in jsondb, too, or because it’s in .items and that file was read before)
Else the tags cannot be applied because the basis to apply them to (the dynamically created item object in memory) is missing.

I should have stated that I have the same issue than the first poster, sorry for that.

The point is that neither the original poster (as stated in post #3) nor I change anything at the items in the UI which were created in a file. The semantic tags are added in the file as well. There is nothing which needs to be written back. I also don’t apply anything in the UI, I just look at the model tree.

When the dynamic loading of items is done at the start, there needs to be some mechanism to later match parent/child connections in the model if the parent is not yet there when loading the child, right? Otherwise it would not work if items are defined in different files which can be read at any order and the jsondb would need to be sorted to start from the top of the model tree to make sure the parent is always loaded first. But this mechanism which works, when everything is in multiple files, does not work when the parent is in the jsondb and the child in the file.
I assume that the reason it works the other way round (child in jsondb, parent in file) is just because for whatever reason, the files are loaded first. (And if this changes it would likely just be broken the other way round)

Shouldn’t think so. I thought tags for display purpose are just tags. This one’s tagged a Point “belonging to” Equipment X. No-one need to find Equipment X, or conversely find any Points belonging to X, until you display by model.

The underlying Item Group - member Item relationship should be working fine, regardless of load order or spread across files. Is that working?

1 Like

The group - member item relationship is working. But in the model tree the item is on the top level after OH restart. (As described in the first post you can get it back to the correct position in the tree with adding and removing bullshit to the file)

No there needs not. Your fundamental assumption is this is designed to work cross text+jsondb and some matching takes place but it is not. In short the answer to the OP’s question is that he did something wrong in making that very same false assumption.
Understandably so, but still a false assumption.

When tags are assigned in UI when you edit the model,they’re applied to the in-memory copy so an item gets “sorted” into the displayed tree. When you change the file that is much like a restart, causing this to happen again.

Any item only exists once in memory. It cannot be created or modified via UI if it existed in file at startup (that’s why it’s displayed as locked in UI). If you remove it from file, you can add it in UI/jsondb but if you then change file again and add it again you don’t actually fix anything. You are breaking the system in fact by messing with the internals.
Again: it is not designed to “match” anything.
That’s why you should use either UI OR files.

Technically, you could have a set of items in files and another set in jsondb if you don’t use the model or if you only ever use the same method in applying an item to the model that you used to create that item so technically, the old statement that you can mix is correct. But that’s highly confusing even to advanced users which is why it has never been recommended to do it like that. That is why I removed that sentence from the docs as it obviously is being misunderstood.

Of course it would, but every single item can only be defined once.

One last try: I do nothing in the UI with the item defined in file. I do not touch it at all. The only thing I do is look at the model tree and restart OH. And still it breaks. That is why I say you cannot mix at the moment.
Please have a look at this bugreport. It is very simple to reproduce:

  • Add a location group “test” in the gui.
  • Add a point in an item-file:

Number test_item “Test Item” (test) [“Measurement”, “Temperature”]

Look at the model tree, restart OH and look again at the model tree.

If this is expected/accepted behavior, we can close that bug as wont fix.

Bear in mind that a Group, whatever type, is still an Item in openHAB terms, so in this scenario an Item has been created in the UI, and is now being mixed with an Item defined in files.


@chaoshome frankly your explanation of what your issue is is lacking clarity (granted it’s twisted).
This, if I get it right, has nothing to do with tagging or the model.
Sure, effects show up in the model creation context, and you don’t know exactly how the model makes use of group as locations.
But ultimately it’s not about the model but about group membership in a generic sense:
you define an item in a file and already assign it to a group therein, too, although that group does not exist at the file processing stage (it is not defined in any of the files).
In parallel you define it in UI. Now load order becomes a factor.
So here, too, if you had stuck with the rule not to mix and had created the group in a file instead, I guess this issue would not have shown up.
The whole point about mixing is it works to have a file set and a UI set of items but only if there is no linkage between any two items that are in different sets.

I’m just explaining what’s happening.
Core developers will know better and only they can tell if they consider this a bug or expected.
But it’s not really model related and to the best of my knowledge has been like that forever.
And you can work around yourself.

  • Add a location group “test_group” in the gui.
  • Add a point in an item-file:

Number test_item “Test Item” (test) [“Measurement”, “Temperature”]

model tree looks like this:
restart OH
model tree looks like this:

If I look at the item in the UI, the group is still there. The only thing that is broken is the model.

The only workaround is to either define all items in the UI or all in file.

Yes the group is still there but the problem is that the item is no longer a member.
The model is a virtual overlay you cannot break. It is just specific tags and specific group memberships.

The group definition is broken because memberships are not defined in the same place as the group itself is.

Nope. Other workarounds are to not use the model, or to define all groups the model needs in files, or to define all items that are model related all in either UI or files. By far not every item needs to be part of the model.