Lutron to Hubitat to Lutron Integration Delay

🛎️ Get Help
1

I'm running into a delay in the Lutron integration when two commands are sent. I don't believe this is the same issue as has been discussed previously. Here's the info (this setup seems strange, I know):

  1. Situation 1: I have a Lutron Caseta plug in dimmer that, when turned on, will turn on 4 GE Link lights. This happens instantly.
  2. Situation 2: I have a Lutron Caseta plug in dimmer that, when turned on, will turn on another Caseta in wall switch. This takes 3-4 seconds before the Caseta in wall switch turns on.

Checking the logs, everything shows up almost instantly. So I think the issue is a delay when two telnet communications happen. In situation 2, the Caseta Hub telnets to Hubitat that an action happened and then Hubitat telnets back to Caseta for an action to happen. I don't know if there's anything that can be done about this, or maybe this is what has to happen. I might even be totally wrong on what is happening here. I'm open to any ideas.

I get that I could use Picos - I'm looking for a different solution.

2

I have a Pico set to toggle a Lutron switch using Button Controllers in Hubitat. This has a 1-2 second delay. If I use a dashboard to toggle the Lutron switch instead, it's instant. So a similar delay as you are seeing when going Lutron -> Hubitat -> Lutron.

3

I've seen this delay as well, in the same situation.

It only happens when I use a Pico to control a Caseta dimmer via Hubitat. In that case there is a delay of 1~2 seconds between the button press and the response from the dimmer. For all other cases, the response is almost instantaneous -- usually less than 1/5th of a second (which is what you would expect from local processing).

For example:

  1. Lutron Pico --> Hubitat --> Z-wave dimmers: almost instant response
  2. Z-wave button --> Hubitat --> Lutron dimmers: almost instant response
  3. Lutron Pico --> Hubitat --> Lutron dimmers: 1~2 second delay
  4. Lutron Pico --> Lutron dimmers: instant response (naturally) , but with a loss of fine-grained control (pushed vs. held, turn on to last dim level, etc.)

The delay does not show up in the Hubitat logs. It also does not show up in the Lutron logs (which you can snoop via a separate telnet session with timestamps enabled).

So it appears that the delay is internal to the Caseta bridge, and only occurs when there is a ~DEVICE statement (e.g. the Pico button press) immediately followed by an #OUTPUT statement (e.g. Hubitat telling the dimmer what to do).

I suppose if you had two Caseta bridges, you could get rid of the delay by putting all the Picos on one and all the switches / dimmers on the other.

1 Like
4

I think I've seen the same behavior in my system.

I've made a general change to my approach: any action that affects a large number of Lutron lights and is scene-like gets set up as a scene in the Lutron system first (the Lutron bridge/repeater has 100 user configurable scenes, also called phantom buttons). Any non-Lutron actions get layered on in Hubitat. That way there is a single call to the Lutron bridge/repeater.

1 Like
5

Are you saying that Lutron Scenes are exposed to HE?
I have never tested nor thought to test that function.

6

Yes. The bridge/repeater has 100 scenes that can be mapped to buttons in HE.

Look at the integration report for a Caseta Smart Bridge. The first device is the Smart Bridge. The first 3 scenes for the bridge appear to be reserved for Arriving Home, Leaving Home, and Emergency. After that are the user defined scenes.

2 Likes
7

Doing another lap on this one.

Can somebody who understands how the Lutron telnet session in Hubitat chime in on this? Is it because the telnet sessions is being opened/closed for every action and so the delay is waiting for the telnet sessions to close? Is there something that could be done. I'm not sure if the full RA2 system has this problem, but if so, it would mean using the Lutron motion sensors would always have a 3-4 second delay when run thru Hubitat and acting on other Lutron devices.

8

telnet by nature remains connected until disconnected, the connection isn't opened and closed for each command sent and received...

9

Is there a "session" of some kind? I'm trying to figure out where the delay is coming from. Does Hubitat send the command, Caseta receives it, but has some built in issue where it won't act too quickly? It just seems odd that you can't have two Caseta commands happen right next to each other - there's always a bit of delay.

