Dusk-to-Dawn Light Control with Lux control and Motion Dimming - RC2

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. That makes perfect sense, @Mike_Maxwell. Hopefully something will show up in the logs that explains what’s going on.

@qwertypo - I am using Evolve which is just a branded Linear dimmer, as I understand it. That would be fantastic if you can capture some logs for review. Thanks!

Tried recreating the issue with no luck, everything is working just fine! So maybe related to the Aeon motion events being unreliable. Since I repaired it I have not had a single issue.

1 Like

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.

I will submit when I get a chance. . . .


Ha! Well, I thought I had this thing sorted and solid. My lights did not turn off this morning :frowning: . 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.

I don’t think it’s just your app. My other 2 apps didn’t turn the light off this morning either.

As for the log. I know you can get the log of the device by going to IDE/my devices/click on the device /list events. That will show all the activities of that device. I use that to see if my app turn on/off my device. I don’t know about log for just app since you can have multiple instances of the same app.

. . . but you can name each instance. In the live logging view, the filters seem to be based on the name that is assigned in the preferences, not the name of the app. In any case, I don’t think these logs are saved . … or, at least they’re not accessible via the IDE.

Thanks, @Navat604, for the report regarding the other apps. i gave support a detailed description of the issue including screen shots, states, code, etc. Hopefully they will shed some light on this. I feel like other weirdness I’ve personally experienced could have been explained by some code issue . . . but not this time.

EDIT: 2/13: I know there is a lot here to digest and maybe no one cares at this point, but, here is the crux of this, I think: The only place in the code where state.sunPosition is set to ‘down’ is in sunsetHandler(). According to the platform, the last run of sunsetHandler() was before the last run of sunriseHandler() where state.sunPosition would have been set to ‘up’. So, it doesn’t seem possible that the code in sunriseHandler() executed and it does not seem possible that state.sunPosition was set to ‘dark’ after the last (reported) running of sunriseHandler().

Well, ST Aaron (not to be confused with me) in support asked me to take this back to the community and recommended some tags: @April, @matthewnohr, @mager . Here’s what I presented to ST Support (with some edits for clarification since a few days have now passed):

According to status page of the SmartApp (a few hours after the lights should have turned off) . . .

. . . . my sunriseHandler() ran at 7:01 AM. This handler looks like this. . . .

Notice line 182 sets state.sunPosition to ‘up’, yet, according to the SmartApp status page (below), it is ‘down’ . . .

. . . also, there is no light meter selected in the SmartApp instance running at my house so the sunriseHandler should have also called gotLight() which should have changed the state variable ambient to ‘light’ which didn’t happen.

The reason why I took this to ST support is because it seems like the platform is reporting that sunriseHander() ran, yet, it seems pretty clear that it did not according to what the platform is reporting in terms of status of the state variable. I don’t understand how this can be a code issue.

Can anyone offer some insight? The entire code for the SmartApp is still available behind the GitHub link in my OP, in the state is was installed at my house.

It would be real handy to see logs from the SmartApp but I don’t think these are saved anywhere. Correct me if I am wrong and just haven’t figured out how to find them.

@AaronZON, Thanks so much for the work you’ve put into this! It works extremely well thus far. I’ve been using it for about 2 weeks in my kitchen with some dimmable recessed lights and a motion sensor. The simple configuration is that when a specific mode is triggered the lights will turn on and stand at 10% brightness for a night light in the evening. Then when motion is detected they go full bright. That works perfectly.

But because it’s my kitchen sometimes it’s an in-and-out trip other times we’re in there for a while. The issue we’re experiencing is that after a while (sometimes it’s 5 minutes, sometimes it’s 20… I can’t figure out what’s happening with the delay. The lights will dim back even when there is constant motion.

Is there any chance there is a setting that I’m missing when it comes to prolonged motion keeping the lights on?

Thanks again for all the work on this!!

Thanks for the feedback, @atburke85. So, you made a selection in the ‘Set for specific modes(s)’ dialog? I don’t honestly know how that works and I haven’t done anything with modes. I think ST automatically puts this dialog in the preferences. . . I didn’t do this in the code. In any case, I’m not sure if it would matter.

Also, please verify, you are using just one motion sensor? Which one do you have?

How the app is suppose to work is like this: when it’s ‘dark’ (either sun is down or light meter reading is below threshold), the light is supposed to be on at the DimLevel that you selected. Then, as soon as any motion is sensed (motion.active event), the lights are turned up to the BrightLevel you selected. They should stay bright (any scheduled dimming is cancelled via unschedule(modeDim)). Once there is a end motion event (motion.inactive), modeDim() is scheduled for the amount of time in the future you entered as the ‘Bright delay after motion stops’ value in the preferences. Then, after the delay, modeDim() runs and lowers the lights to DimLevel.

Once modeDim() is scheduled, there are two things that could cause it to be cancelled: 1) a new motion.active event occurs which should fire handleMotionEvent(evt) which includes an unschedule(modeDim), or 2) another motion.inactive event occurs which would fire handleEndMotionEvent(evt) again which creates a new scheduled occurrence of the modeDim() handler that will overwrite the one that was already there (restarts the delay). This would only happen if you had 2 motion sensors being used by the app.

