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:
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.
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:
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).
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.
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")
}
}
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.
Did you happen to try my simple example driver?
The problem is the attribute name "mode". This is colliding in RM with hub modes. That's a bug. Will look into a fix for this.
In the interim as a work-around, change the attribute name to something other than "mode".
Fix will be in the next release.
Thanks for figuring that out. Wow... A deeper problem than I'd have guessed.
@morse.caleb this is a tougher one for you apparently. I'd suggest considering creating a second attribute with a different name that mirrors "mode" so it doesn't break existing rules?
Or we just live with it for now?? Thoughts?
Given that there is a simple work-around, don't bother changing the driver. Just use all of the mode values as individual triggers, and you get the same effect as *changed*.
For sure, the work around is a good interim solution.
Somehow, I missed that you were going to fix it in the next release--I was only suggesting changing the driver if there wasn't a feasible fix. 
Glad you found the issue thanks so much!
And, it's a relief to know it isn't potentially affecting other "changed" triggers in RM 5.1.
Fix for this released.
Download the Hubitat app
