[RELEASE] Auto_Off - Another choice to automatically turn off devices after set amount of time on

Is there any additional overhead compared to the original app or are there any functional changes from the original? Looks great just was curious.

So far my hair feels thicker and fuller. Haven't noticed anything aside from that... :wink:

Nicely done, @csteele!

3 Likes

Thank you @csteele , I really appreciate your efforts. :sunglasses:

1 Like

Thanks for this! The basic "off" capability appears clear, but I didn't understand - what does the "Master Switch" option do?

You can choose a switch to turn on to temporarily disable the app from running.

2 Likes

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.

To summarize, the functional differences are:

  • Status Hints beside the App name.
  • Polling replaced.
  • Version Check was swapped to 'my' method
4 Likes

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. :slight_smile:

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." :slight_smile:

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. :slight_smile: 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.

1 Like

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):

Screen Shot 2020-10-14 at 9.58.04 am

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 :smiley:

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. :slight_smile:

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 :slight_smile: because it better matches the UI/UX for other Apps.

2 Likes

Yup, yup, yup, agree.

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. :wink:

image

2 Likes

Agreed, this is the elegant solution.

Released

  • Auto_Off Parent v1.0.1
  • Auto_Off_c Child v1.0.3
  • and introducing Auto_Off_o v1.0.1

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:

Screen Shot 2020-10-14 at 8.58.15 PM

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' :smiley:

At the Apps page level:
Screen Shot 2020-10-14 at 9.06.19 PM

1 Like

The polling child app works great for my Hue scenario (below). I'm using the non-polling child for everything else (hard-wired z-wave gear).

Screen Shot 2020-10-14 at 9.10.01 PM

And of course HPM has been updated. :slight_smile:

2 Likes

HPM updates fail with an error:

**Error downloading file**

An error occurred downloading http://whiskers.aclysnet.com/HSM/Auto_Off_o.groovy

I just tried to install with HPM and got this error:
An error occurred downloading http://whiskers.aclysnet.com/HSM/Auto_Off.groovy

Oh good, it wasn't just me - I thought I'd done something dumb as I was beta testing this with Mr Steele.

ok, fixed... not sure how long it takes for Github + HPM to notice...

2 Likes

yep, working 100% now. :slight_smile:

1 Like