Anyone else seeing where their automations are ignoring the time constraint? My kitchen lights are split into 2 automations. One for daylight hours, then another for after sunset. My All Day automation is firing despite being set to only run Sunrise to Sunset - 60. Just started happening today. Don’t know what point during the day but first noticed around 7pm central. Affected multiple of my time constrained automations, but not all.
I have went through all my automations and hit save on them again to force an update and no change. Went into the api and hit update on the weather station and its firing options look normal to what I think I remember normal is. Hate to say its because the firmware update since obv its an automation not the hub…but something backend?
Yes! I have only been experiencing this since today’s firmware update. I actually did post in the firmware thread on the matter. I have some sensors in SmarLighting actions that should only operate in “Night” mode but seem to be doing it all of the time. It’s not all of my sensors either. Just some.
I’ve also gone through the process to remove and add the routines and it doesn’t solve the issue.
KevinH - You might be right that it’s not specifically firmware. My firmware upgrade was approx 12 hours ago, but the SmartLighting wasn’t misbehaving 5 hours ago. It only started about 3-4 hours ago after I left and came back.
Yes same for me. My outside lights were not working right anymore starting yesterday.
My porch light is not turning on with the motion routine anymore either, but I still see the motion events recorded in smartthings.
Any names of the automations that are no longer functioning would be useful in helping to troubleshoot. Also are these marked to run locally? If they are then this issue is likely not directly firmware related. What happens after a firmware update where we add new locally executing devices is that we check to see if the lighting automation is now eligible to run locally, if it is then it gets synced to the hub. Feel free to DM me with any relevant info, I may not respond directly but am actively looking into the issue.
I had it last week but not sure if it’s still happening now. It was/is when an Arlo Pro 2 camera triggers Hue lights. It’s supposed to only be between sunset and sunrise but it was well after sunrise that it was occurring. The Hue lights run locally but the Arlo trigger must be cloud based.
An automation is either all cloud or all local, in your case cloud so it wasn’t touched as part of the migration - definitely worth looking into if you’re having issues though I think support would be a better route right now… would like to focus on triaging any possible issues stemming from todays updates. I did just track down an issue that occurred during the migration but that only effected the na04 shard and only a portion of the apps that were synced (one of the nodes in one of the system involved in the sync started failing without triggering monitoring alerts.) I’ve removed that server and am running the apps that were updated on that node again which should get them back into a working state.
As I said above, I totally see its not a firmware problem. My friend I gave a v1 hub to is having the same issue. I’ve been around long enough here and am a sysadmin myself so yea, know that its not directly related. But things that spark a change, is a good point to note for the start of investigation.
Thanks for looking into things vlad. and indeed I am on na04 now so maybe you got the issue. I can’t check this weekend…but will report as soon as I can.
Mine are all local, on na02, and it’s only a subset of my SmartLighting automations. So far it is only impacting one of them and I am unsure why. I’ve compared two like sensors, running on two like Leviton lamp dimmers, and the only substantial difference is that there is an extra SmartLighting automation that runs on the problematic room that’s triggered during daylight hours by a different switch. After daylight the behavior becomes automated to come on at sunset and then operates on a sensor basis only in “Night” mode.
That is an interesting data-point - v1 hubs would not have been touched at all during the update that I mentioned. May be multiple things in play here that could be causing that behavior. I spent a good portion of the day looking at logs “hoping” I could find something that got past our monitors though I was specifically focused on the updates we ran yesterday after the firmware deployment. Thank you for reporting this - I"ll keep looking.
It sounds like you have a Local Lighting Automation that seems to be ignoring a constraint? If so please tell me the name , thats the exact type of thing I’m trying to track down.
I’m having the same issues. I’m using an aeon multisensor 6 with a Philips hue bulb. It’s set to turn on the hue bulb when senses motion then turn off after 5 minutes. This is only to run from 11pm to sunrise. Issue is that it’s ignoring the time constraint. This started happening after the firmware update. Please fix this.
Hello,
Is the automation Porch Motion Lights at Night? Seems like the only one that fits the description but theres a few bulbs in it so just want to be doubly sure.
Hey Chris,
I think I found the issue - can you confirm that the behavior you are seeing is that the rule continues to turn OFF the Hue bulbs outside of the time constraint but it doesn’t turn them on when there is motion outside of the time constraint? So only part of the rule is ignoring the time constraints.
Any chance you will get to this tonight? We for sure tracked down one issue here - thanks all. What happened was now that we got new devices running locally some of your lighting automations transitioned down to the hub. The hub is running our new rules engine while the cloud still uses the groovy code. There seems to be a bug in the rule generation code in Smart Lighting - this specific automation looks like:
A rule that triggers the lights to come on (with time constraints) when motion
A rule that schedules the lights to turn off when no motion (SHOULD HAVE CONSTRAINTS)
A rule that unschedules action 4 when motion is active
Action that turns off the lights
We need to apply the time conditions to all of the rules in this automation - only 1 has it applied.
Vlad that sounds like what my kitchen lights were doing. Motion didn’t turn them on, but that rule also had a turn off after motion stopped. So I’d walk in and the cabinet lights didn’t turn on. So I turned them on. Then 2 mins after motion they turned off. That rule was to be constrained by time of day. During the day I want them motion controlled. But at night they are always on. As per the details in my PM.
Vlad - You are describing precisely what is happening here. It sounds like at least one automation transitioned correctly (on my living room lamp) but didn’t for the family room with the same type of rule. Seems like creating new rules doesn’t seem to fix the problem either, so it may impact newly created rules.
Argh - apologies. Its been a hectic day and I must have just not put the pieces together when reading your dm. We’ll get a fix prioritized and pushed as soon as possible.
We for sure tracked down one issue here - thanks all. What happened was now that we got new devices running locally some of your lighting automations transitioned down to the hub. The hub is running our new rules engine while the cloud still uses the groovy code. There seems to be a bug in the rule generation code in Smart Lighting - this specific automation looks like: