openHAB 5.2 Release discussion

There’s one possible explanation for this that I can think of, and that is that you have other, long-running rules in the same .js file that creates this rule. That’s why I wrote “context” as well above, all rules that are created using @JSRule can share functions/objects. Because of this, they also share context, and it’s the context that is actually “protected”, not the rule itself. Try to move this particular rule to a separate .js file and see if that makes a difference.

I increased the JS timeout to 50 seconds and reduced the timeout for the curl call to 3 seconds. Now I get the same warning, but it refers to 50 seconds instead:

java.lang.RuntimeException: Failed to acquire the lock for action '1' of rule 'UPDATE_CAMERA' within 50 seconds.

Something does not look right here.

Hi,

I’m using the chat and asked it for the average power consumption of one of my items. The response was:

“Das kann ich leider nicht berechnen, da ich keine historischen Daten oder eine Funktion zur Durchschnittsberechnung für Power_House_ActualPowerOverall habe. Ich kann Ihnen nur den aktuellen Wert nennen.”

(Translation: “I can’t calculate that because I have no historical data or a function for average calculation for Power_House_ActualPowerOverall. I can only tell you the current value.”)

However, the item is persisted (every change, JDBC/MariaDB in my case):

Group:Number:Power:SUM  Power_House_ActualPowerOverall
    "Haus aktuelle Gesamtleistung [%.1f W]" <energyplug>
    (Group_House_EnergyMeter, Group_House_PersistedEveryChange, Group_House_NetPower) {
        stateDescription=" "[ pattern="%.1f %unit%" ], unit="W" }

So historical data is definitely available via the persistence service (e.g. averageSince works fine in rules).

My questions:

  1. Does the chat currently have access to persistence data at all, or does it only see the current item states?
  2. If persistence access is supported: does it matter that this is a Group item, or that persistence is configured via a group membership (Group_House_PersistedEveryChange) rather than per item?
  3. Is there something I need to configure (e.g. expose persistence as a tool/function to the LLM) so that queries like “what was the average power over the last 24 hours” work?

If persistence is simply not exposed to the chat yet, is this planned? It would make the AI chat much more useful for energy-related questions.

Setup: openHAB 5.2 on DietPi (NanoPi R5C), JDBC persistence with MariaDB, persist strategy everyChange via group.

Thanks!

This just shows that the “failure” is real, it’s not just that it waits too short. Something is preventing a rule in the same context from releasing the lock, which makes the context unavailable for use. The most likely cause is a long-running rule, although in theory there could be other causes. Did you do what I suggested and moved the rule to a dedicated file?

Hi, the 5.2 upgrade broke the Souliss binding by requiring the “gatewayWanAddress” attribute for the Gateway thing, however that is not (or at least should not) be a mandatory attribute.

@AndrewFG : looks like you changed “gatewayWanAddress” parameter required attribute from false to true in that PR:

Probably just a mistake ?

Yes. It looks that way. Sorry fof that.

I don’t have write access to the release notes, we need @Kai.

It only sees current Item states, but I am planning to add a LLM tool to read persistence data. FYI, I managed just in time to write docs about the underlying LLM-based HLI:

Technically seen the LLM tooling framework allows registration of tools at runtime, so one could build a JAR with additional tools and they would become available.

Thanks, I’ve fixed the links in the 5.2.0 release notes!

The script that creates the changelog can be found here. Feel free to create a PR as a fix for it!

If you use docker, read the end of that discussion

I just went through the new startup wizard, and it looks nice :+1:

But, there’s one thing: It’s just a narrow column on my screen, leading to a lot of scrolling because lines are wrapped. I guess this works fine on a mobile screen, but it feels a bit “odd” on a proper screen.

Also, there’s a broken image link here:

WebRTC stopped working in UniFi. I reworked everything according to the manual for the new scheme. I receive all snapshots/images, but on the URL where, according to the manual, the stream should be available, I get a 415 error saying that POST is not allowed. When I try to open the same URL with GET, I get a text response saying that only POST is expected.

The URL I am checking is:

/unifi/media/play/unifi:camera:nvr:protect:67acfd36012b3603e400083b:medium

It was taken from the camera properties.

This does not work for any of my cameras. In 5.1.3 it worked, although I am not sure it was using exactly this same URL.

When I moved the named rule into a separate file and call it, I now get a slightly different error message.

