A Hubitat Parent/Child app that turns off your devices after they have been on some time. This App is a "clone and update" of MForander's excellent Auto Off app.
Details
The app allows you to create child apps to individually select switches you want to be turned off automatically.
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.
This App is available through HPM.
Images
Before:
After:
The green status words are hints about the state of that specific App. If the Master switch is On, signifying the app is paused, there will be a red [-] . Obviously "Idle" means the App is waiting for the switch to turn On (or off, if inverted). Equally obvious, I think, is the "Active until ..."status, showing the time that the switch will be turned off (or on, if inverted.)
MFornander made the case that a Parent/Child App would be more complex here
As mentioned above, for this 'style' of Parent, it doesn't run except to create a new Child or display a list of Child apps.
The Child App itself is the original app that subscribes to the target switch, causing the App to run. Therefore, in that sense, the two are identical. However, I didn't leave that app alone. The switchHandler() method went from 5 lines to 13. Three of those are to limit check the # of minutes (1hr) but one line is a call to update the Status 'Hint' seen in green next to the app name. That's the 'expensive part' at 53 lines that didn't exist in the original. So yes, I would say my version of the Child is 'more expensive' than the original. Not due to the Parent/Child aspect, but due to the 'status hint'.
I also chose to replace Polling every minute with an explicit timer. IF you set the Off time to be 1 minute, there's virtually no difference in execution. However, delays greater than 1 minute gains because the App doesn't run just to find out there's nothing to do. So a 7 minute delay means there's 6x gain of whatever minuscule time was spent polling. A 15min delay is a 14x gain, and so on.
I suspect all of my changes might total to be so small as to not be discernible, and certainly not to the human eye.
Would this new polling method be affected if the system time, on Hubitat, were to get updated and say jump over the time in which the trigger would happen?
I ask this because my main use case for the MFornander's Auto Off is in the case of an internet outage or a power outage that caused the network to go down, to have the smart plug on the gateway to facilitate an automatic recovery of the network. See the below post for a better description:
Is this use case still preserved or did you make changes that might break that?
The reason I started this effort was mostly for the "Fun" of converting to a Parent / Child app. I happen to have code templates for it that has been crying to be used.
Next was the desire to add in the green status hint... I thought that would be fun too.
The result is: an alternative that shouldn't replace ALL of MFornander's Auto Off deployment. If you have only ONE instance, I can't see why eating two lines on the Apps list would be "better."
The scheduling for Auto Off uses: runEvery1Minute()
The scheduling for Auto_Off uses: runIn(delay)
The documentation for runIn() advises of an option for "Misfire":
misfire - If set to "ignore" then the scheduler will simply try to fire it as soon as it can. NOTE: if a scheduler uses this instruction, and it has missed several of its scheduled firings, then several rapid firings may occur as the scheduler attempts to catch back up to where it would have been.
Neither MFornander nor I use that 'feature'. I think it's because of the Note. "rapid firings" scares me. Ok, not exactly scare, but applies caution. In other words, I think both versions of the App would react the same to your scenario.
The second question is more about Hub time and it's impact on scheduling. If your Hub, which keeps time by polling an NTP server, drifts because there's no access to a NTP server, then the scheduling would be effected too. I'd advise pulling NTP inside your house via an always on computer that has an internal RTC (Real Time Clock). In this way, the RTC is 'bumped' by periodic polling of an Internet NTP server to maintain a very high accuracy and low drift. You then use the community's NTP driver to sync Hubitat to that NTP server inside your home.
I think I've found an issue - however, I think it's more a fault with Philips Hue integration than anything else.
The scenario AFAIK is only applicable to Hue Bulbs that are switched off at the wall. The bulb is not switched "off" if the switch is manually turned off. As a result, the timer stays active and wont reset without intervention. eg (it's now 10:00am):
To reset the timer I can go into the Dashboard and click it off manually, even if the power is still off to the bulb. The Hue app allows the same thing.
Is there something you can do in Auto Off to prevent this behaviour seeing as you can manually turn the bulb "off" in the dashboard?
PS, I suspected this was happening with the OG app and was one reason I was so keen to get the "Active" status appended to the app name.
This may be unrelated to your observation, but I did notice an odd result during my testing.. and I just tried it again and I don't like the result
When you "open the app" for any reason and Do Not Edit/Change Anything, but click Done, the App will assume you did change something and 'kill' the process. The App thinks it's ok, but it's feet got swept out from under.
There's two options: 1) introduce a Cancel Button to allow one to exit the page without making a change, or 2) detect that an actual change occurred and only 'kill' the process if a change was made. I'm leaning towards #2 because it better matches the UI/UX for other Apps.
And I'm happy to report that I switched to your version, even though I only have one item assigned to it at this point - I think the current status is worth the extra line.
I decided to create a Child app that was as close to the original Polling as I could get, yet remain under a Parent/Child structure. Instead of simply creating one type of Child, now there's two:
This came about as I was thinking about keeping the child code very slim and not packing in the features. Instead, I thought about creating a child app that was focused on one feature at a time. I didn't have any obvious way to test it, so the-light-came-on... I could repackage the original polling code. Probably no big need for it, but it was practically 'free'
