Major Problems in Rules Execution since openHAB5

Setup, Configuration and Use Scripts & Rules
1

Hey Members,
i’m on openHAB since 5 years and the Problems with my installation are getting bigger and bigger.
However i won’t bother you with details and my frustration about, that is not productive.

I moved from Rapi to some Docker and in the Past i upgraded to a x64Architecture and a larger scale System, as i run there other services. Currently i’m using Proxmox and using those Prox Helper Scripts to Install an maintain my Services. It went really well and i can recommend that to everyone on x64 Architecture.
However it is easy there to make backups, stop services and have different “lxc” there. There we got closer to my problem.
I knew about that community doesnt recommend … and is not responsible for those installations. For sure. But on the other side.

I do currently have the following issue.
Virtual Server a: an 4.x installation from late 2025. (runs well and is my reference)
Virtual Server b: upgrading that a installation continously to 5.1… and all my rules run crazy (example will follow later this post)
Virtual Server c: yesterday with 5.1.2. fresh installed and with openhab-cli i recalled the config from Server a. booted three times…

Now to the problem(s) :

Very simple Rule:
rule “Outdoor:Sprinkler:TimerOFF”
when
Item Sprinkler changed from OFF to ON
then
createTimer(now.plusSeconds(400), [|Sprinkler.sendCommand(OFF)])
end
(on webend it looks this, i used it as a code rule in an .rule file asa above) :

image
image758×530 16.4 KB

very easy thing, yes possibly not the perfect code but it worked 5 years to switch off my gardenpump after about 6 minutes…
–> works on SERVER a… but runs wild on Server b and c.
When i switch on my garenpump…

image
image1369×317 21.9 KB

it runs wild. it turn off after a unprecicted time what is not 400s. or not 40s

Problem 2:
All my Timer Rules totally run crazy or do nothing on Server B and Server C.
I’ll skip an example as you might see there is a cron in rule file but anyhow its not doing well…

Problem 3:
I’ll do checking in Rule about (example) an temperature to do something…

