Since the upgrade to v5.1 I am facing that my text rules are randomly not loading on restart.
if I just change the file extension and then return it back to .rules all is loaded.
I think someone else reported similar issue, but I cant trace it back in the search.
Any tip how to solve this?
When they do not load do you see anything in the logs? Errors during loading or lack of a log statement saying that the file was attempted to be loaded at all?
I can see this warning upon restart of the computer related to the problem I faced today:
2026-01-20 09:58:48.913 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'lights.rules' has errors, therefore ignoring it: There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
When I search on the error, I found this:
I am not a software engineer, but I understand the explanation in the linked topic that it is better to avoid definition of the variable types.
I checked the rule file and I can only see the following declarations:
var Timer tmrLightHall
var Timer tmrLightOffice
var Timer tmrLightOfficeButton
var Timer tmrChristmassLights
var Timer tmrFrontEntranceLights
var Timer tmrLightBBQ
var Timer tmrLightKitchen
var Timer tmrLightCarport
var LightBedroomColorCurrentState = LightBedroomColor.state as HSBType
val pState = lamp.persistedState(now.minusDays(7), "rrd4j")
The last declaration appears 4 times, and that is “enhancement“ by Google Gemini that I used to correct ZonedDateTime warnings on my presence simulation that was working for 5-6 years.
I suspect this is the problem, since I see also 4 entries at the start.
On the other hand, if the machine is running and I tried changing the extension to something and back to rules, all started working. No logs no errors.
The warning shouldn’t be the root problem. For one it’s just a warning.
A “closure” in Rules DSL is any time you see stuff in square brackets: e.g. [ | some code].
In this case you have at least four cases where you have a closure (or lambda if you prefer that term, I hate that they use both) where you pass arguments: e.g. [arg 1 | some code]. Maybe in a call to forEach or something like that.
It’s weird that the error only sometimes occurs. But you can eliminate it as a problem by setting a type for the arguments passed to these lambdas.
You should at a minimum see “loading model filename.rules” or something like that.
Appreciated your report
Yes, I know that but my system was running stable so I set the log level to “Warn”
Ok I will have a look this evening.
I suspect it goes wrong in case there’s warning. After upgrade to 5.1 none of the text rules loaded when OH service restarted.
Second service restart loaded some files and for sure not the ones with ZonedDateTime obsolence warnings.
So I used Gemini to fix my rules and now I don’t see any warnings in any of my text rules, with exception of some timer variables that are not used.
My lights rule that didn’t load yesterday has a few of those unused timer variables that give warnings.
But it’s not doing so now so INFO would be the minimum level I’d run with.
Just for clarification your system in Linux based?
yes, Ubuntu
I don’t want to ping someone here but let’s see what the experts can identify…
OK, I set the logging to info and I only get log entry similar as above:
2026-01-27 09:13:38.331 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model 'lights.rules'
2026-01-27 09:13:39.993 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'lights.rules' has errors, therefore ignoring it: There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
2026-01-27 09:13:39.994 [INFO ] [el.core.internal.ModelRepositoryImpl] - Unloading DSL model 'lights.rules'
I suspect the warning comes from this:
grpLightBulbs.members.forEach[lamp |
val pState = lamp.persistedState(now.minusDays(7), "rrd4j")
if(pState !== null && pState.state !== null) {
lamp.sendCommand(pState.state.toString)
logInfo("lights:Mode", lamp.name + " replayed: " + pState.state)
}
]
As mentioned above, changing the extension to something else and back to “rules“ loads the file and rules start working
2026-01-27 09:20:30.022 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model 'lights.rules'
Well, like I said above, you can eliminate these errors that appear sometimes while loading the file by supplying the type of the arguments to all lambdas. Based on the log you have five places in lights.rules where you have arguments passed to lambdas.
For the one you post the type would be [ GenericItem lamp |.
This does not appear to be related to the issue posted above because the file is loaded every time. It’s just that sometimes there are errors parsing the rules and other times there are no errors.
Thanks, it looks like this is the solution (I only did one restart of the openhab sevice)
Since the upgrade to v5.1 I am facing that my text rules are randomly not loading on restart.
If I just change the file extension and then return it back to .rules all is loaded.
Are your items defined in .items files; .yaml files; in the MainUI (jsondb); or created dynamically by some (automation) add-on, e.g. using the provider preset?
Or in other words, can you find out, if (on boot) the rule is parsed before the items are loaded and then this error happens? If this is the case, it would at least explain why this happens sometimes - when the rules are partsed and the rule references not yet loaded items.
I think on boot different modules (bundles) are started in parallel, so on each boot the order in which bundles complete loading (starting) can be different.
Nevermind, I figured this out. For me
g.members.forEach[u | logError("A", u.name + "|" + u.state + " | " + u.class.toString) ]
works with openHAB 5.1 when g is a GroupItem and produces
DSL model 'starttest.rules' has errors, therefore ignoring it: There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
if I have no item g. So the above error happens sometimes, because sometimes the rule is parsed on booting before the items are loaded.
I think we are going to restore a simple warning for these DSL rules errors.