Just curious if any action is needed to implement the Fast Pico driver for existing devices, or if it's just inherent, once the update is applied to the Hub.
If you already have the device setup in the Lutron Integration, simply go into the device details for that device, and change the type from Pico to Fast Pico. That will attach it to the new driver.
You should update your Lutron Integration app also, but it won’t remove your old device and create a new one when you change it there.
I’m not seeing the “fast pico” driver in my options after the .702 update?
I’m using the Lutron Integrator built-in app, it has a Lutron Integration configured. I cannot find any way to update the app … being built-in, wouldn’t the updated app come with the new Hub build?
I also cannot find “Fast Pico” as a device type either in the Lutron integration device list, the Button Controllers app, or the actual Pico under Devices.
Whoa, my bad. It never was included in the build. Next build. Sorry about that!
I was getting excited about something new to break too. 
1 Like
LoL @oldernstone
@bravenel Well at least we’re partly trained for whenever it does arrive. Please don’t prioritize this over the Hue Bridge integration on my account 
1 Like
I've searched, but I'm only finding reference to "Fast Pico" here. How does it differ from the "Pico" driver?
Fast Pico supports pushed function only, it's faster than the standard pico with pushed event response time since we aren't waiting for the held event timer to run, which adds some few hundred ms to the pushed events.
1 Like
The pushed/held Pico fires off the button release, while the Fast Pico fires off the button pressed.
1 Like
sooo 50ms vs 100ms? So speedy! Seriously though, my "normal" speed picos are basically instant. Not sure the benefit?
It makes a difference when I trigger things that are already a little slow. If I change to "Fast Pico", my outdoor light that is triggered via HE Homebridge > Insteon, is faster. The downside is there is no "Pushed" available.
Some people don't immediately release the button, certainly not in 100 ms. So the difference is simply the event firing on press vs release. We added it for purists, who want the pico to work essentially the way Lutron designed it, as opposed to our "enhancement" to turn it into a pushed/held device.
1 Like
Bruce and Mike,
I have been trying out my new Caseta Pro bridge with a few Pico remotes. I have tried both the normal Pico driver as well as the Fast Pico driver. I can definitely see the speed difference of the Fast Pico, however I have also observed something interesting when using the Fast Pico.
It seems that Fast Pico driver is registering 2 "pushed" events for each press of a pico button. The first comes on the physical button down, and the second on the physical button up.
Within Rule Machine I set up a simple Notification on button 1 pushed, using Pushover. Each time I press the pico, I get two notifications (one on the press and the other upon release.)
Is this the intended behavior? I would think the Fast Pico driver should only create an event when the button is being pressed. I do think it would be very cool to create a new event for button "released", as it could be used to perhaps end an action initiated by the button "pushed" event.
For example, imagine where you'd like to allow a user to start ramping up the dim level of a dimmer, and continue ramping until the button is released. This would more closely emulate the function of a traditional dimmer switch, but via a Pico remote.
Thoughts? Maybe I am missing something as I have just started to use Pico remotes. I would really love to be able to press and hold the "up arrow" button on a pico and have a z-wave/zigbee dimmer continue to ramp up until I release the pico button. Same for the "down arrow" button on the pico (ramping down, of course.)
It appears that the Caseta Pro bridge does indeed send two unique events via Telnet, one for press, and one for release. So it seems like it would be easy to add a new event for "released", instead of creating two "pushed" events. Two "pushed" events is likely cause confusion within Apps.
Thanks,
Dan
Hubitat running 1.0.9.118, I do not experience this behavior.
I do get three telnet events from the Lutron Bridge per single Pico button press. (but don't know enough to understand the code, although one could guess that they might be: device identification, button press, button release?)
There should only be two received events per push release.
First digit is lutron button id, second is Pico button number, then pushed, released.
Lutron button numbers do not match physical button numbers, and they vary depending on the type of pico.
Mike,
That is what I am seeing. The problem is the Fast Pico Driver generates two “pushed” events for every physical button press. The normal Pico driver only generates one “pushed” event.
I would like to see the second “pushed” event turned into a “released” event, when using the Fast Pico Driver.
1 Like
+1 this would open the functionality of the Picos.
1 Like
There would be a conflict in adding the released attribute to the pushableButton capability in that not all button controllers are capable of producing this event. It likely begs for it's own capability to avoid this issue.
