Power Allowance App Alternative?

Does the power allowance app work very well? I have it set up on 2 of my light switches, and it does turn them off after the fixed period, but I was looking at the log and the activity and it appears to be firing off the “Off” command even after the switch has turned back off.

I need an app the works for this, it is really starting to frustrate my family with this conversion to a “smart home”, and I’m starting to think for the first time to moving to a different platform.

I use it to turn off the bathroom light if it has been on for longer than 30 minutes. The problem is that someone comes in and goes out, the timer is set to 30 minutes, if the next person goes in 25 minutes after the 1st person has turned on the light they only get 5 minutes. It is very annoying when someone is in the shower. The code in the app just sets a delay for the off on the switch, and never cancels it if someone has physically turned off the switch.

Any ideas on work arounds or do i need to build a new app for it? Or is there a better power allowance app? This does not happen w/ the rule based apps for the WeMo switches.

I have been looking at my activity log and this is what I can kind of tell from the history of that, and what I’ve been able to see from usage. Anyone else experience that?

Do i just need to write a new app, that whenever someone turns the switch off it goes through the collection of timers and kills all of them?

There is one in the shared apps section of the ide called “Improved Power Allowance”. In the description, it says This program using runIn instead of a delay option. This prevents ‘stacking’ of off commands. I’m wondering if this would help your situation? I’m gonna try using this one instead of the old version. I haven’t noticed any issues with the old one, but why not use the improved one right? :slight_smile:

That Improved Power Allowance app seems to work much better. Thanks to @chrisb for putting it together. I hadn’t even seen the Shared Apps in the IDE until now. Very helpful.

Yeah @trasher99er,

This was exactly why I wrote this app. I was running into much of the same problems you were with the power allowance app. As you described in your first post, if you set it to auto off 30 minutes after turning on, it will turn it off 30 minutes later no what has happened in the mean time.

If you turn on at 7:00, ST will schedule a turn off at 7:30.
If at 7:15 someone turns off the light, that 7:30 off is still scheduled.
If someone turns on the light at 7:25, ST will schedule a turn off at 7:55… BUT, that 7:30 turn off is still scheduled as well.

With my app the turn offs are canceled if the light is turned off or on. So…

If you turn on at 7:00, ST will schedule a turn off at 7:30.
If at 7:15 someone turns off the light, that 7:30 off is cancelled.
If someone turns on the light at 7:25, ST will schedule a turn off at 7:55. The 7:30 is still cancelled.

Yeah, i appreciate it @chrisb. I had looked at writing something, but I was just going to put something in the settings to determine if it has been switched off or on, and reset that delay if needed. The runIn command seems to work much better, there is just so little documentation on it.

I really appreciate it. Your version should replace the Power Allowance App, because the behavior is the more expected use case than the current Power Allowance app available.


Interestingly it looks like the canned Power Allowance app has been changed. It now uses runIn instead of a delay command. I don’t know when this change happened, but it’s also interesting that apparently the delay command was changed to only allow 60 seconds as the max for delay. (http://build.smartthings.com/forums/topic/delay-commands-greater-than-60s-not-permitted-since-when/)

Yeah, I’m very disappointed with the communication on this. We really need to be informed on this, I think what happened is they found the same thing working with the delay and runIn, and updated and didn’t let people know.

@Morgan, We’re deeply sorry for how poorly delayed command change was communicated. We’ve actually reverted that change completely because of this and want to make sure developers have plenty of time to migrate their apps to use runIn for longer delayed commands where appropriate. We understand that some developers are using delayed commands with long delays and don’t care about stacking issues (think long delayed flasher apps). Because of this we may just decide to document the drawback and leave it as part of the API. That way developers can decide to use it that way if they choose. Regardless it won’t be going away anytime soon.