Rule does not trigger with "Member of ... changed"

Setup, Configuration and Use Scripts & Rules
1

I had a rule that worked fine with OH2.5 and now with OH3 it does no longer trigger.

What I want to achieve:
A switch that is connected to my garage door should behave like a push button (ie turn off after a short amount of time)

Items:

Group:Switch gSchalter (gHaus)
Group:Switch gSchalter_Garage_Tor (gSchalter, gGarage_Tor)

Switch  Schalter_Garage_Tor_Links       "Schalter Garagentor links [%s]"        <garagedoor>    (gGarage, gSchalter_Garage_Tor)                 { channel="homematic:HG-HM-LC-Sw4-WM:HMCFGUSB2:nnn:1#STATE" }
Switch  Schalter_Garage_Tor_Rechts      "Schalter Garagentor rechts [%s]"       <garagedoor>    (gSchalter_Garage_Tor, gGarage)                 { channel="homematic:HG-HM-LC-Sw4-WM:HMCFGUSB2:nnn:2#STATE" }

Rule:

rule "Taster Garage betaetigt"
when
        Member of gSchalter_Garage_Tor changed from OFF to ON
then
logInfo("Garage","Schalter betätigt")
        val schalter = triggeringItem
        createTimer(now.plusSeconds(1)) [
logInfo("Garage","setze Schalter zurück")
                schalter.sendCommand("OFF")
        ]
logInfo("Garage","Schalter fertig")
end

The rule does not trigger, even the first logInfo is not written. When I trigger the rule manually through the UI the logInfos are written (but obviously nothing happens as no actual item did trigger the rule). Any idea what changed in OH3 that causes my rule now to no longer trigger?

2

Are the members really OFF or maybe they’re uninitialized (NULL) ?
Does the channel really get triggered ? What does events.log say?

3

Usually we’d see a pipe | character after that [

4

Yes, both members are OFF:

image
image745×757 30 KB

Eventlog:

2021-07-27 22:35:52.030 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Schalter_Garage_Tor_Rechts' received command ON
2021-07-27 22:35:52.043 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Schalter_Garage_Tor_Rechts' predicted to become ON
2021-07-27 22:35:52.045 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gSchalter_Garage_Tor' changed from OFF to UNDEF through Schalter_Garage_Tor_Rechts
2021-07-27 22:35:52.046 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Schalter_Garage_Tor_Rechts' changed from OFF to ON
5

You’re right - this got lost somehow, maybe when I added the logInfo I accidently deleted it. The strange this is, now the rule is working again - whatever caused it before to not work. I think the missing | shouldn’t have been the issue as the rule not even got triggered.

At the moment I think maybe it didn’t even have to do something with OH. My system behaves strange, crashes from time to time and Ubuntu forced me the 2nd time in 3 days now to run fsck manually at boot. Maybe my SSD is end of life and produces some strange behaviors. I will replace it and see if the system becomes more stable again.

Many thanks for your help though!

6

Something weird about your Group; with no aggregation function defined, it should not have been OFF to begin with. Think there’s some kind of default Equality function though.

Note, if you are doing development, members added to Groups after the rule has been loaded will not trigger it. The list of targets is built from membership at rule load time.
Editing the rules file refreshes the trigger list.

You didn’t mention your full OH version, so may also need to be aware of this - any Item edit losing rule trigger link

although it is reported fixed at 3.1

7

Ok thanks for that information. I am on OH 3.1.0 (moved from OH 2.5.12). Is there any way I can force the rules to load after the items? The items are defined in file Homematic.items and the groups in Groups.items, rules are in Taster_Garage.rules. Are the files loaded in alphabetical order? I could rename them eg with a number in the beginning to set the right order.
However, I had modified the rules file several times, log always said that the rule file was updated and reloaded but the rule still did not fire. Now it does and I am not sure why now and why not before :slight_smile:

8

Well, you had a typo in it before, now you don’t.