[2.3.2.136-140 C7] Rule with a custom attribute "changed" trigger not executing upon a triggering event?

Yesterday and today, one of my rules (RM 5.1) didn't run.

Looking at the logs, I see the trigger happening:

But, it simply wasn't running (the following shows that it should be logging this one line and that should have been visible in the log pasted above):

This seems to correspond to the .136 version.

I restored .135 -- and upon the reboot, it actually launched the app after it restarted.

Sometime seems amiss with .136 and that app.

@morse.caleb Any thoughts from your end? Your app is reporting the mode change--but it's simply not launching the rule.

I think there might be something else going on. From what I can tell, I didn't change anything about how the mode is being reported. Because the events are showing up in the rule, I think this may be a bug with either Rule Machine or the rule itself.

Is this a Custom Attribute trigger?

Yes.

"mode" from the Ring App

Try this on latest release. Release 2.3.2 Available - #16 by bravenel

1 Like

Well. I tried the new version and it seemed to work last night.

But, this morning, the same thing--the rule triggered but never ran.

I changed the mode back & forth...the triggers showed but the rule never ran.

Rolled back to .135 again and it started working again

I need to see the logs of it "not running". Please show me the Event Subscriptions for this rule.

Also, if you could edit the Trigger, and show me a screenshot of what comes up, that would help. Don't change anything, just cancel out of that.

Is it like this:

If so, I would expect the problem is something like an extra space in the attribute value compared to the text entered above.

Just looking for mode "changed":

Here's the rule--the "Log" line should always result in a line being logged.

I updated the triggers to add explicit checks for all possible "mode" values individually:

image

With the following Event Subscriptions:

And, when using the explicit checks, it works as expected:

Are you running 2.3.2.139? Changed for Custom Attribute triggers was fixed in 2.3.2.138 -- known to be broken before that. I cannot reproduce any failure with this.

There is a state variable called prevState. Show me what that looks like:

Yes, I went from .135 to .139 before the tests tonight.

Now, this time, it seems to be working.

I wonder if there was some latent issue--because I edited the triggers to create 3 more triggers a bit ago, after the previous failed test (so my rule would work), and I just now deleted those triggers for this test. Thus changing the event subscriptions a bit between my earlier failed test and this one. I suppose it's possible that helped address the issue.

If so, I need to figure out which other 5.1 rules I need to work on (and what to do) to make sure they fire properly going forward.

I'll see what happens in the morning.

Thanks!

It didn't work this morning again. I'm at a loss as to what is happening.

image

Here are the events for that device, showing it did change from home to off this morning:

@bravenel Does the fact it is currently showing "0" for the "%value% variable mean anything of interest?

That app has never been triggered with changed, given the prevState value. Since it's never been triggered, %value% does not show anything.

Please remove or disable the app, create a new one; turn on Event and Trigger logging, and be sure it has been Installed. Cause it to be triggered. Then show the state value for prevState, as well as logs for it.

So, I created a new rule with the same trigger and the same first few lines (enough to see if it was running).

Logs when I triggered the mode change:

All logs for just that rule:

The device mode value changed:

The new rule:

Note that nothing shows up in "Events" for the app.

Here's the info from the App Status page:

image

Note that CurrentState is the name of a local variable, which I set to "na" upon creation of the rule.

After doing that, I disabled the new rule and enabled the old rule, then created individual conditions (in addition to using changed). Again, that worked:

I'm not sure what "prevState" is supposed to show, as it is showing only the Private Boolean and the local variable; not the mode information or "value" from the trigger).

image

You're making this much harder than it needs to be. Please try KISS;

Make a new rule with only the changed trigger, no actions. Turn on Event and Trigger logging. Cause Ring to do two mode changes. Post the logs.

See this post:

The rule has always DETECTED the mode changing (and logged the mode change), it's just not running the rule's actions when it does.

When I create a rule that looks for specific modes, those are detected and properly cause the actions to run.

I am running .139 of the Hubitat firmware.

I am running the latest Ring App code.

This works on .135 and not the later versions.

To take all the Ring stuff out, I created a VERY simple device driver that let me toggle the "mode" value between off & home. Driver code at the bottom.

I created a simple rule triggered on "mode" "changed" with 1 action:

As I toggled the mode value, the log showed:

It logged the "event", but never ran the "Log" command.

When I added a trigger explicitly for "mode=off", it ran the log action as expected.

image

I'm hoping this is a KISS and 100% repeatable test case now.

StateTest Driver code:

/*  ****************  StateTest  ****************
 *
 */

metadata {
   definition (
      name: "StateTest",
      namespace: "robstitt",
      author: "Robert L. Stitt"
       ) {
      command "initialize"
      command "refresh"
      capability "Actuator"
      capability "Refresh"
      attribute "mode",  "enum", ["off", "home", "away"]
      }

   preferences() {
      input("logEnable", "bool", title: "Enable logging", required: true, defaultValue: false)
      input("toggleState", "bool", title: "Toggle State", required: true, defaultValue: false)
   }
}

def initialize() {
   log.info "StateTest Initializing."
   refresh()
}

def updated() {
   refresh()
}

def installed(){
   log.info "StateTest Installed."
   sendEvent(name: "mode", value: "off", displayed: true)
}

void logsOff(){
   log.warn "Debug logging disabled."
   device.updateSetting("logEnable",[value:"false",type:"bool"])
}

def refresh() {

   if(toggleState) {
      log.info "StateTest home"
      sendEvent(name: "mode", value: "home")
   } else {
      log.info "StateTest off"
      sendEvent(name: "mode", value: "off")
   }
}
1 Like

Mine is broken again this morning and not responding to the event trigger...so need to run some similar tests. I may need to try to convert to condition driven rather than event driven.

Using my latest example (and supplied demonstration driver), has anybody else been able to reproduce this issue where a custom attribute "changes" and the event is detected--but the rule fails to trigger?

I just updated to 2.3.2.140. I saved the device driver code from above, created a virtual device using that driver, created an RM5.1 rule triggering off the custom attribute "mode" changing, and had a single "log" line in it to see if the rule executed or not. I'm not getting the rule to execute although the triggering event does show up in the log. For me, it's 100% reproducible-every time. I'm wondering if there's something the driver is doing wrong (the "sendEvent" command?) or what might be going on.

@bertabcd1234 do you have any ideas? Thanks!

mine are working fine.. have you consider corruption of your database.. maybe restore an older backup and try.