Smart Lighting "turn off" timer ends if outside initial range? Definate Bug

I have a Smart Lighting routine that turns a light outside my garage on when the garage door goes from Closed -> Open between sunset and sunrise then turns the light off after 10 minutes. Randomly I’ve noticed the light has been left on and I think its because of a bug in Smart Lighting.

Here is what happened: This morning I opened the garage door at 7:33am and the light turned on per the routine. Sunrise as 7:34am. The light never turned off. I checked the “recently” tab and it confirmed this, no off command.

What I believe is happening is the routine “cancelled” as soon as sunrise hit and never turned the light back off. If thats not what happened then the routine has randomly just failed but its NEVER failed to turn the light on, it only fails to turn it off and it seems to only fail turning it off in the morning after sunrise.

I also believe I’ve had the exact same issue with another light thats based on motion and sunset/sunrise. Randomly it is staying on when it shouldn’t and it like the other…its turned on within sunrise/sunset but then the timer goes past sunrise and the routine just stops running leaving the light on all day unless we notice and turn it off before we leave.

Is this a bug? Can anyone else confirm this issue? I’ve already went through the routines after and just Next through them and clicked Done (did that after last hub update) to refresh them. I haven’t deleted and recreated but if this is a bug its not going to matter.

-Allan

Some evidence. Here is my garage door tilt sensor which is used for the Smart Lighting automation. You can see it open and close yesterday night and then again this morning:

Then here is the Outdoor Garage Light. You can see yesterday night the Smart Lighting routine fired and turned it on then exactly 10 minutes later (as set) it turned it off. However this morning it turned it on, again before the sunrise timer, but failed to ever turn it off until I noticed it this afternoon:

I’ve seen this happen before with Smart Lighting. I’m pretty sure it has been this way for a long time. I first saw it when using defined times, not sunrise/sunset.

Allen,

I had a similar problem, I deleted the routine and rebuilt it. That solved my problem.

Thanks for the report. We’ll get someone to take a look at this.

I posted it in the 19.17 firmware thread and it looks like others are having the issue there too. I would assume at least some have tried deleting and re-adding although I can try that with mine.

Thanks. I put in a support request also but all I got back was a pre formatted reply telling me how to use Smart Lighting to setup what I wanted to do and seemed to completely ignore the bug part…

@Zach_Varberg - Any updates? It seems to be pretty consistent and support asked me to delete and recreate my routines but before I did that I created a new routine to test and it failed also so don’t think deleting mine and recreating would help. Here is how I have a test routine setup:

I went past the kitchen motion sensor at 2:10pm/2:11pm, it switched the Cabinet lights on as it should. I then waited and it turned them off correctly at 2:17pm (maybe a minute late…whatever). Then I walked past again at 2:18pm. Motion was detected, cabinet lights back on. However at 2:24pm they never turned off and I’m assuming it’s because the routine said between 2:00pm and 2:20pm. Here is my lights history:

So at 2:28pm the lights are still on. Of course these were arbitrary values as opposed to sunset/sunrise but it does demonstrate the bug pretty clearly.

Possibly a bug introduced with all the local automations added in 19.17 (Hub Firmware Release Notes - 19.17) ?

I can ping the guys working on this again. The problem comes from the ambiguity that goes with the the guards put on the execution. If you set a rule to turn on with a button press from 9AM to 9PM it’s pretty clear what that means, but when you start to get into more complicated rules it’s a little less clear.

Take the rule “turn on with motion, turn off after no motion for 10 minutes” with the guard to only execute from 9AM to 9PM. If motion happens at 8:59 PM, it should turn on, that is clear. Should the light turn off at 9:09 if there is no motion? I think an argument could be made for both, although I would agree with you that the more natural interpretation is that yes, it should turn off. But now consider this situation: Motion happens at 8:59 so the light turns on, then motion happens AGAIN at 9:01, should the light turn off at 9:11? The initial turning on of the lights happened inside the prescribed time range, but the stop of motion did not happen until outside of the range. Now it’s even less clear what the “right” interpretation of the rule is.

All this to say, it is a complicated issue, and while I do think we can do better I don’t think the app actually provides enough specification for us to fully understand the intent of the user.

However, I can give you a few options for workarounds that you can pick between depending on what is the most important behavior for you.

  1. There is a lighting automation trigger type called “Power Allowance” which is admittedly not the most intuitive name, but this lets you set a rule for if a given light turns on, turn it off after a certain amount of time. If you ALWAYS want the light to turn off after 10 minutes, but ONLY turn on with motion in a given time. You can split into two rules, a motion trigger that turns on between the given hours, but a power allowance rule that ALWAYS turns off after a certain amount of time. This has the downside, however, of turning off even if motion continues so works better with longer time periods (you could even use the turn off part of the motion event and use this as a backup with a long timer like 1 hour) But, this option has the advantage that all these rules will continue to run locally and thus would work during an internet outage.

  2. If you manually create a device in graph with the type “Simulated Switch” and add it to the rule, it will force the automation to run in the cloud. The advantage here is that the behavior will go back to whatever it was before, the disadvantage is that you lose the local automation.

  3. Write a “backup” smartapp. This is the most work, but has the highest upside. Basically you could write a monitoring smartapp that has similar rules to lighting automation, but trimmed down for your specific use case. Here you could have it turn on with motion, off with no motion after X amount of time, but with a slightly longer timer. This would allow the existing rule to continue to run locally, but since this smartapp is running in the cloud, it could be set up to use the old behavior, and would then turn the light off if the bug occurred and the local automation didn’t turn it off when you wanted.

