Maybe a "releasableButton" capability?
2 Likes
Yup, that's what came to mind....
1 Like
This is a bug, found and repaired. Next release...
2 Likes
That would work for me! I think a lot of Pico users would find this a very useful feature.
That would be a nice feature if you could adjust the time between pushed and released for a “held” event.
This "feature" could only be implemented such that it applied to all Picos in a system. What would you change it to? It is currently 1000 msec. 1000 msec was chosen because the led blinks on a Pico button press for ~950 msec. So the human factor for held is that you wait until the led goes out, then release.
1 Like
Bruce - Thank you for the quick fix.
What are your initial thoughts about adding a second event to the Fast Pico driver of "released"?
2000ms seems like a reasonable compromise. I would of course want it to be user definable ideally.
2000ms is a very long time to hold the button, IMHO. I was thinking more like 500ms is all that should be needed to call it “held” instead of “pushed”...
That would lead to divorce in this house! 
Bruce's point about the light is very good. Shouldn't be less than 1000ms IMHO 
1 Like
Agree with Dan, 2000ms is way way to long for held, it's an eternity.
Devices that have this implemented in hardware, aeon minimote as an example issue held automatically at around 300 ms, in my opinion 500ms is the absolute max for a responsive auto held response
1 Like
So it is safe to say on this, you do not agree?
Bruce tied this to the led blinking, which makes sense, and honestly I didn't even know that, and I have 40 odd picos...
My preference is for a shorter held time, which is a bit closer to the hardware implementations I have observed, that's all I'm saying.
I'm also talking about automatic held event generation. Push push push xx ms later held, then user releases...
Fair to say, that all of our preferences would ultimately be freedom of choice. Is there a technical limitation that wouldn't allow a user definable value?
While true, this is only achievable in devices where this is implemented in the driver, when it's cooked into hardware it isn't changable, unless that same device has a release event, and most dont, so not every device that's a button controller can have this option.
Understood. Could it not be a setting for the Fast Pico driver specifically, only definable in the "Fast Pico" driver settings page?
Before HE, when I was using a Node.js server to connect my Caséta Pro bridge to ST, it could adjust the timing before held in the config.js file. That's a feature I really liked and do wish I could have again.
That was of course global, but if we were able to set this at driver level, we might be able to have variations, per Pico
Bruce and I have chatted about the possibility of doing auto held in the picos, I think that Lowes was out of stock on round-to-its at the time...
1 Like
I like the idea of an auto-hold feature. However, I also want the option of choosing between having “Holdable Button” and having “Releasable Button”. Seems like having both options would be ideal. Kind of like the choice between “Pico” and “Fast Pico” we have today.
Maybe something like:
- Pico (current functionality, pushed and held events)
- Fast Pico (pushed + new released events)
- Auto Hold Pico (pushed and held events, user selectable timeout for held)
Or something like that.
1 Like
There is a misunderstanding: Held timing would not become part of Fast Pico in any event, as it does not support "holdableButton". Instead, as @ogiewon has suggested, we can add "released" events to Fast Pico and "releasableButton" to the capability.
The timing on "held" applies to the normal Pico driver, the one that reports "pushed" and "held". This timing value is a global value as to Picos, and only applies to Picos. We could possibly make this a user settable value. I will look into it.
2 Likes
I like that idea.
I am very likely misunderstanding the differences. What is the difference between how long a button is held vs how long before it is released?
I'm not under the impression, that either the Pico driver or the Fast Pico driver could continue to send pulses as a button is held, but rather that when the current Pico driver is released is when the pushed event is transmitted and when it is held for 1000ms, that time from the initial push to the release is used to interpret how long it is held. Is that not the case?
If that's correct, then I would hope that similarly, it would be possible for Fast Pico. That, once pushed, it could immediately send a pushed event (as it does now), but that pushed even would be the start of a users definable time in ms, and when when the release event is sent, that definable time between pushed and released is calculated to determine if a sudo "held" state has occurred.
