Dusk-to-Dawn Dimming Motion Light - RC1

Seems reasonable, but, I just did a test. In the code I have posted above, i just change line 151 from

schedule(state.riseTime, sunriseHandler)

to

schedule(state.riseTime, sunriseHandler())

and line 164 from

schedule(state.setTime, sunsetHandler)

to

schedule(state.setTime, sunsetHandler())

And when I ran it on the simulator I got this log:

I’m not really sure what’s going on but it seems like right after the handlers are scheduled, the are run even though they should be waiting for the scheduled time. Then there is that error called on 162 - I guess this somehow a result of running the handlers immediately ??

Just as a sanity check, I took the “()” back out and re-ran. . . no issues. Baffled.

Anyway, let me know if you get a chance to test the new code and if it’s doing what you wanted. Also, if any of the ‘caveats’ are problem, let me know. I know they can be resolved but it’s just more work :wink:

I wasn’t quite sure what this did, but it’s kind of a super night light right?
On at dim level x when its dark, them up to dim level y with motion, and off after that…

My dimmers, and I “think” most of them will ignore a 100 if used as the dim level.
Mine would not brighten up until I changed the 100 value in the code to 99.

It’s a little busy setting the same dim level twice in the code (as seen in the logs), you could iterate through the switches and only reset the ones who’s values differ from the desired…

So far works as advertised.

Pretty much, yes. Except, stays at dim level y (bright) z minutes (you set) and then checks to see if its still dark or after sunset/before sunrise. If so, returns to dim level x. If not (got lighter or sun came up), then turn off.

Interesting. I saw 99 used in some other code and didn’t know why. The dimmer I’m using is OK with 100. I will change to 99, however.

Looking into this made me realize a problem. Everytime there is a luminance event - in your case, probably every 5 minutes - I evaluate the luminance. If its dark, I set the sunPosition to ‘down’. If light, ‘up’. The I run the same handler I use to decide where to go after a motion bright period, which means, every 5 minutes, the lights are going to be either turned off or set to dim level x (lower setting) even if you had set a longer bright time and a motion even had occurred. I think I need to handle this differently.

OK. I’m going to rework this. Maybe tomorrow. I think I know how I need to do it. Stand by . . .

I did a significant re-work of this. I created state.ambient that is dark or light. The dimmer comes on and off based on the ambient state. I created some rules: If the sun is down, state.ambient is dark no matter what the measured light would suggest (prevent some false indications of light). If the measured light is below the threshold but the sun is up, state.ambient is dark. The code looks for transitions and will, for example, do nothing when the light sensor reports that it is dark if state.ambient is already set to dark. The new gotDark() and gotLight() methods are fired once it has been determined that a change has occurred. This should prevent the busy-ness that was there and resolved the logic issues I had.

I reworked the preferences and value lists to facilitate the following use cases:

  1. Dusk to dawn only
  2. Dusk to dawn with motion sensing
  3. Dusk to dawn and light threshold
  4. Dusk to dawn with motion sensing and light threshold

A transition to light simply cancels any motion-activated bright time. Motion is ignored unless its dark.

Since some dimmers don’t like 100, added logic that sets the value to 99 if is was set initially to 100. This way, the user still gets a 100% option in the preferences.

I tested to the extent possible on the simulator and installed at my house and will use it in use case #2 above since I don’t have the illuminance capability in any of my devices.

Questions/comments/suggestions? Bring it on!

EDIT: Just made a super minor change. Updated in Git . . .
EDIT: Also corrected issue with sunriseHandler. Updated in Git . . . .
EDIT - Just posted (1/15/15) a new version that I’m testing now. Should resolve reliability issues that developed
EDIT - The code behind this link was updated again today (1/26/15) and I will be testing it at my house starting today
EDIT - Another tweak. . . see post 49

So this has inspired my first attempt at any kind of coding whatsoever. more of a frankenstein than anything.What i wanted was basically the same app, but with the presence sensor as the trigger so that i could have an outside light come on bright when my wife and daughter come home, then go back to a dim light for the remainder of the night / turn off if during the day. Thanks for the inspiration!

This is great! Super idea. Maybe I should include a presence option in the SmartApp along with motion. I haven’t done anything with presence yet. Would you mind if I used your code (and credit you)? Does your code work as you expected? With all of these features, it will be hard to come up with a concise name ;-).

no worries. Say since last night has the delayed dim / off stopped working for anyone?

@cl810 - I have not noticed any issues. At the moment, the app says the lights are off (as they should be). I’ve been watching this fairly closely so I think I would have noticed if something stopped working last night. I’m using motion as the trigger vs presence. Maybe there is an issue with the presence functionality. I would like to include a presence trigger as an option to the main app . … .so. when I have time to dig into this, I will look into possible issues. What, exactly, is happening for you? Stays bright indefinitely after a presence event? Did you look at the logs?

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.

ADDITIONAL DETAILS:

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