OH3 (Possible) DSL Rules, received update not firing from different files

I’ve come across something very odd which I am sure did not happen in 2.5.
I have various items which are updated from HABPanel.
I have rules files split out into multiple files for readability
each rule acts upon a different item
All rules are triggered by “received update”
The last file to be saved is the only one with rules which fire.


//base items. One per group of blinds.
Number      BlindsSunsetAdjustMinutes                "Blinds Sunset adjust minutes"      //( g_persist_restore, g_persist_restore_db) 
Number      BlindsSunriseAdjustMinutes               "Blinds Sunrise adjust minutes"     //( g_persist_restore, g_persist_restore_db) 
DateTime    BlindsOpenUntil                         //(g_persist_restore)
DateTime    BlindsClosedBy                          "Blinds must be closed by this time." //(g_persist_restore)
DateTime    BlindsOpeningAt                        //( g_persist_restore)
DateTime    BlindsClosingAt                        //( g_persist_restore)


rule "Blinds - Adjust Blinds Close By"
when Item BlindsClosedByAdjust received update
        logWarn("loggerName", "Blinds - Adjust Blinds Close By")
//snip noise

rule "Blinds - Adjust Blinds Open Until"
when Item BlindsOpenUntilAdjust received update
    logWarn("loggerName", "Blinds - Adjust Blinds Open Until")

rule "Blinds - Adjust Close Blinds Adjust Minutes"
when Item BlindsClosedByAdjustMinutes received update
    logWarn("loggerName", "Blinds - Adjust Close Blinds Adjust Minutes")

rule "Blinds - Adjust Blinds Open Until Adjust Minutes"
when Item BlindsOpenUntilAdjustMinutes received update
    logWarn("loggerName", "Blinds - Adjust Blinds Open Until Adjust Minutes")


