Hue Binding - Dimmer Switch

Hi

i installed the pre official .jar you provided too. so far i created 2 dimmer and 2 tap things. all of them are sending values.
today (if i find some time) i will go deeper into testing and try to implement those 4 devices into my smart home so i get rid of the set up via the hue app.

I’ll report back asap :slight_smile:
Again: Thanks for your great work!

When button 2 (16.0) and 4 (18.0) are pressed I sometimes get 98.0, sometimes 99.0. All other combinations of simultaneous pressing don’t give anything at my Tap.

Nothing here on my Tap.

@cweitkamp

I tested it now.

I do ALWAYS get:

34.0=Button 1
16.0=Button 2
17.0=Button 3
18.0=Button 4

I also tested “long press” and “short press” and “simultaneous press”. All the same.
.
.
I can confirm @sihui 's statement:

2 Likes

yep. same here.
but why would you need that?
you have 8 possible things you can trigger with short and long press it think thats sufficient …

1 Like

hi

can you please provide a link to the busch jäger fames you use?

Not at all. It was just discovered during testing :grinning:

Sure. I bought a pair of these Eltako FT55R and combined them with a Busch-Jaeger Reflex SI frame and replaced the EnOcean switch inside with the one in the Hue Tap.
Like I mentioned here, if I had known that the Philips Hue Tap has an EnOcean module inside, I might have taken a simpler route. Because you can just alternatively buy an EnOcean USB300 to function as a bridge and connect the FT55R. That way you can do without a Philips Hue Tap (and Bridge), but you would need an EnOcean binding.

Thank you! :slight_smile:

Dear all,

I am tinkering around with the new Hue specific profiles in my environment and struggling with some not expect issues. I just want to let you know what I am faceing and discuss possible solutions with all of you. I am trying to connect a TRADFRI remote control to a dimmable light. As a side note: the TRADFRI remote control supports 5 different buttons and only 3 events (e.g. 1001, 1002 and 1003, etc.) for each of them. Let’s assume the dimmable has a brightness Channel and the remote a buttonevent Trigger, dispatching one of the above mentioned events.

First of all I added a “hue:toggle-switch” profile to a link between a Switch Item and the brightness Channel. This is working nicely.

Switch myBulbPower {
    channel="hue:0100:1:1:brightness",
    channel="hue:0830:1:2:buttonevent" [profile="hue:toggle-switch", event="1002"]
}

After that I tried to add a “hue:generic-command” profile to a link between a Dimmer Item and the brightness Channel. Know the issue happens. My expectations are when event “2002” has been triggered the brightness increases, and when event “3002” has been triggered the brightness decreases. Changing the brightness using a Slider element in a Sitemap is working fine. But pressing desired buttons only the second one for “DECREASE” is working.

Dimmer myBulbBrightness {
    channel="hue:0100:1:1:brightness",
    channel="hue:0830:1:2:buttonevent" [profile="hue:generic-command", event="2002", command="INCREASE"],
    channel="hue:0830:1:2:buttonevent" [profile="hue:generic-command", event="3002", command="DECREASE"]
}

Currently I am thinking that the framework somehow restricts the multi channel linking to one link per Item and Channel. Meaning during creation one Link will be suppressed. Now the first question: Do you experience similar issues?

What can be a possible solution?

  1. Change the design of the Hue specific profiles to allow more than one “event” for configuration

Rename “event” parameter to “events” and accept a comma-separated list. An example could say more than words:

Switch myBulbPower {
    channel="hue:0100:1:1:brightness",
    channel="hue:0830:1:2:buttonevent" [profile="hue:toggle-switch", events="1002,1003"]
}

This solution will solve a second issue I experienced while testing. If I pressed the button a little bit longer not a “press” was triggered but a “hold released”. BUT this solution will not work with the “hue:generic-command” profile.

  1. Solution No. 1 for the toggle profiles and a mapping between commands and events for the configuration - similar for the mapping in a Sitemap for Selecting elements