in the past ill did like :slight_smile:
var temp = outdoortemp.state as number
and compared this to some value and descided on action.
( Ill know this is not 100% the right term but worked on 365 days for me. ill know about double and comparing did many tries but the problem is simple:
It worked on Server A very well.
on Server B and C … puh… a nightmare. Sometime its in his opinion to be NULL or the Rule just breakes there with stopping all actions before and exiting… Or the comparson to 5 is resulting unpredictable.
Ill tried to catch a NULL und UNDEF in 20 different methods that Copilot suggested to me ill changes over days … however the result was always that execution was broken. - But on Server A it runs well at all.

–> ill have a feeling that here is a kind of JAVA Problem on my side, possibly im the lost and last user about using the textual config with .rule files. … However this is broken to me here.
Ill going to downgrade to my December installation and avoid any updated. … (such a big Plus to have those on Proxmox available by some clicks. ) Its a “predictable System” and restoreable.

However there the rule execution is unpredictable.
Please give me a hint to fix. Ill also had the idea to the changed config of RRD4J and default item logging what here causes some pain… but doesnt change anything here at all.
Ill only saw that restoring a config is resulting in a problem of Linux ownership where the user openhab on the new systemt cant access thos files from samer user openhab files from the old systems even it has rights. ill changes to 777 to skip any issues.

Special thing: On Server D … my last try: a fresh install on a DEBIAN VM (virtual Machine) with installing openhab by command line, ill just copied only the rules things and items. and nothing from the other folders on /var/lib ill mean that fancy DBs… holy. ill dont trust them and expected the issue there… but that server does same as B and C… Crazy or not running rules.

So. Let me be unfriendly, ill expect a kind of java problem and not my simple 6-line code to have the issue there or mightfull there something has changed something what makes my rules now unexecuteable.

Thanks by the way.

2

First, please mark code as code. Use three backticks ` before and after the code or use BBCode
([code]mycode[/code]) There is also a button </> to create the backticks.

rule "Outdoor:Sprinkler:TimerOFF"
when
    Item Sprinkler changed from OFF to ON
then
    createTimer(now.plusSeconds(400), [|Sprinkler.sendCommand(OFF)])
end

is much more readable.

The code is not safe, because the timer can be started multiple times, which may result in erratic behavior.

Better use a global var to test:

// define global vars on top of the file
var Timer tSprinkler = null

rule "Outdoor Sprinkler TimerOFF"
when
    Item Sprinkler changed from OFF to ON
then
    if(tSprinkler !== null)  // if timer exists
        return;              // leave the rule

    tSprinkler = createTimer(now.plusSeconds(400), [|
        Sprinkler.sendCommand(OFF)
        tSprinkler = null
    ])
end

In openHAB5 you can also use the private cache, this is available from Main UI rules as well.

Server A behaves different to B and C: Sounds like a dirty configuration to me, please try reinstalling openHAB.

As I use Proxmox since many years, I can assure you, openHAB works absolutely reliable.
My current configuration:
Proxmox 9.1.5. LXC, 4 Cores, 3 GByte RAM, zfs, disk-0 is 8 GByte with trixie and 64bit OpenJDK 21 headless jre, for openHAB configuration I use additional shares at mountpoints.
openHAB itself is installed via apt, no openHABian (but I used it for years in combination with similar LXC configurations)
I’m using some special configuration to get remote access via VSCode without the need for samba shares, but that’s another story.

1 Like
3

The cause might be that the new hardware runs faster and smoother and therefore uncovers timing problems, which existed even before:

var temp = outdoortemp.state as Number

When openHAB starts, or whenever a binding is in a mood, the state of the item is set to NULL. To read the number value of an item only when it is not NULL but a Number, you can do

var e = outdoortemp.state
if (e instanceof Number) {
  // here e is neither NULL nor UNDEF
  var temp = e as Number  // might not be necessary, maybe e is already a Number
  logError("A", e)
}

In any case, this aborts the Xbase interpreter, the exception cannot be caught:

val a = NULL
val b = a as Number

Besides, when a lambda has no parameters, instead of [| you can write just [.

4

script.model.ScriptInterpreter: emit what cannot be casted to what after a single evaluation of the cast by dilyanpalauzov · Pull Request #5329 · openhab/openhab-core · GitHub allows catching ClassCastExceptions in DSL Rules/Scripts/Transformations:

rule "System started"
when
    System reached start level 100
then
    try {
       s.state as Number
    } catch (ClassCastException e) {
       logError("A", "Caught ClassCastException")
    } finally {
       logError("A", "finally")
    }
end

will print “Caught ClassCastExceptionandfinally` instead of aborting.

5

Udo, thank you.
What is meant with “private cache”?

I’m trying to step a little the shutters for some seconds as it will reduce noise.
Hoever. The timers do that start and i see that the shutters suddenly stop after about
a second.

createTimer(now.plusSeconds(1), 	  [|GF_RS_WohnenL.sendCommand(UP)])
createTimer(now.plusSeconds(3), 	  [|GF_RS_WohnenR.sendCommand(UP) ])
createTimer(now.plusSeconds(5), 	  [|GF_RS_EssenF.sendCommand(UP) ])
createTimer(now.plusSeconds(7), 	  [|GF_RS_KuecheF.sendCommand(UP) ])
createTimer(now.plusSeconds(9), 	  [|GF_RS_Bad.sendCommand(UP) ])
val SunRadia = (SunRadiation.state as DecimalType).doubleValue
if (SunRadia < 90){...

I see the comparison for SunRadia will STOP all times and will exit the rule.
I checked many different wordings… does ist make sense to use the try catch?

6

Hi! Thank you.
the Startup here is not the root cause as no execution will happen here.
The values are not NULL inside, as here are continously data and i monitored that during execution.
The Comparison is not True and not False. it just BREAKS there.

i will do something with a try catch. Thanks.

7

Probably should be using Expire for this type of rule.

Thanks to the addition of the source we know that the command is coming from a rule. That makes it clear that the issue is indeed the timer.

No, there are many still using .rules files. I doubt the problem is that anyway. Something is going wrong with the clock and your guess that it’s likely some java problem is probably the most likely.

The uid for user openhab on the old machine is probably not the same as on the new machine. There is an option in openhab-cli to fix permissions which I think also fixes ownership. If not, on the new machine run sudo chown -R openhab:openhab * on /etc/openhab and /var/lib/openhab.

Nothing has changed in OH that I am aware of that could remotely explain this behavior.

This is true but the events.log shows that’s not what’s happening here. It’s a good thing to fix, but it’s not the problem.

It is not clear what a, b, c, and d are all running on. Is a still on the RPi? You mention using Docker, Proxmox, “Virtual Servers”, and LXCs. That’s a lot of technology and we have no idea how any of it is configured.

Ultimately something is going wrong with the clock in Java. But it’s not clear what that could be.

Add logging to your simple rule. In particularly we want to compare the teimstamp for when the Item changes to ON, when the rule runs (log statement as the first line in the rule), what time the now.plusSeconds(400) ends up becoming, and finally comparing that to when the OFF command is sent from the timer.

There isn’t enough detail to even begin to address any of the other rules.

I suspect this Item is configured with persistence and restoreOnStartup on the old machine. But when you moved the configuration to server B and C you didn’t move the persistence data. You said you don’t touch /var/lib/openhab and guess what? That’s where persistence is stored for rrd4j and mapdb.

So on server B and C those Items have no value. They remain NULL. They will remain NULL until the channel they are linked to updates the Item with a new value, or you manually update the Item with a new value.

It is always best to make your rules handle the cases when the Item is NULL or UNDEF for just such a situation. But these rules will continue to fail until you give these Items a state one way or the other. Without seeing specifically what you mean by “just breaks” and comparisons being unpredictable :person_shrugging: But an Item you don’t expect to be NULL could explain all of these.