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.
items
//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)
rules
blinds.adjust.rules
rule "Blinds - Adjust Blinds Close By"
when Item BlindsClosedByAdjust received update
then
logWarn("loggerName", "Blinds - Adjust Blinds Close By")
//snip noise
end
rule "Blinds - Adjust Blinds Open Until"
when Item BlindsOpenUntilAdjust received update
then
logWarn("loggerName", "Blinds - Adjust Blinds Open Until")
end
rule "Blinds - Adjust Close Blinds Adjust Minutes"
when Item BlindsClosedByAdjustMinutes received update
then
logWarn("loggerName", "Blinds - Adjust Close Blinds Adjust Minutes")
end
rule "Blinds - Adjust Blinds Open Until Adjust Minutes"
when Item BlindsOpenUntilAdjustMinutes received update
then
logWarn("loggerName", "Blinds - Adjust Blinds Open Until Adjust Minutes")
end
blinds.adjust.calc.rules
import org.openhab.core.model.script.ScriptServiceUtil
val getMinuteOfDay= [ZonedDateTime x |
val int minutesOfDay= (x.getHour() * 60) + x.getMinute()
minutesOfDay
]
rule "Auto Close Blinds - Calcs"
when
Item BlindsClosedBy received update
or Item BlindsSunsetAdjustMinutes received update
or Item rrjjuu received command
then
logWarn("loggerName", "Auto Close Blinds - Calcs")
end
rule "Auto Open Blinds - Calc"
when
Item BlindsOpenUntil received update
or Item BlindsSunriseAdjustMinutes received update
or Item rrjjuu received update
then
logWarn("loggerName", "Auto Open Blinds - Calc")
end
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
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.
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
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
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 -
if OH3 compiles triggers pointing at some internal reference to an Item
editing an Item destroys the old reference and makes a new one
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.
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.
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.