Hi all, I’ve been playing with Pico remotes to do a variety of things, and it has been great, but I noticed a curiousity.
If I configure a Pico remote to toggle a Hue Light on / off it works essentially instantaneously. However, if I configure a Pico remote to toggle a Caseta light there is a very noticeable delay. Both are being processed through HA and talking to a local hub, so curious if this is an issue with the Caseta hub processing the command via telnet slower or if the Caseta HA implementation is doing something more interesting.
I know I can use the Caseta app to directly control the lights but I would like to customize some buttons but not all, and HA and Caseta will interfere with each other on button presses.
Also, other items I control using Pico buttons include Sonos (via HA) and they are also very quick.
@Talvish, I have exactly the same issue. I have a few theories as to the root of the problem. Just haven’t had time to test them all out and wanted to post this incase anyone else see it and can help.
My end goal is to use 5 button Pico remotes as scene controllers. Buttons are used to activate scenes (from Home Assistant) or a series of light on/off settings based on an automation that watches for the button press. Everything works but the delay controlling other Caseta Lights is very annoying.
I am currently using both the Home Assistant Core Lutron Caséta integration and the lutron-caseta-pro custom component. Prior to some recent versions of Home Assistant the custom component was the only way to use Pico remotes. I have tested remotes using both the core integration and the pro custom component and the result is the same.
The biggest hint is when using the Pico to trigger a scene. Non-Lutron devices respond instantly but Lutron switches don’t respond until after the light on the Pico stops blinking. I can see the Lutron Switch responding within Home Assistant instantly but the light doesn’t turn on until the Pico stops blinking. Controlling the same light directly from Home Assistant works as expected and turns the light on instantly.
Now onto my theories
When the Pico is broadcasting it blocks the lutron hub from controlling other devices. I see home assistant switching the Lutron light on instantly but the light doesn’t turn on until the Pico remote stops blinking.
Something about having telnet on the Caseta Pro Hub is creating the delay. The telnet session won’t process the request to turn on a light until the receiving signal from the Pico completes. This can be tested by disabling telnet and switching all my automations over to the Home Assistant Core Pico trigger.
My belief from reading about Lutron Clear Connect doesn’t show this problem when using a Pico to control a Caseta Light is that the Pico sends signals directly to the Lights and doesn’t have to go thru the hub.
Just trying to add some additional information as this was the only topic that seemed to describe the same problem I am trying to solve.
The theories are feasible. The Pico remote is sending a signal to the hub, hub is notifying HA and HA is calling back to the hub. Given the hub is in the path twice, perhaps there is some limited synchronous operations in there that give that choppy/slow feeling.
I’m encountering a somewhat similar issue. I’m using a PJ2-4B-GWH-L31 four button scene controller to execute scenes or on/off commands from Home Assistant.
I have two of the buttons set to turn on and off all the lights for a floor respectively. The lights utilizing Zigbee bulbs turn on and off instantly and in unison at a button press. The Caseta lights also always turn on and off in unison but are a clear 1-1.5 seconds behind all the other lights.
I contacted Lutron support to get a concrete answer to this issue:
From previous customer’s request and testing, we have identified that a 2 second delay it is as designed with HA.
Explanation is based around the fact that a button press on a Pico remote transmits the same RF message multiple times to ensure the end-device hears it – this takes about 1.5 seconds repeating this message. That traffic will go over to the Caseta bridge which in turn will pass it along to HA. As HA comes back to the bridge, the Caseta bridge knows that it has an integration command to send out but the bridge waits for the Pico remote to stop transmitting that initial RF message (of 1.5 seconds) to send over the integration command from HA. This results in about a 2 seconds delay with this setup.
It seems that this is the way the Caseta system works with the Pico remotes and the bridge will wait to send the commands to another Caseta device until the Pico remote is done transmitting.
Hope this prevents someone pulling their hair out chasing this issue.
I just tried this out. It doesn’t seem to make a difference if you split pico transmitters and dimmers/switchers onto a separate hub. The Lutron bridge/hub seems to be agnostic to all Lutron RF in the vicinity and will not process integration commands while it can ‘hear’ any nearby pico communicating. This is absurd IMO.
Here was my setup
Bridge 1: All lighting devices (switches, dimmers, etc)
Bridge 2: A single pico (which is NOT paired to the other bridge)
When pressing a button on the pico paired with bridge 2 Home Assistant registers the press immediately, however Bridge 1 will not process any integration commands from Home Assistant while the pico on Bridge 2 is transmitting. Similarly, the Lutron app does not seem to have special priority either and is not be able to control lights either while the pico is transmitting.
I did seem to be able to trick the bridge into executing a command immediately the following:
press the pico
waiting for it to finish transmitting
press it again
The 2nd press when timed correctly would be executed immediately, which means I know this is at least possible and not a nebulous network lag issue–especially when you factor in that HASS is receiving the command on one hub and transmitting commands to devices on another. Honestly feels somewhat like a bug, not a feature when the ‘offending’ device is separated onto another hub.
I’ve been chasing this issue for over a year but with Caseta motion sensors instead of Picos. Did you find a way around this? It drives me nuts that my Caseta sensors take about 2 seconds to turn on lights while my Hue motion sensors, whether they are controlling Hue bulbs or Caseta dimmers, are instant.
I’ve been searching this issue for several weeks and in short, no.
Techniacal recap:
If a pico is transmitting on the same frequency, then the bridge will wait until it is finished before it sends any commands. This behavior is consistent across all Lutron ClearConnect lighting systems including Caseta, RadioRa (non-select) and Homeworks. It makes no difference if the pico is paired to a separate hub as any Lutron system within range that can ‘hear’ the RF transmission will pause executing integration commands until the pico stops transmitting.
The only (theoretical) work around for this is to have a the control Pico paired to a hub that is separate from the lighting you wish to control and to set that hub to a different frequency, however this does not appear to be possible with the Caseta system as there is no method to set the RF channel for each caseta hub.
I had read one unsubstantiated claim that Caseta automatically choses an available RF channel during the setup process, but I found no other evidence that this is true and there is no documentation or information from Lutron support to confirm that claim and no way to view what channel that was set. Its reasonable to assume that Caseta only uses the default RF channel.
You CAN set a different RF channel on RA2 and Homeworks. If someone has one of these systems with multiple RF bases perhaps they can verify if setting two channels allows one base to transmit integration commands while a pico on another channel is still transmitting.
I have seen explicit documentation for the RA2 system for setting individual channels for multiple dwelling units where many systems may operate in close proximity to each other. It would stand to reason that since this is an officially supported implementation in RA2, which is a dealer product and that Caseta is direct to consumer product, that this feature will likely not become available in Caseta.
Solution:
Given that two hubs are needed for speedy pico control via HA, its really not much of a leap to just use a supported 3rd party keypad for scene control with Lutron lighting and be done with it–as absurd as that may seem. I’ve used hue wireless dimmer keypads. They offer a lot of features like press hold, are lightning fast, and have decent battery life. They aren’t decora and they don’t look quite as nice or blend in like the picos, but they work very well for scene control where HA is driving Lutron, maintaining states, etc. I’ve also got my eye on the somewhat-new Leviton in-wall scene keypad. It requires 110V, but also includes engravings which can be ordered right from the app.
Thank you for sharing! I was so confused why my Aqara button was causing my light group of my Lutron Caseta wall switch and my sonoff s31 bedside lamps to turn on at the same time, but using the pico remote to do the same thing caused the s31 lamps to turn on immediately while the caseta switch light was delayed about a second.
Could it be that multiple hubs can see each other on the same LAN and hence will coordinate to not operate at the same time? What if we made them undiscoverable to each other and registered them to different home addresses on the Lutron app?