Agreed! 
Yes indeed. I will do the Telnet experiment and share it with them so they don't blame HE (that will be their initial knee-jerk reaction).
I'm on hold with them right now. I'll cross my fingers on this call and then go on to next steps if they can't resolve it.
P.S, thank you everyone who responded to this trying to help. This community is an awesome space!
1 Like
Here's info from someone who was in contact with Lutron. It doesn't address a 2 bridge scenario, though.
2 Likes
Hi Bill, just read through that thread. I pulled this interesting piece of info out of it;
Blockquote
I am now able to confirm the behavior you are seeing in a test setup here. It turns out that this is a byproduct of how the system handles incoming traffic when the system is hearing RF traffic. When a Pico button is pressed, the Smart Bridge, and the affected dimmers all talk for a short time. While those devices are all talking, the system won’t process and transmit any integration type commands until the currently ongoing RF traffic stops. In that vein, this is expected behavior.
Blockquote
To that end, does anyone want to buy a brand new Smartbridge Pro?
Sorry, I needed to edit this thread, because after thinking about it, this should be mitigated by using 2 Smartbridges, unless the Smartbridge listens to every little piece of RF that comes in on that freq. With that in mind, you could conceivably take down someones entire Lutron system by hooking a Pico up to a bigger battery and leaving the button depressed.
You could similarly mount a denial of service attack against a Z-Wave or Zigbee based system. The radios are serial devices.
I just tried this with a spare Pico remote that I have, which is not paired to my SmartBridge Pro. I then used another Pico that is used by Hubitat to control a Zigbee lightbulb. I could not get the 'random' pico remote to interfere with the pico/Hubitat/zigbee bulb automation no matter how I pushed and held its buttons. Maybe it needs to be paired to something before it can cause a delay? I only have one SmartBridge, so not easy for me to test any further...
I think the issue here is with the Bridge sending RF at the same time as receiving it. As my SB is receiving RF from the Pico, but then trying to send RF to the light switches (also Caseta) at the same time.
1 Like
But, the Pico should only occupy the channel for 50 milliseconds max at a time. Holding the button down doesn't send anything until it's released. Channel interference seems an unlikely thing to be going on. More likely it's some software thing in the SB.
I did a little test with my RA2 system. I set up a rule triggered by either a Pico (Fast Pico) or a Minimote (Z-Wave), each to toggle a RA2 switch. Minimote is instant. Pico is instant relative to the LED stopping to blink, which is about 1 second after the button push. So net, Pico takes 1 second while Minimote is instant. That is not a good implementation on Lutron's part, I'd say. But then, they didn't really design to cater to external integrations. What I didn't test was the timing with a Pico directly paired to the device, but I'd guess that will be instant as it will bypass the main repeater.
1 Like
Yes indeed. I have a Pico that is paired directly with a light switch here as well (the one any only) and it is indeed instant, much like pushing a button on the light switch itself.
I've sent Lutron the logs from the two SB with an explanation of what has been happening, and what I've done to deconflict. They did say that they are reaching out to their engineering team so we'll see.
I am truly hoping that on my original SB (SB1), the original Picos are somehow still lingering in the device list and therefore interfering with SB1, despite being paired to SB2.
I also sent them this little diagram hoping that it better explains the problem.
Pico +++> Smart bridge 1 —> Hubitat —> Smart bridge 2 +++> Caseta Switch (delayed)
Pico +++> Smart bridge 1 —> Hubitat —> Smart bridge 1 +++> Caseta Switch (delayed)
Pico +++> Smart bridge 2—> Hubitat ===> Non Lutron Device (Instant)
Pico +++> Smart bridge 1—> Hubitat ===> Non Lutron Device (Instant)
Non-Pico Remote ===> Hubitat —> Smart Bridge 1+++> Caseta Switch (Instant)
+++> Clear Connect
—> Telnet
===> Zigbee/Zwave
1 Like
How long is the delay? Longer than the 1 second in RA2?
Yes, much longer. Here is a video showing the delay.
This shows the delay difference between a Zwave remote vs Pico.
Something you might try is what was suggested above. Create a phantom button in Lutron that does the action on the switch (set up in the Lutron app), and hit that button with the Pico action instead of the switch. See if that makes any difference. All of the phantom buttons of the SB can be had by including the SB as a Lutron Keypad, integration ID is 1.
I actually tried that already. I didn't realize we were talking about the same thing.
I have my Lutron Scenes set up from Button 1-100 on the SB. I have Scenes within the Lutron App that are triggered by Picos. So basically;
Pico+++> SB ---> HE ---> SB (scene) +++> Switch.
Its the same, although it does eliminate the popcorn effect when triggering multiple switches.
How cool is it that a non-Lutron button device can control Lutron lights better than a Pico, and that a Pico can control non-Lutron lights better than it can Lutron lights? That's embarrassing! It shows a bit of NIH and inward focus, insularity.
3 Likes
Indeed.
I know that on RadioRa the frequencies of the Pico and the Hub can be changed to deconflict with other devices, but I don't think that is the case with he SB.
I think the cheapest solution here is to sell the second SB and to then replace the 3 or 4 Picos controlling other Lutron products with RGBGenie remotes. They'll fit into the decora plates and they work.
Ho-hum....
I never really noticed it for two reasons: Most of my Picos control Z-Wave devices. The one that controls RA2 lights the delay is masked by the ramp-up time for the dimmers. They are never fast, which is OK, and "instant" response to the Pico isn't needed.
I don't think this is true. I've been through their level 2 training, and this never came up. Lutron uses licensed spectrum in the 423 MHz band. Due to this being licensed spectrum, interference is minimized. Also, every use of that band must have low power and low channel occupancy. It's used commonly for garage door openers and the like.
Ah, found this document. This pertains to a two main repeater RA2 setup. I'm just about to add a second main repeater, so it will be an interesting test to have Pico on one controlling a switch via Hubitat on the other.
Yes, that document is what I was given as well. You have to do some weird vodoo button presses with the Picos and then you can cycle through frequencies (within a certain range obviously).
But alas, I think the RGBGenie route will be much cheaper and painless. And, I can always find a use for 4 extra Picos (does anyone really ever have "extra" Picos, or just Picos waiting to be used?)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
