Ahhh, ok, found it.
1153 is an Amazon Echo Flex.
965 is a Somfy Shade
747 throws back an error.
Ok so acknowledge that these devices are eating resources, but I do have to point out that his problem started way before any of these devices entered my mesh. The problem is about 1yre old and these devices are only 1 month old (approx).
But yes, still something to look at.
I would see if you can somehow optimize these apps, or maybe pause the app or device just to see what happens.
I recognize that you have had issues with this before adding these devices, but you can never quite tell if they might be making it worse unless you try a few things.
The stuff you labeled as Lutron was only 11 and 16 milliseconds, so there is no appreciable delay in that particular part of the code.
What is the app ID of your Lutron hub? You can browse to the app itself and see the ID in the address bar of the browser.
I will ask again though, what does your home network look like? Are the Hubitat and Lutron hubs on the same network switch or router? They have reserved addresses? What brand/model is your networking equipment?
Yep, that one was reported as a DEVICE
I believe these two showed up as APPS, so you'll need to use a different URL to look those two up.
Hi, both SmartBridge and HE are on the same switch, TP Link 16 port gigabit switch. TL-SG1016D and they both have their IPs reserved.
I have mine on a TP link too, so that is probably a good sign. Different device, but far as I know no known issues like there seems to be with Netgear and maybe a couple others.
Ok, those apps that are reporting high usage is the Ecobee Suite Manager and the Amazon Echo, both Cloud devices which generally talk way too much). Just added that one last week. But yes, I can pause it for now to see if there is any change.
Could this be a setting or an old version I'm working with on the Lutron hub? I know there aren't many user accessible settings on that thing, however, the more I think about this, the more I think it HAS to be a problem with the Lutron hub and not HE. Everything running through HE including the Lutron stuff works instantly. Its only when I need to send and return at the same tim e through the Lutron hub do I run into issues.
The only thing I see in the Lutron app is on the Settings > Help and it lists version 7.4.2.The Lutron app itself from on the Android Play Store is at also 7.4.2, so I don't know if the hub firmware has a version we can see or not?
Might be worth calling Lutron to see if they can tell if your hub is updated.
I don't have logging turned on, but otherwise looks the same as your screenshot. I was mainly wondering if one of the apps in your screenshot above that had the high times was Lutron. But it looks decent. In fact 17ms runtime is pretty good all things considered.
I would (without any other way to tell) concur with this conclusion. The Hubitat side of things seems to be good far as the Lutron stuff goes. I would try that longer test, but if the Lutron app, devices, and so on are all sub 100 milliseconds (WAY less actually), I doubt Hubitat is the problem here.
Ok, well, I just ordered another Smart-bridge pro, so the entire forum is about to get an other real world test (read guinea pig) on this!
I'll fill everyone in on what my results are.
Best, and Happy Holidays!
That is pretty extreme! I don't know if that will fix it, I sure wouldn't suggest that it will. But I am curious what happens with a new bridge.
I would still call Lutron and tell them what you are experiencing. Maybe you will get a free bridge out of that call?
I predict that when you do this:
Pico (smart bridge-1) -> hub -> caséta device (smart-bridge-2)
that you will have nearly instant response.
You can model this behavior pretty easily. Try this:
Virtual button device -> hub -> caséta dimmer
and
Pico -> hub -> virtual dimmer
Whatever timings you see for those two, will resemble what you'll see for the one at the top.
My brother gets a discount. 
Also, I just complained to them last week about their Sonos integration and got a free light switch... don't want to push my luck. 
Ok, so maybe not complain. But it would be interesting if they can see what firmware you are on, or if it is current.
I do continue to run two Lutron Caseta Smart Bridge Pros but I have never followed up on the experiment that was mentioned. I have a mix of devices (Picos, Switches, Dimmers) on both of the Smart Bridge Pros. No latency problems. I also have a number of Picos that I use strictly for 3-way switch/dimmer configurations - those I associate locally for speed and reliability, Hubitat never "sees" those.
Can’t you do both? Can’t you integrate the Pico with Hubitat AND connect the Pico directly to the Caseta light switch/dimmer?
Sure you can. But all of the buttons are mapped via the Caseta native mapping...so no real reason to map those picos to Hubitat, IMHO (unless you want a Hubitat connected bulb/switch to be triggered at the same time as the Lutron swith/dimmer.) I do exactly the same as @Eric.C.Miller. I only integrate Picos with Hubitat that are not used natively in the Caseta platform.
So, I've got some not so great news.
I have installed my second smart bridge, and transferred the Picos, and.....It still seems to be a little slow.
Ok, so here's what I observe.
There's definitely a delay on the side of my Hubitat. Not sure what's causing it.
I'm including a link to a video so you can see what I am talking about. Video Somfy vs Caseta
In the video above, you'll see two remotes side by side. The Zwave Somfy remote that came with my smart shades, and the Pico. You'll see that the reaction by the Somfy controller is WAY faster.
So I am thinking that the Pico, even though unpaired from the first Smartbridge, must still somehow be 'blocking' the clear connect signal from the original Smartbridge. Anyway, I'm just throwing stuff at the wall to see what sticks here.
Also, just to confrim the steps.
Still getting this delay.
Also, some of these Picos are controlling non-Lutron devices. Those devices react instantly to the Pico button press.
I'm also posting a photo of the lutron device page. Maybe someone sees a glaring error here?
A way to deal with the issue is to program and use the scenes available on the Lutron bridge. The bridge has 100 spaces for scenes. You then just press the scene button from within Hubitat and the bridge will set all the Lutron devices via a single command. An added benefit is that this process eliminates any popcorning of the lights.
Hi Bill, unfortunately even using that method, the delay is still present. The only consistent element of the delay is the Pico. Using ANY other trigger does not produce the delay. Using the Pico produces the delay in Lutron devices every time. I do however use this method when there are multiple light switches involves, however it does not help with the delay.
I just tested this by using the Lutron App on my phone as a speed test.
So when I hit a button on the Pico, the light switch (via HE) is effected instantly.
Meaning that even the Lutron App on my phone is getting the command from the Pico, through the HE instantly. The change is reflected on the screen of my phone, so the SmartBridge is getting the command from HE in a timely fashion, it just isn't able to push that command out to the lights quickly,
Download the Hubitat app
