[quote=“jarrodirwin, post:60, topic:198651”]Hey rigpapa,
Had a play with this and it does work - Not sure if you’d rather me comment on the Github issue or here but will just do here for now.
In my somewhat complex timer, it looks like if the “off” action dims one of the “on” devices (like in my TV watching scenario where if the TV is on, turn one light off and dim the other), then this sets a manual timer so defaults to the “on” status’s. This essentially means the lights never get back to the ‘off’ state. This could be due to my dimming of the the lights being triggered through lua in a scene and not directly in the timer settings…?[/quote]
Haha. So, with the addition of looking at the dimming level, DelayLight now sees your “off” scene activity as a manipulation of the light to “on”, and initiates manual timing. But that should not be a problem if ManualOnScene is set to 0 in that DelayLightTimer–it should leave the scene alone and not reset it, leaving the one light off and the other dimmed as your scene prescribes. And because you still have a light on that’s a watched load for that timer, it should be timing, so that seems OK. Are you sure ManualOnScene is set to 0 for that DelayLightTimer?
I have another timer for the hallway which is much simpler. On but dimmed to 50% when motion is detected, off after X seconds. When this is manually turned on and the manual timer is counting down, a change in dimming level resets the manual timer like expected with the new feature. When auto timer is triggered, changing the dimming level does nothing still - assume you haven't implement that option yet?
That option isn’t provided yet. Once a DelayLightTimer starts in a mode, the mode does not change. That’s too complex an issue to address before heading out the door on vacation. 
EDIT: Confirmed the dimming being set via Lua in my 'off' scene is what's causing the timer to hear a dimmer state change. When I changed the hallway timer to simply dim instead of turn off, it worked as expected. To get this working with my 'off' scene, I tried changing the watchMap() code for dimmers to listen for LoadLevelTarget events instead of LoadLevelStatus and although this did let the lights turn off and dim correctly, it also created a new manual countdown timer... even though everything is in the desired 'off' state - so that doesn't seem like a solution.
Now I’m really confused. But nonetheless, yes, your “off” scene setting a dimming level <> 0 would start manual timing. If any load is actually on (as in, drawing power), the timer should be timing. And also, because your light setting is in Lua, there would be no reasonable way for the timer to learn that 30% means “off” to you. The net effect of this, though, should only be that manual timing runs continuously on the timer until the lights are really, truly off (Status/LoadLevelStatus == 0). The timer periodically expiring will re-run your “off” scene, but that won’t change anything from its current state. It’s a harmless side-effect of your choice of implementation for that scene, unless I’m missing something more sinister in what you are describing.
As I'm new to Vera, Scenes and Lua, do scenes wait for all actions and code to run before returning true/success? When using scenes does the timer wait for any type response from the scene before continuing? Wondering if I can add some halt/wait in my scene Lua that gives my lights enough time to dim before they get heard from the timer (or something).
Scene execution in Luup is a “hail Mary.” You tell it to run the scene, and hope that it does everything the scene prescribes. But, because any device can be offline at any time, there isn’t a comprehensive summary status. When scene Lua is involved, you know even less about what’s going on. You’re just hoping it all works. There are alternate ways of running a scene where I can be notified when the job completes, but those are costly in real-time performance (the time between trigger and execution of the scene increases and becomes less deterministic than it already is), and will still only tell me when the scene execution ends, not if every part of its execution was successful (i.e. every device is now in the prescribed state).