import org.openhab.core.model.script.ScriptServiceUtil
val getMinuteOfDay= [ZonedDateTime x |
    val int minutesOfDay= (x.getHour() * 60) + x.getMinute()

rule "Auto Close Blinds - Calcs"
        Item BlindsClosedBy received update
    or  Item BlindsSunsetAdjustMinutes received update
    or  Item rrjjuu received command
logWarn("loggerName", "Auto Close Blinds - Calcs")

rule "Auto Open Blinds - Calc"
        Item BlindsOpenUntil received update
    or  Item BlindsSunriseAdjustMinutes received update
    or  Item rrjjuu received update
    logWarn("loggerName", "Auto Open Blinds - Calc")

I have 3 other files with rules in them, all related and show the same pattern.

If I put all rules into one file then it works ok. As soon as I split out into seprate files, it breaks.
If file “A” was the last one to be edited, it will work and “B” will not. If I edit “B” then “B” will work and “A” will not.

I don’t suppose anything like this has been seen by anyone else?

All rules are ok and function as-expected, left out here for brevity

worth adding, I am triggering these from

All rules have a unique name?

1 Like

Since a few days I’m struggling with a simular problem:
From time to time a switch in my basicUI is not starting a rule what shell trigger on it:

Item SwitchItem received command ON

I log-file I can see the item is receiving the ON-state, but the rule is not starting.
When I’m saving the rules-file in VSCode once again the rule is fireing once more. But maybe only for a few times.
I’m working with textual rules and items in OH3 on a Raspi3B.
Until now I’ve idea about the reason. Everthing what I’ve tried to explore this behavior was not successful.
Mostly all rules in this rules-file stop firering after I saved the astro.things-file.
So today I moved my astro-binding-definition from things-file to the OH3-main-UI.
Since this moment the rules are fireing. Let’s wait and see …
Maybe this can be a starting point for you.

Sorry - been a manic week with work.

yup. I checked that actually as I noticed a new error in the logs with rules.
It works when they’re all in the same file, not when they’re in separate files

interesting. Glad it worked when moving to the UI. Sadly, it’ll be a while before I can move the rules to the new UI.

Was it the same where they worked and just stopped working?

I’d love to start moving the rules to the new UI but it’ll take a while and one has to live too :slight_smile:

I am finding more and more examples of this happening which is now becoming crippling :frowning:
Latest pattern seems to be:

  1. Have items which fire rules without issues
  2. Edit item file, rules stop firing.
  3. Touch rule file and rule springs back into life.

Could it be that the link between an item and a rule is broken when the item is changed?
If this was true then it would be quite a large problem.

Found a way to recreate it!


Group g_test1

Number hhtest1 (g_test1)
Number hhtest2 (g_test1)
Number hhtest3 (g_test1)


rule "DDD"
when Member of g_test1 changed
    logWarn("FFHH", "Starting")
  • Save the rules files, change one of the item’s value
  • watch the rule fire
  • edit the item file, simply add a carriage return, and save the file
  • Change the value of the item and watch the rule not fire.

Initial try

Attempt after a few minutes - same

Edit the rule file

it works! Clearly there is a disconnect between an item and a rule which triggers from a group.
Could someone else try this and confirm please?

1 Like

This may be the same as I see, yes it feels like something is “disconnected”.
But I have to go to work first.

Would you confirm your actual filenames? I have seen a weird suggestion that fred.rules may interfere with fred.items etc.

I have the same performance with astro binding even when loaded from the UI.
The rise and set start events simply do not fire the rule.
Tried various combinations, even changing time zones, but still rules do not fire.

(Solved) I my case the solution was quite trivial.
When typing the trigger for sunrise or sunset events the word START must be typed in ALL CAPITAL letters. Typing Start or start will not trigger the rule

1 Like

I could not recreate this fault. It works as it should do.
Btw, I used this rough sitemap, for changing Item value:

sitemap test label="test"
    Frame label="Test" {
        Setpoint item=hhtest2 minValue=0 maxValue=21 step=1

For this test I created files named test.items, test.rules and test.sitemap
Im running openhab 3.1.0~S2131-1 .deb
But something was fishy, and that is why I started tracking “unstable”
I have not changed anything of importance to my rules and items on this snapshot, so I can not tell if this is better or not.

I’ve just realized that is not the same problem.
You’ve switched to Member of triggering, and then edit member Items.
I understand Member of actually expands out to individual Items when DSL rules are compiled i.e. editing members after rule compile time is almost certainly doomed.

Does hint at a possible mechanism though -

  1. if OH3 compiles triggers pointing at some internal reference to an Item
  2. editing an Item destroys the old reference and makes a new one
  3. any xxx.items file based reload is treated as an edit of all included items

then pre-existing rules will be left with non functional triggers pointing to dead Item references, until rules are recompiled.


I can confirm this and it’s also the case for the other supported rules languages. If you change the Group membership, you must reload the rules that have Member of triggers to regenerate them with the changed Group membership.

I do not know if this is also the case for UI created Rules. To some degree I’ve backed off of heavy use of Member of triggers in my UI based rules so I don’t have any direct experience. Though given what I know about the UI rules, it might be the case that those do not require a reload.

1 Like

Thanks for confirming chaps

I have a similar problem, not sure about the root-cause or how to fix it: Rule does not work dependent on position in rule file - #5 by rlkoshak

I was linked to this threat (obviously bad search on my side; sorry!). I have no single " Member of trigger", hence I can exclude this. If the topics are too similar, feel free to close mine with a proper hint.

It this a known bug of OH3 or a bug in the files on my site? I am kind of lost how to solve this.

Thanks and best

Has this been cleared up a bit more anywhere? I am running into a similar situation where my rules are not triggering. These rules are imported into a new install of OH3 from OH2 so I know they were working.

I can get them to trigger if I play around with the files, put the rules in individual files, etc, but I cannot seem to pinpoint the behavior.

The items are grouped, but I am not sure how to work around the issue.

Dear dot850,

unfortunately I can not give you any advise. I was hoping that an update fixes this!

Nevertheless it proves something setup-independent is going wrong.

Anybody out there who can help to fix this?

Thanks and best!

Same problem here!