Lutron Pico to Control Hue Bulbs

Hi, I'm new to HE. I will be migrating from ST in the near future. I have a little over 50 Lutron devices and another 35 Hue devices and about 75 z-wave devices and about 20 Zigby devices, so I'm not looking forward to all the exclusions I'm going to be doing in the near future. Anyway, I wanted to see what I could expect from the Lutron and Hue integration. I liked the idea of using Pico's being exposed in the HE environment and able to control hue lights. The localized nature of HE was also very attractive. I set up one Lutron Pico with a new Lutron Pro Hub and integrated HE with my Hue hub as well. I used rule machine to set up buttons to set the lights to a particular temperature and brightness. All seems to work, but I have noticed an annoying lag between when the buttons are pressed and when the lights respond. About half of the time, it is small, maybe 0.5 to 1 second, but about half the time, it is longer and not infrequently, it won't work and I have to press it again and then it works.

Based on the lack of seeing people complain about this issue when I searched the community, I'm guessing that this isn't the expected behavior. Perhaps my expectations were a little too lofty though. I was thinking that the latency would be almost none like the Lutron connected bulb remote (I know the LCBR connects directly to the lights, so it is slightly more direct, but I didn't think the local lag would be noticeable). Can anyone advise about how this connection in HE usually works and also if there are common mistakes in my setup that I likely made?

How far is your test Pico from the Lutron Hub when you run the test? Lutron states that Caseta has only 30' range unless you have a repeater (plug in lamp module) to extend the Clear Connect network. I have about 10 picos set up to control multiple ZigBee, Zwave, TP-Link and Wyze plugs. With ZigBee/Zwave, the control is very fast (as it is local). TP-Link is semi local with the HE Driver but still must go through Wi-fi. The Wyze plug needs to go through IFTTT and then another cloud jump to Wyze. That plug can take 1-2 seconds to control. But all others are very fast. I currently have 60 Lutron devices (Dimmers, Lamp Modules and Picos) and they work very quickly.

Thanks. My new Pro Hub (I had been using a non-Pro hub previously) is only about 20 feet away from the Pico in question. The Hue hub is further away and maybe I'll move it closer for testing tonight. I have it upstairs in a server cabinet which I know isn't a great idea. When I test the rule from my phone interface, it seems to respond instantaneously though, so I wasn't thinking that it was an issue with the hue side.

What type of transition time have you set the lights for? Can you show a copy of the edit device page for your Hue Lights, your Pico and the button app?

I ended up getting more HE hubs due to this issue. I don't have as many Lutron devices as you. Only 35 Lutron devices, around 40 hue bulbs and 100+ z-wave and 100+ Zigbee. Many RM, ML and SL rules. This caused huge delay for me.
I ended up moving all my Lutron and Hue to another hub and run rules just for pico on that hub.
I use hubconnect to move devices from this new hub back over to my old hub for other automations.
With this. I have no delay between Lutron and Hue.

Quick question, as that is not normal: I am assuming that you are using a C5 hub. What network switch/router is that hub connected to? There are some compatibility between the C5 hub and certain network switches/routers that can cause the telnet connection to drop and then it has to be re-established, which could cause the delay you are seeing. There is a workaround that could be applied to your hub but you first want to make sure that this is actually the case.

To verify, you can do this:

  • On Hubitat, go to Devices and find the "Lutron Telnet" device.
  • Enable the "Enable debug logging" setting and hit "save"
  • Go to the Logs in Hubitat and see if the logging is giving you an indication if the connection is dropping/re-establishing

This should show you if there are any frequent re-connects. You can also post a screenshot of the logs here and ask for more assistance

1 Like

Last I heard, the hub will now automatically detect this problem and apply a fix within 24 hours.


I have the same experience. Sometimes the lag is minimal (1-2 seconds), sometimes the lag is long (3-5 seconds) and occasionally I have to press again.

I would recommend the same thing here as above, enable the debug on the Lutron Telnet device and lets take a look at the logs to see what is happening here

Thanks for the responses. I'll post the logs once I have some populated. I'll attaching screenshots of my devices below.

Do you have any Hue Bridge bulbs added or just the Hue group? Last I heard, there were some problems when adding only groups if you didn't also add at least one bulb (even if you have no need to use it directly in Hubitat). One concerning fact is that "Current States" for your "Living Room" device is not populated. You should see something like this there:

This suggests that Hubitat may not be correctly parsing information it gets from the Bridge, assuming you have polling/refresh enabled in the Bridge Integration app. My experience with Hubitat's stock integration is that it should "optimistically" (before it hears back from the Bridge; polling is technically optional) change the attributes/current states if you manually manipulate these values with commands, as it seems you've done (by way of the Pico, but you could also try on the device page yourself to rule out some automation as the problem).

To summarize, my advice would be to add one sacrificial Hue Bridge bulb to Hubitat if you've only added Hue Bridge groups (you don't have to use it). If this really bothers you, I wrote a custom Hue Bridge integration that doesn't require this, but I'm trying not to keep mentioning that everywhere I go. :slight_smile: If it's not the "bulb problem," then I'm not sure what to make of this (though I still think something is odd with the group either way). You may be able to figure out more if you look at the live logs as you try this again.

