This is the sort of thing I see. I only have 4 webCoRE pistons running, the rest of my automations are RM. Also when I come in if I've been out for a few hours i can get this. This was happening before the .121 update, for me anyway.
I reverted a lot of my devices back to ST (wanted to prove it was not my devices/setup that was causing the issue) and they are now running quicker than they were on HE. (Using all webCoRE automation so everything is cloud based).
On HE I'm using Life360 for presence, so the recent posts about webCoRE and NEST presence do not refer to my setup.
We'll, my theory about nest integration causing this sluggishness seems to be debunked. Even with 0 nest devices integrated I just experienced the issue again. Unfortunately, I cannot roll back easily as I failed to make manual backup of 1.1.1.119. A reboot seems to have brought things back to normal for now. Eagerly awaiting a work-around or fix for this issue.
Hah, I guess I just assumed that I needed a manual backup to roll back. Thanks!
It has helped my hub going back to the old rev
This. this has been my problem for some time. My lighting automations are very slow initially, and then after they've gone off once they are fast again for a while. it seems to happen to pretty much all my lights at one point or another, but certain ones seem to be worse. It doesn't seem to matter how things are automated as it occurs with the simple lighting automation, RM, and webcore. webcore shows there is a delay, often about 10,000 msec before things fire. Looking at the motion sensors in hubitat, they turn to active almost immediately, but then nothing happens for 10 seconds.
This has been driving me nuts.
I believe there is a long standing issue with ZWave and getting-a-word-in-edgewise. If there are a lot of devices that have something to say, the Controller Send may get pushed to the back of the line. Certainly it needs to Listen to all the traffic being sent as priority over Sending.
This thread from long ago (featuring some familiar faces) is worth a re-read. Thanks again @JDRoberts. I'll be sure to pause my GE switch refresh polls next time I do a Z-Wave repair 
1 Like
I setup a “zz-Pairing” virtual switch just for this purpose. I have several rules that are disabled when this switch is on. I prefixed it with “zz” to put it at the bottom of my list.
1 Like
No sluggish performance here with
87 z-wave
109 zigbee
30 virtual switches
But I also don't have webcore, Hue or Nest just smarttiles and Life360 connector. Life360 is not refreshing. No polling here either.
I reverted back to 1.1.1.119 and Life360 at least is staying connected. On 1.1.2, Life360 wouldn't stay connected for more than an hour or so. I had to manually open the Life360 App and click DONE to get it to update presence status for our three phones.
2 Likes
Do you still need tickets to investigate this? I just updated, and everything is sluggish now.
Yes, that would be good.
I posted this in the Generic Z-wave lock thread, but it also applies here:
As I was going through my log files for a support ticket on another possible issue, I discovered what appears to be a delay in firing on my front door lock that wasn't there prior to 121. In the RM rule, when a switch would turn on, it would be about 3-4 seconds before the front door locked. Now, as I am looking at the log files, it seems to take anywhere between 10 and 12 seconds before the lock changes. To me standing on the front porch, this seems an eternity and I now think I was mistaken in saying the lock doesn't lock/unlock. I think I am not waiting long enough to see if it really does. I will continue to test, but I'm not sure where the issue could be: RM 2.5 or Firmware 121. I will submit a ticket on this as well.
Update: Last night I put new batteries in my lock. The battery level was in low 40s so I didn't think this would have any impact. It was just a stab in the dark. This morning my automation ran at it's original speed. I'll keep testing, but I was really surprised at this. I'm not sure if the lock did some form of a reset with the batteries being out, or if there is something that happens when they drop below 50%.
2 Likes
Yes, I've had numerous problems like this as well with my Yale Z-wave lock. Finally had to exclude it from the Z-wave network for the time being. I think this is an area that still needs a bit more love from the engineers. 
1 Like
Same experience here
1 Like
Wow, well this explains a lot. I started migrating 3 days ago, brand new to HE. It seems snappy, but certain things just aren't happening right.
First thing I noticed is my Z-Wave door sensor automations weren't firing all the time, and sometimes the sensors wouldn't report changes to HE. I'm using webCoRE. I decided to switch these automations to RM, and they work perfectly every time now.
webCoRE does not execute on the cloud. It all happens hub-side. Only the dashboard and editing utilize the cloud, iirc.
Regardless, I'm also getting some sluggishness from Zigbee sensors, and I've been thinking they were my Osram bulbs repeating badly. Now I'm not so sure.
I don't have my Nest on HE at the moment. Is it possible to delete the app? I don't see an option.
8081 doesn't give me any option to roll back to. I wonder if it shipped with 1.1.2
So has the underlying issue been found with this update? If so any plan to release a fix in the coming days.
Set a simple lighting rule to turn on my front lights when i arrive after sunset. I came home tonight and nothing turned on. Hoping the life360issue gets worked out. My webCoRE presence worked flawless before hoever I haven’t hooked that back into Hubitat.
My Simple Lighting open/close light rules are acting up today. Not firing the first time, etc.
