Nothing looks terrible but what are these two devices and app? Assuming cloud devices by the times.
Dev 610 - Group: All Inside Lights
Dev 689 - Garage Ceiling Light Parent (GE/Jasco Motion Sensor/Dimmer, JasonJoel's driver)
App 737: aaTestApp ("On: Group: All Inside Lights")
The stats page is interesting--what do the various things mean (so I know what to watch for)?
What about 389?
Device Stats enabled: true
true means stat collection is running false means its disabled
Device stats start time: 1601922767885
This is what time stat collection started in some funky way I cant decipher but the hub knows what it means.
Device stats total run time: 132008
This is how long the stat collection has been running.
device id 77 runcount 10 total runtime 59 average run time 5.9
Device ID number is the device that it is talking about
Runcount is how many times that device has been triggered during the collection
total runtime is time in milliseconds that all of the runtimes added up to.
average runtime is the average runtime for each triggered execution on the device.
Same goes for the app stats but for apps.
And, after that was done, the following did NOT turn on (after a refresh to to make sure the status was right):
Basement Ceiling Lights
Basement Room Ceiling Light
Dining Room Lights
Fireplace Ceiling Lights
Guest Bedroom Closet Light
Kitchen Ceiling Fan Lights
Laundry Room Light
Loft Lamp
Note: I typo'd -- I meant 389, not 689.
If you spaced out the on triggers does it complete?
This rule turns off about 150 devices.
1 Like
In that specific case, I ran the "least likely" to work well method.
But, when I do them about 3-5 at a time, spaced out, with refreshes, I still have some that don't behave. I had 2-4 this morning, I believe. My "Set At Home" app runs when I disarm and several lights were off (I didn't do a thorough audit--I just drove it again to get things in shape).
I'd take out those refreshes. That's a lot of commands all at once. I'd also enable group on/off optimization so it isn't sending on's or off unnecessarily. Clump devices into groups of 5 or 6. Leave out ones you are doing specialized things to like setting dimmer/fades and such.
Those refreshes actually seem to help more than hurt.
The hub seems to not properly track status all the time, so it thinks things are on or off when they are the opposite.
I added those to help make sure the status is correct before sending the commands because, otherwise, things were not acting right even more frequently.
As you can see, I tried to put delays in there to space those refreshes out--and to allow them to complete before taking actions.
Your still sending like 10 device refreshes at once. Your hub is pooping all over the place at that point. Retries and resends clogging up.
Might also help to split this rule up into two. One for your custom tweaks to stuff and one for just the on off. Some other stuff like the basement lights move that into a simple automation or motion lighting app. Same for your HSM status, move that to it's own rule.
Rules don't take extra resources. No need to cram everything in one.
Also this IF is unnecessary given you are triggering if it is open or closed at the time the rule executes.
Nm its two different doors. Didn't catch that at my glance over.
Group optimization is on already (but, that made no difference to the problems).
As for the refreshes. I sent 7, then a 2 second delay. Then 3 more. Then, delay statement of 4 seconds (from the beginning--so 2 more seconds after the second refresh).
I'll try splitting it more. 3 devices, wait 2 sec, 4 devices, wait 3 sec, then wait for another 2 sec before proceeding (so, 7 secs to let the refreshes settle).
Good rule of thumb is .6 seconds per device assuming you have a good mesh. Group optimization helps when the devices are already in the desired state since it doesn't send a command unnecessarily. Also front loading your devices refreshes before you execute this rule would help. Just run it a minute or two before hand. Then you can take out the refreshes from this rule. Could also run them after if you wanted as well with just a link to the refresh rule. Another thing to keep in mind the fades take a few seconds to complete so it will send it a command and as the devices are fading it will keep sending commands through the process and then more once it finishes.
Yes, if I could predict the future.
This is the rule that turns on the lights when I disarm/open the doors, etc.
So, there's no way of knowing when it needs to run until it needs to run. And, I want lights to start popping on as soon as possible so I'm not running around in the dark for several minutes.
Thus. I tried to run a few key lights up front with refreshes and smaller delays.
Most of the fades are fairly quick--I thought the protocol indicated that devices only needed to report at the conclusion (possibly, excepting very long fades)? And, these are "Dim" type fades which should only need to send a single command to the device, as opposed to Hub "Fades" that send zillions of commands.
I predict the future with geolocation, wifi connections, and bluetooth tags.
Geolocation rules trigger when I'm close. Within a minute or two of the house. Wifi triggers when I pull into the driveway and bluetooth tags trigger when I'm at my door. Door contact trigger the main rule.
But, the more common case--is when I finally decide to wake up in the morning/afternoon/whenever. 
For that I use a pressure sensor in my bed.
lol.
WAY TMI for my hub.
But, I generally trigger it from a button while I'm still in bed.
