I have made the update from OH3.2 to 3.3.
Had to recreate my Netatmo binding as well.
Unfortunately, the update also seems to have broken my whole Semantic Model.
Subgroups are missing or invisible, some have been moved to the top branch.
I was now able to recreate the problem in a virtual machine.
There were no noticeable errors during the update process so far.
Tested with:
Raspberry Pi 4B
VM with Debian 11 64bit
Is it possible to straighten this out or do I have to start everything from scratch now?
Itâs hard to say. We donât know what the model is supposed to look like and we donât know how you created the Items. What specifically do you mean by ârecreate Netatmo binding?â You had to recreate the Things? Did you ensure the Things kept the same UIDs? Did you have to recreate the Items? How did you recreate the Items?
-> Floor
--> Room
---> Things
----> Items of Things
-> Floor
--> Room
---> Things
----> Items of Things
The Locations âBadâ, âFlurâ, âHeizungâ, âKuecheâ, âSchlafzimmerâ, âWohnzimmerâ are completely wrong.
For example, I am also missing the second floor and the first floor as a whole.
However, all items are still present.
The new creation of missing locations does not work, because they are supposed to already exist.
The Netatmo binding has changed, so it was recommended to recreate all of it.
I was just about to set it up when I noticed the problem with the model.
It probably has nothing to do with the actual problem here for now, I just wanted to note it.
The Semantic Model is built using Groups with special tags. So you would have a Group with a âFloorâ label of some sort. Youâd have a second Group that is a member of the âFloorâ Group with a âRoomâ Tag.
There are no such thing as Things in the Semantic Model. What you have is a Group Item with a proper Equipment Tag. Then the Items that are linked to the Channels of the Things will each have a proper Point and optional Property tag and they will be a member of the Equipment Group Item.
Itâs all Items. The hierarchy is defined using Group membership. Whether an Item represents a Location. Equipment, or Point is done using the Item tags.
So you will have to go through all your Items and make sure the Group memberships are as you expect.
Okay I think we have misunderstood each other here.
My setup was as follows:
- House
-- first floor
--- Heater
--- Bathroom
-- second floor
--- Kitchen
--- Livingroom
-- third floor
--- Livingroom
--- Kitchen
--- Sleepingroom
-- Attic
-- Staircase
-- Outside
-- Testarea
- Other
-- Some stuff
What is missing now?
The subdivision per floor is completely gone.
The living room on the second floor is gone.
The groups of Things it contains are also gone.
By gone / no longer present I mean invisible, because the Things are still all present in the system.
All other âroomsâ have been pushed to the top branch of the tree.
What seems to be still correctly present are the assignments to âOtherâ and everything at âOutsideâ.
But since no answers have come here now according to the motto âOh the error is knownâ, I am probably once again a single case?
I could also reproduce the problem in a VM, so I exclude a single case but ehr.
Unless there is something to salvage here, how can I really cleanly remove the current model and start a new one?
The configuration of your system is still unique to you, so yes, this is likely a single case. So we have to know about your system. There are many known reasons why items disappear from the model page and probably many more unknown. Each one has a different cause and solution.
We canât really give you specific help until we understand both your system and the problem. Unfortunately, OH is a very complicated program and so for us to be able to communicate about the problem we all have to be very precise. You simply cannot have a âgroup of Thingsâ, that is an impossibility in OH because group and thing have very specific meanings which are not compatible.
So we donât yet know what you mean. Perhaps looking through this will help you:
This is not case; you have gotten responses from two top contributors here who have helped answer thousands of questions combined. There have been several attempts at answers even though we still only have partial information. If you want more specific answers than you need to provide more specific information.
This is where the details of YOUR system some into to play. You will notice that both of the answers rely on details that are specific to how you built and configured the system. There is a difference between just telling us vaguely what it should look like and telling/showing us the configuration you have done to make it look like that.
Iâm sure it is possible, but give us more and be as precise in your terminology as you can so that we can help you.
What sort of information do we need?
Did you use the UI or items files to create all these items in the first place?
Can you find these missing location items in the items page? If so can you show us the configuration from the item details page?
Are there errors in the browser console? What do they say?
Have you noticed if the missing rooms all contain items linked to one particular binding? Other than netatmo, what other bindings do you use?
We know you have a vm running debian, but nothing else about your system. Has your java version changed recently? How did you install OH in that vm?
You CANNOT share too much information. If thereâs a bit thatâs not helpful we can ignore it, but we cannot guess at information that is not there.
It might help to re-review the Concepts section of the docs so we are all using the same terms for the same things. Perhaps skim through the first few pages of the Getting Started Tutorial as well to reinforce the relationship between binding, Things, Channels, Items, and the Semantic Model.
I also asked a bunch of questions in my initial reply that you never answered. We tend not to ask rhetorical questions. If we ask, we expect an answer. Not answered from my first replay:
Did you ensure the Things kept the same UIDs?
Did you have to recreate the Items?
How did you recreate the Items?
Something went wrong and we need a ton more details from you to understand where things went wrong. At this point, itâs like taking a picture of your car to a mechanic and saying âitâs making a weird noise, can you tell me how to fix it?â
Hi @all,
I got the exact same problem after the update.
It seems, that the problem is based in the name of groups and items. I got a few errors like this:
2022-08-03 20:38:08.280 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add âNumberItemâ with key â1OG_MotionSensor_BatLvlâ: The specified name of the item â1OG_MotionSensor_BatLvlâ is not valid!
after reboot.
So a Number as the first character for an ID is not allowed anymore.
In my understanding itâs necessary to create the groups and items with a new ID, because restoring a backup will not work out without the ability to change the ID.
Maybe its easier with the backup, because the model is correct and you can change the parent group.
Or does anyone has another better idea?
Cheers
Hannes
PS: I defined everything via UI.
The Items are missing in the Items page as well as the semantic model.
It was never allowed (I donât know the specific technical problem but itâs been in the docs since OH 1.x). Itâs just now that checks were put into place to ensure that such Item names are rejected instead of leaving them to cause what ever problems these Item names cause.
You have a few options to deal with it. But ultimately you cannot really rename an Item, only delete and recreate it. Since the Item doesnât appear in the UI, youâll have to either use the API Explorer or the karaf console to delete the old Item(s) that start with a number. Then you can recreate them without the leading number as the first character.
You could search through your jsondb files and edit them by hand but given these are just semantic model Groups and likely not used anywhere else, itâll be just as fast and safer to do it by deleting and recreating.
@JustinG
Did you use the UI or items files to create all these items in the first place?
I use the UI
Can you find these missing location items in the items page? If so can you show us the configuration from the item details page?
Yes all items are still there
Are there errors in the browser console? What do they say?
No errors in the browser console
Have you noticed if the missing rooms all contain items linked to one particular binding? Other than netatmo, what other bindings do you use?
No i use a view Bindings like Bose, MQTT-Broker, ExecBinding, Wifi LED Binding, âŠ
We know you have a vm running debian, but nothing else about your system. Has your java version changed recently? How did you install OH in that vm?
Yes the VM did a java-update. I ran this first and was able to use openHAB normally afterwards. After the Java update everything was still normal. I have installed openHAB via repository. (apt install openhab âŠ)
Did you ensure the Things kept the same UIDs?
They should have kept the same UIDs. I have not checked this, as I cannot remember them all 100% accurately.
Did you have to recreate the Items?
No, I have not done that yet. I wanted to know first if you can still save something here before I set up everything again.
@HannesFE
I think you just found the error.
I have the entries too. 2022-08-03 15:36:53.123 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "GroupItem" with key "3OGKueche": The specified name of the item '3OGKueche' is not valid!
As @rlkoshak already wrote, you should not be allowed to start IDs with a number.
But you can do that via UI and openHAB seems to have no problem with that.
But as it looks, openHAB has a problem with version 3.3.
In fact, I started my floor subdivision with a number in the ID and - I need to check this first - probably on one or two other items as well.
There is a PR that fixes that to prevent it in the works already. As I said, itâs not been allowed since the beginning but itâs never been enforced.
This isnât related to the Semantic Model problem but it could be a different problem. Go to the Thingâs page, click on Channels. All the Channels that are successfully linked will have a blue dot with a 1 in it (or 2 or three if it happens to be lined to more than one Item). If it does not then your Things were created with a different UID (most Thing UIs contain a randomly generated segment so if you didnât change the ID when accepting the Thing from the Inbox it likely has a different UID.
That is part of my confusion. When you said regarding Netatmo âit was recommended to recreate all of it.â it wasnât clear if that meant Items or, you perhaps did not understand the link between Items and using âCreate Equipment from Thingâ which generates Items for you.
But I think you probably have found your root problem. You cannot start an Item with a digit, only a letter. See my post above for how to recreate these location Groups. You donât necessarily need to delete the old ones but if you want to get rid of those errors in the logs youâll need to.
Okay, I hope the fix goes live soon.
Otherwise, probably more people run into the error, which do not know.
As a simple user, you use the UI to set up everything conveniently - bang - itâs broken after the update.
I just checked, the channels are still linked, even for those that are no longer visible in the model.
I only wanted to mention the problem with Netatmo briefly to rule out the possibility that it could be due to a broken binding.
Then I will probably now given to work and build my model from scratch.
Too bad, that now needs a few hours time.
Comment, for info only - invalid Item names beginning with digits have been seen to cause âmysteriousâ problems with DSL rule triggers, old-style sitemaps, and persistence services.
All of those are difficult issues to solve until someone reveals/spots the invalid name, so I for one welcome the new stricter validation
So just to understand what happened: is it correct to say that the âsemantic model messâ of the OP was caused by item names starting with a number (which was forbidden long before OH3.3, but not enforced until now)?
This only happens to people that didnât read the docs.
Yes we all are lazy or inattentive at times and yes itâs a lot of work and stressful keeping up but if you get hit by something that you would have avoided by reading the docs, itâs your very own fault. Donât account this to anyone else but yourself, please.
Itâs extremely hard for developers to determine and document all the no-gos, and impossible to wrap a complex system like OH in code or UI that catches any bad input.
yes, and if you are caught up in this trouble, see post 10 above. I also posted how to delete and recreate theses on the 3.3 release thread where I provided a bit more detail.
@rlkoshak
I have now recreated the linked channels of the no longer existing locations, so that openHAB is usable again.
So far it seems to work again.
I havenât looked directly into the JSON data yet to see if there are any leftovers there.
@tophee
That is correct. Apparently I am also not the only one who had the problem now. Stupid but happens.
Donât want to know how many out there now also have this problem.
@mstormi
That is correct. I made the mistake and also really did not read the docs. Therefore I am also to blame for the error.
The stupid thing is that I always find such mistakes in the stupidest way.
Even if the development of everything is difficult and takes time, some parts need to be build idiot-proof, so that something like this does not happen again.
So I think itâs good that such errors - even if self-inflicted - are revealed, so that in the future the openHAB users are protected from it
A developer does not have the idea to start an ID with a number, because he knows the problem.
A stupid user like me however can do it. ÂŻ_(ă)_/ÂŻ
Therefore, I can now say that through the tip of @HannesFE the error was found and the system is now running again.
Therefore, thanks to all for the input.
Iâve seen a similar problem which is related to the order in which openhab reads the files.
Imagine you define a location Foo in âa.itemsâ and an item Bar in âb.itemsâ and of course Bar is supposed to be in location Foo.
Sometimes openhab will read a.items before b.items and sometimes the other way around. If âb.itemsâ is read first, you will end up with a broken semantic model where everything is showing in the root of the tree.
The only way to work around this is to restart openhab rather than mess with the files while itâs running as at least the items are read in alphabetical order in start-up.
