No proof at all to me but if it is to you then this means the problem is somewhere else.
So go ahead and continue searching for a solution.
If openHAB is coming up at all this isnât an OS nor a Java issue. If MainUI is coming up at all, this isnât an OS nor a Java issue.
You may want to or need to upgrade the OS to Trixy at some point, but I donât know that this is the root cause of the problems you are seeing right now.
Thatâs normal. OH has a self signed certificate which was not issued by a trusted certificate authority. But you can click on âshow advancedâ or something like that and youâll have the option to load the page anyway.
It may work to go to Bookworm but if you try to keep upgrading that way all the way to Trixy, in my experience, at some point the networking will break and youâll have to install it from scratch anyway. That a big reason why apt doesnât update between OS versions like you expected. There are breaking changes between OS versions which can cause havock to end users.
So if you do want to upgrade the OS, which I would recommend, I suggest taking backups of your configs, burning a new SD card with the latest openHABian (which is based on Trixy) and then restore your configs to the new install.
How do you figure? That means that something prevented all components from starting, probably some bindings/ThingHandlers. Iâd say that is very likely to be related to why the Things wonât display.
From where did you get the idea that he uses HTTPS? If heâs not, port 8443 wonât work. I would suggest trying 8080 instead.
Start level 70 is an indicator that some things cannot go online (e.g. wrong IP, missing credentials, gateway/bridge not accessible).
The problem of the user is something completely different. See screenshot above.
Itâs not really an indication of just that. Itâs an indication that âall bindings didnât complete successfullyâ or something like that. The startlevel never got the âOKâ to proceed to the next level. So, the exact problem that prevents the startlevel from proceeding can vary. Iâve seen the Thing UI screen fail to load for this reason several times. It seems to depend on exactly how the binding failed. Iâm not saying that itâs ideal, MainUI could probably handle this better than just being stuck in the âloading pictureâ. But, Iâm pretty sure that if logs are examined, a binding problem can be found, and if that is either resolved or this binding is disabled, the startlevel will reach 100 and the UI will âstart working properlyâ.
From where did you get the idea that I think he uses https?
He does not use https as can be seen above.
Are you reading the thread? It is now the third time I am referring to an answer for you to an information provided above.
No, not at all. Again, if you look at the log provided above (sic) there are tons of reasons in there why start level cannot be 100.
That being said, it does not mean that on top of that there is a binding which causes some more problems.
Because you asked him to use port 8443 - which is used for HTTS, not HTTP.
Yes, I asked him to try with https because he was using http. Whatâs the point here?
Going further with the advance only gives a option to enter the page in non secure way. Which is the same as http
That might also be the solution here. But I sure want to find the reason for this cause first.. I will try disable some of the bindings as Oliver suggest earlier.
I thought you were trying to resolve the problems heâs experiencing, not introduce new issues to confuse. I just didnât understand why you would drag HTTPS and certificate errors into all this. HTTPS doesnât magically make anything better, itâs just the same HTTP traffic that is encrypted, and can only every cause more problems - except in the few situations where browser developers intentionally disable stuff over HTTP - which is rare, but do exist, but seems unlikely to be relevant here.
I donât think I understand what your goal is. Yes, Iâve read the thread, and Iâve read it onec again now since you keep insisting that I havenât. There are however many things going on today, so my memory isnât aways able to keep everything clear, and I donât always read to the bottom before I answer something if I think I see something relevant. That can be impractical because the answer may have been posted further down, but if I donât do it, I risk forgetting about the issue before I reach the bottom - and even if I donât forget it, I might not find back what I wanted to reply to. I wish I could âtag things for repyâ as I read, and then hande them all once I reached the end of the thread, but thatâs not how it works.
As the log shows, there are some more or less âseriousâ issues with some of the bindings, especially lgthinq:dryer-202:4bb559ca4d:a6fc6dc7-34e8-147a-8f50-44cb8b0819e7 seems like it has problems that go beyond simple configuration problems. I would try to disable the binding for this, and see if the UI starts working.
To repeat myself, Iâve seen this exact behavior when bindings fail to propery initialize (not the Things, but the bindings themselves), so I still think that thereâs a good chance thatâs the reason why the UI misbehaves.
I did some log study.
There are some issues in the log. But the log doesnt specific say which binding.
Looking at the errors, its at least 4 bindings or channels/links which has errors I have not seen before the OH update. But, for some reason I doubt these are cause by the binding, as two of them for god know what reason have found new Things in the inbox, Things which are equal to the things already installed. I would assume a binding failure wouldnt be able to find ânewâ Things.
Thats why its rather tricky this one.
Even though this isnât properly âfact basedâ, I feel like the errors reported for lgthinq:dryer-202:4bb559ca4d:a6fc6dc7-34e8-147a-8f50-44cb8b0819e7 indicates a problem on âa binding levelâ more than the others. Isnât it reasonable to believe that it is supplied by some âLGâ binding? I would try without that binding first.
I just stopped all the obvious bindings which indicate some kind of failure in the log, including the lgthinq, one by one.. Its still the same issue.
And just a few seconds ago I stopped all (19) bindings which has been installed for my devices, (there are a huge amount of bindings which has nothing to do with devices).
Still the same issue..
Does stopping the bindings allow the startlevel to proceed to 100? Otherwise, Iâm thinking that you might need to disable the problematic binding and restart OH to hopefully get the system to initialize properly.
I think thereâs a way to disable select bindings using services.cfg, but I think that can easily cause a mess if youâre not already using that file for controlling add-ons. I usually just uninstall the binding in question when I want to troubleshoot (without deleting Things/Items etc.), Iâve never experienced that I have to reconfigure anything when I later install the binding again - but I canât know for sure that this is always the case for all bindings, obviously.
I didnt check that..
I did wonder if I had to uninstall the bindings rather than just stopping them.. Its a bit of a pain going through the bindings in karaf console 
Startlevel is probably a bad indicator here anyway, because it can mean so many things. Simply a misconfigured Thing can cause it to not proceed, so it probably wouldnât have proceeded even if stopping the binding âwas sufficientâ. Iâm pretty sure that, if this is caused by a binding problem, that itâs just one - so the clue is to figure out which one.
Do you have an idea, what this is:
2025-12-28 23:57:39.807 [ERROR] [.converter.ZigBeeConverterColorColor] - 0017880100FF3D87: Error 0xffff setting server binding
2025-12-28 23:57:39.813 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880100FF3D87: Channel zigbee:device:9b4aa8145e:0017880100ff3d87:0017880100FF3D87_11_color failed to initialise device
Not beyond that itâs the ZigBee binding that has some trouble. The first line sounds a bit strange, and could perhaps indicate a problem with the binding. The second line is just a consequence of the first, Iâd guess.