Looking to establish a single rule for any number of bathroom fans that turn off after 30 min (for now, it's set to 15 seconds to debug) I also recognize that somebody may turn off the fan before the time elapses, and I'd rather NOT be running a timer for no reason (eg to wake up and turn off the fan when it's already off, which just creates work for the hub) Ideally, I also don't want to spam zwave unnecessarily with an extra "off" but I recognize at the moment this does that.
Here is what I've written:
It does kick off when a fan turns on, and if I manually turn it off, it recognizes that but the timer functionality with the OR and a flat wait never seems to do what I want.
In this log snippit, the fan is turned on at 12:24:28 and runs until I turn it off 12:26:57, at which time the FIRST part of the OR seems to kick off the timer. When the timer is done, it proceeds to shut things off.
I've been toying with other approaches (trigger on change, cancellable wait) etc but they get messy and I'm still battling odd behaviors, thus the "slim this down" approach.
I ALSO am concerned that 2 different devices could trigger same app, but haven't even tested to see what happens then...
I'm probably counting blades of grass now, can someone help bring me back to a realistic solution?
I don't know if this is relevant or not, but your first Wait for Expression is wacked - you built it as an OR, but you have no second thing to evaluate.
Anytime a rule is triggered in RM again, it cancels Event and Expression waits. Additionally, since the rule is re-triggered as a new instance, the "last device" will be whatever device the new instance was triggered by.
You might be able to achieve what you are looking for in one piston with webcore. I keep a running list of open doors that way. In my rule, they all share the same timer (if any door in my list is open for X minutes, I get a TTS broadcast of all open doors with a request to close them) But, I would honestly just do separate rules as @TArman suggested if you are trying to have concurrent waits with separate timers for each triggering device.
VERY interesting, it let me build it that way without any error. I actually see issues when I go to edit it. So perhaps theres a bug there to be addressed.
That's what I run today -- but I hate having tons of logic duplicated as it's 1) more places to edit if I want to change logic in my rulesets, and 2) should be inherently less efficient and potentially put more load on the hub. One trigger that covers the 3 fans vs 3 triggers. Maybe under the cover it's not much different, but my C8 and ZIP has less than reliable moments that if I can figure how to optimize should reduce those.
Agreed -- one of my iterations was trigger on the 3 fans to "changed" which then meant I also had an IF conditional around the whole timer bits for "turns on." Essentially letting the cancellation happen. Basically 2 evals -- just thought that a "wait for time or off" would be more efficient (and proving to be harder to write)
Yah, that's one of my concerns. I'd hope that the spawn would be per event device, but I haven't proven that out yet since the base logic hasn't worked. But my suspicion is that I will have the same "one timer" problem vs timer per device. I was hoping somebody who knew the implementation or had done the experiement already would weigh in.
Thanks for the perspectives. I will probably iterate through fixing the OR and go back to "changed" trigger logic. Then onto the simultaneous device experiment.
Haven't dealt with webcore yet, mostly because of the "even more stuff running" concern. Too much of my embedded device experience haunts me on adding in more stuff and the impact it has on hardware.
Appreciate the comments guys - anyone else with other insights? I'll update as to what I land on eventually...
Have you considered having 4 rules: one rule to execute the duplicate logic, and one rule for each fan that runs the actions of the logic rule? That way you only have one place to edit the logic, but each fan can have its own timer. Just a thought. I do this sometimes when there is logic that I need in multiple rules. There's no load on the hub unless the rules trigger.
There's really no difference where it matters: your single trigger is going to create three event subscriptions, the same as three separate rules that each have their own single trigger. You can verify this by taking peek at the App Status page for any of these (real or hypothetical/test) rules.
Without reading through every single reply so far (perhaps someone has already mentioned this) I think your original issue stems from the timeout, as you suspect, but specifically from the fact that the value of the built-in device variable gets changed to the string "timeout" when the actions proceed as a result of the timeout rather than a device event -- and, without digging too deep into internal Rule 5.1 workings, I suspect this is intertwined with how "Last event device" is determined.
Even if you could overcome that (e.g., by finding a way around the timeout -- if your switches don't do something kooky when they're sent an "off" command when they're already "off," you probably don't need to care unless you're absolutely trying to minimize traffic), I think you'll still run into the problems mentioned above, i.e., that an event from any of your devices (because they're all triggers) will cancel any pending "Wait." So, you'll probably run into problems where some devices don't get sent the commands you expect at least some of the time.
All that to say I'd second the suggestion for separate rules for each device. But if you absolutely want to minimize duplication, I suppose writing a custom app, whether you end up needing one instance for all or three with one for each, is another way to achieve that goal.
The rule makes use of a couple of RM features you might want to consider, if they apply to your use-case, such as "physical on" and "Command only switches that are on".
Thanks all. Some great feedback from everyone and confirmation I'm caring about things that ultimately don't matter.
And @bertabcd1234 I hadn't even considered looking at the App Status page. Probably should have done that early on to realize the effort wasn't worth the spend.
Collectively, you've all talked me back into "unchecking disable" on my duplicated rules and deleting the overly clever and likely never to work ruleset. But I did walk away having learned about Last Event Device so it wasn't totally for naught!
Appreciate the back and forth food for thought gents.
But if you absolutely want to minimize duplication, I suppose writing a 
