Friends of Hue Switch/Button Events not triggering correct (button long press release OR button held)

[8OND007]

The problem

Niko Hue 4-button switch: https://www.niko.eu/en/article/120-91004 does not trigger all 4 available events anymore.

"Button released after long press" and "Button held down" don't work anymore after upgrading 2021.11.x to 2021.12.x

What version of Home Assistant Core has the issue?

core-2021.12.1

What was the last working version of Home Assistant Core?

core-2021.11.5

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Philips Hue

Link to integration documentation on our website

https://www.home-assistant.io/integrations/hue/

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

Niko 4-Button switch is also known as : https://www.zigbee2mqtt.io/devices/PTM_215Z.html

[probot-home-assistant[bot]]

hue documentation hue source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @balloob, @marcelveldt, mind taking a look at this issue as it has been labeled with an integration (hue) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[marcelveldt]

Can you please look in the developer tools and subscribe to "hue_event" (you'll have to type it in the box and click start listening). You should see the events coming in when you press the buttons on the remote. Can you have a look what events you see emitted, especially the hold down actions

[marcelveldt]

As you're Dutch, I might as well include a dutch screenshot ;-)

[8OND007]

When I hold the button long time OR when I release it after long time it only generates an "initial_press" :

{ "event_type": "hue_event", "data": { "id": "nachthalnikoschakelaar_button", "device_id": "c33d3441823827b7d789c7ee4fd2bed9", "unique_id": "f64674b7-f2e4-4db5-bf76-2b9f1ade5d87", "type": "initial_press", "subtype": 4 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:09:12.831996+00:00", "context": { "id": "7b2453e5fc81b33601445b53f65f197d", "parent_id": null, "user_id": null } }

I know above is a different switch, but it's the same problem with the same type of Niko switch.

"held down" and "release after long press" don't generate hue_event's.

[marcelveldt]

Please test with the Niko button/switch as events differ between devices. For example not all devices support long press events, only a few (like the Dimmer switch)

[8OND007]

Yes, I tested with the Niko button/switch, see below. Only short_release and initial_press work. The other events which are listed as available do not work anymore since update. They did work in the past. (2021.11.x) Strange thing after upgrading tot 2021.12.0 long press released did work some time, but then died. Upgrading tot 2021.12.1 did not solve it.

Event 14 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "240bdbc5-3f43-4b17-8355-3c4db8afe507", "type": "short_release", "subtype": 1 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:06.680849+00:00", "context": { "id": "a7e4b06ccd9ce649ec69725e4b3692da", "parent_id": null, "user_id": null } } Event 13 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "240bdbc5-3f43-4b17-8355-3c4db8afe507", "type": "initial_press", "subtype": 1 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:05.680368+00:00", "context": { "id": "cf72d54f5ac99394ded886f95a30c1a5", "parent_id": null, "user_id": null } } Event 12 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "55f33d1d-65eb-4aee-acef-ec5b815c7736", "type": "short_release", "subtype": 3 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:05.676754+00:00", "context": { "id": "6578f897daa69de404b61c5de93d5b11", "parent_id": null, "user_id": null } } Event 11 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "55f33d1d-65eb-4aee-acef-ec5b815c7736", "type": "initial_press", "subtype": 3 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:04.664564+00:00", "context": { "id": "5965ccf9ce4f939a38e7815989e8542d", "parent_id": null, "user_id": null } } Event 10 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "55f33d1d-65eb-4aee-acef-ec5b815c7736", "type": "short_release", "subtype": 3 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:03.620788+00:00", "context": { "id": "2caa4d5c759a4eb052fed44a59536ece", "parent_id": null, "user_id": null } } Event 9 fired 12:17: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "55f33d1d-65eb-4aee-acef-ec5b815c7736", "type": "initial_press", "subtype": 3 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:17:01.428703+00:00", "context": { "id": "a0d7914585ebef6463497d93f8ec0809", "parent_id": null, "user_id": null } } Event 8 fired 12:16: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "240bdbc5-3f43-4b17-8355-3c4db8afe507", "type": "short_release", "subtype": 1 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:16:59.235628+00:00", "context": { "id": "0cc06b22e540068bd1d5e3e8f44a567f", "parent_id": null, "user_id": null } } Event 7 fired 12:16: { "event_type": "hue_event", "data": { "id": "keukenpationikoschakelaar_button", "device_id": "59137cad4fec3b2ed438c0c53fe699bb", "unique_id": "240bdbc5-3f43-4b17-8355-3c4db8afe507", "type": "initial_press", "subtype": 1 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:16:53.115686+00:00", "context": { "id": "b188e5ca61f53e517ceb8030c4c842f8", "parent_id": null, "user_id": null } } Event 6 fired 12:16: { "event_type": "hue_event", "data": { "id": "nachthalnikoschakelaar_button", "device_id": "c33d3441823827b7d789c7ee4fd2bed9", "unique_id": "f64674b7-f2e4-4db5-bf76-2b9f1ade5d87", "type": "short_release", "subtype": 4 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:16:17.393017+00:00", "context": { "id": "e07fb51c1f78463026744ebc8d632174", "parent_id": null, "user_id": null } } Event 5 fired 12:16: { "event_type": "hue_event", "data": { "id": "nachthalnikoschakelaar_button", "device_id": "c33d3441823827b7d789c7ee4fd2bed9", "unique_id": "f64674b7-f2e4-4db5-bf76-2b9f1ade5d87", "type": "initial_press", "subtype": 4 }, "origin": "LOCAL", "time_fired": "2021-12-13T11:16:16.380106+00:00", "context": { "id": "75ab319edfd76694c72d6d71d2ca7afc", "parent_id": null, "user_id": null } }

[marcelveldt]

anything in the HA logs that might be related ?

[8OND007]

nope, nothing related in the logs. sorry Marcel. Maybe some else also noticed this problem.

Just as I was thinking about removing my Hue Bridge all the way and adding all my Hue stuff to my already running Zigbee2MQTT with the new Sonoff Zigbee 2.0 stick. In Zigbee2MQTT these switches should work on all events. So if the new Hue Integration does not work in the end I can still switch all to Zigbee2MQTT.

[marcelveldt]

For sensors, remotes etc. a separate zigbee stick is the better choice. For lights and scenes, stick with the Hue bridge. Why not use both ? They can happily coexist.

That said, I'll do some debugging later today with a few remotes I have lying around here to see if I can spot something.

[henneaux]

same issue/challenge with Friends of Hue switch from Busch-Jaeger, in previous versions hue_event would fire on 101 (double up) and 99 (double down) for this switch. maybe this helps for debugging, good luck and thanks!

[marcelveldt]

I've been debugging this one today with another user and we noticed that these events do not get emitted anymore for these (Friend of Hue) devices. Not at all. Only the initial_press and short_release events were emitted, nothing else.

Is one of you able to help out with further debugging ? You may contact me on discord if you want.

If someone is able to temporary revert to 2021.11 from backup it would be interesting to know if the events still work there.

[8OND007]

indeed they do not get emitted anymore.

After initial upgrade to 2021.12.0 and a reboot, they worked shortly (very good even for long press release event, better than in 2021.11.0, it looked more accurate in timing), but then died completely.

I first noticed these events were gone on my device nodes in NodeRED. Where used to be the device name of my Niko Switch was now my SamsungTV device. I had to change it back to the right device name of the Switch and select again the right event. What I also noticed there in the device node popup (nodered) was that the event text changed different times on each opening of the popup. First it was a textual full text, but then it was shorter text with _xx numbers. Each time when opening the device node visualisation of event text changed. This morning I tried the 2021.12.1 and this did not fix anymore related to this problem. Also the "flash" does not work anymore, but I found that in an already mention issue on github, it is not available anymore with API2.0. So I guess I have to make the lights flash with some manual automation code or Node RED logic.

hennaux's Friends of Hue switch from Busch-Jaeger is probably the same rebranded switch I think. Under the hood it's all a EnOcean PTM 215Z batteryless switch.

I did not make a backup of my previous 2021.11 core, so I can't help you there, sorry.

I read on the Zigbee2MQTT device list site, these green devices are very specific:

"This is a Zigbee Green Power device which allows it to be very energy efficient. Messages from Green Power devices cannot be "understood" by normal Zigbee devices, therefore they need to be "translated" first. Not all Zigbee devices can do this translation, currently the only devices known to do this are Philips Hue devices. This means that the Green Power device has to be in range of a Philips Hue device in order to use it." "Green Power devices don't support binding and are not included in network scans"

Their events can only be translated by a nearby Philips Hue device. Maybe something change between API1.0 and API2.0. It's a V2 Hue Bridge i use.

Reason i'm thinking of switching completely to Zigbee2MQTT is to make my SonOff zigbee dongle zigbee (channel 11) network stronger by migration my Hue devices (now on Hue hub on channel 15) also to Sonoff zigbee channel 11. My Zigbee dongle is not in center of my house, but in garage (in one corner of my home). Previously I used a tasmotized SonOff zigbee bridge with was located in center (wifi). My new Sonoff dongle has less range than the Sonoff zigbee bridge. So I was thinking about using my Hue bulbs als repeaters for my Sonoff zigbee dongle network. (zigbee2mqtt). I don't really use the Hue App with scenes etc..... but it seems indeed a better choice of choosing scenes and colors with the original Hue App. And indeed you are right they can coexist like i'm using now. I did have to move my 2.4 Wifi channel away from overlapping zigbee channels 11 & 15 to avoid Wifi interference from Zigbee.

[marcelveldt]

I suspect that the events are even not emitted on the previous V1 api/integration. We'll have to wait until someone confirms that can temporary revert to 2021.11 to test but I think this is a hardware/firmware/bridge issue and not related to the V2 API move.

[henneaux]

I can't revert to 2021.11 either. it is indeed an EnOcean PTM 215Z batteryless switch under the hood

below hue api response v1 (the double down press gives back button event: 99)

{ "state": { "buttonevent": 99, "lastupdated": "2021-12-13T16:14:39" }, "swupdate": { "state": "notupdatable", "lastinstall": null }, "config": { "on": true }, "name": "hue_bathroom_switch", "type": "ZGPSwitch", "modelid": "FOHSWITCH", "manufacturername": "PhilipsFoH", "productname": "Friends of Hue Switch", "diversityid": "ded6468f-6b26-4a75-9582-f2b52d36a5a3", "uniqueid": "00:00:00:00:01:70:b4:a5-f2", "capabilities": { "certified": true, "primary": true, "inputs": [ { "repeatintervals": [], "events": [ { "buttonevent": 16, "eventtype": "initial_press" }, { "buttonevent": 20, "eventtype": "short_release" } ] }, { "repeatintervals": [], "events": [ { "buttonevent": 17, "eventtype": "initial_press" }, { "buttonevent": 21, "eventtype": "short_release" } ] }, { "repeatintervals": [], "events": [ { "buttonevent": 19, "eventtype": "initial_press" }, { "buttonevent": 23, "eventtype": "short_release" } ] }, { "repeatintervals": [], "events": [ { "buttonevent": 18, "eventtype": "initial_press" }, { "buttonevent": 22, "eventtype": "short_release" } ] } ] } }

and just tried the v2 api but I don't really know where to look, used this endpoint: /clip/v2/resource/device/7cb7bed5-728b-491b-8e64-93534ed910dc

{ "errors": [], "data": [ { "id": "7cb7bed5-728b-491b-8e64-93534ed910dc", "id_v1": "/sensors/7", "metadata": { "archetype": "unknown_archetype", "name": "hue_bathroom_switch" }, "product_data": { "certified": true, "manufacturer_name": "PhilipsFoH", "model_id": "FOHSWITCH", "product_archetype": "unknown_archetype", "product_name": "Friends of Hue Switch", "software_version": "0.0.0" }, "services": [ { "rid": "57aff9c6-653e-4d18-859d-64548b7ebdd9", "rtype": "button" }, { "rid": "5c3f5937-ebda-4fb6-bced-dcca6b498d23", "rtype": "button" }, { "rid": "300c09b2-cd6a-4533-9d65-75e88e326633", "rtype": "button" }, { "rid": "89110285-1323-4e9f-9c2f-1a18e6911bc6", "rtype": "button" }, { "rid": "4416c28e-fc60-4751-8b14-81359500571f", "rtype": "zgp_connectivity" } ], "type": "device" } ] }

[marcelveldt]

@henneaux Your snippet from the V1 bridge response confirms it: The only event types reported as supported are "initial_press" and "short_release".

So this means that this is actually a Hue issue, maybe a bridge or firmware update broke it.

This explains why it did actually work for some shortly on the new integration, it broke shortly after. Let's hope Signify (or the button manufacturer) fixes the issue.

[henneaux]

Yes true, but in the v1 api (not bridge) although it is not supported, the button event 99 is registered (see first state attribute). This button event I used in automations in 2021.11 and before.

In the v2 api this is not the case. I subscribed to the /eventstream/clip/v2 and no message for the double down/up presses.

Too bad :(

[marcelveldt]

Hmmm, if 99 is still registered something is still working under the hoods so maybe this is just a small temporary glitch

[albanco]

For info, my experience with another FoH button: Feller FoH.

• Double button press events are not emitted anymore
• Released after long press and button held down events are not emitted anymore
• All the above events were emitted until I migrated from 2021.11.3 to 2021.12.1 this evening

Looks like it's impacting several (if not all) FoH switches.

[marcelveldt]

I think its best if we create an issue on the Hue developers forum. I'll do that tomorrow. It might have more impact if a few people reply to that topic to show there's a need for a solution. No idea if it will work but who knows.

[Radon-X]

For info, my experience with another FoH button: Feller FoH.

* _Double button press_ events are not emitted anymore

* _Released after long press_ and _button held down_ events are not emitted anymore

* All the above events were emitted until I migrated from 2021.11.3 to 2021.12.1 this evening

Looks like it's impacting several (if not all) FoH switches.

Also info from my site: All the same for me with upgrade from 2021.11.5 to 2021.12.1 and Feller FoH

I restored now back to 2021.11.5 and it's working again. If some info is needed, let me know.

[marcelveldt]

It still works in 2021.11 because that is still polling the bridge so the raw value is detected for existing setups. The inputs object is however missing the available button events for the remote and my guess this is also why the events are not sent at all on V2 eventstream.

A temporary hack/workaround I can think of is to poll the bridge for 5 seconds after a "initial_press" event is received, just to catch the following (now missing) double/hold events but this is really awful and a last resort.

I'm going to contact Signify if they can provide a solution.

[EddyK69]

I can confirm that it's also not working anymore for Scenic/Gira FOH switches...

[marcelveldt]

Contacted Signify. Now let's hope for a quick response. In the meanwhile I'll start thinking about a temporary solution.

[8OND007]

Here's some more interesting haunting info :

The trigger view is different an a NodeRED device node, on the left it has a short notice, on the right a longer textual notice. It does change sometimes out of nowhere.

Further the left device trigger is triggered sometime without pushing/releasing the physical buttons on the switch (at night for example), I noticed this at night several times because I added a push phone notification the to device trigger. Trigger cause is then "Button released after short press" while everybody at home was sleeping at night :

"4' short release is triggered while not pressed/released.

[8OND007]

I've enabled debug log for Hue in HA because i'm getting a lot of Hue errors in the logs, for ex: hue HA core log.txt

AttributeError: 'NoneType' object has no attribute 'last_event'

another user already noted this random Hue_Events false triggering on https://github.com/home-assistant/core/issues/62289#issue-1083957603

maybe my attached log gives more info on this issue.

If I analyse the log myself I see different times the Hue Bridge is reconnecting (while it is hard wired LAN). Further I see false buttons events during the night (both initial_press & short_release) while nobody touched these buttons during the night.

[elmigbot]

I think its best if we create an issue on the Hue developers forum. I'll do that tomorrow. It might have more impact if a few people reply to that topic to show there's a need for a solution. No idea if it will work but who knows.

Hello, I looked around for your issue at Hue Dev Forum but could not find it. Do you have a link, so I can chime in for more impact?

[marcelveldt]

@8OND007 the issue with the false triggering remotes on reconnect is fixed today, should be in the 2021.12.4 release.

@elmigbot I've contacted them by email as the forums did not look very responsive. It appears the same applies to email ;-) I'll also post the same message on their forums.

BTW: I ordered one of those remotes myself to test and I can indeed see the same behavior. Most interesting is that the official Hue app also not allows those additional triggers so my best guess is that they removed it completely from the device support.

[elmigbot]

Yeah, the Hue app never supported the double button click. I only discovered it because sometimes a single button press, will emit a double button event code. (Using the hue app, this is felt as an unproductive button press.)

But, the app still does support long presses, so hopefully at least that comes back.

[mvdwetering]

I am a bit surprised by the events that are expected for Tap / Friends of Hue switches.

The hue bridge never had repeat or long_release events for Friend of Hue switches and Tap (Tap also does not have short_release). These devices simply can not generate those events. This can also be observed from the "capabilities" object on the sensors in the v1 API (capabilities is not available on v2 API). If there were other events in HA previously then something was emulating those events.

For reference this is the list of events per device type:

• Tap supports only initial_press.
• Friends of Hue switches support initial_press and short_release
• Wallswitch module in rocker mode supports initial_press and short_release I think. Not 100% sure, but don't want to change it in my setup to test.
• The rest (Dimmerswitch v1/v2, Smartbutton, Lutron Aurora and Wallswitch module in pulse mode) support initial_press, short_release, repeat and long_release

[elmigbot]

Yep! The FOH do not list the double press events in the capabilities. They are as follows though:

        100: "double_upper_press",
        101: "double_upper_release",
        98: "double_lower_press",
        99: "double_lower_release",

As far as the long pressing goes... Its true only the initial_press and short_release exist. I was only trying to say the app uses long presses for dimming, etc. It must use the ongoing time between press and release to determine its being held down.

[8OND007]

I had it with the Philips Hue bridge and new Api 2.0. The old Api 1.0 worked at least. Looking at Philips dev forum, I don't see a lot of info on it. I understand that Marcel is not to be blamed for this, it's simply not available anymore in Hue Bridge Api2.0.

It's clear to me now that for Friends of Hue (aka EnOcean PTM_215Z) only the following zigbee trigger actions are available out of the powerless remote: press_1, release_1, press_2, release_2, press_3, release_3, press_4, release_4, press_1_and_3, release_1_and_3, press_2_and_4, release_2_and_4, press_energy_bar (so double upper/lower press/release in hard available in the EnOcean and to Zigbee2MQTT).

The HUE Bridge did some tricks on Api 1.0 where the bridge counted the time between press and release to "emulate" a long press event (release). I used this long press event (Api1.0) to also toggle 2 Tasmotized lights (Sonoff). Next to this HA automation I also used the HUE App (bridge logic) to

• link left up/down with a group 2 HUE lights (Patio)
• link right up/down with a group 2 HUE light (living room). So 4 lights in total.

But: It's a pity you can't use/define in the HUE App each of the four buttons (Friends of Hue Remote aka EnOcean PTM_215Z) seperate to toggle a light/light group. HUE only allows a ON action to a button and an OFF action to a different button. With other words you always "loose" 2 button (out of 4) to turn on/off a light)

That's the reason I used this long press event which was available in Api1.0 (and HA integration), but seems to be ditched completely with the new Api2.0 (and HA Integration).

Because my whole setup is now useless and the wife/kid is freaking out, I decided to "ditch" the complete HUE Bridge. I don't use all the fancy light color scenes etc really. I migrated almost all my non color lights & already 1 Friend of Hue remote (Niko) to Zigbee2MQTT. (for ease, strenghten my existing small Sonoff Zigbee 2.0 USB stick running Zigbee2MQTT).

After some (un)pairing from Hue bridge to Zigbee2MQTT (thanks to https://www.zigbee2mqtt.io/devices/PTM_215Z.html and https://zigbee.blakadder.com/Philips_LWB010.html) everthing seem to work now. The main advantage with my 4 button remotes is I can now program (for ex. in Node RED or HA Automation) to Toggle a light with a single button. Hell yeah :-) So I dropped the old long press/release logic because I can now do 2x more stuff with single press on each button to turn on/off lights.

In future I'll also need to do some NodeRed timing logic to count how long it takes between initial press and release to make my own "long press" event in Node RED (for example to dim UP/DOWN lights like the default function in the HUE bridge App. As elmigbot suggests in his previous reply. Dimming is not possible now anymore (I lost this functionality because diming with "long press" was in HUE bridge logic running Api1.0 AND also on Api2.0). Maybe I can use a single button long press now to dynamically DIM UP/DOWN in function of where the brightness was before.

tomorrow I'll migrate my second and last Friends of Hue 4-button remote to Zigbee2MQTT.

If I look at my HUE light bulbs integrated on Zigbee2MQTT, I now have new/more effects: blink/breathe/okay/channel_change/finish_effect/stop_effect. So I can use the blink/breathe effect again like on Api1.0, but what was also ditched with Hue Api2.0. A second win-win.

Button presses are now instantly available as event/data in MQTT and HA. Faster than before.

And last I now hope to have a more strenght zigbee network (Stick channel) and can ditch the Hue Bridge (seperate channel) completely.

Ooooh the zigbee :-D

[henneaux]

I actually like the fall back/contingency that the Hue bridge offers in my setup, it is really stable! The API v1 is still working, and since you mentioned NodeRED, would it not have been easier to use the Hue Magic node? This still triggers on the 100/101 and 98/99 presses (msg.payload.buttonAlt).

Plus, I think listening to the API v2 eventstream instead of polling the bridge is the way forward (but I am not a dev...) By the way, the ghost clicks have been fixed in 2021.12.4, at least the error (AttributeError: 'NoneType' object has no attribute 'last_event') has not shown today 👍 Thanks Marcel 🥇

[Radon-X]

What do you mean with "I like the fall back" and "API v1 is still working"? In my case, HA 2021.11.x use API v1 and is working and I need the double upper/lower press/release. With 2021.12.x is only API v2 used and there are no event at all for a double press. If there are two events, I'm able to handle it, but not without any event.

Sure it is possible to buy another Zigbee-Bridge witch support Zigbee2MQTT but it is not a solution for me. And the NodeRED Hue Magic Node can be a workaround, but will API v1 also be disabled at some point like in HA? And it makes a new connection for the Hue Bridge. I guess this makes it "slower" because of two connection partners.

Somethink like a "Fallback" from API v2 to v1 in HA would be nice or a possibility to choose (short term). But best solution would be if the bridge API v2 can provide double upper/lower press/release or at least both of the events, I'm sure the bridge get something different from the FOH Buttons otherwise it would already provide both events (right and left).

[JPDeckers]

The HUE Bridge did some tricks on Api 1.0 where the bridge counted the time between press and release to "emulate" a long press event (release).

The EnOcean always only fired an event on press and one on release. Just enough energy generated by your finger, hence no battery needed in the device. Looking at the implemented rules of the v1 api on the bridge for a FoH switch, with some state management and a 1 second delay between press and release cutoff they implemented/faked the hold for brightness increase/drop (4 second timed increment to full brightness, cut off on release).

The V2 api does simply not fire these hold events.

I had it with the Philips Hue bridge and new Api 2.0. The old Api 1.0 worked at least. Looking at Philips dev forum, I don't see a lot of info on it. I understand that Marcel is not to be blamed for this, it's simply not available anymore in Hue Bridge Api2.0.

I cannot imagine them dropping the hold on the FoH buttons, this is basically essential use and would break all existing Hue app implementations. The v2 implementation is simply not completed yet, as they state on the developer site: "V2 API is currently in early access and not yet feature complete"

They however also state that the rule engine (what implemented the custom hold) is currently not available on V2. The alternative does also not allow 3rd party definitions. See https://developers.meethue.com/develop/hue-api-v2/migration-guide-to-the-new-hue-api/#Rule%20engine

So I hope Signify will add the hold soon as an implemented behavior script, but maybe, just maybe, they'll drop it and we'll have to implement it ourself...

[marcelveldt]

I've ordered one of these switches myself so I'll see if I can implement the hold now myself. Basically its just firing repeat events until released....

[henneaux]

What do you mean with "I like the fall back" and "API v1 is still working"? In my case, HA 2021.11.x use API v1 and is working and I need the double upper/lower press/release. With 2021.12.x is only API v2 used and there are no event at all for a double press. If there are two events, I'm able to handle it, but not without any event.

I mean with fall back that my lights and switches (connected to the Hue bridge) work independent from my homeassistant instance. so, in the case my 'server' goes down, my lights still work. The Hue bridge still supports both API v1 and v2, and for now I only run the specific presses through NodeRED (via Hue Magic node through API v1). I agree not convenient, I guess more polling than necessary... Just a (low effort) workaround.

[marcelveldt]

@henneaux be aware that anything still accessing the v1 API with polling will really hurt performance of your bridge and even HA can suffer from that. Today we've been testing a lot and discovered that the bridge can handle about 2 requests within 250ms. So if those requests are given away by something that is "hammering" the bridge with polling, you will notice this performance wise in both your Hue lights responsiveness and the HA integration...

And yes, setting the button automations in Hue app directly is the best solution if you're actually controlling Hue lights. The remotes even work when HA is down.

[chrismanivong]

Here is a little work around as an automation to get back long press:

https://github.com/krys1976/HA-HUE-FOH-LongPressRelease/blob/main/package-automation-foh-lp.yaml

[marcelveldt]

We've implemented a (temporary) workaround in the aiohue library. As of 2021.12.7 there will now be long press and hold events emitted for FOH switches.

[Johnr24]

Hello, Is there any update on the status of double buttons, my home assistant is being kept on 11.5 for now as the double button function is key to how I use these switches

[marcelveldt]

Hello, Is there any update on the status of double buttons, my home assistant is being kept on 11.5 for now as the double button function is key to how I use these switches

We'll have to wait for Signify because they seem to have dropped that completely. The's no event (at all) when both buttons are held down.

[Johnr24]

Hello, Is there any update on the status of double buttons, my home assistant is being kept on 11.5 for now as the double button function is key to how I use these switches

We'll have to wait for Signify because they seem to have dropped that completely. The's no event (at all) when both buttons are held down.

Is there anyway it could be cheated? or no?