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

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.

3 Likes

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:

Screen Shot 2022-03-24 at 6.17.05 AM
Click the grey X and make it red.

Screen Shot 2022-03-24 at 6.17.23 AM
A Disable column appears.

Screen Shot 2022-03-24 at 6.17.34 AM
Disable the App(s) you need.

Perfect. No matter how simple it is every day I learn something new in Hubitat.

1 Like

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.

Turn debug on. Click Done.
Turn Debug Off. Click Done.

Go into the child App and click the gear at the top right. You should see this:

3 Likes

That did it - thanks.

I thought that did it, but look at some of my log:

New version released to correct this typo. HPM is updated also.

1 Like

Thanks ill give it a go.

Hi - thanks for the work on this app. I installed it and everything was working except the master switch. When the master switch is OFF, the job activates and shows me the green status, but once its time for the lights to turn off it skips that. But when the master switch is ON the job is restricted '[-]' and does not activate.

I noticed in the code line 167 the if statement seems reversed, unless I am not understanding how the master switch is supposed to be used. I updated the if statement and replace on with off and everything seems to work correctly.

	// Call off(), or on() if inverted, on all relevant devices and remove them from offList
	if (!master || master.latestValue("switch") == "**on**") {
	    invert ? deviceList*.on() : deviceList*.off()
	} else {
	    if (debugOutput) log.debug "Skipping actions because MasterSwitch '${master?.displayName}' is **Off**"
	}

I seem to be getting an error while trying to add this driver... New to HE and Came from ST-- When we originally added drivers os i am privy to the process.

Are you adding this to apps code or driver code? This is an app, so should be added to apps code.

As a new HE user, I strongly suggest that you install HPM first, and then use that to install this app (along with lots of other useful community developed apps and drivers). Installing via HPM is simple and fast, and makes updating equally as easy.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.