So, what you are describing ‘shouldn’t happen’. The next time it does, please look at the log for the motion sensor and see if there is any wierdness in the events posted.

Also, there has been discussion here in the community about issues with the unschedule() function . . . sometimes it happens quickly, sometimes not. This could be a contributing factor.

@AaronZON, I did a diff on the code I was running and the RC2 code you posted and there were a few differences. So I started fresh with the RC code and it seems to be working now. I just spend the better part of 20 minutes dancing with the dog in my kitchen without any issues from the app. The debugs showed a series of resets but nothing else out of the ordinary. I’ll keep an eye on the logs and update you if anything changes. Thanks again so much for the support!

1 Like

I’m not sure how many are using this app but I just wanted to update you on a few things:

  1. There was a platform update in late February that addressed some an issue that could have been the root cause of occasional failures I had observed (really only 2 since the latest code version). I suspect an issue with how unsubscribe() was working was the root cause and may have been fixed. No problems for me since this update . . . . keeping fingers crossed.

  2. This platform update also talks about improvements to sunset/sunrise performance. However, I think I coded around any issues this may have been causing anyway and I don’t think this app will see any difference from this aspect of the update in particular. Based on what I have seen in the forums, other apps were having much more frequent failures.

  3. Please be sure you are running the latest code. The last commit was on Feb 5. The latest is behind the Git link at the top of this thread.

  4. No action on the publication request . … . still just indicating ‘submitted’.

Still interested in any feedback you might have. Less about additional features (but still let me know) but more about issues/problems you might be seeing.

I am, and have been for about two weeks now?

So far, I’ve had no issues with the updates pushed by ST. Everything seems to be working with respect to the sunrise/sunset. Now if I could just get the rest of my house to leave the switch alone…

Ha! Duct tape is the answer.

But seriously, a nice feature might be to have the option to gracefully recover from manual intervention. Maybe X minutes after a manual change to the dimmer the app re-initializes. This must be possible, however, for whatever reason my family doesn’t mess with the dimmer I have running on this app so I’m not personally super-motivated to dig into this. The app will gracefully recover after a motion event or the calling of a gotLight or gotDark handler as it stands now.

It’s been very solid for me. I use it to operate all of the motion sensing lights in my home. FYI, the code says that it was last updated in Jan. With the updated Cree bulb device types and the updated ST backend, I’ve had no issues recently. Very solid app. That recovery feature would be nice. I’m tempted to get a light sensor.

Good catch. Thanks. The commit in February was for the change I made for you to add the 0% dimmed state option but I did not update the comments in the actual code. I will correct this when I get a chance. Thanks for your feedback.

Hi - just tested this tonight with a Fibaro Motion sensor (that has lux sensor). I’ve set the lux level setpoint at 50 - yet it seems to be ignoring it (whether lux is above or below 50 - lights always act as if it is in night mode) … seemingly being overridden by the default location coordinates (all tests done after 10pm).

Anyone else have this problem?

Hey @tuffcalc! Thanks for the report. That’s the intended behavior. If the sun is down, it is ‘dark’ regardless of the state of the lux sensor. Here’s the code:

def sunsetHandler() {
	//Light meter not evaluated here.  Sunset has priority over light measurement in determining state.ambient
	log.info "sunsetHandler()"
    state.sunPosition = "down"    
    if (LightMeter) {
    	if (state.ambient == "light"){
        	log.info "Sun went down but it is already dark so do nothing"
        log.info "Light measurement option not selected, sun went down so it is dark"

. . . so, the idea is that you don’t want headlights or even the lights you are controlling to trick the app into thinking the sun is up. The purpose of the lux capability is to allow the lights to come on when it becomes dark for reasons other than the sun is down . .like a storm.

Please test during the day and let me know if everything is working as expected. I don’t have a lux sensor so I’ve not tested this in real life.

1 Like

@AaronZON - ahhh, makes sense.

I was actually trying to use it as a simple Lux/motion sensor for indoor use (lights on when dark and motion detected, leave lights on even if Lux is now bright because lights on, turn off after x minutes of no motion / rinse and repeat).

I guess I got greedy :slight_smile:

I will try it out in daytime and report back if any issues.