Rules not being followed

  • Platform information:
    • Hardware: Celeron N3160
    • OS: CentOS 7.6
    • Java Runtime Environment: openjdk version “1.8.0_191”
    • openHAB version: 2.4.0
  • Issue of the topic: New setup, new rules not being followed

Just getting started with OH2, I recently removed a Vivint GoControl panel and I’m rebuilding the z-wave setup. Yesterday I defined 4 rules. Two operate a power outlet triggered by a door sensor to turn on/off a strip of LED’s. The other two rules do the same for light switch with a time of day component added. It all seemed to be working just fine until sometime earlier this morning when they just stopped. Opening or closing the doors had no effect on outlet or switch.

I reviewed the rule settings in paperui and it seemed to be set up just right and nothing had changed, so I clicked the check mark to save them. Now all four rules work again. I did reboot the system earlier and that’s likely when the failure started but I can’t be sure. So I rebooted again and confirmed the rules are not being followed until after I view and save each one.

Is there a setup step that I’ve missed somewhere?

It sounds a whole lot like a bug. @5iver, is this related to an open issue on the NGRE or should OP open a new issue. This doesn’t seem to be quite the same as the play button breaking the Rule problem.

Unfortunately, the NGRE is still named “experimental” for a reason, but we are getting really close to removing that moniker.

Not just reboots causing this. Just tried a “systemctl restart openhab2” and the rules stopped working again. A quick open and save of each one fixes them.

Would switching over to the snapshot repo bring me any luck in fixing this? I’ve been a little reluctant to use the snapshots since I’m very new to this. I’m pretty skilled with Linux though, been doing sysadmin work for about 12 years now so OS level work doesn’t faze me much.

Don’t do that until end of the month. The snapshots are basically broken, because the core is re-organized atm.

But OH2.5M1 (milestone) is quite stable, apart from an annoying scheduler warning message at the start.

The rule engine has two known problems that I know of. 1) Triggers are not registered on start (your case) and 2) A misconfiguration in one of the rules pulls the entire engine down.

And haven’t experienced any other issues so far. Hopefully both of those problems are fixed for 2.5M2.

This issue makes me wonder if it is not an example of the rule engine starting up before the Items are ready. Using Jython, I check to make sure everything is setup before letting the rules load. I’ll see if I can recreate this in my test environemnt. Although, I have seen some erratic storage services behavior, where sometimes rules are not enabled/disabled properly after an OH restart.

@BiloxiGeek, could you explain how these rules are setup… or even better, provide the json for one of them? Could you restart OH again and check to make sure the rules display aa Idle and not Uninialized - Disabled?

Do you have any more details on how to reproduce? I don’t recall this being reported before and I haven’t found an open issue for it.

Okay, I’m gonna enable the testing repo and update to the 2.5M1 milestone release tomorrow morning. Since the rules not being read in at start is there some way to fix that? Command line fix would be great in case I’m working remotely and only have ssh access into the system.

@BiloxiGeek, you replied before I could update my post… I had some questions for you.

There’s two rules. Pantry light turns on an outlet switch so the LED light strip in the pantry turns on whenever the door is open. Turns off when door is closed. Think refrigerator light.

Closet rule does the same for a light switch in the wife’s closet but only between 7AM and 9PM.
automation_rules.json (4.9 KB)

Did a restart using systemctl and all four rules show up as IDLE

I opened the first rule and then saved it so it started working again, the view in the webbrowser did not change at all. Had to di the same for the other three rules to get them to work.

I’m getting my head wrapped around wiring rules in /etc/openhab2/rules so I’m curious if rewriting these rules there will solve this?

I’m kinda an old school command line junkie sysadmin so using .rules files seems much more like my style.

I haven’t dug into this yet, but yes, you shouldn’t have this issue with the Rules DSL. However, you may want to consider using Jython or Javascript instead, which can be used to create rules for the new rule engine. I use Jython for all of my rules, but have not encountered the issue you have reported. It would be interesting if you would recreate them in Jython, if you experience the same issue.

Here are your rules in Jython, using the helper libraries…

from core.rules import rule
from core.triggers import when

@rule("Master Closet Light")
@when("Item zwave_device_2eebb52b_node4_sensor_door changed")
def masterClosetLight(event):
    if event.itemState == OPEN:
        events.sendCommand("zwave_device_2eebb52b_node3_switch_binary", "ON")
        masterClosetLight.log.debug("Turned light ON")
    elif event.itemState == CLOSED:
        events.sendCommand("zwave_device_2eebb52b_node3_switch_binary", "OFF")
        masterClosetLight.log.debug("Turned light OFF")

@rule("Pantry Light")
@when("Item zwave_device_2eebb52b_node8_sensor_door changed")
def pantryLight(event):
    if event.itemState == OPEN:
        events.sendCommand("zwave_device_2eebb52b_node5_switch_binary", "ON")
        pantryLight.log.debug("Turned light ON")
    elif event.itemState == CLOSED:
        events.sendCommand("zwave_device_2eebb52b_node5_switch_binary", "OFF")
        pantryLight.log.debug("Turned light OFF")

@BiloxiGeek, I’ve come across this issue in a test environment running OH S1534, and I just wanted to confirm that you are running OH 2.4 stable, and not a snapshot or even milestone build.

I was running the stable 2.4 when I ran into this problem. But I’ve transitioned to 2.5.0~M1 from the testing repo since then. My rules are all working now with a few adjustments. For the trigger I changed from using “from CLOSED to OPEN” to just “to OPEN”. This was necessary since the door sensor is initially in a NULL state after restart.

I’ve also transitioned to editing my rules in vim at the command line. I’m a linux sysadmin so that suits me much better. So my initial issue has been overcome by subsequent events and is no longer a problem.

1 Like