I'm trying to use the Button Controller app to mimic standard Pico behavior with a group of lights (also connected to Lutron switches). I have set up the rules to mimic on/off/up/down behavior when the Pico buttons are either pushed or held/released.
The performance of the Lutron integration is leaving a lot to be desired. There are lags of up to several seconds before Pico events are logged in the Lutron Telnet app. Some button presses are not registered at all. The issue does not appear to be on the Lutron end because if I also configure the Pico to control a light via the Lutron app, the response is instantaneous. Even when button presses are recognized, the response of the two lights in the group varies wildly -- one of them may respond immediately, the other takes several seconds to respond. Again, the problem does not seem to be on the Lutron end, since they respond instantaneously to control from the Lutron app.
How can I debug the cause of the slowness? Is my Hubitat hub simply under high load and slow to process the telnet traffic from the Lutron SmartBridge Pro? Are there any diagnostics I can look at beyond just looklng at the Logs tab and counting the delay from when I press a button to when the Lutron Telnet app logs the event?
Two things to try that have helped when I had odd problems with the integration.
Open the Lutron Integration and just click "Done".
If that didn't help, unplug the Smart Bridge Pro for 30 seconds and plug it back in. The first button press after it boots again will probably have some lag, but it should be fine on the next press.
I tried (1) and it seems to have helped a little bit. I'm going to wait and try (2) later.
In the meantime, though, I now see a number of ERROR responses in the Lutron Telnet logs:
What are these indicative of? It doesn't appear to be related to the button mappings in Button Controller, because they are sporadic. At other times, there are no errors and the buttons appear to be operating correctly.
I want to add additional integrations when certain buttons are held (1, 3, 5). If the lights are paired with the Pico in the Lutron app, holding those buttons will continue to operate the lights. In order to preserve the existing behavior of controlling the lights, but not have the lights controlled when holding those buttons, I need to replicate the "normal" behavior first,* then add the additional integrations. So while my button settings more or less operate like the "native" Lutron control of the lights, the lag makes it feel decidedly inferior.
Device 3 is the Living Room Ceiling Lights, which as I said, seem to be operating normally most of the time, but occasionally result in this error. Button controller settings are:
Do I? Is there another trick to preserving the "normal" behavior of the Pico controlling these lights by pairing it in the Lutron app, yet having the ability to attach actions to holding certain buttons without having those buttons also trigger the normal behavior?
It has previously been reported that “Lutron Pico to SmartBridge to Hubitat to SmartBridge to Caseta Dimmer” has a noticeable delay of a few seconds. It is recommended to perform this type of automation directly within the Lutron App if performance is critical.
Using a Pico to control a Zigbee or Z-Wave device is nearly instantaneous.
So does that mean there is no really workable solution to wanting the Pico to operate normally for on/off/up/down control of Caseta dimmers, but add functionality attached to held/released events?
It's set to the Lutron Pico driver. And I do get held/released events, though not realiably. (The lag seems to mean that some pushed events end up getting interpreted as held/released.)
Then it's probably what @ogiewon mentioned. Must be collisions as the bridge tries to handle two things at once. I know some do have a bridge just for picos and another just for the Dimmers. That might be why.
there is definitely lag when trying to dim a lutron dimmer with a pico via hubitat. my work around is to only add functionality to picos via hubitat. They are setup in the lutron app to control the light, then in hubitat i’ll make long press off turn on/off some other lights as well. It’s really the dim function that is the biggest problem b/c you can’t sync dimming among lutron and non-lutron lights - it will get out of sync. so my dim up and down buttons only control the lutron lights.
definitely a limitation, and it seems to be one that is baked into the lutron hub, unfortunately.
Lutron Telnet "~ERROR,3" is "Invalid action number, The action does not exist for this command". So Hubitat is telling Lutron to do something it doesn't believe is valid.
The "~DEVICE,6,5,4" message is saying your Pico (Lutron integration device 6) had the raise button (button 5 in Lutron, button 2 in Hubitat) released (Lutron action 4).
Action 4 is a valid action for a Pico, so I don't know the source of the error. @bravenel will have to comment.
The Pico→Lutron Bridge/Repeater→Hubitat→Lutron Bridge/Repeater→dimmer route can cause lags in my experience as well.
There are 2 ways to minimize the issues:
For raising/lowering performance. Program your dimmer to Pico mapping in Lutron software as stated above. Add non-Lutron devices to the Pico in Hubitat.
For setting levels (scene) performance. Program your Lutron lights into a scene the Lutron software. Add the Lutron scene and non-Lutron devices to the Hubitat Scene app (or any other app that can push a button). Your bridge can accommodate up to 100 scenes. They are stored as virtual buttons on the bridge (see your integration report). Think of the bridge as a 100 button device (with push only actions).
Is there any way to keep the Lutron dimmers mapped in the Lutron software but not respond to "held" events, so those can be handled in Hubitat? If not it seems like a Pico needs to be either dedicated to Lutron devices or to Hubitat integration with non-Lutron devices, but not both.
Do you think having the Picos and dimmers on different SmartBridges would help reduce the lag if controlling via Hubitat?
I don't know that I'd buy another one just for Picos, but I am near the 50 device limit so may be getting another one sometime soon anyway, and could probably make sure that Picos are on the opposite one from the dimmers I want to control via Hubitat.
I may try doing that for another integration I have in mind, though I don't think it'll help as much with this one. Thanks for the detailed response!
In Caseta no. In RadioRA 2 you can program the 'up' and 'down' buttons to raise/lower (Telnet only reports push and release, held is internal to Lutron) or nothing at all.
I guess maybe I don't understand your issues. I thought your issues were with Lutron dimmers not responding in a timely manner to Pico presses when the dimmers are controlled via Hubitat? The way to address Lutron performance issues (on/of, raise/lower) is to keep the dimmers and Picos linked in the Lutron system (remove Hubitat from the communication path).
As stated above, the communications bottlenecks do not affect Pico->Hubitat controlled Z-Wave and Zigbee devices. So you can add those devices to a Pico without creating Lutron performance issues. But note that since these devices are all in their own systems and have their own performance curves, there's no programatic way to atomically sync ramping across systems. The best you can do is try to set the systems up similarly with available control parameters. (That's one reason I use Leviton Z-Wave dimmers in my home as they have similar control parameters as Lutron RadioRA 2 dimmers)
I have Picos controlling a set of Lutron dimmers in the living room and master bedroom. I'd like to add additional control using the "held" event on some buttons that don't otherwise do anything special when held (1, 3, 5)--turning ceiling fan off and on in the bedroom, opening/closing shades in the living room. So I can leave the Pico mapped to the Lutron dimmers in the Lutron software, but then holding the button triggers the Lutron-mapped activity in addition to the "held" event in the Hubitat driver. I don't want both actions to happen on "hold", only the one I have configured in Hubitat.
So I tried to replicate the default functionality of buttons in Hubitat, rather than using the Lutron app, so I could attach additional actions to the "held" events without triggering both the default action and the new action. This doesn't work well due to the lag issues, leading me to conclude there isn't a good way to have a Pico perform its "default" actions on Lutron dimmers for push events while also handling hold events to attach new actions. If you leave the native mapping in the Lutron app, you get the default action in addition to the "held" action; if you perform the mapping in Hubitat, while you can replicate the default functionality, the lag makes it too unpredictable to use in practice.
Pico button presses generate a lot of RF traffic. Because they're Tx only devices, they have no way to know that they've been "heard" by the relevant devices. So, when you press a button they actually transmit repeatedly (pretty much in sync with the LED flashes on the Pico). In the case of two Tx only devices talking at once, they just Tx several times over the course of a second or two and statistically at least one message from each makes it through the noise ...
I expect that's what's happening here. The Pico transmissions are causing the SmartBridge to wait before transmitting its own (Hubitat-initiated) signals to the dimmers.
Rather than add additional, identical-looking ones.
