Dusk-to-Dawn Dimming Motion Light - RC1

my light didn’t go off this morning too but because my mode didn’t change.

Using which app? I haven’t tried to figure out modes yet but I know ST automatically puts a mode option in the preferences. Did you select a mode option? The app is designed to work independent of modes and I haven’t tested it to understand how modes would interact with the app. If the mode selection option creates times of the day where the app is turned off, I would think that could cause problems. I wonder if there is a way to suppress the mode selection item in preferences . . . .

I am using your app for my driveway light and because I don’t have motion sensor everywhere yet. I want the light to be full bright when I am home and not sleeping yet. So I actually installed two of the same app to do different thing at different mode.

Interestingly, my lights did not go off this morning. Checking the logs of the dimmer shows no evidence of anything happening at sunrise. I will dig in more when I get time. . . maybe later this morning.


Based on what I’m seeing the in application state:

it looks like sunriseHandler() didn’t fire as scheduled this morning. Tomorrow’s sunrise is scheduled as expected:

the ‘Prev Run Time’ has always looked like this even when the scheduled jobs happen as expected. I’ve just assumed there is an issue with how the platform stores and/or reports the Prev Run Time. So, I don’t think I have any way of knowing whether or not this morning’s sunriseHandler() was scheduled correctly and just did not fire for whatever reason.

In my investigation into this, I think I found a problem in the sunriseHandler() that should be unrelated but might cause an issue when luminance is selected as the trigger. I will look into this when I can.

UPDATE: I didn’t touch anything and everything has worked as expected the last couple of days. Probably an issue in the platform. I still think there is a problem in the sunriseHandler but it would only be an issue for anyone using the luminance option (which I am not).

Understood. Seems like you should be able to do this with the built-in stuff but I’m not sure. In any case, I don’t know why this wouldn’t work using this app. Maybe there is something in ST that is causing some weird behavior with scheduled events.

I corrected the problem I found in the sunriseHandler(). The problem was pretty minor: The lights would not turn off at sunrise if the light was already above the lux threshold. However, this should have self-corrected as soon as the next report from the light meter. I did not test this, however. In any case, I updated the post above where I included the Git link.

I was super-busy over the holidays so I didn’t pay attention to ST goings on . . . . seems like my sunrise handler has not fired at all in 2015 (lights have stayed on all day). Not sure what happened . . . it was working before. Is anyone aware of a platform-wide issue that could be causing this?

EDIT: Also, I discovered separately that using runIn for times less than 60 seconds is either prohibited or just unreliable. There is a runIn in my code I use in the routine the starts the lights at 30% and then transitions to the selected dimmed level after 3 seconds (a workaround for certain bulbs that will operate but won’t start at very low dimmed levels). So, if this runIn fails, the light will remain at 30% until dawn or until a motion event occurs. If anyone has a suggestion for a better way to do this, please let me know!

I just uninstalled and re-installed the app at my house to see if this corrects the problem with the sunrise handler not happening as scheduled. Not sure how it would, but just checking.

UPDATE: The un and re-installation of the app seemed to solve sunrise issue but only for one day. Once again, today, my sunrise handler did not fire as scheduled. I started a new thread to discuss troubleshooting options.

1 Like

Thank you for the update Aaron. I have the same problem as what you have. Change the schedule time to some none peak did not help either. Unless they are talking about peak time is something crazy like from 5pm-9pm. for now I just manually turn the light off in the morning.

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

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.

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

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

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.

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.

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.


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.

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") {
        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"
    	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.

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?

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