I want it to light up at night, or by LUX, when there is movement. But otherwise be off. I haven’t seen that in ST. I also like the idea of it being on DIM, but maybe only for a few hours a night.
I added “0” to the list of Dim options and that seems to turn them off.
I’d love to to see the App pole the current dim level, so if I adjust the bulb brightness myself, it will except that as my new setting. Usually a 40% dim is perfect for me for motion, but sometimes I am working in the yard area, and I like to brighten the lights to 100%, motion events would fight me and keep putting them down to the level determined in the app. I could see it resuming back to the app setting after the motion timeout expires. Would this suit this app or should be setting this up another way?
thanks for your work on this. I’m having one issue with the RC1, but I’ll try your RC2 tonight to see how it works.
Could you build this into the RC2? I know that it isn’t really the point of your app, but in my case, I wanted to have one light stop going to a dim state but didn’t want to go through the hassle of Uninstalling your app just to try that particular light on an “Off” setting.
EDIT: I see that RC2 was released on 1/26/15, and that’s the version that I was already using. My issue may be related to my motion sensor or the GE Link bulbs, but I thought I’d ask here. Currently, my dim and bright phases get swapped. Also, sometimes, if I walk into a room just as the lights turn off (due to no motion being detected), the lights will not turn back on - even if I do jumping jacks in front of the motion sensor. The ST app shows motion, but the lights/this app do not trigger…
Any ideas? Maybe that delay setting isn’t set right? The motion sensors have a 4 minute delay before reporting no motion. I’m thinking of setting the sensor into Test mode so that they register no motion right away.
Thanks for all the great feedback. Sorry for the slow response. . . busy weekend for me.
The point of this app is to have some light on always during dark times outside. However, as you found, adding a “0” to the list of dim options should result in the lights being turned completely off after motion stops and after the selected delay.
I think the way to deal with this is by adding an ‘on-off’ switch. This is beyond my capabilities at the moment but I think what is possible is to have a virtual switch that the app watches. When the switch is on, the app runs as expected. When the switch is off, the app would stop and unschedule all the events and unsubscribe to everything except the on-off switch. Then, once the switch is turned back on, the app would start up again as if it had just been installed. In order to keep it simple, I think I would want the app itself to instantiate the virtual switch. Again, I think this is possible but beyond my capabilities right now. If someone wanted to help me with the instantiation of the switch part, I think I can handle the logic for how to respond to the switch.
3 weeks ago was before the latest revision. It is certainly possible that the latest code would have been OK during the flaky time you mentioned. In fact, I think it was this flakiness that got me looking at the code and lead me to the improvements in the latest version.
hmmm. . . not sure about this. If you can capture the log from the app during this behavior, I could try to figurre it out. The app is going to ‘bright’ based on a motion event from the motion sensor. Then, once the motion sensor sends a motion stopped event, the app schedules the dim mode to fire after the delay period. I’m having trouble figuring out what might be causing the behavior you’re seeing. The logs should be able to shed some light on this. I’m using the SmartThings motion sensor and there is no built-in delay for the end-motion event. Maybe the events your sensor is logging is somehow confusing the app. Looking at the log for just the motion sensor might also be helpful in sorting this out. EDIT: I looked into the motion capability in the docs and there are only ‘active’ and ‘inactive’ states supported so it really shouldn’t matter how the device was managing this as long as the capability was implemented as intended with only ‘active’ and ‘inactive’ states and events declaring changes.
Also, I noticed that the dimmer I am using seems to be interpreting a setLevel(0) as a off() command. The reason why I think this is that when I look at the dimmer state after a setLevel(0) is sent, it seems to be remembering the last level and reporting this but also reporting an ‘off’ state. So, if it was at level=10 and ‘on’, after sending a setLevel(0), it is level=10 and ‘off’. I’m not sure if this has to do with anything, however.
Not sure how to diagnose this, but I had a motion event turn on my lights during the day. I double checked my zip code settings, everything settings wise looks fine. Let me know if I can find any other info for you to help figure out what happened.
In the IDE, goto My Locations>SmartApps>[whatever you named the SmartApp in the Other section], then the Scheduled Events table is at the bottom of the status screen that comes up.
I know there some some sort of glitch today in the platform but I checked my house and all seems to be well
EDIT: The other thing that would be super helpful would be - that is, if you can get this to repeat - is to turn on live logging, make the app misbehave, filter the log for just that SmartApp, and send me that (either a screen shot or copy/paste of the text)
I did have it completely stop responding to motion, but when I looked in my events, it looked like motion events where not firing, so I repaired my Aeon multisensor and it started working again.
I did have a different issue with it, not sure what happened, but I turned the lights on myself via the smart app, and set them to 100%. I have a process running to turn them off when there is no motion for 20 minutes, and that failed, and walking in front of the motion sensor after that window did not dim them down to 40% which is what I have in your app for motion events. I turned the lights off in the smart app, and then triggered motion again and they resumed normal function. I really need to be able to switch lights on to different levels sometimes, so I might have to go back to a simple on-off method for motion events, its just unfortunate that the default app won’t look at sunrise sunset for motion events. Maybe Magic Home will be a better option for me until you add virtual on-off down the road.
I’ll leave it running for now and report back if I see any other issues, I’d say so far it seems pretty solid as an app
Real life got in the way this last week but I’m happy to say that your app has been more reliable than SmartThing’s own “Turn Light On With Motion” app. In fact, I REALLY wish that your app offered a dimming value of 0 so that I could replace the SmartThings app entirely. That would also let me have one app control several lights rather than have two “Turn Light On With Motion” apps running.
I currently have 3 GE Link bulbs in one ceiling fixture. At night, I like for all three to trigger at 100% with motion but 2 to turn off w/o motion. The third bulb goes to 10% as a nightlight. Right now, your app controls the nightlight/10% bulb, but I have the ST app run the other two.
EDIT: I saw your edit on GitHub, I’ll test tonight and let you know!
OK! OK! It’s done ;-). GIT is updated. Please test and let me know if it works for you. I have just the slightest concern that this will cause issues since the dimmer I have seems to interpret level=0 as off . . . which shouldn’t be any issue but I don’t know.
This is a little troublesome. Can you show me the app you are using for the 20 minute off-delay? Also, what dimmer are you using?
My app does not use on() and off() methods, only setLevel(). I don’t know why it would, but I wonder if some dimmers and/or lights are confused by getting only setLevel() calls and never on() or off(). Or, if another process is using on()/off() whilst mine is using only setLevel(), does that confuse the dimmer/bulb? @Mike_Maxwell, you seem to be an expert on dimmers. . . do you know?
Don’t know to be honest, however thinking about this from a hardware implementation POV:
setLevel(0) has to be interpreted by the actual device as off(), otherwise turning it on would result in no light output…
So setLevel(0) is ignored, and the device is turned off. calling on() turns on the dimmer to it’s previously stored dim level.
Calling setLevel(0) will produce an off event, setLevel( >0 ) will produce an on event.
Thanks @qwertypo for testing and feeding back. I’m going to call this good for now . . .
@DITPL, I went ahead and also added the “0” option to the version of the code in the IDE (The GIT version also has this) and published to me with no issues. After the discussion yesterday, I’m not worried about issues with having a “0” option.
Ha! Well, I thought I had this thing sorted and solid. My lights did not turn off this morning . SmartApp status page says the sunriseHandler() ran this morning but I can find no evidence of this in the logs and the current app state seems to indicate that it could not have run. I have a ticket into support. If I could see the log from the app itself I might be able to sort this out myself. I think the only way to see log messages from the app is to have live logging on. Someone correct me if I am wrong.
Anyway . … stay tuned. I will let you know what I get from ST support on this.
BTW, the publication request is currently still in the ‘submitted’ state.
UPDATE (2/11/15): Didn’t touch anything . . . lights turned on last night as scheduled and turned off this morning. No response from support yet.