I have a strange phenomenon since a few days. It seems that a rule is being executed:
10:52:50.121 [DEBUG] [re.automation.internal.RuleEngineImpl] - The trigger 'Time_cron_0_10_d502d7a1505c11ed9b5f0800271b840c_d6491340505c11ed946d0800271b840c' of rule '1512cf09-6295-4ce2-a3eb-e23a91bd5094' is triggered.
10:52:50.137 [DEBUG] [re.automation.internal.RuleEngineImpl] - The rule '1512cf09-6295-4ce2-a3eb-e23a91bd5094' is executed.
This Rule turns on all the lights for me. Now I have rules that should turn on lamps, but they don’t have a cron trigger but are event based. They never caused any problems before. I have now gone through all the rules and in the only two rules (from 1708) where cron is used, no item is used that has anything to do with lamps. So also no item, which triggers another rule event-based.
If I go into karaf, I also don’t see a corresponding ID for such a rule or this “cryptic” name at all.
With me, my Rules always have unique names. I also looked, but all Jupyter notebooks are deactivated, no rule is active in JSR223 either and not in HABApp either.
How would you proceed now to find out which Rule is ultimately causing this problem?
Go to MainUI → Developer Tool → API Explorer and scroll down to the Rules. Open the /rules/{ruleUID} end point, “Try it out” and paste that rule UID into the form and see what comes back.
That should tell you what rule it’s talking about. That UID looks like one of the UIDs that gets automatically generated from a text based JSR223 rule when the ID is not specified (which is why it might be hard to find).
Learned something again. Has unfortunately brought nothing. It comes a 404 error and that the rule does not exist. I have deleted the rules that are not text-based. But they were actually deactivated before. And I deactivated Jython scripting to be on the safe side. Maybe this works.
Bit suspicious about this. It has the feel that a periodic cron trigger is “stuck” in the scheduler, calling a captured version of the rule.
If you later delete or edit a rule, it should remove the trigger from the scheduler and so allow the garbage collector to clear away the linked ghostly rule … but what if that process messed up for some reason?
I would still expect a reboot to sweep it away.
I stopped openHAB and cleande the /var/lib/openhab/tmp and /var/lib/openhab/cache folder. I can now rule out the possibility that it was not Jython. I have now simply moved all rules. So /etc/openhab/rules to /etc/openhab/rulesbak. So it should start completely without rules, because the cache is empty.
In the intermediate step I had also restarted openHAB after I had already cleaned up the two folders once. Since I would have actually hoped that this would work.
sudo mv /etc/openhab/rules /etc/openhab/rulesbak
sudo systemctl stop openhab
sudo rm -r /var/lib/openhab/tmp/*
sudo rm -r /var/lib/openhab/cache/*
sudo systemctl start openhab
# now no rules are existing
sudo mv /etc/openhab/rulesbak /etc/openhab/rules
# now all rule models are loaded, but I see that the rules are still not existing again.
sudo systemctl stop openhab
sudo rm -r /var/lib/openhab/tmp/*
sudo rm -r /var/lib/openhab/cache/*
sudo systemctl start openhab
# now all rules will exist again and work
The presumption would then probably be that a Rule had blocked in some way. And regardless of the fact that I start/stop openHAB and clear cache & tmp.
Hmmm…this looks striking similar to an issue I faced several years ago in OH2.
That has been fixed for some time, but I wonder if there isn’t something similar going on here just a little further down the line. Can you share the cron statement that you use in the rule that caused the issue?
Sadly not. I have had to move all the rules. This means that in the end I could not find out which rule really caused the error. With me the lamps go on by the error. What I can say, however, is that no cron is used for all rules that have to do with lamps. That’s what irritated me the most about it.
Okay, I had actually taken out a few rules individually. If I put them back in, the error happens again. With this I can limit the errors to the following rules:
rule "Badlicht an"
when
Item iApplikation_Alexa_BadLicht changed to ON
then
// Alle Lampen ausschalten
gBad_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, ON)
Thread::sleep(50)
}
]
end
rule "Badlicht aus"
when
Item iApplikation_Alexa_BadLicht changed to OFF
then
// Alle Lampen ausschalten
gBad_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, OFF)
Thread::sleep(50)
}
]
end
rule "IoTlicht an"
when
Item iApplikation_Alexa_IoTLicht changed to ON
then
// Alle Lampen ausschalten
gIoT_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, ON)
Thread::sleep(50)
}
]
end
rule "IoTlicht aus"
when
Item iApplikation_Alexa_IoTLicht changed to OFF
then
// Alle Lampen ausschalten
gIoT_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, OFF)
Thread::sleep(50)
}
]
end
rule "Multimedialicht auf Blau"
when
Item iApplikation_Alexa_MultimediaLichtBlau changed to ON
then
// Alle Lampen ausschalten
gMultimedia_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, HSBType.BLUE)
Thread::sleep(50)
}
]
iApplikation_Alexa_MultimediaLichtBlau.sendCommand(OFF);
end
rule "Multimedialicht an"
when
Item iApplikation_Alexa_MultimediaLicht changed to ON
then
// Alle Lampen ausschalten
gMultimedia_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, ON)
Thread::sleep(50)
}
]
end
rule "Multimedialicht aus"
when
Item iApplikation_Alexa_MultimediaLicht changed to OFF
then
// Alle Lampen ausschalten
gMultimedia_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, OFF)
Thread::sleep(50)
}
]
end
rule "Kuechenlicht an"
when
Item iApplikation_Alexa_KuechenLicht changed to ON
then
// Alle Lampen ausschalten
gKueche_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, ON)
Thread::sleep(50)
}
]
end
rule "Kuechenlicht aus"
when
Item iApplikation_Alexa_KuechenLicht changed to OFF
then
// Alle Lampen ausschalten
gKueche_Lampen?.allMembers.forEach[item|
if( item instanceof ColorItem )
{
sendCommand(item, OFF)
Thread::sleep(50)
}
]
end
However, the state of these trigger items is currently still NULL.
I have now changed the rules so that when changes from OFF to ON, that they are triggered.
Item iApplikation_Alexa_BadLicht changed from OFF to ON
...
Interesting observation. Some “ghostly happenings in the night” have previously been traced to zwave linked Items going to NULL state, apparently linked to nightly heal process. (they shouldn’t)
Later of course a NULL->ON or whatever update occurs which may cause unexpected rule triggers. These events should be visible in your events.log (I think the original transition to NULL is not, but you see Thing status changes instead)
If it’s a change it should still show up as a change in events.log. Only ItemStateUpdateEvents are suppressed (they can be enabled by setting the log level on that event to INFO instead of WARN).
@Michdo93, one thing you can do to see if @rossko57’s idea is happening is to add a log statement at the top of these rules and log out previousState. If it logs NULL around midnight you have a pretty good clue that’s the reason. You can prevent the lights from going on by adding
if(previousState == NULL) {
return;
}
That will prevent the rule from doing anything when the Item changes from NULL.
In the UI you can handle this in a rule condition.
mm, but I think the NULL state is arrived at by some underhand means (after all, a binding should never set NULL state) somehow the Thing activity causes Item reinitializing, not a state update.
Anyway, just supposition at this time, events.log will record unexpected transitions from NULL for evidence.
