OH3 Rules stop working after changing sitemap

  • Platform information:
    • Hardware: Intel Xeon Cascade Lake, 1560MB RAM, VM on Server
    • OS: Ubuntu Server 20.04
    • Java Runtime Environment: JDK-11-jre
    • openHAB version: 3

Hello everyone,

I am experiencing a pretty strange behavior of OH3 and I’m wondering, if anyone has the same Problem.

One week ago, I upgraded from OH2.5 to OH3 and after changing a Sitemap, suddenly not a single rule worked anymore.
I found out, if I edited every rule (adding an empty line) and saved it, suddenly OH executes them again.
The same happens, when I modify ANY .item or .sitemap file, if related to a rule or not. After modifying every .rules file (adding or deleting empty lines) the rules start working again.

Today, I set up the virtual Server for OH from scratch and directly installed OH3. The behavior is still the same.

Does anybody have an Idea how to fix this?

Hi @Vidar,

I’m experiencing the same (primarily for cron triggered rules) but unfortunately haven’t found any workaround except restarting the OH service.

The error messages in rules are also not exactly an improvement. While previously you had a reference to the rule’s name, now it’s only an index (i.e. the ordinal number of the rule within the rules file).
I’m afraid making the configuration of rules easier for users via the UI actually made things worse for users relying on file based configuration.

What’s more, org.openhab.core.model.script.ScriptServiceUtil seems not to be working.

Hopefully these point will get fixed with an upcoming service release.

Could it be the same as this?

I’m finding a few recreatable rules problems at the moment.

Could it be the same as this?

Yes, I think so.

No Idea.

Here is my workaround:
I rewrote the rules as scripts in the UI. There turned up another problem:
The DSL interpreter seems to have an implementation error, so some bigger Rules took minutes to execute or even crashed OpenHAB.

Solution: I rewrote them again in Javascript, BUT be aware, that the JS Implementation is an outdated one, which does not support things like setTimeout() jet.
My dirty workaround for Timeouts: write a while loop, and let it compare the time now with the desired time after timeout (!==). Not elegant, but works.