Slow response on first press

I using HE with a Lutron Smart Bridge Pro. I have approx 7 Zigbee and 6 Zwave devices.
I use Lutron Pico remotes to control lamps that are plugged into either Ikea Tradfri plugs or Zwave plugs (one Pico for each lamp).

The first time I press a Pico remote in the morning it takes approx. 3 or 4 seconds for the lamp to respond. Subsequent presses result in approx. 1 second or sub second response.

Are others experiencing this behavior?
Any advice on how to speed up the first press response time?

Welcome to the communities!
The behavior you describe is fairly common for battery-powered button controllers. After a period of inactivity, they need to rediscover the network. I can't speak specifically to the Lutron Picos but I have Hue, Eria, and Aeotec and they all take varying degrees of extra time for their initial press after inactivity.

I notice this as well, but as far as I can tell it's only once per hub reboot. It's also only once per Lutron system, not per Pico, e.g., pressing any Pico button once any time after the hub reboots makes them all work quickly again. I don't think I've noticed the issue recurring without a hub reboot, but I could just not be paying enough attention.

As to the cause, I don't know. No one on Hubitat staff seems to have this problem (I used to think it was because I was on Caseta with just Picos and the telnet connection didn't get initialized until I pressed a button, but I still get the behavior on RA2 with occupancy/motion sensors that send events over telnet before I press a Pico, when I still have the problem.) Lutron's system isn't a mesh, so it shouldn't suffer from the issue some Zigbee (and probably Z-Wave) devices have when they've been dormant for a while and might need to do a small dance to rejoin their parent/router. For what it's worth, I still don't have any in-wall RA2 devices, but I can't see why that would matter here.

Your experience sounds like mine... first press of any Pico is slow, then all Picos respond normally. Also, (in my case) it is not 100% inconsistent. Sometimes the first press responds normally.

I have noticed that sometimes I don't see my Lutron Bridge Pro on my network (yes I am using a static IP). Maybe this is the source of the issue??? I think I'll ask around on the Lutron community site about this.

1 Like

I just installed my first in Wall Caseta dimmer. I'll see if this makes any difference (maybe it "pings" the bridge to keep it awake) ???

1 Like

Yah, I have a smartthings button and rarely use it because it SUCKS. And I'm a typical HE user with the expectation of instant.. response. Haven't found that with my button. I'd rather ask Alexa to turn something on than push that frustrating button.

1 Like

Thanks! I like when someone points downward and says “hole!”, before I walk right into it.

1 Like

I installed my first in wall Lutron Caseta dimmer a few days ago. It has not made any difference in the delay issue... it took about 4 seconds for the device to switch on after the first Pico button push this morning.

I'm trying this next:
I noticed that the DHCP option is selected in the Lutron My Home App (settings, advanced, integration settings, network settings). I unelected DHCP. I'll see if this helps

Are you rebooting your Hubitat hub every night by any chance? The only time I see a slight delay like you’re describing is the first Pico press after a hub reboot. Afterwards, everything is quick to respond.

I seem to recall someone from Hubitat mentioning that the reason for this is that after a reboot, it takes a second or two to load/compile the application being used for that specific automation. It’s been a while, so I might not be recalling this accurately.

I'm not rebooting the hub. Should I be rebooting every night?

No, you should not need to reboot your hub, except during firmware updates. That’s pretty much the only time my hub gets restarted.

I'm not sure that would describe what I see happen: the first Pico is slow to respond, then any (not just that one) are fine afterwards. They are part of different apps/automations, or at least different child apps and a couple different parents. If only the parent matters, I suppose it might (I haven't paid that much specific attention). I assume it can't be the Lutron integrator app: contrary to my earlier hypothesis, I thought maybe others didn't notice this due to having higher-end systems like RA2 with occupancy sensors, which would communicate over telnet, possibly slowly the first time, before anyone would have time to make a Pico be the first thing to (slowly) try. Now that I'm using RA2 with those sensors myself, I can say it didn't help.

I'm not sure I've seen staff even acknowledge that this happens, not that I think they could necessarily do anything about it; the telnet connection seems fine (motion sensors are already communicating), so it might be something on the Lutron side (or maybe once per category of device?). I asked about it during Hubitat Live once when they were talking about buttons and I didn't make myself clear enough that "after a reboot" meant any time after, not just immediately after, where I'd reasonably except some things to be a bit slow with other tasks being performed at that time.

Still better than a Zigbee button struggling to wake up or find its way through the mesh (and likely better than whatever few Z-Wave buttons there are, though I haven't used most newer ones), but I don't want to give anyone the illusion that I find this 100% perfect, either. :slight_smile: