I have a couple of these. Love them they are super low profile and have that ultra modern look. I just use them as on/off + dim up/down.
[{"id":"db5a0a3f.9a5928","type":"switch","z":"70c2e683.a04438","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"1","vt":"str"},{"t":"eq","v":"0","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":530,"y":180,"wires":[["d6b5dd16.925e1"],["719140f9.8b90e"]]},{"id":"d6b5dd16.925e1","type":"change","z":"70c2e683.a04438","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"1","tot":"str"},{"t":"set","p":"next","pt":"flow","to":"0","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":740,"y":140,"wires":[[]]},{"id":"719140f9.8b90e","type":"change","z":"70c2e683.a04438","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"0","tot":"str"},{"t":"set","p":"next","pt":"flow","to":"1","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":740,"y":200,"wires":[[]]},{"id":"ffc6e6b1.c48ab8","type":"function","z":"70c2e683.a04438","name":"get next value","func":"msg.payload = flow.get(\"next\")||0;\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":180,"wires":[["db5a0a3f.9a5928"]]}]
I was just informed that each button does a triple click and then hold. That adds even more presses. They’re good little buttons, I’m still new to them, but I think I’m going to like them. I now own two.
I haven’t tried the picos. In discussing them with Markus, he tells me that there are clear limitations with these that makes him not want to try them. I’ll take his word for it. I’m sure others will pipe in. There are plenty of people who like them. I can say that the Opples haven’t disappointed me, but … click … 
I think I’ll always like them.
1 Like
The only limitation with Picos is that anything other than a single press needs to be derived based on time stamps. The devices report both press and release events. So a press means a press event quickly followed by a release event. A hold means a press with delayed release. A double tap means multiple presses. The issues relate to figuring out the right number of milliseconds between events. There are OS implementations, including node-red flows, that can provide a guideline for timings.
2 Likes
Only? That sounds painful.
As I said, plenty of people/projects have implemented holds and at least double taps. It’s simple math. Not that painful. The best thing about Picos and Lutron is that they always work unlike Z-Wave especially or even Zigbee.
2 Likes
I have a few different brands of zigbee buttons but none have ever stopped working other than a dead battery
so they too “always work”
anytime i hear complaints about how zigbee or zwave don’t work reliably my first thoughts are you have poor mesh coverage and need a couple repeaters, you have junk repeaters on your mesh, or your using a hub with a poorly implemented stack…
1 Like
2 Likes
I agree, but a poor implementation or dead nodes can be a cause of dead batteries. I know that there is talk about a migration, and I’ve been testing this. Will migrating tables work? Yes. I have a working mesh to prove that. But, I recently reset my Z-Wave and went through my network. I found that everything paired with barely one button press for activity on CORE and reacts in a heartbeat. NOT that it wasn’t snappy enough before, but I’m super happy with performance as of late.
I know that you don’t want to hear it, but it seems that a fresh install is the way to go on these things. It’s something that you should put some thought into because it’s convenient to migrate these things, but this migration won’t be as clean as a fresh install. This creates frustration. It only took me a couple of hours to migrate 50+ devices. It’s just a thought and observation.
4 Likes
Undoubtedly part of the issue. Yet not the entire issue.
Silicon Labs should not have released 700 series controllers. 700 series is still beta. And Z-Wave no matter the series is completely brittle. What is the point of a mesh if a single bad device can bring down the rest of one’s devices? There’s a reason that Z-Wave is developing the 800 series so quickly and LR devices are likely coming. Lutron has shown that at low frequency star topology can work really well without all the mesh complexity.
On the Zigbee side the mesh can be extremely easy to get working reliably. As long as the devices one adds are either standard or the driver writer has figured out the manufacturer’s non-standard protocol implementation. IME Zigbee is much more resilient than Z-Wave, even with many fewer repeaters.
I suspect that Thread/Matter will make a big difference over the next few years, to everyone’s benefit. Even Lutron is putting 2.4Ghz radios that seem to be Thread-based into their new controllers (but they aren’t using Matter). Z-Wave will have to fight to remain relevant. And Zigbee will naturally wither away.
2 Likes
Yah, it’s interesting to watch things progress. I think everything has a place and a use. I really think there is a use case for all protocols. Some will stick around because it’s easy for newbies to understand. Other protocols will be more advanced. I recently redid my z-wave network to see the effects of migration compared to a fresh install. It was night and day. I feel like a take over, no matter what protocol or platform can be messy for many reasons. I paired the most important devices used in our home. Contact sensors, switches, and locks and left some of the extras out for now. My total number was around 60. I was dealing with some instability on a migrated system and some speed issues. The fresh install took a few hours and since I had a list of the naming convention, the rules picked back up where they left off. No reconfiguring in node red. I still see some instability, but I believe that will calm down as the mesh settles in. I did do everything in one day. I’ll be patient and see where it goes. I do plan on removing a few of the problematic zigbee devices. I have some lightify strips that like to complain. A lot. They’ll get retired at some point I think.
Do you have a good flow to achieve this? I finally got some picos and the Hubitat driver for double tap is not playing nice with NR. Ideally with only the base nodes, not some special ones.
I have a few I’ll post
Just use the “Lutron Pico Legacy” driver, if the double tapped events are causing any issues.
1 Like
@LosinIt and @RRodman have talked about their pico flows. Perhaps one of them will post them here for you. They’re much better than anything I have at the moment.
2 Likes
They are not causing “issues” just double tap does not seem to work with the NR nodes. Everything else is fine though. But since they are not working I was thinking of just using the Fast Pico driver and deriving the hold and multi-tap functions myself.
1 Like
I’d be happy to except I do not use double tap and my automations are in node-red leaving HE to be nothing than a “radio server”. I have never had a Pico connected to HE, they’ve always fed into NR. Sorry.
Ok so the pico remote logic is a major PITA to do…
The hubitat drivers are working with the raw data and using logic the programmer worked out to distinguish what kind of press has been done. To change the behavior you will have to alter the driver or work with the raw data yourself. I can’t be of much help getting anything to work with hubitat sadly.
The current node-red nodes for lutron parse and apply their own logic to determine which button was pushed once configured properly, and only report the button pressed, no pressed held or released info.
On top of that, if you hold a button for too long, at least with the NR node, the hub/node does not give you ANY output at all.
Now bypassing the NR luton nodes and working with the raw data from the hub you can work out logic for single double and held but it gets rather complex to get it all working smoothly and as expected each time.
You can kind of cheat with the current NR lutron node to do a double tap, by using a wait or stop timer to see if a second press occurs within a given amount of time and then acting only when it does, however this will introduce a delay in response of normal button presses as the flow must wait for the timer to complete before passing a single click on.
You could also use an unconfigured NR lutron node, which will then return all the raw data the hub sends, but that will also require manually filtering what device the data is coming from prior to the logic for presses and holds…
I am only using standard presses at this time, so I cannot provide any logic to help you 
Other existing solutions I know of are for other systems like HA and handle the logic through a plug in.
If your going to give it a go yourself here is a github link to one of the solutions for HA, it will let you see how the telnet data is parsed and what good timings are etc
3 Likes