It looks like that should work. The only thing I can think of that wouldn't turn it off is:
- if the Rule effectively never gets past the first action because your switch is on and never turns off; or
- you "re-trigger" the Rule while it's waiting for that last delay, currently 4 seconds (or since you don't have any trigger events: invoke the Rule from another Rule, or manually hit "Run Rule Actions")
Turning on logging for your Rule ("Action" logging would probably be the most helpful, but anything can't hurt) would be a good idea if you want to see what actions are executing when; then you can troubleshoot from there with a better idea of why not if it isn't working as expected.
Full logging on, now.
The problem is likely in the wait in the last line.
There are 8 total hubs that can call this rule, some may have several rules that can run this rule. It is an attempt at just having one "voice" for the system. Truly, it is triggered by virtual devices going active, with delays, volumes, etc. Imbedded in the virtual ( Omni sensor) values.
It gets cought up when there are two motion events close together.(turns on, gets re run by having another motion event run it again.
Or I could just move a motion sensor from it's perfect position to a less optimal position.
Software is more challenging and fun!!!
One option you could use is a delay instead of a wait; a retrigger will not cancel those. But either approach seems problematic to me in that regard; the first instance that finishes will set the switch to off, even if others are still going. Using a numeric variable to count--increasing or decreasing as necessary and using a value of 0 as the test instead of the switch state--could theoretically work, but that approach seems pretty fragile to me (just one failure and your variable will be stuck above zero).
Maybe it would be a good idea to zoom out and ask about the problem you're truly trying to solve? Someone might have an idea for a different approach.
Using hubmesh to have just one hub Chromecast to just one Google home mini. With multiple hubs feeding it. A que, would be the best method. Just throw the next "phrase" at an app. The app just keeps track of the expected output, and makes it happen.
First in, first out.
Would love to do it in RM. (Preferred)
I don't have any specifics ideas for that (besides the one above I don't really like), but perhaps others can chime in. I figured the goal was something like that, but what is the actual problem? Does sending a second string to speak interrupt the first if it's not done speaking yet? This seems like it might be nice to handle at the driver level, but we don't really have control over that: besides that other idea, my only idea is some sort of "proxy" device that queues and tracks things on its own, perhaps with some sort of auto-reset in case something goes wrong (e.g., your hub happened to be rebooting, maybe for an update, at the exact mkment when the lock was scheduled to "expire").
It probably wouldn't be hard to write an app/driver combo that did this, but I'm not aware of anything out there at the moment. A Rule or two could probably do something similar too. But perhaps this is an issue others have solved in some way and could chime in on.
Thats a lot of hubs!
I ask a lot of "it"