One thought I had is that the system is waiting for the on command to finish (as in, it's a dimmer switch that is going from off, to dim, and fading up to full bright) and the trigger doesn't happen until it's full bright. Even still, it seems like there's a 2 second delay not accounted for.

10

I wanted to revive this thread because I'm having similar issues with a hybrid Lutron RadioRa2 & Caseta Pro system and Lutron Hybrid Keypads. I plan to put a lot of these keypads around my house to eliminate multi-gang switches and the first few I've installed I'm experiencing delays on keypad button presses of about 2.5 seconds. Setting up this system is expensive and time consuming. My goal was to end up with a professional looking system but these delays are causing me to feel otherwise!

Here is how I set things up:
1- add the Hybrid Keypad to RR2 system via Essentials
2- grab the device ID from Essentials
3- Add both a dimmer and a keypad to Hubitat corresponding to the newly installed Hybrid Keypad - note that Essentials assigns unique IDs for each

I then program scenes on the Hybrid Keypad buttons within Hubitat using Rule Machine. Button 1 press does the following:

  • turn on to 100 pct the lights that are hard-wired into the keypad
  • turn off bedside table lamps (Caseta devices)
  • turn on keypad LED 1 and turn off LEDs 2-4 to off

For this button 1 press, there is a 2.5 second delay in turning those hard-wired lights on. The same occurs when triggering the button press on the keypad device in Hubitat. However, if I use the dimmer device corresponding to the keypad in Hubitat to turn on the same hard-wired lights, there is no delay at all.

Conclusion, seems to be an issue with Lutron Keypad communication in Hubitat? Any help is appreciated.

11

Checking my logs...

Keypad Button 1 press - entire procedure takes almost 5 seconds, the order in the logs is different than the order in the Rule Machine (ceiling recessed set to 100% is first in Rule Machine). And there seems to be replication of tasks...

dev:3862020-07-02 10:06:36.056 am infobutton led 4 off
dev:2902020-07-02 10:06:35.951 am inforcvd: DEVICE,12,84,9,0
dev:3562020-07-02 10:06:35.843 am inforcvd: OUTPUT,12,1,0.00
dev:3562020-07-02 10:06:35.577 am inforcvd: OUTPUT,11,1,0.00
dev:4192020-07-02 10:06:35.523 am infoMaster Bedside Table Lamp (Erica) was set to 0% with a duration of 0
dev:2902020-07-02 10:06:35.461 am inforcvd: OUTPUT,11,1,100.00
dev:3862020-07-02 10:06:35.398 am infobutton led 3 off
dev:3562020-07-02 10:06:35.298 am inforcvd: OUTPUT,12,1,0.00
dev:4182020-07-02 10:06:35.272 am infoMaster Bedside Table Lamp (Paul) was set to 0% with a duration of 0
dev:2902020-07-02 10:06:35.228 am inforcvd: DEVICE,12,83,9,0
dev:4192020-07-02 10:06:35.154 am infoMaster Bedside Table Lamp (Erica) was set to 0% with a duration of 0
dev:3862020-07-02 10:06:35.126 am infobutton led 4 off
dev:2902020-07-02 10:06:34.985 am inforcvd: DEVICE,12,84,9,0
dev:4172020-07-02 10:06:34.982 am infoMaster Bedroom Ceiling Recessed was set to 100% with a duration of 0
dev:3562020-07-02 10:06:34.873 am inforcvd: OUTPUT,11,1,0.00
dev:3862020-07-02 10:06:34.824 am infobutton led 2 off
dev:4182020-07-02 10:06:34.820 am infoMaster Bedside Table Lamp (Paul) was set to 0% with a duration of 0
dev:3862020-07-02 10:06:34.604 am infoMaster Bedroom Entry led 4 was turned off
dev:2902020-07-02 10:06:34.555 am inforcvd: DEVICE,12,82,9,0
dev:3862020-07-02 10:06:34.480 am infobutton led 1 on
dev:4172020-07-02 10:06:34.416 am infoMaster Bedroom Ceiling Recessed was set to 100% with a duration of 0
dev:3862020-07-02 10:06:34.353 am infoMaster Bedroom Entry led 3 was turned off
dev:2902020-07-02 10:06:34.242 am inforcvd: DEVICE,12,81,9,1
dev:3862020-07-02 10:06:34.062 am infobutton led 3 off
dev:3862020-07-02 10:06:34.007 am infoMaster Bedroom Entry led 2 was turned off
dev:3862020-07-02 10:06:33.992 am infoMaster Bedroom Entry led 4 was turned off
dev:2902020-07-02 10:06:33.861 am inforcvd: DEVICE,12,83,9,0
dev:3862020-07-02 10:06:33.664 am infobutton led 2 off
dev:3862020-07-02 10:06:33.641 am infoMaster Bedroom Entry led 1 was turned on
dev:3862020-07-02 10:06:33.614 am infoMaster Bedroom Entry led 3 was turned off
dev:2902020-07-02 10:06:33.510 am inforcvd: DEVICE,12,82,9,0
dev:3862020-07-02 10:06:33.325 am infoMaster Bedroom Entry led 2 was turned off
dev:3862020-07-02 10:06:33.313 am infobutton led 1 on
dev:2902020-07-02 10:06:33.111 am inforcvd: DEVICE,12,81,9,1
dev:3862020-07-02 10:06:32.924 am infoMaster Bedroom Entry led 1 was turned on
dev:3862020-07-02 10:06:31.723 am infobutton 1 pushed
dev:2902020-07-02 10:06:31.264 am inforcvd: DEVICE,12,1,3
dev:3862020-07-02 10:06:31.185 am infoMaster Bedroom Entry button 1 was pushed

Compare to using Hubitat to force the Dimmer to on, 0.111 seconds:

dev:2902020-07-02 10:10:34.727 am inforcvd: OUTPUT,11,1,100.00
dev:4172020-07-02 10:10:34.616 am infoMaster Bedroom Ceiling Reces

12

I don't have a Lutron bridge, but this issue intrigues me, can you have two Lutron integrations running on the same hub? That way there would be two different telnet sessions. Or if you have two HE hubs, one integration per hub with buttons on one and lights on the other?

13

I believe you can have as many Lutron integrations as you want.

14

The reason I ask is in order to see if the delay is due to the telnet session being "busy" with the incoming button press and due to that have to establish a new Telnet session to send the "tun on the light" event? That way, if the light events would already use a separate Telnet session, that conflict wouldn't occur. If two separate Telnet sessions would still have this issue, the limitation would then be traced to the Lutron, but at least it would be clear where the issue is. Do remember, I don't own any Lutron bridges, so these are just theories.

15

I've read elsewhere on here that Telnet sessions are not "open" or "closed" per a command but always open. That said, I'll eliminate all commands except the turning the ceiling lights on and see if it makes a difference.

16

Yes, they are maintained and left "open". This is why I suggest running it in a way where you have two open telnet sessions, one for buttons and one for lights. If I did have a Lutron device that is what I would at least try. That or look at the actual network traffic with Wireshark and see if there is a new Telnet session established under these circumstances. I know that is not how it is supposed to work, but that doesn't mean that is not what is happening.

17

The idea in my house is to have the "prettier" and more expensive RR2 devices visible and, wherever possible, have the less expensive Caseta devices invisible. For example, I'd rather use the Caseta plug-in dimmers hidden behind furniture than the more expensive RR2 plug-in dimmers. So, for my application at least, it's not possible to separate between buttons and lights.

18

I see, what I mean would be to basically setup two connections to each Lutron bridge and make sure that when a button press comes in on one connection, the corresponding command to turn on a light goes out over the other. If this is supported by the Lutron integration (ie will it let you have two separate integrations to the same bridge) or have other negative effects like duplicate devices, I can't answer, but it would be a way to rule out the Telnet session being "busy" as the reason for the delay.

19

Here's the log - it's the same 2+ second delay:

dev:4172020-07-02 11:46:25.508 am infoMaster Bedroom Ceiling Recessed was set to 100% with a duration of 0
dev:2902020-07-02 11:46:25.456 am inforcvd: OUTPUT,11,1,100.00
dev:4172020-07-02 11:46:25.304 am infoMaster Bedroom Ceiling Recessed was set to 100% with a duration of 0
dev:3862020-07-02 11:46:23.647 am infobutton 1 pushed
dev:2902020-07-02 11:46:23.397 am inforcvd: DEVICE,12,1,3
dev:3862020-07-02 11:46:23.318 am infoMaster Bedroom Entry button 1 was pushed

20

Over the one and only Telnet session, correct? This type of delay would drive me nuts, anything beyond 250ms and I am displeased with my automations. My goal is a maximum of 150ms, but that is not always doable.