openHAB 5.1 Milestone discussion

mpmario · October 4, 2025, 10:12pm

Hi,
yesterday I upgraded from version 5.01 to the milestone build, thank you for your work!! Unfortunately, none of my text-based JavaScript rules work anymore — the keyword “rules” is now reported as unknown.
I’m aware of the new option “Auto injection for all scripts, including file-based,” which was enabled by default. However, I noticed that adding the line

const { rules, triggers, items } = require(‘openhab’);

at the beginning of a JS file makes it work again.

I think thats not the intended behavior, right?

Nadahar · October 4, 2025, 10:16pm

I’m not JavaScript expert, but I think the difference in syntax is related to the difference in the JavaScript enging (and the version of JavaScript that it supports). The “new” JavaScript add-on uses GraalJS and the “old” one uses NashornJS. You can still install the NashornJS add-on if you don’t want to rewrite all your scripts right now. My guess is that they will work better there.

sihui · October 5, 2025, 6:36am

I had the same problem a while ago: change that option in the UI to something else, save, go back to Auto injection for all scripts, including file-based scripts and transformations, save, restart openHAB. After that the problem was gone.

florian-h05 · October 5, 2025, 4:11pm

I still wonder what causes this. The new configuration parameter defaults to “auto inject everywhere”, so I am a bit out of ideas why it does not do that.

jimtng · October 5, 2025, 4:27pm

is the default set in java code or only in the config xml?

sihui · October 5, 2025, 4:36pm

I had to switch between different openHAB versions the last days because of another issue, that behavior was reproducible: switching from 5.0.1 to 5.1.0.M1, switching from 5.1.0.M1 to Snapshot #4840. I switched between 5.0.1 and 5.1.0.M1 several times, every single time I had to apply the workaround for that setting.
No big deal, but it gets you more gray hairs

florian-h05 · October 5, 2025, 4:38pm

In both.

I think this should be fixed by [jsscripting] Fix wrong max value for config parameter declaration by florian-h05 · Pull Request #19384 · openhab/openhab-addons · GitHub, which is not part of 5.1.0.M1

rheos · October 11, 2025, 5:33pm

I’m having the same problem loading items in a Windows environment (The addBindingConfigReader method has thrown an exception). I’ve run some tests and found that quite a few item files load without error, but others don’t. For example, items associated with the astro binding fail to load. Items in a file created using the example in the binding documentation also load with errors. The error occurs during startup.
I’ve identified item files that fail, loaded them afterward, and they seem to boot completely. I’ll also check if the pingdevice works.

sihui · October 11, 2025, 5:39pm

Solution is here:

(update to a recent snapshot version)

florian-h05 · October 18, 2025, 11:16am

28 posts were split to a new topic: openHAB 5.1.0Mx: UPNP Issues

moody_blue · October 26, 2025, 3:00pm

I have this rule written in blockly

In 5.0.2 all ok. But in 5.1.0.M1 none of the “store expire” commands are working, only the final ON command.

milo · October 26, 2025, 8:10pm

What is the plan about vue update?

Nadahar · October 26, 2025, 8:34pm

I think they are working pretty hard on it:

https://github.com/openhab/openhab-webui/pull/3350

Sacha · October 27, 2025, 10:59am

Hello Openhab forum.

I hope I’m at the right place to post my question. If not, please forgive me.

Openhab 5.10 M2 on Pi5. Using OH since 2023. Mainly Zigbee, but also some other bindings.

After migrating to M1 I had problems with JS UI rule conditions not working anymore because the return statement had changed.

There is a long thread about that.

I ended up modifying all my codes to add ‘return true/false and setting the JS addon parameter ‘Wrap Script Conditions in Self-Executing function’.

That has been OK until I upgraded to the recent M2.

I discovered by accident - just chanced to see the error message in the log - that a rule was failing.

Digging a bit and went to the JS addon: the ‘Wrap…’ parameter had been reset when installing M2.

This seems very dangerous as many rules may silently stop working.

So, my question/request is of course: is it possible that the addon keeps it’s previous parameters. And does this apply to any addon ?

Thank you for your help.

florian-h05 · October 27, 2025, 1:28pm

When explicitly configuring a parameter, its value is always kept. If you haven’t configured a parameter yourself and used the default, that default may be subject to change, though that should be avoided.
The changes to the add-on (again) were done to avoid breaking changes to the last stable release, I.e. 5.0.x. Between milestones and especially snapshots, things can change several times and break several times …

rlkoshak · October 27, 2025, 3:47pm

They fail how? Errors (if so what’s the error) or don’t run? If they don’t run, have you logged out the value of the Button Item to make sure it is what you think it is?

Note, there are changes in work in 5.1 M1 which change how the event Object works and the necessary changes to Blockly have not yet been merged. Those should not come into play here but it’s worth paying attention to.

Sacha · October 27, 2025, 5:16pm

