openHAB version: 3.0.0 <- I certainly updated to 3.1.0 Testing
Issue of the topic: Rules aren’t triggered, do not show in main UI, after saving the file, the rule shows in main UI and can be triggered again.
Today a rule wasn’t triggered so I checked the main UI what the rule was doing there and it didn’t exist there (happened after reboot). So I saved the rule file again (after adding a clear line) and the rule popped up and was to be executed. I don’t have any log errors or warnings about this.
Does someone else also have this problem?
(By the way, I executed option 41 - testing again in openhabian-config, but in main UI it says below, not sure if that supposed to be 3.1.0 - testing?)
Happened multiple times now after reboot, i.e. for several rules / files. The total count of rules in the Main UI does change when the rule is added after save. I have 215 rules in total, but maybe a bit more if some aren’t calculated at this moment. Every rule in my files start with 1 - , 2 - , 3 - , 4 - , etc. The reason I did this is it’s easier to bug fix because of the error in openhab.log [Script execution of rule with UID ‘test-1’ failed:] > the first rule in that file. Some of my files have 15 rules, so it’s more easy to find
This is a severe bug and I hope it’s beiing fixed. I’m on Testing 3.0.0 version but I had the same problems on the stable version 3.0.0. I don’t hope it’s due to the 64 bit version of openhabian i’m running. So I hope anyone with 32bit has the same problems. Maybe I will test the 32bit version, but that means I have to reinstall it on my SSD and had a lot of problems when installing 3.0 couple of weeks ago, so i’m not a fan of doing this
There are a number of similar reports knocking around on this forum. Most often, the observation is that some expected rule fails to trigger, and the recovery is to edit the xxx.rules file.
I think all these instances are associated with DSL rules loaded from xxx.rules file rather than UI, but as with your own post that is an inference and not explicit. It is possible that files-based users are just more likely to notice and provide detailed comment!
Again, by inference rather than direct observation - these incidents of triggers or rules ‘lost’ seem to be associated with other editing activity - editing Items, usually.
Do you think that is the case for you? It would be an important factor to know.
It might be coincidence just because most OH3 systems are being tinkered with a lot.
Note, there is red herring knocking about - there is a known problem involving only ‘Member of’ group triggers that can be messed up after rule load time if you edit the Group membership Items. This appears to be something different that produces similar enough symptoms to get confused with what I think you are observing. But it might be closely related.
There has been a report that ‘System started’ triggers in DSL rules files no longer run when they used to in OH2. Often this would be a ‘nuisance’ invoking S-S when doing editing work - but I wonder if it was in fact necessary in some way.
I had to read carefully because your english is well above my english I think ;). But from what I read, editing item could be the trigger of not loading/triggering the rules. You are correct that after migrating to OH3.0 i tinker a lot with the code because of these problems / bindings with extra’s / code beeing slightly different / etc.
My example I encountered last night was this. Due to a problem with a binding I had to stop / start the binding / delete things / add them again / delete items / add them again. So a lot was going on in my system. After that we went to sleep and then one of the rules is being called at a certain moment to set some proxy’s for the lights at night:
rule "9 - Proxy instellen voor alle verlichting"
when
Item System_pod_mode received update or
Item SetLights changed to ON
then
if (System_pod_mode.state == "voorochtend"){
PrxOverloop.postUpdate(20)
PrxHal.postUpdate(80)
PrxSlaapkamerspots.postUpdate((cfgSlaapkamerLuxOchtend.state as DecimalType).intValue)
PrxSlaapkamerlamp.postUpdate((cfgSlaapkamerlampLuxVoorochtend.state as DecimalType).intValue)
lgSlaapkamer_A.sendCommand((cfgSlaapkamerAmbOchtend.state as DecimalType).intValue)
}
if (System_pod_mode.state == "ochtend"){
PrxBijkeuken.postUpdate(100)
PrxHal.postUpdate(80)
PrxOverloop.postUpdate(cfgOverloopLuxOchtend.state.toString)
lgKeuken_A.sendCommand(45)
.
.
.
etc.
So these 2 items (System_pod_mode & SetLights) didn’t trigger this rule, in fact the rule wasn’t loaded according to the Main UI. But these two items aren’t part of what I tinkered with last night. They where never reloaded, at least not on purpose, although the system tends to reload a lot when you save some item files.
You wrote:
[ there is a known problem involving only ‘Member of ’ group triggers that can be messed up after rule load time if you edit the Group membership Items.]
Do you mean, if one uses the trigger [Member of] in rules? Or just if items are related to a group and are changed one way or the other?
Hope I gave a bit more information with this, looks like this is a problem which have to be solved to get OH3.0 a bit more stable.
btw, just to be curious, what does this mean > [Often this would be a ‘nuisance’ invoking S-S when doing editing work]
I can’t comment on the rest but I can talk about this one. In OH 3 the concept of run levels was created. System started triggers now means “the system has changed to run level 20”. But, as you might imagine, the run level only changes when openHAB starts up. If you reload a .rules file later the System started rules won’t trigger because the system will already be past run level 20.
This is actually more “correct” for a trigger named “System started”. I believe there is work, or at least discussion about adding a “Rule reloaded” trigger to handle the case where the .rules file is reloaded after OH has already started.
This problem has to do with changing the members of a Group. When you have a Member of trigger, that actually gets replaced with Item triggers when the .rules file is loaded. Consequently, when you change the Group’s members the rule’s triggers won’t change to reflect the new membership until you reload the rule too.
Sorry, native speaker I will try to avoid phrases like “red herring”, which just means “false clue” and has nothing to do with fish.
I’ve no doubt about that.
More curiousity about how it used to get invoked in OH2 - was some other hidden rule re-initialization going on, that doesn’t happen in OH3? (Which could have masked or been a deliberate fix for the observed problem)
Just that OH2 users would be surprised to have their “System started” rules suddenly running when they’d only edited something.
As Rich says, OH3 “System started” is acting more like it says it will.
It’s just an aside really, from thinking about what are the knock-on effects of editing.
I think this is important, and maybe missed by other people with this problem.
I guess we need a way to see when rules are ‘unloaded’ for diagnosis.
I actually had to post an explanation for that on this forum years ago.
In OH 2.5 there was no initialization event or run levels so the System started rules where triggered when the .rules file was done loading. Thus when ever the file was changed or when OH restarted and loaded the .rules files those rules would be triggered.
In the NGRE in PaperUI, System started rules never worked at all. I think that was one of the things that drove us toward these run levels. That and the age old problems where rules would start running before everything else is ready for them to start running. That problem is also fixed with the run levels.
For now the recommended approach to rerun those rules after OH has started is to manually run them from MainUI. If you’ve a lot of them you could even create a rule that runs those rules so you only have one rule you have to manually run.
If it’s not shown in MainUI that’s probably a pretty good indication that the rule did not get loaded and created.
One could edit $OH_USERDATA/etc/log4j2.xml and change the log level for openhab.event.RuleAddedEvent to INFO or DEBUG and entries will be added to events.log when the rule is loaded and created and I think unloaded too. Unfortunately, the rule ID will be automatically generated so one will have to go back to MainUI and correlate the log statements that only show the UID and that label for the rule. You could change the other Rule event log statements to see other rule events (e.g. rule runs, rule becomes idle, etc).
Or one can use the event stream in the developer sidebar to see the rule events as well if you don’t want to change the logging config.
I agree that ‘system started’ should be when system starts, I like this way! But I [mis]used it a lot in OH2.x. When I started with OH2.3 I thought it was pretty strange but got used to it. Glad it now is as it should be in my opinion.
Don’t be sorry! I like when people use their own expressions! When it’s not clear i’m glad to ask the meaning of it
I don’t use any of these. I’m not very good at the semantic model and grouping side of openhab, Don’t get me wrong, I use groups and the semantic model for OH3 is finished (via text files) but it feels like in some situations I better use ‘member of’ then other sollutions. But this could not be the reason why my rules aren’t loaded/fired.
Funny thing, this morning I reloaded openhab and a while after that I posted this thread. At that moment I had 215 rules, I wrote only one rule today, but I just checked and now I have 228 rules! And my system load was running low (about 5% cpu usage and 0.3 load) at that moment. But I still had 215 rules, so that tells us, Openhab “searches” in some sort of way new rules or get’s triggered to add them because of an item being triggered maybe during the rest of the hour/day.
This is interesting to know!
When I have the time, I will try that. I’m getting a little familiar with the new logging type so it wouldn’t be to much of a hazzle to do this.
The typical thing is, some of my rules refuse to load sometimes. but most of them are loading/fireing always. It’s almost always a couple of rules which have this problem. I’m trying to find out what the correlation is between these rules.
In my situation it looks like it only happens when openhab reloads or when I save big item files which couses reloads of multiple files.
Can we report this anywhere or is it investigated somewhere on Github?
This is the sort of comment seen in other threads; working on other files is suggested to mess with rules.
There’s no firm word of that yet, going to be hard to demonstrate.
Existing issue -
This one I’m sure is a statement of the very specific ‘Member of’ trigger issue.
(I’m now having a vague memory that a fix in OH2 was or could be to reload rules files … and so eventually get System started triggers. This stuff is all incestuous .)
I do not think there is a current issue for this more general issue.
I will try to avoid phrases like “red herring”, which just means “false clue” and has nothing to do with fish.
.)
, it was more of an explanation why I didn’t use [member of] trigger