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

[csteele]

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.

[dJOS]

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.

[csteele]

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.

[danabw]

@csteele

I'm leaning towards #2 because it better matches the UI/UX for other Apps.

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.

[dJOS]

@csteele

I'm leaning towards #2 because it better matches the UI/UX for other Apps.

Agreed, this is the elegant solution.

[csteele]

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:

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'

At the Apps page level:

[dJOS]

@csteele

could repackage the original polling code. Probably no big need for it, but it was practically 'free'

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

@dJOS

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

[csteele]

And of course HPM has been updated.

[dJOS]

HPM updates fail with an error:

**Error downloading file**

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

[tony.fleisher]

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

[dJOS]

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

[csteele]

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

[dJOS]

@csteele

ok, fixed.

yep, working 100% now.

[csteele]

Dimmers are switches plus (extra)

The existing Auto_Off will 'slam' a Dimmer to Off, pretty well. Is there any value in having a dimmer dim to off, over time, instead of 'slamming'?

[dJOS]

@csteele

Is there any value in having a dimmer dim to off, over time, instead of 'slamming'?

There may be some dumb dimmers out there that don’t fade to off, so I’m sure someone will find that useful.

My use case is to turn off lights lazy family members leave on. So fade to off won’t be seen by anyone. It might be kinder on certain dimmer mechanisms tho?

[tony.fleisher]

@csteele What is expected behavior when creating a new auto_off child when one of the switches is already on?

[csteele]

I didn't change the logic of MFornander's wonderful work. The answer would be "The same as..."

But, in reviewing the code, I would say that Auto_Off is started via an Off to ON transition. Any selected switch goes from Off to On will start the timer for that Child's set of switches. At the end of the cycle, they will all be send an OFF command.

[tony.fleisher]

When cycle time is -1 and a switch is on. There is no schedule but label shows active until dec 31..

[danabw]

@tony.fleisher

When cycle time is -1 and a switch is on

Why would you set the auto-off time to "-1" or negative anything?

[tony.fleisher]

The app does it: atomicState.cycleEnd = -1
There is a problem with the label handling