There are probably some other potential solutions that I’m not thinking of right now too, but that gives you at least a few options. I’m sorry it’s not working right now, and as I said I will bump the people who work on this as well. But with the holidays and everything, I wouldn’t expect any solution to go out for a while.

2 Likes

Maybe the app needs to be rewritten so the trigger occurs between the times specified but the routine continues indefinitely. Not knowing anything about the underlying code but understanding code in general that can’t be too hard to implement and would fix what I’m calling a bug in the way it currently executes.

Yup, and that’s what I suggested as a fix. With the most straightforward fix, the light would turn off 10 minutes after all motion stops during the last motion event before the end of the time limit, but not stay on if motion restarted after, see example below for what I mean.

2 motion sensors, time guard of 9AM to 9PM

  • motion 1 on at 8:58
  • motion 2 on at 8:59
  • motion 1 stop at 9:02
  • motion 1 start at 9:03
  • motion 2 stop at 9:03
  • motion 1 stop at 9:04
  • 10 minute timer starts to turn off lights as all motion stopped (9:04)
  • motion 1 starts at 9:05 (should this trigger, which is now clearly outside the trigger range, cancel the timer to turn off the lights)
  • motion 1 stops at 9:06

What time should the light turn off? 9:10? 9:14? 9:16?

Capturing this case is even more complex. I think that 9:14 is a reasonable solution, and works for most peoples use cases, but I can also see 9:16 being the correct behavior.

There is an entirely other case where there is ambiguity as well. Take the case of “turn on with open, off with close.” Open and close can be two completely distinct events and the “base” state could be either one. If the rule says 9AM to 9PM should either trigger outside of that time? Should open and close be “tied” together?

I’m not trying to say this isn’t a bug, and I’m always glad to find and fix bugs. It’s just pretty nuanced what a “bug” vs “different interpretation” is for lighting automation. This is being worked on though, and we will do something that, at the very least, is better than the current behavior.

1 Like

@Zach_Varberg

I have exactly the same issue as described above and await an improvement. Currently I have to switch off lights myself if they were triggered just before the mode change (in my case).

In addition, is it also possible to fix the behaviour whereby a motion sensor ignores ongoing activity.

See below…

In SmartLighting I have the following setup - switch on lights for 5 mins if there is movement and lux is less than 200

Works great most times, however, if I’m in the room at say 210 lux and am continually triggering the motion sensor, then the lights will not come on at 200 lux, but only come on if I sit still longer than the 5 minutes in order to then set a new motion event on the sensor.

Surely the lights should trigger with existing motion on the sensor, not just on a new trigger after 5 minutes of zero activity have elapsed.

1 Like

I agree fully with @23dash, That is how I would expect it to work. Any action within the constraints should reset the timer which should be allowed to run past the constraints like I mentioned before.

In the meantime can we get the smart lighting app renamed to average intelligence lighting app?

1 Like

Hey, at least it runs locally!

I’ve managed to work around this a bit, at least to get around lights being left on because a SmartLighting time range expired. This is how I did it for the basement.

Rule #1:
Turn Basement Lights ON when motion, OFF 10 minutes after motion stops.
Guard Time: Sunset - 15 mins to 11pm

Rule #2:
Turn Basement Lights OFF 10 minutes after motion stops.
Guard Time: 11pm - 11:30pm

What this doesn’t address is any cancelling of timers if someone stays in the space after 11:30, but since we don’t spend much time down there, that’s an acceptable limitation.

2 Likes

So this should hopefully be fixed now. You will have to open and re-save your rules to get them to update (I know, I know, it’s a pain). But hopefully now, this should work as expected.

2 Likes

@Zach_Varberg

That’s great news Zach

Does it also fix this…

It will not fix that. That is due to the fact that the only stateChange events are propagated through the system. It would take significantly more changes to lighting automation to support that sort of change.

Surely most people would want lights to come on at preset lux level while there is already movement on the sensor. Hopefully you can see merit in this.

I completely understand the use case. It’s just a matter of prioritization and the amount of work necessary. Since the original bug reported here was related to something new, and something I was tangentially involved in, I pushed it through. However, what you are talking about is how Smart Lighting has always worked, as well as being a larger workload so we can’t just sneak it in without planning. Support keeps stats on contacts for issues, so I would recommend letting them know about your concerns. For now, you would have to use a community solution to get that behavior.

Doable in webcore. Not your optimal solution of course, but given the current status and your use case it’s where you need to go.

I doubt that many people have a light sensor. Me personally I just base it on sunset/sunrise (which was why this post was created in the first place).

Awesome. Thanks Zach. I only have a couple and now I can delete my “catch all” rule that was turning some of these off 20+ after sunrise as it’s not needed.