I've created a virtual switch that I use to override lighting automation; if the switch is on, the automation just exists there.
I wanted the switch to get set whenever the lighting was modified outside the automation, stay overriden (on) for 15 minutes, and then reset the state (off).
For some reason this is not working with either Delay 00:15:00 or with Off:Switch --> Delayed 00:15:00. The switch gets turned on, but never turns off.
This is how it currently looks:
There's no reason that rule shouldn't do something, even though that "something" may not always be what you expect (but should definitely include an "off" at some point). It's possible your device just isn't responding to the "off," but you can tell what the rule thinks it's doing for sure by turning on logging in the rule for at least "Actions" (and "Triggers" is usually helpful, too). Then you'll see what it's doing when and will have a better idea of how to troubleshoot--or where.
It should be noted that any trigger event firing will cause your actions to run again from the beginning, and nothing here is ever cancelling that delay--so this is why I said above that it may not always do what you expect. If the light turns on digitally, then sometime adjusts the level 5 minutes later, you'll get two scheduled "off"s: one for 15 minutes after it turned on, and another for 10 minutes after that (15 minutes after you changed the level). This also means that if you turn the light off at minute 11 and turn it back on at minute 14, it will turn off 1 minute after that--not 15 minutes. If you want these actions to "reset" the timer, consider using a "Wait for event: elapsed time" instead, which is cancelled on re-trigger. You could also mark that delay as cancelable and run a "Cancel Delayed Actions" before it gets re-scheduled, like at the beginning of your actions. If you want to wait for 15 minutes from the first event, you can do that with a bit more work, maybe enlisting Private Boolean and only scheduling the delayed action if Private Boolean is true (then setting it to false before starting the delay and back to true after the delayed "off").
But, that wouldn't explain the issue you describe...so logging is your friend for now. 
Sadly, no - nothing happens. I manually turned the override switch off, activated a change in lighting, waited a couple of minutes, and it didn't turn on. Then, I manually ran the rule in RM, and the ON action triggered, the delay was registered, but the OFF never happened.
Log as follows:
When you're waiting for the delay--which the rule does appear to be scheduling--check the "App Status" page for that rule. You can get there from the gear/cogs icon next to the rule in the app list, or the same icon on the top right of the rule page. Scroll down to "Scheduled Jobs," and see if you find something there--you should--after the delay is scheduled (and disappear after it should have run).
I get this delayedActs but its unclear to me what Action is going to be taken at that time. I didn't change the Rule, so I have no reason to believe that this time will result in it turning Off either 
But also doesn't make sense why change the source light doesn't invoke trigger to turn it On to begin with 
Something else might be off, because I just noticed that my mode manager is not changing mode at the scheduled time... (it's 21:37 as I type this; yes, I checked TZ and time on the hub 
)
Sounds like you've already checked Settings > Hub Details for the correct time, time zone, and location, but if not, verify it there. Otherwise, something does indeed seem up. I might try a reboot if you haven't already, then consider going back into Mode Manager and the problematic rule and hitting "Done" (which generally saves the app's settings and re-initializes things like subscriptions and schedules).
Regarding the "on" trigger event not matching, physical vs. digital events are notoriously unreliable for lots of devices, so that would be my guess. The "Events" tab/page (on the device page for the device in question) would be one place you can verify the "Type" of event, which if it's wrong or absent would, of course, cause a trigger event to not match. If there's anything you can use instead that is more reliable, like a button event (if your device is a Z-Wave CentralScene-capable device, which is pretty common with modern devices, this may work) or any "switch" event if you don't care about digital only, that may help.
It's a Hue bulb; I didn't think to check the Events tab for what happens when I turn it on / off. I assumed it was a digital switch given it a Hue, but it might be Physical. That being said, it's also why I added the 2nd trigger of the dimmer level changing, which also fails to trigger the Rule.
I'm doing the update to 2.2.8.155 at the moment, and will click the "Done"s and reboot once that's complete, and then test again. 
No change at all
Hue bulbs don't really have physical on or off--anything that happens should be via Zigbee (or Zigbee via the LAN integration on the Hubitat side if you're using a Bridge, which I'd generally recommend). If you turn it off, then it lost power and can't send an "off" event at all, and when it turns back on I don't think anything special happens, either. This is really meant for smart switches and dimmers where an "off" or "on" could have come from a tap on the switch (physical) or a command from the hub (digital). If you don't care about that distinction--and if you do, I'd make sure your device reliably reports it (again, many don't)--I'd just use the "Switch" capability for your trigger. That will catch any on/off event.
If that's what you're doing and it's still not happening, that's another story, but if you're physically turning the bulbs on/off with the switch, that would explain it. You'll need to either find another way to turn the bulbs on or off, or you'll have to rely on another event instead.
I am using the Hue bridge and the integration, which is why I chose Digital for the trigger... but it's all moot if my Mode won't update (and didn't) and the Rule won't run the post-delay action even when activated manually.
Yeah, I'd just use "Switch" for that (and, again, really any case where you don't care about the difference, but for devices like these that don't have a physical way to turn them off--at least not while remaining smart--there isn't one anyway). But, as you note, a different problem...
I'm not sure about your delay, but my suggestion to reboot is based on the fact that this performs some database maintenance, which may be helpful if you are experiencing odd problems. I think this includes reboots as part of firmware upgrades, but trying one on your own just to be sure wouldn't hurt. Downloading a recent backup, doing a soft reset, and then restoring that may also help "clean up" any oddities. But I'm not sure either of these problems sound like database corruption to me--everything looks pretty normal except for schedules, and you've already checked the obvious. But both of these actions are generally harmless if you wanted to try.
Appreciate your attempts to help, but I’ve been clear in my my diagnostic steps, including that I’ve actually done those things.
If I have to soft reset and restore upon just deploying the hub and first attempting to use it for anything, that’s truly not promising.
So after firmware image update, click Done and manual reboot @ 18:00 last night, Mode changed to Day this morning, and now I'm waiting to see if it'll change to Evening.
Sadly, the post-delay turning off of that virtual switch (when run manually) simply doesn't happen. And I'm wondering, is that even the right way to sequence those that On->Off with 15mins in between (irrespective of being cancelable or resettable).
Yes, that should work (even if unexpectedly after a retrigger). A standalone "Delay" action like you have effectively pauses there, the schedules a job to resume at the next action after the delay.
I wonder if just re-creating it would have worked, too. The two rules you posted would be identical in outcome in this case. The difference with putting a delay on an action as opposed to using the standalone "Delay" action is that the former schedules that particular action for the specified time in the future and then continues with the next action, while the latter (as explained above) effectively pauses there until the delay is up. Since you don't have any actions after this, there would be no difference in this case.
Glad you have something working, in any case!
Download the Hubitat app
