Thing intialization problem while upgrading from 4.1.0 to 4.1.1 or 4.2.0

1

HI!

I’m struggling with several problems since 4.1.1 publlished.

First when I upgraded it was way too slow starting up just mentioned in this post. I have a beefy (192GB RAM, 12 threads) server with a hyper-V ubuntu guest which runs docker and several containers beside openhab.

I downgraded back to 4.1.0 all started to work except binding install status in marketplace page similar to this.
I managed to get bindings to display correct status in WebUI and in karaf installing them from console manually but I have all my things NOT_YET_INITIALIZED status constantly. Similar problem is here.
Note: While I investigated I found some file path error in usedata/config/org/apache/felix/fileinstall folder that the deploy.config file is not in its (fileinstall) subdirectory but it has a name of fileinstall%007edeploy.config. This might be a file name concat bug in source code but I have no time to investigate further. This does not produce any error or warning in logs and the same happens in the default install with 4.1.1.
Note2: I had some strange listing formats inside userdata/config/org/openhab/addons.config beginning with a comma. I removed these commas and the initial binding install was successful. I list my original file here:

:org.apache.felix.configadmin.revision:=L"94"
automation=",jsscripting"
binding="evohome,ipcamera,samsungtv,systeminfo,jellyfin,ntp,androiddebugbridge,fronius,network,logreader,miio,chromecast,astro,mqtt,unifi,http,exec"
includeIncompatible=B"false"
misc="openhabcloud"
package="standard"
persistence="rrd4j,jdbc-sqlite,influxdb"
remote=B"true"
service.pid="org.openhab.addons"
transformation="jsonpath,regex,scale,map"
ui=",basic"
voice=",googletts"

