This topic can be used for any discussions around the openHAB 5.0 Milestone builds as it has been announced in openHAB 5.0 Milestone Builds.
3 Likes
Hi,
Are there any other compatibility changes besides the Java version and 64-bit OS?
/Franz
Just noticed two strange issues. Everything else seems to work flawless.
1 with DSL rules, not sure what is going on, it worked flawless in 4.3.3.
2025-02-23 20:26:41.159 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'notificatie_wasmachine.rules'
2025-02-23 20:26:41.208 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/vnd.openhab.dsl.rule' could not be found for identifier: f2edf256-b084-4c26-97cd-cf4df6cc97a4
2025-02-23 20:26:41.214 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/vnd.openhab.dsl.rule' could not be found for identifier: b1d927d9-03e1-48ae-8f27-83b9355b10ab
2025-02-23 20:26:41.224 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/vnd.openhab.dsl.rule' could not be found for identifier: cced0d9e-f6d2-4081-ab87-a231499055e3
2025-02-23 20:26:41.227 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/vnd.openhab.dsl.rule' could not be found for identifier: 0a332eb5-957c-42ad-b0ab-184f666cf86a
- Home Connect binding looks functional, but the log shows:
2025-02-23 20:26:35.130 [WARN ] [dler.AbstractHomeConnectThingHandler] - Could not open event source connection. thing=Wasmachine, haId=BOSCH-WAYH2842NL-68A40E271D28, error=Client service is closed
2025-02-23 20:34:35.128 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectDryerHandler of thing homeconnect:dryer:api_bridge:wasdroger tried accessing its bridge although the handler was already disposed.
2025-02-23 20:34:35.133 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectWasherHandler of thing homeconnect:washer:api_bridge:wasmachine tried accessing its bridge although the handler was already disposed.
2025-02-23 20:38:35.130 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectDryerHandler of thing homeconnect:dryer:api_bridge:wasdroger tried accessing its bridge although the handler was already disposed.
2025-02-23 20:38:35.134 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectWasherHandler of thing homeconnect:washer:api_bridge:wasmachine tried accessing its bridge although the handler was already disposed.
2025-02-23 20:42:35.131 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectDryerHandler of thing homeconnect:dryer:api_bridge:wasdroger tried accessing its bridge although the handler was already disposed.
2025-02-23 20:42:35.135 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler HomeConnectWasherHandler of thing homeconnect:washer:api_bridge:wasmachine tried accessing its bridge although the handler was already disposed.
// repeating every 4 minutes
There is now an problem rendering UI components that use the vue-fragment library.
I filed an issue just a couple days ago, but haven’t had a chance to track it down. This does appear to be a fairly critical issue for some custom widgets.
1 Like
No, there shouldn’t be.
1 Like
I don’t seem to be able to view/edit ‘inline scripts’ in rules. When I click to edit, I just get a blank window. Same on two different installs.
For the rules in question, openhab.log has an entry like:
2025-02-24 16:51:22.959 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '0ad032c4e1': Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null
Hello together
I have exported the configuration (openhabian → backup configuration) from my running 4.3.3 system and imported it into my new openHAB 5.0.M1 installation (latest openhabian → restore).
Overall it really looks good, but I have an issue with persistence rrd4j and restoring items:
- A lot of items have status NULL (a lot means about 150 of 660 items)
- For all these items update “everyMinute” does not work. The items keep the date of backup
- The persistence files are all there (/var/lib/openhab/persistence/rrd4j)
- I can see the history, trend lines and graphs in openHAB
- User openhab is the owner of the *.rrd files
- Rrd4j persistence configuration are the same → Persist all items and no filters
- Selected strategies: everyChange, everyMinute, restoreOnStartup
What I have already tested:
- Zram increased → No change
- Zram disabled → No change
- Clear cache and restart openhab → No change
- Uninstalled / installed rrd4j persistence service → No change
For me it looks like that initial restoreOnStartup does not work for all items. This happens for e.g. standard number items without UoM.
Any ideas? Or is there more input I can share here that helps to find the issue?
Did you already try to delete the corresponding rrd-files?
You will lose the deleted data, but you should gain working persistence.
Mmhh, I don’t want to delete the history because all this data is important for my home automation system.
But I have just realized, that all these Items in status NULL are set over UI or Rules and not directly linked to a Thing channel.
When I use restore configuration I would expect that all items are restored.
Don’t know if this matters, but I did have a messy first log with the transition from OH4.3.2 to OH5.0.0M1 in Docker. Examples
Many times;
2025-02-25 15:33:43.774 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
java.lang.IllegalStateException: Invalid class loader from a refreshed bundle is being used: org.openhab.core.model.rule_5.0.0.M1
For each item
`2025-02-25 15:33:32.783 [WARN ] [d4j.internal.RRD4jPersistenceService] - No rrd4j database definition found for PatioMotion110_BatteryLevel`
And three out of four cameras.
`2025-02-25 15:34:00.763 [WARN ] [amera.internal.servlet.CameraServlet] - Registering servlet failed: ServletModel{id=ServletModel-82,name='/ipcamera/1921680200',alias='/ipcamera/1921680247',urlPatterns=[/ipcamera/1921680247/*],servlet=org.openhab.binding.ipcamera.internal.servlet.CameraServlet@4985523c,contexts=[{HS,OCM-74,default,/}]} can't be registered. ServletContextModel{id=ServletContextModel-73,contextPath='/'} already contains servlet named /ipcamera/1921680200:`
However, after restart cleared them all up. Good job to all developers
I tried to do an upgrade from 4.2.x to 5.M1 and ran in quite a bunch of issues, I eventually had to do a from-scratch installation of 5M1, and it did not run smooth
The most important issue is that at startup quite a few bundles remain in the Resolved status, and the system does not fully start up. Things like BasicUI, or OpenhabCloud, numerous add-ons do not start.
Any idea what could be causing this ?
Not sure. Could you share your log file?
I guess i should have put my post about version 5 milestone issue here.
It’s the same issue I reported above with the oh-repeater using fragment: true. This has since been fixed in the latest snapshots.
Alternatively you should just be able to replace the fragment: true line with
containerStyle:
display: contents
Where do I find this piece of configuration? I use old style text-based configurations
If you refer to @JustinG‘s answer, this does not belong to your question.
@Kai Something is off with the bundle resolution mechanism of 5.0.0.M1
Doing a fresh install, then adding all bindings (and nothing else) → all bundles resolve and become Active
Adding OPENHAB_HOME/config/* → some bundles turn not Active and stay in the Resolved state, and it is quite deterministic as in my case it is always the BasicUI, Openhab cloud, RRD4j that are stuck. Wild guess : bundle resolution is done by a limited number of threads and they end-up in a lock state ?
Then I removed the Openhab Cloud bundle → Some more bundles turn from Resolved → Active, I have no clue why
Removing OPENHAB_HOME/userdata/cache/* → A whole bunch of bundles are stuck in the Resolved state, not only the previous troublesome ones
[Some bindings take a bit longer to transit from the Waiting state to Active, for example the Sonos binding but I guess that is due to the upnp stuff going on]
Anyways, by doing a few more cleanups of OPENHAB_HOME/userdata/cache/* suddenly all bindings reach the Active state
Regards
Karel
Thx - I already had the feeling being completely lost during my OH catchup exercise. LOL
To continue:
Adding the Openhab Cloud bundle while the runtime is running → it gets Active
Restarting the runtime afterwards → whole bunch of bundles are stuck in Resolved
Removing the cache, restarting the runtime → All resolve and become Active
Looks like I have similar experience. @holgerf as you seem to have good knowledge about the bundle resolving, are you aware of this issue?