BTW, as long as you never program the 4th button by holding it, you can work around the unpredictability by keeping track of the previous command and looking at sequence numbers. I have the remote working in zigbee2mqtt (just merged into dev branch) and it’s very reliable - as long as you don’t reprogram the bottom button.
zigbee2mqtt logic here:
What issues did you see when reprogramming the 4th button? From what I am seeing, it will switch to reporting the state set through the 2nd and 3rd buttons, which really isn’t an issue.
I could have sworn the 4th button was also sending ZCL: On commands if the top button previously sent a ZCL: Off command. Of course, I’m not able to reproduce this now 
Keying off MoveToLevelWithOnOff, if it actually always gets sent on button 4 presses, seems like it would work totally fine, and then just needing to differentiate between button 3 and button 4 through an approach such as yours should work.
Might have to mock something up now and bang on it awhile to see if it breaks
Is there any way to register double or triple presses of the buttons so that the 3 buttons could end up triggering 6 or 9 actions (nice)
I just re-tested to make sure I was remembering correctly. Here’s what I get for four successive button presses after reprogramming:
zigbee2mqtt:debug 2019-12-18 22:15:14: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToLevelWithOnOff', cluster 'genLevelCtrl', data '{"level":254,"transtime":0}' from endpoint 1 with groupID 16387
zigbee2mqtt:debug 2019-12-18 22:15:14: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToColorTemp', cluster 'lightingColorCtrl', data '{"colortemp":370,"transtime":3}' from endpoint 1 with groupID 16387
zigbee2mqtt:debug 2019-12-18 22:15:35: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToLevelWithOnOff', cluster 'genLevelCtrl', data '{"level":254,"transtime":0}' from endpoint 1 with groupID 16387
zigbee2mqtt:debug 2019-12-18 22:15:35: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToColorTemp', cluster 'lightingColorCtrl', data '{"colortemp":222,"transtime":3}' from endpoint 1 with groupID 16387
<WHY!?!>
zigbee2mqtt:debug 2019-12-18 22:15:46: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandOff', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 16387
</WHY!?!>
zigbee2mqtt:debug 2019-12-18 22:16:08: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToLevelWithOnOff', cluster 'genLevelCtrl', data '{"level":254,"transtime":0}' from endpoint 1 with groupID 16387
zigbee2mqtt:debug 2019-12-18 22:16:08: Received Zigbee message from '0xccccccfffea9cdd3', type 'commandMoveToColorTemp', cluster 'lightingColorCtrl', data '{"colortemp":370,"transtime":3}' from endpoint 1 with groupID 16387
Why there’s a random single “off” message thrown in, who knows… But that’s what I see every time I reprogram the remote with the scene button.
Luckily resetting knocks some sense into it.
4th button is “Memory” button. That is why is repeating other buttons. See screenshot below.
If original intent of remote is replicated in smartthings device handlers, that can be perfect, with options to change them to standard buttons.
4th button can be used as 3 Scene button. For example 1 scene could be dim 20% and 2700K. 2nd can be dim 50% and 4300K, etc… or if used for shades can be 20% down, 50% down and 100% down.
Have you been gettting this to work with multiple remotes to act uniquely?
To Preface:
I unpaired 7 bulbs from their respective remotes, paired the bulbs to Hubitat hub, paired a Remote (Remote A) to Hubitat hub, then Touch-Link’d remote to each of the 7 bulbs into bathroom vanity. I am able to control all of the bulbs successfully thru Hubitat & with the remote. It worked!
I then grabbed an 8th box and did the same 3-step process to unpair, pair & Touch-Link the devices and installed the bulb (Bulb 8) into a lamp. I pushed the power on the second remote (Remote B) and EUREKA!! it worked too! Unfortunately Remote B also turned off all of the bulbs in bathroom vanity about 30ft away. So, I started over and made sure that the wall switch to the vanity was turned off in case I was close enough to affect those bulbs when TouchLinking Remote B to Bulb 8. Still same problem, Remote B controlled all 8 bulbs and Remote A now would not control any of them. I finally tried a 3rd remote (Remote C) from a bulb that I hadn’t even pulled out of box and had the same thing happen.
Not understanding how TouchLink works, I assume that its an issue within that system but I wanted to ask the experts. Thank you.
On the SmartThings platform, yes. Each remote would have a different Device Network Id, or DNI, that can be used to differentiate which remote sent the events. I have not tested on any other platforms but assume they wouldn’t be doing anything different.
These remotes work by sending out multi-cast commands to groups that the bulbs come pre-added to. I do not have enough knowledge of the Hubitat system but it sounds like it is not properly handling preexisting device groups if this is unintended or undesirable behavior.
I am so happy I was not crazy and yet simultaneously really wish that I was as it would have made the DTH easier to write. We are going to have to characterize what is causing the 4th button to occasionally send these on/off commands
The 2nd and 3rd buttons do support long presses. multi-press support could be added within the DTH but do be aware that adding multi-press support will inherently also increase the time it takes for events to trigger off the button presses as the system must wait to see if you are done pushing the button. Also, I haven’t played much with multipress but I do recall that the button didn’t seem to be sending multiple events if pressed in quick recession. If this is the case it would seriously hinder any sort of multi-press UX
In an ideal world we would be able to write a DTH that abstracts away all of the “smarts” in the remote and just creates generic button press events. You can then use these events to trigger actions through automations in the SmartThings ecosystem! This could including recreating the 4th buttons factory behavior 
Yes. Even Hubitat sees the remotes separately. All that’s good for is battery status, but it works.
Hubitat’s developer has indicated that their current or planned roadmap does not include supporting inbound group messages.
And, if I remember correctly, they support long press with two clear distinct messages - “start” and “stop” instead of a single “long press” event. So you could even be fancy about your long press and support long and longer presses (or support dimming).
I just tested. I may be slow at clicking, but I can’t click too fast for the remote. I’m getting my zigbee2mqtt messages for every single rapid click. This includes button4 with my double-event detection code (so the second message is being squashed).
The only time I get missed messages are a) when the remote’s been asleep for a while (unfortunate), or b) out of range (and range is not great)
Or… just reset the remote and never program a scene. 
I’m so happy to see you say that. I agree 100%.
Could be super fancy 
I’m thinking any publicly available DTH would just trigger off the start command to indicate a long press, and then just discard the stop.
In that case I’m clearly just mis-remembering
There is a long string about this on the Hubitat Community websiite and it was mentioned that the Hubitat does not support multi-casting so I probably won’t be able to get these remotes properly working directly with that hub. HOWEVER, since I also have my SmartThings hub and have the 2 hubs connected using HubConnect, I am going to further explore the Zigbee2mqtt option.
Thanks again for the info.
@BroderickCarlin, any chance you’re prepared to share your DTH? I’d be happy to help out as a beta tester or anything else I can do to move it forward.
Ditto for me too since I bought 4 bulbs in anticipation 
I’ve got 10 bulbs ready to go
Will the DTH require Zigbee2MQTT or will it work directly with SmartThings hub?
Any potential release would be after the holidays
Any official DTH would not have any 3rd party dependencies
Awesome! Can’t wait! Thank you.
I just bought 6 today, lol