Hi Florian.

At version 5.10 M1 I had to correct rule return problems.
That implied modifying the code AND setting an option in the JS addon configuration.
I went to the addon configuration ‘Configure JavaScript Scripting’ and switched the ‘Wrap Script Conditions in Self-Executing Function’ option to ON.
I don’t know what you mean with ‘explicitly configuring a parameter’. Is there someting I didn’t do right ?

Yesterday I installed 5.10 M2 and had problems with rules.
When I went to the ‘Configure JavaScript Scripting’ and the option was OFF.
I had to remodify it to ON.
In other words, the option has NOT been kept from M1 to M2.

Sacha · October 27, 2025, 5:38pm

Ok, I understand better what you mean with ‘explicitly configure’:

I checked in a previous OH 510 M1 backup.
The option was NOT set in userdata/config/org/openhab/jsscripting.config.

I don’t understand why because I HAD to set it.
Maybe, it was defaulted anyway. Strange.

Now in M2, it DOES exist in jsscripting.config:

:org.apache.felix.configadmin.revision:=L"3"
scriptConditionWrapperEnabled=B"true"
service.pid=“org.openhab.jsscripting”

It is kind of a mystery, but I guess the problem will not happen again.

Thank you for your help.

Sacha · October 29, 2025, 9:04am

Sorry to be back with another issue.

I just use this Openhab remote addon just for fun. So it is not very important for me. But it may be for other people.

It worked on 5.1.0 M1 and now fails on M2.

Error message:

==> /var/log/openhab/openhab.log <==

2025-10-29 09:48:47.755 [DEBUG] [l.handler.RemoteopenhabBridgeHandler] - Try the root REST API…

2025-10-29 09:48:47.756 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - Request GET http://192.168.1.119:8080/rest/

==> /var/log/openhab/events.log <==

2025-10-29 09:48:47.757 [INFO ] [penhab.event.Thing_Label_in_Messages] - Thing ‘remoteopenhab:server:72d24720f6’ - ‘Remote openHAB Server’ now UNKNOWN

==> /var/log/openhab/openhab.log <==

2025-10-29 09:48:47.856 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - REST API version = 8

2025-10-29 09:48:47.856 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - REST API items = http://192.168.1.119:8080/rest/items

2025-10-29 09:48:47.857 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - REST API things = http://192.168.1.119:8080/rest/things

2025-10-29 09:48:47.857 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - REST API events = http://192.168.1.119:8080/rest/events

2025-10-29 09:48:47.857 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - topic namespace = openhab

2025-10-29 09:48:47.857 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - Request GET http://192.168.1.119:8080/rest/items?recursive=false&fields=name,type,groupType,state,stateDescription

2025-10-29 09:48:47.862 [DEBUG] [l.handler.RemoteopenhabBridgeHandler] - checkConnection for thing remoteopenhab:server:72d24720f6 failed: Failed to get the list of remote items using the items REST API

org.openhab.binding.remoteopenhab.internal.exceptions.RemoteopenhabException: null

at org.openhab.binding.remoteopenhab.internal.rest.RemoteopenhabRestClient.getRemoteItems(RemoteopenhabRestClient.java:196) ~[?:?]

at org.openhab.binding.remoteopenhab.internal.handler.RemoteopenhabBridgeHandler.checkConnection(RemoteopenhabBridgeHandler.java:381) ~[?:?]

at org.openhab.binding.remoteopenhab.internal.handler.RemoteopenhabBridgeHandler.lambda$0(RemoteopenhabBridgeHandler.java:182) ~[?:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]

at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]

at java.lang.Thread.run(Unknown Source) [?:?]

Caused by: org.openhab.binding.remoteopenhab.internal.exceptions.RemoteopenhabException

at org.openhab.binding.remoteopenhab.internal.rest.RemoteopenhabRestClient.executeUrl(RemoteopenhabRestClient.java:600) ~[?:?]

at org.openhab.binding.remoteopenhab.internal.rest.RemoteopenhabRestClient.executeGetUrl(RemoteopenhabRestClient.java:559) ~[?:?]

at org.openhab.binding.remoteopenhab.internal.rest.RemoteopenhabRestClient.getRemoteItems(RemoteopenhabRestClient.java:190) ~[?:?]

… 8 more

2025-10-29 09:48:47.863 [DEBUG] [nternal.rest.RemoteopenhabRestClient] - Closing EventSource

==> /var/log/openhab/events.log <==

Tried to uninstall/reinstall the addon, remove/recreate the remote thing. No luck.

michaeljoos · October 29, 2025, 2:38pm

Upgraded to M2 –> Can someone double check if this button works?

For me it works only in “Items”.

In “Things”, “Pages”, “Inbox”, “Rules” nothing happens.

In Developer Sidebar I see a similar issue. “Show All” does not work 100% (e.g. for rules not):