Thank to all for the great work, I appreciate this very much. I have upgraded from OH 5.0 to 5.1 and all works well, only the Entso-E item will got no updates any more.
My production environment is a raspberry 4 8G with bullseye 64-bit and Java 21 by “OpenJDK 64-Bit Server VM Temurin-21.0.9+10”. For testing and try out purpose I use docker OH instance and there is the same. After rollback the docker instance to OH 5.03 the Entso-E works well again. No change in at the entsoe.things and entsoe.items files.
For the Entso-E binding I turned on the “debug” logging a I got this:
2025-12-27 13:41:09.824 [DEBUG] [ntsoe.internal.handler.EntsoeHandler] - Fetched 192 price entries
2025-12-27 13:41:09.826 [DEBUG] [ntsoe.internal.handler.EntsoeHandler] - Day-ahead check: false
2025-12-27 13:42:09.827 [DEBUG] [ntsoe.internal.handler.EntsoeHandler] - Fetch new prices? Empty=false Hour13<=13
2025-12-27 13:42:09.828 [DEBUG] [ntsoe.internal.handler.EntsoeHandler] - Fetching new prices from 2025-12-25T23:00:00Z to 2025-12-28T23:00:00Z
2025-12-27 13:42:09.829 [DEBUG] [.entsoe.internal.client.EntsoeClient] - Sending GET request with parameters: https://web-api.tp.entsoe.eu/api?securityToken=xxxxx-xxxxx-xxxxx&documentType=A44&in_domain=10Y1001A1001A82H&out_doma
in=10Y1001A1001A82H&periodStart=202512252300&periodEnd=202512282300
All specific stuff for Z-Wave is broken in 5.1, Main UI is no more able to display the Z-Wave network map and the specific actions on the controller thing are missing in UI.
@Mark_VG - There was a mainui commit which was merged yesterday from @florian-h05 (#3665) which will likely address this issue. I don’t know the exact time the snapshot gets built, but I would try 5.2-SNAPSHOT again today to see if that addresses the issue.
I have updated my system from a development build (sorry, I did not record which one it was) to 5.1.0. The one cron trigger and a few “irem received command” triggers are not triggering. I can run/start the rules from the web interface.
I already created a very simple test rule, which should reset a trigger item and output an info log. This test rule is also not executed.
Edit:
I assume the issue is changed handling of variables and values defined within the rules file. I have used values and variables within timer ad-hoc functions and it was not obvious to me that this was the reason for the issues with running other rules contained in the affected rules file.
Example:
val String filename = "inHeating.rules"
var Timer heatingUpdateSetpointsLockTimer
rule "heatingSystemStarted"
when
System started
then
HeatingInitializationComplete.postUpdate(OFF)
createTimer(now.plusSeconds(10)) [ |
//logInfo(filename, "Executing 'System started' rule for Heating") // The filename variable cannot be accessed from this section anymore.
//heatingUpdateSetpointsLockTimer?.cancel() // This variable cannot be accessed from this section anymore.
if (Heating_Mode.state == NULL) Heating_Mode.postUpdate("NORMAL")
gHeating_Mode.members.filter[item | item.state == NULL].forEach[item | item.postUpdate("AUTO")]
//...
]
end
The “error detection hint” is always two lines too low, since 5.1:
Log:
16:25:23.130 [ERROR] [l.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'scratchpad' failed: TypeError: [object Object] is not a function in <eval> at line number 3 at column number 1
I have run some tests and can confirm that the Shelly binding is at least part of, if not the whole, problem. I had 2 Shelly Gen 4 relay/switches running in OH 5.1 with the Shelly Binding and was getting the jetty.util.thread.QueuedThreadPool error/warn. I removed the Shelly Things, uninstalled the Shelly Binding, restarted OH, paired the Gen4 Devices using Matter, restarted OH again and waited for more than 72 hrs, while monitoring the logs. The jetty.util.thread.QueuedThreadPool error/warn never appeared in this time.
I then reversed this process, and reinstalled the Shelly binding, created new Things for the Gen4 devices and monitored the logs. The error/warn appeared in the log almost immediately and continued to periodically reappear while using the Shelly binding. I have now removed the Shelly binding and will just use Matter going forward.
@Nadahar I have zero idea about this, and you might be the current active expert on this.
I’m wondering:
Whether we could create an isolated thread pool for each binding/add-on which are then separate to the main core pool(s).
Are the threads taken up by Shelly cpu bound / busy, or just io blocking? If there’s a way to detect that a particular addon’s pool exhausted + cpu bound, can we proactively kill them and disable the binding or at least assign them lower overall priority so they don’t hog the entire system?
This is further support for proper study of the use of virtual threads, so that further guesstimates about the number and size of expensive thread pools is virtually obsoleted. There appears to be significant incorrect information circulated about the capabilities and advantages of virtual threads vs. native threads, and since virtual threads are official in Java 21 and later, it’s a great time to invest effort in studying that superior potential. It would be very sensible for experienced software engineers involved in openHAB to give this topic proper study.
2025-12-27 17:30:48.681 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'logging.persist' has errors, therefore ignoring it: [4,2]: no viable alternative at input 'default'
The is a logging.persist file which after upgrading to this version looks like this:
// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
// if no strategy is specified for an item entry below, the default list will be used
default = everyChange
}
/*
* Each line in this section defines for which item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* item (excl. the group item itself).
*/
Items {
// log all temperatures on every change
//Temperaturen_Ist* -> "Temperatur" ;
}
I didn’t change the file, does anyone know what’s wrong with the default line and how to fix it?
I did not find the issue being discussed, according to my search, so I hope it’s ok to ask this here.
Thanks.
Deleting the default line solves it may be they forget it to parae I don’t know there are more reports in this thread but no answers on this cool new feature the feature is so cool that they even didn’t mention it in the release notes…so take a coffee and relax
Is everything still persisted when I remove this line?
(I am not using the mapdb persistence, but the plain old rrd.)
I thought to have understood from the release notes that now there is no default persisting of everything anymore, I “fear” when deleting the line the default persistence is gone.
I don’t know due to this secret new cool feature no one will answer this question I can only say it’s still persisted in my case but I have for each item a strategy…
Best thing about is you need to check the code by yourself it’s really easy and fast forward
on this cool new feature 