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