Interesting topic you brough up! So, here are some initial thoughts…
But first, as a kind of reference design, or source of inspiration, I want to look at the Hue way of working (I know, it’s common knowledge, but it helps me get the thought process going when I write it down.
The Philips Hue product line has different types of switches, the Dimmer Switch (battery operated) and the Tap (energy harvesting based) are among the most popular. I’m not familiar with the TRADFRI remote control, but from the description and from the fact that it has a battery, I assume it operates similar to a Dimmer Switch, except it doesn’t send a pressed event? Can someone elaborate on the TRADFRI remote control?
The Philips Way
The 4 buttoms of the Dimmer Switch are ‘designed’ for: On, Increase, Decrease, and Off. In addition it distinguishes between pressed, short released, hold and long released of each button. When initial pressing a button, the pressed event is triggered and when released within about 1 second, a short released is triggered. If the button is still pressed beyond this, repeated hold events are triggered until the button is released, in which case a long released event is triggered. This happens on the switch with different events. Philips Hue users have another feature that is handled by the Hue bridge: repeated short pressing of the same key. You can have it trigger different events/scenes with each press of the button, like: 1 press turns on the hallway light, 2 presses also turns on the kitchen lights, 3 presses turns on the diningroom lights in addition, etc. All these possibilties are equal for each of the 4 buttons of a Dimmer Switch
The Tap also has 4 buttons, but they have only one event per button (combination) that is triggered when the key is pressed. This is primarily due to the limited amount of kinetic energy that can be produced by the keypress to generate the ZLL signal (they have no batteries): it can fire just one shot so to speak. Also, the Hue Bridge can handle multiple presses of a Tap button to do ‘smarter’ things.
I would argue that many people are happy with a behaviour similar to the one described for the Dimmer Switch. But just mimicking that would be ‘below openHAB standards’, which primarily stands for a flexible home automation framework. OK, that was way too long…
What should the binding do?
The multiple events appoach would allow for the full set of options in particular to deal with ‘hold’ and ‘release’ events. Using profiles like this can also mimick the standard behaviour of a Dimmer Switch, except for the repeated key presses, which would need some kind of rule processing to maintain state between events. Also, given the different types of switches, including the TRADFRI, this would be the most flexible aproach.
I am not sure how a short released or long released would fit into this dimmer scenario as they are not realy Dimmer
commands. Another aspect I’m not sure about is the potential timing issues when combining hue-profiles with rules that trigger on updates or changes, for instance to mimick multiple key presses. That could mean that it’s an either/or scenario (use profiles or rules)?
Also, given the fact that there are different types of switches, from Philips, IKEA, OSRAM, and others, with sometimes somewhat different features or behaviour, the binding should IMHO be as agnostic as possible.
All this leads me to the conclusion that a solution where multiple channels can be linked (as shown in the non-working example) would be ‘the best’ solution. BTW, I have not yet tested that myself. The scenario with multiple commands could be an alternative implementation within the binding, but not a very neat and clean one, I think.