Dusk-to-Dawn Dimming Motion Light - RC1

SmartApps & Automations
42

The problem is that “peak” follows sunrise/sunset across 4 different timezones …

43

Ha! Yea, I guess that could really stretch out the peak time!

I had thought to, but didn’t get around to trying this . . . . thanks for reporting this

Just to be clear, I am not seeing a ‘delay’. The event is simply not firing at all. Like it was forgotten or somehow ‘lost in the mail’. A delay of a few minutes would be unnoticed in this application, I think, and would be fine.

44

I think I know why some of the scheduled events are not firing. I think some scheduled events are delayed slightly such that I am scheduling tomorrow’s event (and overwriting today’s) before today’s occurs. I think I know what to do to fix this and will do so when I get some time. . . .

45

OK. I just completed a fairly significant rework to how sun events are scheduled. I’m now doing this once a day at 12:13 local time rather that twice a day at sunset and sunrise. Hopefully this will resolve the issues I had been seeing. The code behind the GitHub link earlier in this thread is updated. I will report back in a few days after I have been able to verify that it is working.

UPDATE 1/16/15: So far so good, except the start routine didn’t complete last night so the lights stayed at 30% until the first motion event. I had changed the runIn to a runOnce to resolve this but it didn’t work. Maybe a peak-time traffic issue. It did work several times during my testing. I am considering adding an arbitrary offset to move the event just slightly off peak when the user does not opt for an offset. . . .maybe a minute or so. Very frustrating that there is no reliable method to make something happen with a short delay of a few seconds.

1 Like
46

Thanks for the update. Will try it out tonight. Not sure if this is related but all 3 of my GE link bulbs lost connection and won’t reset using 3 different dimmer settings with this app. All other Ge link bulbs in the same area with different app are OK.

47

Thanks @Navat604. I’m not sure how a SmartApp would cause the issue you are describing. The only thing I can think of is the method used for turning the light off. In my SmartApp, I am using the setLevel() method and setting to 0 rather than using the off() method. I have been curious to know, in general, if there is a preferred method.

48

Just posted another edit today - scroll up and find my last GitHub link. Added an arbitrary offset of 1 minute to both the sunrise and sunset times to reduce the chance of peak performance issues when no offset is selected by the user. I also reworked the way offsets are set by the user. With this change, I have now exorcised the last bit of code that I didn’t understand but that came along with a template or other example ;-). This code works on the IDE. I will load it at home and start testing today.

The new code also includes some general house-cleaning, comments, rationalized log entries, etc.

Enjoy!

49

Thank you! I was going to log in today and report that I’ve had a lot of luck with this app combined with Magic Home and the GE Link bulbs. I noticed today that you allow us to select multiple motion sensors… I’m going to attempt to have two motion sensors in my kitchen to improve performance. I’ll report back.

50

Thanks for the feedback, @DITPL!

Yes, support for multiple motion sensors has been there since the original code @pstuart put together. However, I have never tested this and really haven’t thought about how this would work. I think I need to add one line of code, unschedule(modeDim):

def handleMotionEvent(evt) {
	log.debug "handleMotionEvent() Motion detected . . . ."
    
    if (state.ambient == "dark") {
    	switches?.setLevel(state.BrightLevel)
        state.Level = state.BrightLevel

        unschedule(modeDim)   //in case motion has stopped on another motion sensor and modeDim was scheduled

    	log.debug ". . . set the dimmers to level $state.BrightLevel"
    }
    else 
    {
    	log.debug ". . . but its light, so do nothing"
    }
}

This handles the scenario where one motion sensor posts a ‘motion stopped’ event, modeDim() is scheduled, however, in the meantime, the other sensor post a ‘motion’ event. In this case, you would want to cancel the scheduled modeDim(), Actually, now that I’m thinking about it, this should be the case even if there is only one motion sensor . . . that is, if motion is sensed during the time delay between motion ending and the modeDim() call, the call should be cancelled. The modeDim() call should be based on the motion stopped event of the last sensor that sensed motion.

I’m going to chew on this before I commit the change but if you want to try it, please do so and report back.

EDIT: After looking into this, I determined I just needed to move the unschedule(modeDim) from the handleEndMotionEvent() handler to the handleMotionEvent() handler. This should now correctly handle the case of motion being sensed during a delay before dimming - regardless of how many motion sensors are used. I have update the code on GitHub and that’s what you will get if you follow the link I have earlier on this thread. Thanks, @DITPL for bringing this up.

51

Continuing the discussion from Dusk-to-Dawn Dimming Motion Light - RC1:

Alex, how do you get around false presence notices?
Does your app have any way to trigger only if a presence has been “away” for more than x minutes?

52

I just wanted to thank you for this smart app. It was one of the first that I installed and it has worked very well for me. I’ve been having a lot of problems recently with my Aeon Multisensor that is triggering the app, but that’s not your fault! :smile: Before purchasing the hub, I remember asking ST support if this function existed, which was very important to me, and they said “No, but some smart ST user has probably written an app to do it.” They were right. Great work and thanks again.

1 Like
53