I think that just shows you what bundles are supposed to be active by startlevel 30.
Do you bychance have any binding that isn’t working?
No I did not spot anything hinting that. Where could I check for sure ?
I saw another warning about an empty .rules file so I am deleting that one too.
I have a bunch of warning but they are all the same and due to the current state being NULL.
here is one:
2025-01-06 21:01:58.961 [WARN ] [rest.core.item.EnrichedItemDTOMapper] - Failed transforming the state 'NULL' on item 'BedroomLightMode' with pattern 'MAP(bedroom_light_mode.map):%s': Target value not found in map for 'NULL'
The map file is there, valid, and old… Instead there is no entry for NULL. I get the warning but that should not be an issue.
OH no longer chokes with all my rules out of the way.
I will check and bring them back one after the other.
There must be a nasty one…
I would guess all it’s Things would be in an error state. It should show up in the bundle list perhaps as an error state.
I would expect to see those. I doubt they are causing problems. If you have restoreOnStartup though I kind of would have expected that to happen already and they wouldn’t be NULL.
I don’t even know what that is. Interesting finding.
I am reintroducing my rules slowly.
I am already suspecting some rules related to the SMTP mailer and I added those very recently. It is however too early to conclude. I will update once I am sure.
top -H -p $(pgrep -x java)
It drills down and help spotting why this java things eats so much CPU (when it does).
It is very useful actually and also shows sometimes the watchservice going overboard:
which may be related to the issue that has been reported a few times already in the form of “I save my rules but they are not reloaded”.
Currently I suspect that one to make OH unhappy:
rule "Test Mailer"
when
// 31st of February at 5am. If my calculations are correct, this should be ... never.
Time cron "0 0 5 31 2 ? ?"
// s m hh DD MM WW YYYY
then
val mailer = getActions("mail","mail:smtp:mailer")
mailer.sendMail("<redacted>@gmail.com", "Test Email from OH", "This is the mail content.")
end
The cron is not an error, I wanted a cron that never happens so I can only trigger it manually.
I think Rules DSL will support a rule without a when now. The other languages support calling another rule and rules can be triggered manually so it makes sense to have a rule without a trigger, even though Rules DSL doesn’t support calling another rule itself.
Test without a trigger. Just immediately follow the when with the then.
I would not be surprised if an impossible cron caused a problem and I’m pretty sure you didn’t need it anymore anyway.
I hope this PR would help so users don’t have to figure out what “Handler” means. Are there other cases where “Handler” could mean something other than Binding?
EDIT: Created a PR on webui so it’s translatable Thing Details: provide a default description for HANDLER_MISSING_ERROR by jimtng · Pull Request #2986 · openhab/openhab-webui · GitHub
1 Like
So first of all, I am back to business:
I still need to re-incorporate 2-3 rules and run some experiments.
So far my take-aways are:
- upgrade => clear cache
- High CPU =>
top -H -p $(pgrep -x java)to dig in the specific process that goes rogue - issues with rules => Move them all to a
disabledfolder and bring them back in small batches until it breaks again - do monitor your cpu/load/temp to get an early alert if a “bad” rule is introduced
On the last point, I am using GIT to manage changes, this is very useful to keep track ot “what has changed recently”. I realize however that I almost never spot newly introduced issues right away unless the changes have a big impact (such as increasing the load significantly as shown on the graph above).
LSP seems to disagree for now:
As you noticed however, I don’t really need this rule anyway. It was a test I was running daily for a few days, then I decided to “disable” the cron.
Once a bad cron is introduced, it seems that a OH restart is required, otherwise, the issue seems to “stick”.
Not that I’m aware of but I haven’t looked at the code.
This should happen as part of the upgrade process. But sometimes in rare cases something goes wrong and it needs to be done again.
LSP may not be up to date with the actual code. 
The cron actually is an error:
'?' can only be specified for Day-of-Month or Day-of-Week.
So, unsupported syntax broke the OH rule engine, and you would probably get the same scenario by just restarting OH without any upgrades.
You could have configured it to run in the year 1970 instead of using “illegal” syntax…
Next time just make it
Item Test changed to ON
Make sure you have a dummy Switch Item called Test, and switch it to ON when you want the rule to run…easy peasy 
I did not create Test dummy item because I don’t want to have 1000 Test dummy items… (I did that a few times, then @rlkoshak brought to my attention that rules can be ran manually from the UI so no dummy Item is even required to test).
IMO is it very bad that ANY cron would break the engine.
The following cron should allow OH to start 99 9 99 9 9 9 x c c c ??? ###. Sure, it is expected for the cron NOT to run obviously but if a cron is bad, OH should log it as WARN/ERR and move on, ignoring the rule/cron… not just starts an endless loop.
I much prefer the option from @rlkoshak to NOT provide a when clause but since I am relying on LSP for my validation, for now, this is kind of a no option unless I badly would need it (which is not the case).
So the main issue overall is that I had an insignificant rule, using a faulty cron (so what…) and the whole OH was hanging due to that without even a hint of the cause.
Agree, the rule should have been invalidated and move on to the next one.
I guess the rule engine finds your syntax correct, but then it goes and asks the guy in the cron engine room what time I should run this rule? He says, give me a sec to calculate…still calculating, hang on…
So why not have 1 MyDummyItem and use it in 1000 rules to test. You dont need to have 1000 dummy items, as you will not be using the dummy item.
As it seems the rule when … then without a trigger is not acceptable to DSL, you have to give him something
I would think the cron can be validated with a regex. Maybe it is not or the regex is wrong.
If the “cron guy” needs 1s to find out when it should run, there is a major issue…
Because 1 dummy item is one too much
That’s what LSP says but @rlkoshak mentioned that LSP may be outdated and it may work without. I did not try yet though.
right, my mistake, he actually said give me a msec to calculate…but 38 minutes later, he was still wraping his head around your ambiguous cron expression.
Well, If you cannot afford a dummy item, then find some item of some thing that is irrelevant or never changes.
Or get creative, something like, when Item LivingRoomSensorVoltage changes to 100000. When SomeBatteryPercentage changed to ON
I did, here you go
2025-01-08 14:47:44.856 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'staging.rules' has errors, therefore ignoring it: [6,1]: no viable alternative at input 'then'
The developers can either fix the bug you discovered (1) or tell us, use another rule engine if you don’t like how this one handles ambiguous cron expressions (2), or dont use ambiguous cron expressions (3)
I’m good with either one
Calculating when a cron should run it deterministic. It is not an iterative process that may take a random / infinite time to calculate.
yeah… not sure this is much better than cron running on 31.02 at that point.
I am not even sure it would pass validation, did you try that ?
That’s however not the kind thing I would like to read in my rules… but yeah, thanks for the tip/idea.
Nice, thanks for the test.
Yes, I hope the outcome will be (1), as unless I miss something, it should be doable to:
- use a regex (or a few) to check for validity
- if the computation takes too long (1s would be an eternity…) this should be aborted and the rule flagged as invalid.
I see an alternative but I don’t know how feasible it is. I could imagime a simple:
rule "do stuff manually only"
when
Never <== new one (not supported atm)
then
// do stuff
end
Please open a new thread to work through your issues. With the information provided your problem is not related to the problem discussed on this thread.
It should have reported a syntax error though. So that at least is OH not behaving correctly. Certainly it shouldn’t prevent OH from starting.
If you are OK with a warning in the log, the dummy Item need not even exist.
This is the correct option. A bogus cron expression should be reported as an error, not cause OH to refuse to come up fully. Assuming we are correct and it is indeed this bogus cron expression that’s causing the problem. Though the issue may be upstream in the Quatrz project.
It used to be OK. The state of the Item and the ON are converted to Strings and compared that way. At least the last time I worked with Rules DSL you could put anything there, it’s not that smart. Your rule just will never run.
May as well just leave the trigger out. That should be less work for the developers than adding a whole new trigger which will have ripple effects beyond just Rules DSL.