I updated the Child drivers yesterday..
Either update via HPM or click Import in the driver code window. An extra click of Done in each Child also seemed to resolve it. But all the above assumes that what I fixed was actually an issue and that you encountered it 
Let me know if it didn't.
I selected two devices in a child app and set them to turn off after 60 minutes. Does it monitor the state of each device separately and turn them off separate after 60 minutes of on time? If that is my intention do I need to put the devices in separate child apps?
Let's say you have two devices selected. You've set the time for 2 mins.
at "minute 0" device #1 turns on. A scheduled task is started for +2 min. At "minute 1" device #2 turns on. A scheduled task for +2 min is started.
app:458 2021-05-18 05:30:08.766 pm debug switchHandler delay: 120, evt.device:pseudoSwitch, evt.value:off, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:0, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[:], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], false ^ false = false app:458 2021-05-18 05:30:08.762 pm debug label: Switch Idle app:458 2021-05-18 05:30:08.734 pm debug label: Switch Idle dev:333 2021-05-18 05:30:08.699 pm info pseudoSwitch was turned off app:458 2021-05-18 05:30:08.680 pm debug scheduleHandler now:1621384208671 offList:[333:1621384208607] actionList:[333:1621384208607] deviceList:[pseudoSwitch] app:458 2021-05-18 05:29:53.719 pm debug label: Switch Active until today at 5:30pm app:458 2021-05-18 05:29:53.696 pm debug scheduleHandler now:1621384193682 offList:[333:1621384208607] actionList:[:] deviceList:[] app:458 2021-05-18 05:29:43.092 pm debug switchHandler delay: 120, evt.device:pseudo Outlet, evt.value:off, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:1621384208607, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[333:1621384208607], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], false ^ false = false app:458 2021-05-18 05:29:43.089 pm debug label: Switch Active until today at 5:30pm app:458 2021-05-18 05:29:43.082 pm debug label: Switch Active until today at 5:30pm dev:424 2021-05-18 05:29:43.041 pm info pseudo Outlet was turned off app:458 2021-05-18 05:29:43.018 pm debug scheduleHandler now:1621384183005 offList:[333:1621384208607, 424:1621384182934] actionList:[424:1621384182934] deviceList:[pseudo Outlet] app:458 2021-05-18 05:28:08.657 pm debug switchHandler delay: 120, evt.device:pseudoSwitch, evt.value:on, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:1621384182934, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[333:1621384208607, 424:1621384182934], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], true ^ false = true app:458 2021-05-18 05:28:08.653 pm debug label: Switch Active until today at 5:30pm dev:333 2021-05-18 05:28:08.579 pm info pseudoSwitch was turned on app:458 2021-05-18 05:28:01.845 pm debug switchHandler delay: 120, evt.device:pseudoSwitch, evt.value:off, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:1621384193635, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[424:1621384182934], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], false ^ false = false app:458 2021-05-18 05:28:01.836 pm debug label: Switch Active until today at 5:29pm dev:333 2021-05-18 05:28:01.770 pm info pseudoSwitch was turned off app:458 2021-05-18 05:27:53.679 pm debug switchHandler delay: 120, evt.device:pseudoSwitch, evt.value:on, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:1621384182934, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[333:1621384193635, 424:1621384182934], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], true ^ false = true app:458 2021-05-18 05:27:53.676 pm debug label: Switch Active until today at 5:29pm dev:333 2021-05-18 05:27:53.597 pm info pseudoSwitch was turned on app:458 2021-05-18 05:27:43.025 pm debug switchHandler delay: 120, evt.device:pseudo Outlet, evt.value:on, state:[Status:Current, Copyright:© 2020 C Steele -- v1.0.5, cycleEnd:0, delay:120, appDisplayName:Switch, InternalName:Auto_Off_c, offList:[424:1621384182934], UpdateInfo:04/05/2021, prevPref:Mltwc2V1ZG8gT3V0bGV0LCBwc2V1ZG9Td2l0Y2hdbnVsbGZhbHNl], true ^ false = true app:458 2021-05-18 05:27:43.017 pm debug label: Switch Active until today at 5:29pm dev:424 2021-05-18 05:27:42.843 pm info pseudo Outlet was turned on
The logs show: offList:[333:1621384208607, 424:1621384182934] Which is saying that device 333 and 424 are in "the list." Two minutes after device 424 was turned on, it got turned off. At that point, "the list" was reduced to just device 333. Two minutes after the 2nd time device 333 was turned on, it was turned off.
Is that what you were asking?
Yes, this is precisely what I was trying to do. I do not want the duration of time on for Device 1 to affect the auto off time of Device 2 and vice versa.
Although I could be certain that it behaves as intended by keeping two separate child apps, it is less cluttered and better organized for me by keeping both devices in one child app.
Then you found the right App.
That Mattias Fornander created a great app. It works the way you want because he wrote that... me, I just rebuilt it into parent child... too easy in comparison
@csteele I was wondering if you could please add a “restrictions” type option.
Eg disable timer if switch X is on. Enable timer when switch X turns off.
A use case for me would be if the ensuite light is on and the ensuite exhaust fan is on, disable 30 minute ensuite light timer as the ensuite is likely still in use (by my wife). As soon as exhaust fan turns off, start the auto off timer.
To use your example, in concept, if at 1 minute and 15 sec device #1 is turned off and then back on, does device #1 turn off in another 45 sec or in another +2 minutes? Thank you.
Turning off a device clears out the schedule for that device.
Turning on a device creates a schedule for that device. If the schedule was 2 mins then it would turn off after 2 mins.
Perfect....Thank you
newer user here. Can someone help me figure out what the master switch in option does. What I am trying to achieve is
When a master switch (virtual) is on, than any of the child switches turn off automatically at their given time.
If the master switch (virtual) is off, then any of the child switches will NOT turn off automatically at their given time.
I really want this so that during say day light hours lights left on turn off, but in the evening when everyone is home, they dont auto turn off.
Hope someone can help
When the Master switch is Off, it prevents the scheduled OFF at the end of the time period.
When the Master switch is On, it allows the scheduled OFF at the end of the time period.
No Master switch selected functions the same as if one was defined and it being On.
So I read through the thread and wasn't clear on a fundamental aspect of this app. What is the difference between these two?:
If my objective is to prioritize system resources and I'm less concerned about a countdown timer being 100% accurate what option should I pick? I assume it is the delay version but I wanted to make sure.
From the very first post in this Topic:
There are two notable differences between this pair of Apps and the original App from MForander: It's a parent/Child version, where each monitored switch (or dimmer) is an individual App, visually within one container (parent). It's a visual ordering feature. The Parent app only runs during the Child creation process and each Child App is functionally the same as the original App, except for: The second notable difference is that the code uses runIn() to schedule the Off event not polling.
MForander explicitly stated he wasn't interested in anything but a polling style app. I wanted a challenge and forked his excellent code and converted it to a scheduled event for the end of the time interval.
Enough people liked parent/child element and the banner updating that I forked the code again and made it another child app, but otherwise untouched. Thus providing one-stop-shopping.
That doesn't really tell you which to pick, but it does explain the difference. You have a choice of the hub looping on a test to detect the end time, or of a timer, scheduled to occur once, at the end. The result is probably identical, except for the tiny fraction more hub load from polling.
It began as a self challenge, and I thought one, maybe two others might enjoy it.
Thank you that's exactly the insight I needed.
I had a feature request unless I missed this in the app. Is it possible to add the capability to pause a child app? I'm in the middle of migrating this to a new hub and I don't want to remove from my old hub until I've tested and comfortable with the performance on the new hub.
All Apps have a Disable option:
Click the grey X and make it red.
A Disable column appears.
Disable the App(s) you need.
Perfect. No matter how simple it is every day I learn something new in Hubitat.
Hi all, the apps works great, thanks @csteele! Just an FYI for anyone with the same use case. I just came across an anomaly,
I have a situation where I have 2 virtual switches being monitored in the same child. In one situation I am triggering them at the exact same time, the app would schedule 2 events but only 1 switch would turn off. After a little testing it looks like when both 'on' events happen simultaneously only 1 device gets auto off'd. I changed my rule to turn on switch #1, wait 1s, then turn on switch #2. In this case they both worked fine. Because they're virtual I believe that both will literally be set at exactly the same time causing the anomaly. Physical devices will never have this scenario so the issue probably has not been seen before.
Is it possible to eliminate all these debug messages in my log? As far as I know I have debug logging turned off in the app.
Download the Hubitat app