I’ve tried to add my not working astro sun thing again manually (just for testing) and it suddenly started to work but the original one had still NET_YET_INITIALIZED state. After pause/start cycle it changed to HANDLER_MISSING_ERROR state . Then I tested the same with my fronius binding which caused the same. I checked my thing config in json database and I found that my original thing channels has only numbers without unit definition and my new one has UoM defined.
Original:

  "fronius:powerinverter:9b8547c620:abb47a934e": {
    "class": "org.openhab.core.thing.internal.ThingStorageEntity",
    "value": {
      "isBridge": false,
      "channels": [
        {
          "uid": "fronius:powerinverter:9b8547c620:abb47a934e:inverterdatachannelpac",
          "id": "inverterdatachannelpac",
          "channelTypeUID": "fronius:pac",
          "itemType": "Number",
          "kind": "STATE",
          "label": "AC Power",
          "description": "AC power",
          "defaultTags": [],
          "properties": {},
          "configuration": {}
        },
...

New:

  "fronius:powerinverter:d1aaff817e:25f8ce3580": {
    "class": "org.openhab.core.thing.internal.ThingStorageEntity",
    "value": {
      "isBridge": false,
      "channels": [
        {
          "uid": "fronius:powerinverter:d1aaff817e:25f8ce3580:inverterdatachannelpac",
          "id": "inverterdatachannelpac",
          "channelTypeUID": "fronius:pac",
          "itemType": "Number:Power",
          "kind": "STATE",
          "label": "AC Power",
          "description": "AC power generated by the inverter",
          "defaultTags": [],
          "properties": {},
          "configuration": {}
        },
...

So I’m just guessing but may the introduction of UoM changes lead to this? Is there any simple method to repair any undefined UoM states in my json database for my things, items, etc?
I saw that my update.log contains these lines:

Starting JSON database update...
[main] INFO org.openhab.core.tools.internal.Upgrader - Already executed 'itemCopyUnitToMetadata' on 2023-07-25T08:31:38.170672096+02:00[Europe/Budapest]. Use '--force'  to execute it again.
[main] INFO org.openhab.core.tools.internal.Upgrader - Already executed 'linkUpgradeJsProfile' on 2023-07-25T08:31:38.179227054+02:00[Europe/Budapest]. Use '--force'  to execute it again.
JSON database updated successfully.

Can I repeat this manually? From console or karaf shell? How can I check it the UoM update has really worked? Is there any log settings that displays UoM errors in general?

Any further help would be appreciated as I has 137 things and 677 items that I don’t feel the urge to redefine all via webUI.

P.S.: Right now as I’m writing this some of my things 40-50% of them changed to ONLINE. This happened in 20-30 mins range from openhab startup. Another strange thing is that half of my MQTT things are ONLINE, half of them are still NOT YET READY.

2

I can’t see how. All the UoM changes only impact Items, not Things or bindings.

UoM only can be “repaired” for Items. And the repair is really more just fixing an Item that is defaulting to the wrong unit. It’s not going to cause Things to not come online or any of the other problems you’ve reported.

To summarize, any Number Item with a Dimension will now use the system default as the Item’s unit if there isn’t unit metadata defined on the Item. That’s it.

The first line automatically added unit metadata to Items that had a State Description Pattern that defined a unit or based on the unit the binding reports it publishes.

The second line deals with the JS Scripting transformations used in the transform profile. Briefly between OH 3.4 and 4.0 the syntax changed for the Script profile to make the syntax compatible with the old JS Transformation syntax. This line changes that old syntax to the new/older syntax.

Yes, by running the upgradeTool which you can find in that tool in OH’s bin folder.

java -jar upgradeTool.jar

But these are not the source of your problems.

Look at events.log. If the “Item foo changed from blah unit to blah unit” (e.g. Item 'RichsOfficeSensors_Humidity' changed from 32.6 % to 32.5 %) shows the Item changing to the unit you expect, it worked. If the unit isn’t what you expect, you need to manually add the unit metadata to that Item.

Yes, there will be an error in the log if there was an attempt to update an Item to a unit that is not supported by that Item’s Dimension (e.g. tried to update a Number:Power with 45 °F). In all other cases, there won’t be an error. If there is no unit in the update, the default unit for the Item is assumed. If the unit in the update is different from the Item’s default, the value is converted to the Item’s default. The unit is removed from Number Items without a dimension.

Note that the upgradeTool only works with managed configs. If you have all text file based configs, the upgradeTool does nothing.

But even so, nothing the upgradeTool does not anything you may have done with UoM is the root cause of any of the problems that you are reporting.

I cannot guess waht the root cause of your problems might be but the first thing I would try is clearing the cache. Something us up with the bindings and clearing the cache causes the bindings to be reinstalled.

3

Thank you for responding!

I would try is clearing the cache

That was my first attempt and I did several times in each versions that I’ve upgraded to (4.1.1, 4.2.0).

I can’t see how. All the UoM changes only impact Items, not Things or bindings.

I was just guessing based of my observations. My original things do not initialize correctly but if I add the same thing again (duplicate) the new one worked. So I looked at the json database org.openhab.core.thing.Thing.json file and I found the difference I’ve listed above in the channel definition section. No links added and no new items defined with the new thing. So the only difference was:

"itemType": "Number",

changed to

"itemType": "Number:Power"

Some of my channels has no unit defined (all my generic mqtt things that I added myself in back on version OH 2). I just thought that it might have some relation to UoMs.

I appologise for my above resoning but I’m really afraid that I need to enter everything I’ ve done thgoughout the years I’ve been using openhab. (I’ve not done any file based configuration only WebUI.)
So can you give some advice which path should I take to investigate further? How to make logs more verbose to display more errors or warnings of the slow and unsuccessful initialization of my things?

Edit: I’ve found in log4j2.xml these lines that I’ll turn to DEBUG to reveal some clues:

		<Logger level="DEBUG" name="openhab.event.ChannelDescriptionChangedEvent"/>
		<Logger level="DEBUG" name="openhab.event.ThingStatusInfoEvent"/>
		<Logger level="DEBUG" name="openhab.event.ThingAddedEvent"/>
		<Logger level="DEBUG" name="openhab.event.ThingUpdatedEvent"/>
		<Logger level="DEBUG" name="openhab.event.ThingRemovedEvent"/>
		<Logger level="DEBUG" name="openhab.event.StartlevelEvent"/>
		<Logger level="DEBUG" name="openhab.event.AddonEvent"/>

This might give some info on this. Am I correct?

All help is appreciated.

4

Probably not. That is just the event bus. It will tell you when events occur and what those events are. But to know what the bindings are doing you need to change those to debug level logging. You can change <Logger level="INFO" name="org.openhab"/> to DEBUG or TRACE and will put everything into debug or info level logging. Or in MainUI you can navigate to Settings → Add-on Settings → MQTT (for example) and change the logging level for just that one binding there.

5

It seems like you and I are the only ones with this problem. Very strange! But thanks, I’ll try to make a separate OH installation and test it

6

In the first post linked several topics that seem a lot like mine (or yours). And it looks like it all comes together somehow. Right now I’m planning to set TRACE to org.openhab and dig deeper but I have only limited time currently.

7

As soon as I have a little more free time, I will definitely join the search for a solution! In the meantime, hope is only for you!

1 Like
8

I have same problems! Windows 10 pro on NUC computer 16/256. One thing that I react on is why does not briges load first? Maby I am a bit confused ( 69 year) but trying to keep up. Have used openHAB sens version 1 and I love it. Normaly love smal challenge but here I hit a stop. Sorry bout my English ( blame my age :slight_smile: )

9

Right now I have migrated to a separate Hyper-V guest of debian and installed openhabian as described in the manual. All is working at 4.1.1 with no delay or lag, response times are lot less on WebUI and all of my rules.

What comes to my mind is that my previous setup (see post 1) inside docker with a host mode networking there were almost 20 network cards available for openhab. Each other container NIC was listed inside openhab container. So UPnp/IP/etc discovery might took so much time that it was a significant (15-20 min) delay to reach system boot level 100 keeping my things at NOT_YET_INITIALIZED state. (I even tried to specify only my main IP address for OH and turn off discovery services but did not work.) This might need some research to start up openhab alone on a docker host, spin up several other containers and measure startup times for openhab.

This is for future reference for others searching for some workaround.

10

I have two physical network interfaces (there are also virtual Hyper-V and OpenVPN), but the problem remains. On another machine there are a dozen different interfaces and there are no problems. But it seems to me that you are thinking correctly. I wonder how to completely disable searching for devices on the network (new functionality).

11

You can disable the UPnP and mDNS suggestion finders from the UI, Settings->System Settings->Add-on Management->Advanced.

Alternatively you can do it in a config file, see here: UNSUCCESS: openHAB updated from 4.0.2 to 4.1.0 on docker - openhab unresponsive - #16 by Mherwege

mDNS has always been running, also in previous versions of OH, and the suggestion finder does not do active scanning, only listens to what was already happening. That is different for UPnP where an active scan is triggered by the suggestion finder.
If disabling the suggestion finders does not make a difference, these suggestion finders are not the cause of your issue.

12

but what is the reason, how can we (who have the problem) solve it? :sleepy: :sleepy: :sleepy: :sleepy: :sleepy:

13

I understand. And I don’t know what the cause of your issue is. I see a lot of unfounded pointing to the new suggestion finder functionality to be the cause of this, and I offer a way to completely disable it. That allows to validate if it is the cause, or to exclude it as a cause.

14

For me it seems to be Network Binding problem. If I uninstal it all is ok. Instal it again and same delay in startup.

15

I stumbled on those settings just before reading your post, and turned them off. When I next went to the add-on store, most of my bindings started showing up again in the store.
Maybe I got lucky with the timing, but you may be on to something.

The TP-link binding was installed before upgrading Openhab from 4.1.1-1 to 4.1.2-1, but if I search for it manually in the store, it still shows as uninstalled atm. Perhaps it’ll resolve itself in the next few minutes as well…

EDIT: I got impatient, and just clicked “install” in the store, and my TP-Link Kasa devices started working again. :man_shrugging: