When you had removed lots of devices and it was stable, perhaps it would have been better to introduce your devices in a slower manner. That way you would have a better idea of what device caused the issue to reoccu rring urring ur.
If I knew the cause this thread would not exist.
What I am saying is that I originally believed it to be related to Homebridge. I installed homebridge adding all devices that I would use. That broke things. I reintroduced homebridge in a number of ways each time causing the issue (thus a very extensive thread of homebridge in this forum where others acknowledged the issue).
However, I have come to also realize that the issue is coming up whether I have homebridge installed or not, it just takes longer to manifest itself. I realized this because I had this problem and documented it to support about a month before I ever installed homebridge and several homebridge users don't report this being an issue.
I almost think of it as an old Microsoft Windows memory leak. If you have some program/task running in the background that is slowly eating away your memory you may never realize it is there... until you run some memory intense program in windows. Your first thought is to blame that memory intense program because every time you run it Microsoft Windows would crash. That example seems way too analogous to the current situation as I think Homebridge might be that memory intense program in HE.__
The reason I never noticed the issue, absent homebridge, was because the HE team constantly releases firmware updates (at least every 10-12 days which is a nice thing). When I update the firmware I reboot HE and whatever is causing the issue stops before it has the chance to truly manifest itself.
All the Homebridge (Hubitat) App is doing is sending HTTP requests to Homebridge Service on every subscribed device event with the specific change.
I can see this being an issue if you have 200+ highly active devices where is just constantly sending device events. Beyond that, I really struggle to see how it's the Homebridge (Hubitat) App causing the schedule execution issues.
It's bidirectional though. Events on the Homekit side get sent to the Homebridge (Hubitat) App that must be handed to Hubitat.
I sincerely doubt it's the "expected, rational" traffic that is causing a problem. Therefore the "unexpected/irrational" traffic becomes the question area... error handling, etc. 
What happens if in the Home app we turn on/off a switch/light and on the Hubitat side, the device is failed/dead? Could "excessive" cpu be burned via retries? <-- this is me trying to create a story that weaves thru the known facts. Homebridge is a factor.. my testing is inconclusive because I only just turned it back on yesterday, wanting to try out the Presence suggestion. I have 45 devices selected in the Homebridge (Hubitat) App, all Switch Devices, except one "Other" - my Yale Lock.
Hubitat works the same today as it did yesterday... for me, this time. Previous deployments didn't. Removing Homebridge (Hubitat) App coincidentally improved things.. just like rebooting often does.
For me, there's no smoking gun related to Homebridge (Hubitat) App. There's just some heavy coincidence.
I agree. I don't think its home bridge. I just think homebridge is a heavy coincidence because every action in HE is now duplicated (to the extent you are sending receiving commands to/from homebridge).
Where I am still stuck is why does this only effect events that are time sensitive.
For instance,
- When all hell broke loose Alexa worked just fine and commands to turn on lights were snappy and normal;
- When all hell broke loose I have a simple lighting rule to turn on a certain light when a door is opened and turn it off when the door closes. Never fails. BUT
- I have a rule that says turn on a light when a door is open and turn off the light X minutes later... rule fails.
Everything involving any measure of time fails.
I would think if this is a memory type of an issue wouldn't everything slow down/fail? In other words, if this were a memory issue would I say "Alexa turn on the lights" and wait 30 seconds?
I don't have any coincidences that scream "time related" to me.
BUT
"would I say "Alexa turn on the lights" and wait 30 seconds" <-- that is familiar. Although in my case Alexa is barely a week old here and I'm pretty sure I'm the only one in the house that's said anything Home Automation'ish to her
I do see motion events not turning on lights with variable delays of "instant" to 20+ seconds. My ZWave network seems to be "crushed under the burden" of turning on a light. 
But in the specific cases I am seeing of this delay.. it's got no "time" element.
So if you have a light that is automated to turn off in 2 minutes... it always turns off in 2 minutes?
That type of delay would drive me nuts.... too much like SmartThings behavior
@JDogg016 I think I said earlier in this Thread, (I know I typed these words somewhere...) I don't monitor the OFF timing very well. If Electricity was free, I'd just have everything ON and have 50 fewer Rules to worry about But it's not, so I want the lights to go off "sometime after we're done" in that room. I know that when I create the Rule, yes, I watch, it does go off exactly on time. But +- 20 second accuracy on day-to-day -- just don't watch that closely. Sorry. 
Same with lights that come on or go off at "sunset" or "sunrise". Off the top of my head, I don't know when that is, so a 20 second "error" is invisible.
1 Like
So we are on the same page. I never monitor(ed) mine that closely. When all hell breaks loose, the light simply never goes off (metaphorical huh?)
That's a quote for the ages... the Home Automation ages. 
1 Like
That's because it's not a memory issue. We need to see apps details page showing scheduled events that don't happen when they should. If the problem is reproducible, then those should be easy to get.
Time failures would most likely come from something unrelated trashing the cpu, logs, database, or z-wave mesh. Custom drivers are the most obvious thing to be suspicious of. We'd be super eager to see a scheduled event that doesn't happen in a system that does not have devices with custom drivers installed.
1 Like
Good to know. I’m awaiting for the issue to creep up again. If I create a rule that says turn on Zigbee/Seaver’s device at 1:00pm. What logs would you want to see whe the rule does not run?
I would want to see the app detail page that shows the scheduled event after you've hit Done in the rule, and then a full page screenshot of logs in the All category for around the scheduled time, and the app detail page after the scheduled event that didn't happen.
Got it. Next time the issue happens I will do this and reply. FWIW I have removed the Eight Sleep App and devices which were generating a bunch of logs and re-installed homebridge.
12 hours and no issues.
So it happened again last night some time pretty late. I have a Rule that changes the house to 'Late Night' mode at 12 am and that did not run. In addition, the house switches to 'Day' mode with the Good Morning Rule at 7am each day. This did not run.
The outside lights turn off at Sunrise each morning (they are still on).
So in following the directions of @bravenel I have done the following:
- Created a rule called 'Test for Broke' which: (i) at 8:36 a.m.; (ii) turned on two lights. Screen shot attached.
- Attached the details of the rule following its creation (ie. after I hit Done).
- Posted the logs from after the rule was to run at 8:36 a.m.; and
- Posted the app detail screen after the rule was supposed to run.
Obviously this rule did not run and the two lights at issue are still off.
The house is currently in Babysitter Mode. This occurred because everyone in the house is Away except the 'Babysitter'. This mode triggers because it is not TIME dependent.
Homebridge still works just fine.
All other rules which are time dependent do not function. For instance, a Simple Lighting Rule designed to turn the garage light off two minutes after the laundry room door contract triggers open fails.
PLEASE HELP
