Mysterious Continuous Triggering

📐 Rule Machine®
1

I have a rule that locks and unlocks a doggy door based on a bunch of things (e.g., whether it's dark outside, whether either of the back gates are open, whether anyone is home, etc.). My rule works fine; you can see the triggers below (I won't bore you with the whole rule).
image

I don't like the fact that my weather device (I use DarkSky) only updates periodically, so it can get dark and the door might not lock for a while. So, I thought I'd get cute and add a poll of the weather service at the beginning of the actions. Setting aside the fact that I now understand that isn't the best way to solve my original problem, I did notice some very odd behavior that I thought @bravenel would want to know about. If I add the polling statement as a first action during the day time when it's light out, the rule keeps triggers infinitely, this despite the fact that it should only trigger when the weather device is LUX<=50 (And I confirmed that it's the Weather that's triggering the rule and it's Lux reading, as you can see below, well into the daylight region.

Could this be a bug? Why would the rule the trigger continuously?

2

I'm afraid it's going to remain a mystery until you show the rule and some logs.

1 Like
3

You actually want FACTS? You're so demanding, Bruce! :stuck_out_tongue_winking_eye:

Below is the rule and log....note that the first action of the rule (which is the custom action of the DarkSky DH to poll the server and refresh weather attributes) is what recreates the infinite triggering of the rule via the illuminance trigger. When I remove it (which I've done because it's not even proper logic), the "false" triggering goes away.

Honestly, I don't need this problem solved since the idea of updating weather attributes after triggering is a flawed approach on my part. I only bring it to your attention in the event it uncovers some underlying problem that will help others. So many people in this community have helped me.

image
image.png710×514 141 KB

Here is the log. When you scan from the bottom up, you'll see one full iteration of the rule, and just the beginning of the second. The rule retriggers infinitely. Why would it triggers at daytime illuminance levels, absent mode or gate changes?

app:11272019-09-29 02:48:54.215 pm infoAction: IF (Doggie Door Lock unlocked(T) [TRUE]) THEN

app:11272019-09-29 02:48:53.802 pm infoAction: pollData() on Weather

app:11272019-09-29 02:48:53.484 pm infoDoggie Door Lock Management v2 Triggered

app:11272019-09-29 02:48:53.345 pm infoDoggie Door Lock Management v2: Weather illuminance 3847

app:11272019-09-29 02:48:52.709 pm infoAction: END-IF

app:11272019-09-29 02:48:52.678 pm infoAction: Notify Mark (Pushover): 'Attention, the doggie door has been unlocked since it's not dark, the gates are closed, and somebody is home.' (skipped)

app:11272019-09-29 02:48:52.629 pm infoAction: Unlock: Doggie Door Lock --> delayed: 0:10:00 (cancel) (skipped)

app:11272019-09-29 02:48:52.573 pm infoAction: IF (Doggie Door Lock locked(F) AND North Gate, South Gate all closed(T) AND Mode in Day, Evening(T) AND Illuminance of Weather(3847) is > 100(T) [FALSE]) THEN (skipping)

app:11272019-09-29 02:48:50.515 pm infoAction: END-IF

app:11272019-09-29 02:48:50.508 pm infoAction: END-IF

app:11272019-09-29 02:48:50.502 pm infoAction: Cancel Delayed Actions (skipped)

app:11272019-09-29 02:48:50.488 pm infoAction: Notify Mark (Pushover): 'Attention, the doggie door has been locked because it has gotten dark.' (skipped)

app:11272019-09-29 02:48:50.448 pm infoAction: Lock: Doggie Door Lock (skipped)

app:11272019-09-29 02:48:50.363 pm infoAction: IF (Illuminance of Weather(3850) is <= 50(F) [FALSE]) THEN (skipping)

app:11272019-09-29 02:48:50.136 pm infoAction: END-IF

app:11272019-09-29 02:48:50.127 pm infoAction: Cancel Delayed Actions (skipped)

app:11272019-09-29 02:48:50.114 pm infoAction: Notify Shane (app), Caden (app), Odette (app), Mark (Pushover): 'The doggie door has been locked because no one is home (or awake).' (skipped)

app:11272019-09-29 02:48:49.990 pm infoAction: Lock: Doggie Door Lock (skipped)

app:11272019-09-29 02:48:49.977 pm infoAction: IF (Mode in Asleep, Away, Vacation(F) [FALSE]) THEN (skipping)

app:11272019-09-29 02:48:49.762 pm infoAction: END-IF

app:11272019-09-29 02:48:49.755 pm infoAction: Cancel Delayed Actions (skipped)

app:11272019-09-29 02:48:49.744 pm infoAction: Notify Shane (app), Caden (app), Odette (app), Mark (Pushover): 'Attention, the doggie door has been locked because a gate in the backyard is open.' (skipped)

app:11272019-09-29 02:48:49.680 pm infoAction: Lock: Doggie Door Lock (skipped)

app:11272019-09-29 02:48:49.654 pm infoAction: IF (North Gate, South Gate any open(F) [FALSE]) THEN (skipping)

dev:12272019-09-29 02:48:49.630 pm infoDarkSky.net Weather Driver - INFO: Polling DarkSky.net

app:11272019-09-29 02:48:49.219 pm infoAction: IF (Doggie Door Lock unlocked(T) [TRUE]) THEN

app:11272019-09-29 02:48:46.415 pm infoAction: END-IF

app:11272019-09-29 02:48:46.405 pm infoAction: Notify Mark (Pushover): 'Attention, the doggie door has been unlocked since it's not dark, the gates are closed, and somebody is home.' (skipped)

app:11272019-09-29 02:48:46.378 pm infoAction: Unlock: Doggie Door Lock --> delayed: 0:10:00 (cancel) (skipped)

app:11272019-09-29 02:48:46.374 pm infoAction: pollData() on Weather

app:11272019-09-29 02:48:46.322 pm infoAction: IF (Doggie Door Lock locked(F) AND North Gate, South Gate all closed(T) AND Mode in Day, Evening(T) AND Illuminance of Weather(3850) is > 100(T) [FALSE]) THEN (skipping)

app:11272019-09-29 02:48:45.062 pm infoDoggie Door Lock Management v2 Triggered

app:11272019-09-29 02:48:44.859 pm infoDoggie Door Lock Management v2: Weather illuminance 3850

4

I think your rule would work if it began with something like:

IF
   Illuminance > 50
   Exit Rule
END-IF

Without that, I think it is triggered again because of the pollData().

5

Thanks - but per my note above, I'm no longer trying to solve the problem with the rule. It's solved.

The question that remains is why pollData() triggers this rule when actual LUX is in the thousands?

6

Seems to be a problem with the DarkSky driver. I wonder if each time pollData() is called, it resets to 0 and then to current lux value.

1 Like
7

Yeah that's my working theory too -- that's the only thing that explains the behavior. Unless there's some weird RM thing going on.

1 Like
8

No, I tried reproducing something like your rule with lux values from Fibaro Multi-sensors and cannot. So it isn't a generic issue.

I'm looking at the DarkSky driver code now.

9

It would also probably trigger if they marked the events as isStateChange : true. I didn't look at the driver, as I don't use that integration. Just thinking out loud.

2 Likes
10

No, this shouldn't cause the implicit condition to fail. I can't get a similar trigger to fire with a high lux value.

11

Good point. I don't know, I never make "becomes"/</> triggers. I handle it explicitly in the conditions. The couple of times I tried a > or < implicit condition on RM4 it didn't work (always triggered on every value update). But that was a few releases ago, and I haven't tried again since.

12

Seems like this is an unintended consequence of how the DarkSky driver works -- @aaiyar let us know if you find anything. In the meantime, I'm not polling the weather for this use case anyway, so all good.

13

In my constant quest to keep my Hubitat running smoothly, I've came across this as well.

I have rules triggered by (Philips Hue) illumination censors. Every time the censor reports illumination, the rule will trigger. If illumination is higher than the "less than" value specified in the rule, the rule will not execute. But every time the illumination is indeed lower, the rule will execute, with SKIPPED values, if some conditions are not met. The rule is only supposed to execute if the illumination is lower AND between certain hours.

I have ten similar rules. Is this putting strain on my Hubitat?
It would be nice to restrict the times the rule trigger...