OH 2.2 bug - Group item rule does not fire until rule file reloaded

Setup, Configuration and Use Scripts & Rules
1

I’m using the following configuration:

Group:Switch:AND(OFF, ON) gHomePresence "Occupied [(%d)]" <presence>

rule "houseOccupied"
when
    Item gHomePresence changed from OFF to ON or
    Item gHomePresence changed from ON to OFF
then
    logInfo("h", "h")
    if ( systemStarted.state == ON ) {
        lock.lock()
        try {
            houseOccupiedCheck.apply()
        } finally {
            lock.unlock()
        }
    }
end

After a restart of OH the rule will not fire (h is never logged) no matter how many times I transition gHomePresence between ON and OFF.

As soon as I touch the rules file to cause OH to reload the file the rule starts firing as expected.

I’ve upgraded from 2.1 which did not have this issue. Is anybody else seeing similar issues?

2

@Kai Do you have any ideas on this issue or any pointers on extra logging I can enable to try and debug further?

3

Did you try to look in to the log? (Using the karaf console with the command “log:tail” will give a constant readout!)
Further Information on logging.

What is the state of gHomePresence after a restart (UNKNOWN ?).
Your Trigger could be simplified to “Item gHomePresence changed”.

BTW: You can expect an answer by the community on such a problem. However please note that this is an opensource project, nobody is making his living from that. So give the community some time for answering.

4

Yes I’ve looked in the log and it’s not a case of gHomePresence moving from NULL to either ON or OFF. The log clearly shows transitions from ON to OFF and OFF to ON, but my logInfo in the rule is not logging anything.

Last week I was using the simplified “Item gHomePresence changed”, but changed it after I noticed a problem with the rule not firing. I thought explicitly checking the state transition had somehow solved the problem, but it turned out that it was solved by the rule file reloading.

5

I had similar issue in an older version, I think it was OH2.0.
There I also needed to edit and save the rule filem and then it ran propperly.
But now the problem is gone, without knowing really why.

Holger

6

For testing purposes I have the following rules:

rule "houseOccupied2"
when
    Item gHomePresence received update
then
    logInfo("gHomePresence", "update")
end

rule "houseOccupied"
when
    Item gHomePresence changed
then
    logInfo("gHomePresence", "changed")
end

On startup the openhab log has:

2018-01-15 18:40:44.305 [GroupItemStateChangedEvent] - gHomePresence changed from NULL to OFF through rHome

The events log has:

2018-01-15 18:41:25.165 [INFO ] [smarthome.model.script.gHomePresence] - update
2018-01-15 18:41:25.171 [INFO ] [smarthome.model.script.gHomePresence] - update
2018-01-15 18:41:25.174 [INFO ] [smarthome.model.script.gHomePresence] - update
2018-01-15 18:41:25.171 [INFO ] [smarthome.model.script.gHomePresence] - update

After startup and toggling the state of gHomePresence by switching one of the members:

2018-01-15 18:45:15.966 [GroupItemStateChangedEvent] - gHomePresence changed from OFF to ON through guestHome
2018-01-15 18:46:42.211 [GroupItemStateChangedEvent] - gHomePresence changed from ON to OFF through guestHome

2018-01-15 18:45:15.975 [INFO ] [smarthome.model.script.gHomePresence] - update
2018-01-15 18:46:42.208 [INFO ] [smarthome.model.script.gHomePresence] - update

After using the unix touch command on the rules file:

2018-01-15 18:49:34.297 [GroupItemStateChangedEvent] - gHomePresence changed from OFF to ON through guestHome
2018-01-15 18:49:36.389 [GroupItemStateChangedEvent] - gHomePresence changed from ON to OFF through guestHome

2018-01-15 18:49:38.849 [INFO ] [smarthome.model.script.gHomePresence] - changed
2018-01-15 18:49:38.849 [INFO ] [smarthome.model.script.gHomePresence] - changed
2018-01-15 18:49:38.851 [INFO ] [smarthome.model.script.gHomePresence] - update
2018-01-15 18:49:38.856 [INFO ] [smarthome.model.script.gHomePresence] - update

I’m struggling to see how this could be a problem with my config.

7

This doesn’t affect all my groups as some of the others I’ve tested do fire a changed rule without having to reload the file.

As a test I duplicated the gHomePresence group (gHomePresence2) and included all the same members as gHomePresence. After a restart I get a changed rule firing for either gHomePresence or gHomePresence2, but it seems non-deterministic as to which one works as it changes following an OH restart.

8

Certain you do not have another rule in another file with the same name? Must be unique system-wide.

1 Like
9

Yes that was it a duplicate rule name. In the process of moving to 2.2 I did a bit of tidying up of my rules and ended up with a duplicate name.

Thanks a lot for pointing that out, its saved me hours more of messing around trying different config. :slight_smile:

If only my searching of the forums yesterday had shown:

10

I feel with you Mike, only after i solved the issue i found the proper thread. The rule naming is a semi well hidden quirk of openhab and has not jet a part in the beginners doku or somewhere. It also seems that creating some error logging is extreamely difficult. Oh well, thats what opensource means i guess :slight_smile:

11

It would be nice if OH flagged duplicate rule names. I suspect that may be non-trivial though, as overloading a ‘duplicate’ named rule is presumably how in-flight updating of a rule file happens.

12

I have just created a Pull Request against the Rules documentation to add that rule names need to be unique.

1 Like