Dimmer myBulbBrightness {
    channel="hue:0100:1:1:brightness",
    channel="hue:0830:1:2:buttonevent" [profile="hue:generic-command", commands="2002=INCREASE,1003=INCREASE,3002=DECREASE,..."]
}

This solution needs more text to configure multiple events for the same command.

  1. Open a feature request to enhance the framework

I am not sure if I am able to implement it on my own because currently I am more or less the profile user not the expert in the core implementation.

Which way do you prefer?

Your opinion and different suggestions for different ways to solve this are very much appreciated

Have a nice evening.

Not sure I understood everything so don’t hesitate to blame me :slight_smile:

but from my user perspective what I would expect is simply:

one dedicated openhab channel for:

  1. buttonA long press
  2. buttonA short press
  3. button B long press
  4. button B short press
  5. button C long press
  6. button C short press
    etc.

Can’t we have such thing ?

For people who wants some combo : button A + B pressed in “the same time”, openhab provide some rules so you can easily achieve that with the previous suggestion.

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. :grinning:

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.

1 Like

Well thank for the rectifications (I thought maybe the hue tap had some short click features too)

I think this should be splitted into two Pull requests otherwise it will never be merged.

For the Hue tap switch it’s farily simply described -> one tap button = one channel
why not already merge this part and then discuss for the dimmer switch and tradifi things which looks more complicated ?

Most of people here have probably the hue tap switch which is more recent.

It is already available in the latest snapshots.

The TRADFRI remote control is nearly identical to the Hue Dimmer Switch. It is battery-powered but it has five instead of four buttons. The buttons are On/Off, Up (Increase), Down (Decrease), Left and Right (both for switching scenes). The On/Off button dispatches a pressed event, the rest triggers short released, hold and long released events.

I assume this is a Hue specific feature and it is implemented in the firmware / protocol / API. My Hue Dimmer Switch connected to a deCONZ emulated bridge sends only one hold event combined with a final long released event. Because of this I am thinking about a “repeated-command” profile (see at the bottom of my post) …

Or the mentioned “repeated-command” profile.

Hm, I completely forgot about that. But I think because of complexity it is more or less a use-case for a rule.

It is possible to link multiple Channels to an Item but - to make it clear - it is not possible to link a dedicated Channel more than once to an Item which restricts the usage for the new profiles - in the current implementation.

A brief glimpse on my thoughts about the “repeated-command” profile

  • Triggers on hold event until either long released is triggered or a maximum amount of repetitions are reached
  • Sends repeatingly a desired command delayed by some milliseconds
  • Command, maximum amount and delay are configurable

Just a remark on Hue / Homekit integration.

The Hue app can set a Hue Dimmer to be configured in the home app.
The home app can then create an action on each of
Button 1 - Single Press
Button 2 - Single Press
Button 3 - Single Press
Button 4 - Single Press

In this way, I have some dimmers set multiple home scenes per button.

I don’t know if Apple are considering implementing other press types in the home app.

Hopefully the OpenHAB implementation wont contradict with these conventions.

Steve

This makes me thinking: if ‘we’ :grin: add different types of ZLL devices, the Hue binding becomes more a kind of ZLL binding.

I do not think so. In general it would be nice to support every device which claims to work with Philips Hue. But on top of that the Hue interface supports a lot more features (e.g groups or scenes) than forwarding data from ZigBee based devices. Hopefully I will find some more time to work on the integration into the bindings.

Absolutely not. Indeed we are looking for any kind of solution or idea to provide the user as much as he expects from the Hue App itself.

This multiple presses in a row implanted the next idea for a another profile in my mind …

Is there a way to figure out which hue specific profiles are implemented? I‘m using the docker 2.5.5-Snapshot release and the hue:toggle-switch Profile works fine. I wonder what else is implemented.

AFAIK there are no official Hue specific profiles. At least my proposals never made it into the binding.

You can read everything about existing profiles here.

Thanks. But the hue profiles are currently implemented in the snapshot release?
It seems to work or does it works now naitively without a profile ?