error updating camera ParkingCamera java.lang.IllegalStateException: Multi threaded access requested by thread Thread[#71179,OH-rule-UPDATE_CAMERA-1,5,main] but is not allowed for language(s) js.

The first issue I have noticed is that the overview page no longer loads. It just has a spinning wheel as if it’s loading, but never does. I tried re-saving the page in settings (which does load the layout) but that didn’t fix it.

Secondly it appears as though there’s a lot of issues with my items linked to MQTT things. The items that send commands and also receive updates no longer seem to receive item update states.

I think we might still have an issue here, that I don’t fully understand.

@florian-h05 I have this dead simple rule that doesn’t really do anything:

rules.JSRule({
    name: "Initialize Items",
    description: "Initialize items on system startup",
    triggers: [triggers.SystemStartlevelTrigger(100),
        triggers.ItemCommandTrigger('Override_InitializeItems','ON')
    ],
    execute: () => {
        console.warn("System Actions> Initialize Items> Starting.");

        console.warn("System Actions> Initialize Items> Initializing scenes.");
       

        console.warn("System Actions> Initialize Items> Ending.");
    },
    tags: ["System", "Initialization"],
    id: "InitializeItems"
});

Yet still, it logs this during startup:

01:07:50.665 [WARN ] (le-InitializeItems-1) [e.automation.internal.RuleEngineImpl] - Failed to execute action '1' of rule 'InitializeItems': Multi threaded access requested by thread Thread[#286,OH-rule-InitializeItems-1,5,main] but is not allowed for language(s) js.
java.lang.IllegalStateException: Multi threaded access requested by thread Thread[#286,OH-rule-InitializeItems-1,5,main] but is not allowed for language(s) js.
	at com.oracle.truffle.polyglot.PolyglotThreadAccessException.rethrow(PolyglotThreadAccessException.java:75)
	at com.oracle.truffle.polyglot.PolyglotContextImpl.enterThreadChanged(PolyglotContextImpl.java:1109)
	at com.oracle.truffle.polyglot.PolyglotEngineImpl.enterCached(PolyglotEngineImpl.java:2240)
	at com.oracle.truffle.polyglot.HostToGuestRootNode.execute(HostToGuestRootNode.java:109)
	at com.oracle.truffle.api.impl.DefaultCallTarget.call(DefaultCallTarget.java:118)
	at com.oracle.truffle.api.impl.DefaultRuntimeAccessor$DefaultRuntimeSupport.callProfiled(DefaultRuntimeAccessor.java:206)
	at com.oracle.truffle.polyglot.PolyglotValueDispatch$InteropValue.canInvoke(PolyglotValueDispatch.java:2677)
	at org.graalvm.polyglot.Value.canInvokeMember(Value.java:1131)
	at com.oracle.truffle.host.adapters.HostAdapterServices.hasMethod(HostAdapterServices.java:113)
	at com.oracle.truffle.host.adapters.SimpleRule$$Adapter.getUID(Unknown Source)
	at org.openhab.automation.jsscripting.internal.threading.ThreadsafeSimpleRuleDelegate.execute(ThreadsafeSimpleRuleDelegate.java:78)
	at org.openhab.core.automation.module.script.rulesupport.shared.simple.SimpleRuleActionHandlerDelegate.execute(SimpleRuleActionHandlerDelegate.java:35)
	at org.openhab.core.automation.module.script.rulesupport.internal.delegates.SimpleActionHandlerDelegate.execute(SimpleActionHandlerDelegate.java:62)
	at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1403)
	at org.openhab.core.automation.internal.RuleEngineImpl.lambda$9(RuleEngineImpl.java:1184)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
	Suppressed: Attached Guest Language Frames (1)

If I run it manually, it runs without problems. I don’t understand how this can be, it doesn’t even handle any “objects” that can be shared between threads. I’m starting to wonder if the “context lock” isn’t enough, what if the thread that compiles the rule still hasn’t GC’ed the context when it attempts to run? Will that trigger a “Multi threaded access request”? If so, the rules must be compiled by the rule threads, but there’s still a problem with rule files with multiple rules - since these have multiple dedicated threads that will reference the same context. Or, is there something completely different going on here?

For those encountering binding / startup issues (i.e. the issue discussed here), I have created a PR here that could hopefully resolve it.

Regarding the startup/binding issues, it seems to me like we’ve identified two independent causes:

  • The Ecovacs binding seems to have a problem with some of its dependencies, which makes the installation fail. This failure makes any subsequent features fail to install as well.
  • Installations with many network interfaces (often the case with Docker) might take so long to start mDNS (one instance is started per network interface) that FeatureInstaller don’t get access to the OSGi registries until the installation is deemed a failure. It’s not clear to me why this doesn’t eventually resolve itself, but a workaround could be to reduce the number of network interfaces.

It’s a narrow column deliberately — it might be a bit wider, but too wide is difficult to use as content is spread too wide across the screen.

That displays for me …

Try clearing the browser cache and reload openHAB. If that doesn’t help, look into the console of the browser dev tools. If there is an error, report an issue of on openhab-webui.

Yeah I thought about clearing the cache afterwards, but had no effect.

Dev tools in the browser does turn up errors. There’s a recurring failing HTTP request:

Request URL: https://192.168.0.26:8443/rest/events?topics=openhab/items/null/command
Request Method: GET
Status Code: 401 Unauthorized

I tried logging out of OH with the intention of logging back in to see if that made a difference, but now the page doesn’t load anything. (The same error is occurring repeatedly in the background)

Can you set any Item as UI Command Item in Help & About and retry?
Or if you are on a desktop browser, try to go to Application → Local Storage in the dev tools and clear everything from openHAB there.