Here is some of the log from my Lutron app

My suggestion is to look at all of your logs live yourself when you press a button on the Pico. The Lutron app will probably register it first (those are the logs like "rcvd: DEVICE,2,2,4"), followed almost immediately by your Pico device ("button 1 pushed" and whatnot). If you have an automation configured to do something based on that Pico button event, you may also see something in the logs shortly after that for the app (if you don't, turning on "debug logging" for that app, if an option like that exists, may help) or affected devices (as long as the app actually did do something to them and you didn't disable "description text logging," though turning debug logging on can't hurt if you want maximum verbosity).

It's definitely easiest to do this live since you can see in real time how long it takes after you press the button before you see any Pico button event (or at least the telnet log), something we can never see in a screenshot (or copy/paste, which is a bit harder to read and some people here don't like, though I do like that it is friendlier for people with low bandwidth or using screen readers). You can also see how long it takes between the button event and your app actually doing something. Again, this is much easier to do live than to look at afterwards.

That being said, what kind of Lutron system are you using? There are some telnet errors in there that are not typical, which could be a lost network connection. I'm assuming you have a static IP address reserved for either your Caseta Pro Bridge or RA2 Main Repeater on your router and aren't using VLANs, double NATting, experiencing any other LAN problems with your Hubitat, or can think of or notice anything else that could possibly cause network problems? I wouldn't be surprised if some of your events from Lutron simply weren't making it to Hubitat for this reason (again, something that would be much easier for you to see in live logs).

1 Like

Have you also tried rebooting both the Lutron Hub and Hubitat? Note, Hubitat must be rebooted from the system menu, don't hard AC cycle.

I haven't tried to reboot the Hubitat hub. I'll do that per your recommendation. I'll also try to check the logs in real time when I get home tonight. I'm not running any VLANs or double NATing. I have an ASUS router, several Eero routers hardwired and set to bridge mode throughout the house and several dumb switches to distribute the ethernet. I am running a new Lutron Pro Hub alongside my old Lutron non-pro Hub. The non-pro still has all my devices except the one Pico I migrated to the Pro hub. My Hubitat right now only has Sonos, Hue and Lutron integration. I added two Hue bulbs to Hubitat (I had indeed only added rooms previously), but this didn't improve my situation.

Correction above …. good luck

After following some of the recommendations here and a tip I received about from @dan.t via PM, I don't seem to be having any dropouts anymore. I only notice about a 2 second delay between pressing a button and the hue light responding when I haven't used the switch for a while. After the initial press, the light delay becomes more like half a second on subsequent presses. Initially, I was expecting there to be no delay like my Lutron Connected Bulb Remotes and hue bulbs. But, maybe I just had the wrong expectations which I'm completely OK with if that's the norm.

Is this the expected behavior and what I can expect from this combination of devices? Or do I need to troubleshoot further? I used this setup as a test, so I only have a few devices connected. I could do a factory reset on the Hubitat hub and the Lutron Pro Hub without too much extra work/headache.

Thank you to all who offered their help. I really appreciate it. I ended up doing a soft reset on the
HE hub and then adding back the lutron connection and hue connections. It seems to have solved the problem. I'd say there is a little less than 1 second delay now initially and then nearly instantaneous response on subsequent presses. I probably screwed something up with my initial install, but thankfully it seems to be really good now. The wife approval index has been reached at least. I also installed a sage doorbell sensor and am using the text to speech function to notify through Sonos my poolhouse, patio and back yard that doesn't have a chime installed. I've been wanting to do this for when I'm entertaining and expecting guests to roll in. The text to speech built in function is really nice. Some of the voices are pretty funny. Thanks again!

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.