I've been trying to setup some automation using Lutron Caseta switches as the trigger and I noticed that the Lutron integration has about 3 second delay whenever the Lutron is the trigger. This applies to all types of triggers: on/off/dimmer level.
For example:
If
Lutron switch turns off
Then
Turn off zigbee bulb
What I'm seeing is that when the Lutron device status changes (on/off/dimmer level) there's about 3 second delay before HE receives that status change from the Lutron Integration.
Is this something that can be fixed on the HE side?
Caseta devices push notifications of state changes, they aren’t polled. I’m not sure what could be done from the Hubitat side. Are you seeing the state change immediately in Hubitat log when you use a physical switch?
from the bottom of the above logs
device 49 (pico) 11,3, indicates button 4 was pushed.
output 48 (shade) 0.00 is the requested position (fully closed)
device 49 (pico) 8,3 is button 1 pushed
output 48, shade stops, indicating a position of 91%
device 49 (pico) 8,3 is button 1 pushed again...
output 48, shade responds with a target position of 100%, fully open
consolidated:
dev:1392 2018-04-19 14:46:37.704:info Office Shade was set to 100.0% ~100ms
dev:1451 2018-04-19 14:46:37.604:info rcvd: OUTPUT,48,1,100.00
dev:1391 2018-04-19 14:46:37.574:info Office Pico (shades) button 1 was pushed ~90ms
dev:1451 2018-04-19 14:46:37.453:info rcvd: DEVICE,49,8,3
dev:1392 2018-04-19 14:46:35.990:info Office Shade was set to 91.04% ~70ms
dev:1451 2018-04-19 14:46:35.917:info rcvd: OUTPUT,48,1,91.04
dev:1391 2018-04-19 14:46:35.886:info Office Pico (shades) button 1 was pushed ~85ms
dev:1451 2018-04-19 14:46:35.801:info rcvd: DEVICE,49,8,3
dev:1392 2018-04-19 14:46:34.017:info Office Shade was turned off ~110ms
dev:1451 2018-04-19 14:46:33.908:info rcvd: OUTPUT,48,1,0.00
dev:1391 2018-04-19 14:46:33.886:info Office Pico (shades) button 4 was pushed ~130ms
dev:1451 2018-04-19 14:46:33.756:info rcvd: DEVICE,49,11,3
device 1451 is one of my bridges, ~XXms is Hubitats response time to the events generated by the bridge.
I just tested with my lutron caseta dimmer to Smart Bridge Pro to Hubitat to a quick rule to turn on a zigbee outlet switch and its less than a second from tapping the on of the dimmer to seeing it in logging and the outlet switch turning on, the outlet actually clicks just before logging shows the events.
The lutron interface reports changes to devices in near time to the lan connection, so there isn’t anything that would explain the 3 second delay you are seeing on that part.
There might be something delaying your rule processing? Do you have anything polling or refreshing other devices at a close to 3 second interval?
Try this. Use a rule to bind a second dimmer to the button presses of the first dimmer. I can verify using this method there's about a 3 second delay from the one turning on before the second one does.
According to the logs, the delay between events is only 150ms, so either the outbound command to the Smartbridge pro is delayed by 3 seconds, OR the inbound push notification from the smartbridge pro is delayed by 3 seconds.
I checked with my phone. The delay is the push notification to Hubitat from the Smartbridge Pro.
There's still a slight delay (~1 sec) using a pico paired directly to the dimmer. So it's weird that the pico telling the dimmer to turn on has a 1sec delay but the dimmer turning on itself has a 3sec delay before notification.
So my observations:
Turn on light manually
Smart Bridge Pro reports light on after ramp rate (could be the 3 seconds you are experiencing)
Hubitat sees light on
Hubitat processes subscription to Simple Lighting
Hubitat turns on second light
Going the opposite, turning the light off, almost no delay because Smart Bridge Pro reports off much quicker.
This pattern will never turn both on/off at same time. Groups would be a better option. But I believe the observed "delay" is the ramp rate and when Lutron reports the light as "on".
That would make sense except… when using a pico button controller paired directly to the dimmer, it happens faster (~1 sec). Does the pico report “on” more quickly than the dimmer? And if so, why?
The lutron interface only reports when the dimmer reaches 100 (the OUTPUT,X,1,100) and you can see it is immediately followed up with changing the next light.
There are no other events reported by Lutron for button pushes or hold... That's what the picos are for I guess.
I have confirmed with Lutron that Caseta dimmers are designed with the 3 second delay
Here's what Lutron tech support told me:
Lutron RF dimmers always wait 3 seconds before reporting changes made locally at the dimmer. This is because the user is often fine-tuning or adjusting the dimmer with multiple back-to-back events (on/raise/lower/etc), so the dimmer waits until local activity has stopped (3 seconds after the last local activity) before reporting the final level back to the system. The level reported by the dimmer is intended for status purposes only, and is not intended to be used for triggering other events.
A better solution is to use Pico and Keypad events. These are reported immediately to the system, and will result in much faster response time, as the events from a Pico are intended to result in other devices (dimmers, for example) changing in response to the button events. If setting up automation, Lutron recommends using button events rather than level status updates if quick response time is desirable.
Sure, but you have to have the dimmers physically installed. If you can’t receive the feedback of the physical button presses on the dimmer, what’s the alternative? Just hide them somewhere and replace all the switches with picos? That’s dumb. The button presses should be exposed for the dimmers for consistency.
In the log, I get the on/level event only, not the button event.
sure I get that, however engineering staff do indeed eat their own dog food here, bold move on my part?, you bet.
I would not have considered an implementation such as this on any other platform...
