Has anyone ever noticed or have any definitive information/opinion if the RA2 main repeater prioritizes integration scene calls (ie phantom button presses via #DEVICE command) over setting a dimmer/switch to a specific level (ie via #OUTPUT command).
Trying to figure out if there is something specific to this RA2 (regular, not select) system running latest 12.10.0 or it's consistent across all RA2 systems. This system has NO Lutron Picos or occupancy sensors (ie no 1-way Clear Connect Lutron devices).
Here's the background. Recently decided to replace all Lutron motion (aka occupancy) sensors on a large RA2 system (~180 RA2 devices) with Zigbee 3.0 motion sensors connected directly to new Hubitat C-8 (using Hubitat Room Lighting Apps to turn on various Lutron RA2 light switches/dimmers). Most of the RL apps I setup are simple and just say if motion becomes Active for a single Zigbee motion sensor then turn on (âActâ) a single RA2 switch and if motion becomes inactive for 10 minutes turn âOffâ the switch. The key is that each of the RL app instances are for just a single RA2 switch (ie only one RA2 device is being controlled in the âDevices to Automateâ).
What I noticed was there was an intermittent delay (not all the time, only sometimes), up to three seconds, for the Lutron RA2 light switch responding to the main repeater being told by Hubitat to turn on the single RA2 switch. I confirmed with simultaneous wireshark trace and timestamped synced output of a parallel telnet connection to the Lutron main repeater that the Hubitat and RA2 repeater are processing and acknowledging the call to turn on the RA2 switch in less than 150ms every single time â just canât tell if the Lutron system is waiting on sending the 430 MHz Clear Connect on command to the RA2 switch or not because I donât have any means to monitor the proprietary Lutron RF communications. I am positive the delay is not on the Zigbee or the Hubitat side of things as confirmed by the Hubitat logs.
I am very familiar with Lutron RA2 best practices (ie. using a Lutron programmed scene/phantom button to eliminate popcorn effect when turning on/off multiple RA2 switches/dimmers). That said, for turning on a SINGLE RA2 switch I thought there would be no advantage of using a phantom scene (ie. the #DEVICE command call of a phantom button on main repeater) vs directly setting the load/zone level (ie the #OUTPUT command of the switch or dimmer).
For example, the following two scenarios accomplish the exact same thing (turn on a single RA2 switch with ID of 77). This is going behind the scenes a bit to understand how the Hubitat RA2 driver actually uses Telnet to communicate to Lutron system.
Method to turn on switch by directly setting the single switch to level 100%:
#OUTPUT,77,1,100.00,0,0 (very simple in that the system is told to turn switch ID=77 to 100% with 0 delay and 0 fade - This method is where we sometimes see a delay of up to 3 seconds although sometimes (about 1 in 3 times) it happens in sub 1s as is desired.
Method to turn on switch to level 100% using a Lutron scene (ie via phantom button press on repeater):
#DEVICE,1,44,3 (whereby calling for the press of button 44 on the main repeater (ID=1) has switch ID=77 programmed to go to 100% with 0 delay and 0 fade on the main repeater). With this method the transition of the switch (ID=77) always happens in sub 1s (albeit sometimes closer to 150ms and sometimes closer to the full 1s but anything sub 1s is good in my book).
Just curious if anyone else (esp @bravenel) has experienced or noticed the same thing where the system seems to turn on switches quicker with the #DEVICE vs #OUTPUT command?
P.S. If anyone wonders why I am ditching Lutronâs occupancy sensors itâs because we got annoyed with the Lutron imposed one second halting of their RF Clear Connect channel. That time actually can cascade to be four or more seconds when multiple one way devices are used (ie. a longer hallway being equipped with multiple occupancy sensors). Waiting four seconds in the pitch-black dark of night to turn on closet or bathroom lights was no longer acceptableâŚproblem kept getting worse as more and more occupancy sensors were added (even using the split repeater trick as the cascading/additive delay effect just moves to the other repeater if multiple one way Lutron devices are being used/tripped at the same time). In addition, Zigbee 3.0 Motion Sensors are now so mature that I feel they are equal to Lutron in terms of reliability and surpass Lutron in terms of flexibility and aesthetics/size.
