openHAB 4.0 Milestone discussion

rlkoshak · June 27, 2023, 4:39pm

helmar74 · June 28, 2023, 6:32am

Hi,

I upgraded my Testsystem to OH4.0.0 M3.
After that all my ZWave Door/Windows sensor doesn’T work anymore.
Here’s the errormessage in openhab.log:

2023-06-28 06:18:54.942 [WARN ] [core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'zwave:shenzhen_doorwindowsensor_00_000' for thing 'zwave:device:020e4758:node30' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
2023-06-28 06:18:54.944 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'zwave:device:020e4758:node30' because the thing type was not found in registry.
2023-06-28 06:18:54.954 [WARN ] [core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'zwave:shenzhen_doorwindowsensor_00_000' for thing 'zwave:device:020e4758:node32' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
2023-06-28 06:18:54.956 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'zwave:device:020e4758:node32' because the thing type was not found in registry.
2023-06-28 06:18:54.965 [WARN ] [core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'zwave:shenzhen_doorwindowsensor_00_000' for thing 'zwave:device:020e4758:node31' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
2023-06-28 06:18:54.967 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'zwave:device:020e4758:node31' because the thing type was not found in registry.

I guess the device is missing in Zwave Device registry?
Has someone an idea to get them back to operation?
They were working well in OH 3.4.4 production system

My sensor looks like this one:

It look’s like the device is recognized with a other type in OH4.0.0 M3 as in OH 3.4.4.

Where can I change that the sensor are recognized as shenzhen_nasds01z_00_000 and not as “zwave:shenzhen_doorwindowsensor_00_000” ?

Created this issue also in addon discussion:

Edwin_de_Boer · June 28, 2023, 7:17am

Hello Nelson,

Looks a lot like how Node-Red is working, I think.
I’m currently migrating from the .rules to Node-Red!

helmar74 · June 28, 2023, 2:15pm

Fixed it by Recreating ZWave Things

helmar74 · June 28, 2023, 2:32pm

Hi again,
next issue is upcoming
Some of my Fritz!DECT 200 Wall Plugs are in state UNKNOWN, some are Online and are working.
Here’s the logoutput during startup:

2023-06-28 16:12:06.355 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.368 [ERROR] [.update.UpdateChannelInstructionImpl] - Failed to create channel 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX:power' because channel type 'system:electrical-power' could not be found.
2023-06-28 16:12:06.369 [ERROR] [.update.UpdateChannelInstructionImpl] - Failed to create channel 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX:voltage' because channel type 'system:electrical-voltage' could not be found.
2023-06-28 16:12:06.370 [INFO ] [core.thing.internal.ThingManagerImpl] - Updating 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' from version 0 to 1
2023-06-28 16:12:06.410 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'kodi:kodi:9849245e' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.414 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'kodi:kodi:9849245e': {thing/channel=Type description kodi:volume for kodi:kodi:9849245e:volume not found, although we checked the presence before.}
2023-06-28 16:12:06.466 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_210:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.469 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.476 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.483 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:06.488 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'avmfritz:FRITZ_DECT_200:192_168_1_1:1XXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:08.493 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'amazonechocontrol:echo:1XXXXXXX:GXXXXXXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:08.495 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'amazonechocontrol:echo:1XXXXXXX:GXXXXXXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-06-28 16:12:08.499 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'amazonechocontrol:echo:1XXXXXXX:GXXXXXXXXXXXXXXX' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.

The working devices show the same configuration and firmware version as the unknown devices:

Anyone an idea, what’s going wrong here or what I can check and do to fix it?

helmar74 · June 28, 2023, 3:07pm

I tried re-adding the unknown things, this didn’t solve the problem…

mstormi · June 28, 2023, 4:48pm

Please respect that this thread is to collect and discuss systemic issues with milestone builds, it’s not for your personal singular issues. Please open separate threads for your needs.
Thank you.

helmar74 · June 28, 2023, 5:09pm

Hi

Sorry but IT Isn’t a Personal issue.
IT was working in 3.4.4 and wit Oh 4.0.0M3 Not.
So I assume it’s an issue with current Milestone when updating from 3.4.4

I think more User will Run into this issue and it’s good for them to know upfron

Regards and sorry for them circumstances.

hmerk · June 28, 2023, 7:26pm

I agree with @mstormi, your issue is not Milestone related but seems to be a binding issue. Therefore it would be better to open a separate topic for this.
Please provide some more information in the new topic, like OS, Java version, how did you upgrade, did the upgrade script complete without errors…

helmar74 · June 28, 2023, 8:23pm

Opened

helmar74 · July 2, 2023, 4:57pm

Just updated to OH 4.0.0. Unknown AVM DECT 200 Things still present.

helmar74 · July 2, 2023, 5:04pm

Updated from OH4.0.0M3 to OH 4.0.0M4.
I don’t see any status changes in event.log and I don’t see “Rule engine started” message in openhab.log

I cleaned the cache, than “Rule enginge started” was shown and startup was normal.
After restarting again, “error” is back again. No status changes in event.log and no “Rule enginge started”

When Restarting (after pressing enter) this is shown in openhab.log (at shutdown phase):

---------------------------------------2023/07/02 19:20:18--------------------------------------2023-07-02 19:22:34.685 [INFO ] [nal.ScriptEngineFactoryBundleTracker] - All automation bundles
ready.
2023-07-02 19:22:36.312 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2023-07-02 19:22:39.171 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Stopped HABPanel
2023-07-02 19:22:39.224 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2023-07-02 19:22:40.736 [INFO ] [control.internal.WebSocketConnection] - Web Socket close 1006.

So it looks like OH 4.0.0M4 is not starting correctly…

Mark_VG · July 2, 2023, 5:04pm

The Phillips Hue V2 API Binding is not listed in the release notes. Is this an oversight?

helmar74 · July 2, 2023, 5:15pm

I set to german localisation:

2023-07-02 19:08:05.950 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.0.0.M4 (build Milestone Build)
2023-07-02 19:08:07.602 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
2023-07-02 19:08:07.612 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to '48.5744853781016,12.580565571261104'.
2023-07-02 19:08:07.615 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'de_DE'.
2023-07-02 19:08:07.618 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'SI'.

But Timestamps are in englisch in sitemaps:

Must it be configured anywhere else?

helmar74 · July 2, 2023, 5:53pm

I figured out more.
I stopped the Telegram and Openhab Cloud Bundle, as it is causing trouble with my production system.

openhab> bundle:list | grep Reso
245 │ Active   │  80 │ 4.1.92.Final           │ Netty/Resolver
278 │ Resolved │  80 │ 4.0.0.M4               │ openHAB Add-ons :: Bundles :: Telegram Binding
292 │ Resolved │  80 │ 4.0.0.M4               │ openHAB Add-ons :: Bundles :: IO :: openHAB Cl
openhab>

If I restart Openhab Cloud bundles in console, the system remains startup and start’s correctly.

That’s really a strange behaviour.
Screenshot after restarting OH 4.0.0M4:

Restarting Openhab Cloud Bundle:

Afterwards it looks like OH 4.0.0M4 is operating normal.
(Rule engine is working and status updates for items are received.)

J-N-K · July 2, 2023, 6:04pm

Can you please check the openHAB start level: Developer Tools/API Explorer/systeminfo/GET systeminfo/Try it out/Execute?

JustinG · July 2, 2023, 6:21pm

I get the following fatal error when trying to start a container with the M4 docker image:

Launching the openHAB runtime...
./runtime/bin/karaf: 247: [: Illegal number: 
./runtime/bin/karaf: 247: [: Illegal number: 
./runtime/bin/karaf: 97: [: Illegal number: 
./runtime/bin/karaf: 300: [: Illegal number: 
-Djava.endorsed.dirs=/usr/lib/jvm/temurin-17-jdk-amd64/jre/lib/endorsed:/usr/lib/jvm/temurin-17-jdk-amd64/lib/endorsed:/openhab/runtime/lib/endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

M3 image still works just fine.

helmar74 · July 2, 2023, 6:22pm

Hi sure:
First I restarted the Cloud Bundle:

{
  "systemInfo": {
    "configFolder": "/etc/openhab",
    "userdataFolder": "/var/lib/openhab",
    "logFolder": "/var/log/openhab",
    "javaVersion": "17.0.7",
    "javaVendor": "Raspbian",
    "osName": "Linux",
    "osVersion": "6.1.21-v8+",
    "osArchitecture": "arm",
    "availableProcessors": 4,
    "freeMemory": 556943528,
    "totalMemory": 912916480,
    "startLevel": 100
  }
}

Than I restarted OH 4.0.0M4, it looked like this during “error condition”:

{
  "systemInfo": {
    "configFolder": "/etc/openhab",
    "userdataFolder": "/var/lib/openhab",
    "logFolder": "/var/log/openhab",
    "javaVersion": "17.0.7",
    "javaVendor": "Raspbian",
    "osName": "Linux",
    "osVersion": "6.1.21-v8+",
    "osArchitecture": "arm",
    "availableProcessors": 4,
    "freeMemory": 590629208,
    "totalMemory": 912785408,
    "startLevel": 20
  }
}

After restarting Cloud Bundle:

{
  "systemInfo": {
    "configFolder": "/etc/openhab",
    "userdataFolder": "/var/lib/openhab",
    "logFolder": "/var/log/openhab",
    "javaVersion": "17.0.7",
    "javaVendor": "Raspbian",
    "osName": "Linux",
    "osVersion": "6.1.21-v8+",
    "osArchitecture": "arm",
    "availableProcessors": 4,
    "freeMemory": 601903232,
    "totalMemory": 912785408,
    "startLevel": 100
  }
}

Tuny · July 2, 2023, 6:58pm

When I try to download (manual installation; linux) the last milestone it always gives me only the snapshot?

Does this mean snapshot and milestone is the same, because they are both last successful build at the moment?

@hmerk: Sorry for pinging you directly. Where can I download the lastest milestone for linux manually?

J-N-K · July 2, 2023, 6:59pm

This seems to be the same issue: Rules refuse to load at startup due to jars in addons folder · Issue #3676 · openhab/openhab-core · GitHub, we should continue the discussion there. Do you have add-ons in the add-ons folder?