I created a rule in rule machine, it was intended to slowly dim my kitchen lights down over a half hour with a time-based trigger.
I found that if I tried to make any subsequent changes to the dimmer level after the rule had triggered, the rule didn't cancel the remaining fade steps, it would go right back to where it was in its fade countdown and continue as before.
I deleted the rule, I haven't had a chance to figure out how to recreate it with a cancellation of the remaining fade steps if someone physically changes the dimmer at the switch while the rule is fading down.
I subsequently created a rule that would dim the kitchen lights down if someone turns the lights on at the switch during evening mode (over 2 seconds). The condition is kitchen lights >60, the action is set level 60 fade over 2 seconds, restricted to evening mode.
Last night I noticed that the kitchen lights were rapidly dimming up and down. I looked at the event log for the device, and the slow fade over a half hour was clearly running (the action executed by the rule I deleted). Here is a shot of the event log from the device.
I just double checked to make sure I don't still have a rule that's visible in the apps list. And there's no other rule that should be executing the same actions. Why are the actions from the rule I deleted still running?
Was the rule already started when you deleted it? It might be the commands were already queued before you deleted the rule. Or a daily schedule might be created at 12am when the system starts a new day. It’s a funny bug though.
Yeah, the rule was probably running when I deleted it. However that was several days ago and I didn’t notice anything amiss til last night. I created the new rule maybe two days ago.
Looking farther back into the device log, the original rule’s actions continued to be run every night at 7:30pm even after it was deleted. I guess I didn’t notice anything til last night because with the new rule in place, the dimmer level kept ping ponging up and down.
Try rebooting the hub. It should clear out the orphaned routine. My suspicion is that the routine couldn’t be removed when the rule was deleted because it was running, so it’s still there just unlinked to a rule. If a reboot doesn’t fix it, email support@hubitat.com and they can get it fixed. @mike.maxwell Your thoughts?
pretty sure I installed the last firmware update since deleting that first rule, which I’m assuming involves a reboot? But I’ll reboot nonetheless and see if it happens again tonight. I suspect I’ll need support to clear out the headless rule’s actions, but we’ll see.
Thanks!
Still happening despite resetting the hub.
I’ll reach out to support re: getting rid of this rule’s actions. Thanks for the suggestions.
This happened to me too! I created a rule to close my curtains in my office at sunset, and another one to open them at sunrise. Right after creating the two rules, I deleted the rule to open them. The blinds opened anyway in the morning, This went on for two weeks even though there was not a visible rule in the Rule Machine section, or listed in the curtain driver. It’s like it took 2 weeks for my Hubitat to realize the rule was deleted. Lots of reboots and I think 2 updates before they finally stopped opening.
Interesting, the schedule for the actions must have been hanging out in some kind of cache for a while, even though the rule itself was gone, I guess?
Bobby with support is looking into it for me, hopefully we can get it to stop in less than two weeks!
@bobbyD here’s the the log at 7:30pm when the headless rule started up again..
Rules log when they do anything, and those logs aren't showing that. All of those log entries are from devices. So how can you be sure this is from a rule?
TBH, I have no idea what’s going on.
But this is how the rule acted before I deleted it. Every couple mins it would drop the fade level by 1% at a time from 100% to 60%.
Those actions continue to occur even though the rule has been deleted.
I don’t have any other automation that would execute the same actions.
We are looking into it. Thanks.
2 Likes
Much appreciated. Please let me know if I can provide any additional info to help track down what the issue is.
1 Like
@max.leung pointed out if you select the device that’s got the ghost automation, you should be able to see all rules currently accessing that device. They’ll be listed at the bottom of the page. Maybe you can select the rule from there and delete it?
Working with support on it, thanks.
I can see that. I’ve just read other people having the same problem, so I thought if this was a solution to it we could have a public answer and support wouldn’t have as many problems to solve. 
Max was able to delete the duplicate rule from the device page when he encountered this issue, so maybe that’ll be the solution for other people too.
Hopefully for some, not for me.
I’ll be on vacation for a few nights, so nbd for me till it gets fixed.
We have looked into this, and do not believe this is coming from deleted rules. When an app is removed, any scheduled events it established are unscheduled. We cannot reproduce this behavior you are reporting. Also, as I said above, if it were a rule running, it would leave footprints in the logs, which are not there.
Guess I’ll just have to wait then. Thanks.
Figured it out in the end, thanks @bobbyD and @bravenel
It wasn't coming from the deleted rule at all. It was coming from an old webcore piston in ST that I hadn't deleted (or paused). The strange thing is that I'm using a new Lutron pro bridge with hubitat and the old Lutron bridge that was connected to ST is powered down. And the webcore piston was written to execute actions on a different Lutron dimmer when everything was still connected to ST.
So that's a lesson for me I guess. While moving things over from ST to hubitat in stages, make sure all remnants are gone from ST and webcore, at least when it comes to Lutron devices.
2 Likes
