Hue FoH switches not longer fire long press

mija87 commented 3 months ago

The problem

If I long press a button of my FoH Gira switch, it not fired as a long press, but as a "first press". A short press still fired as a "short press". If I lissen to Hue Events, it gives me a long press but HA not showing as a long press.

What version of Home Assistant Core has the issue?

2024.6.3

What was the last working version of Home Assistant Core?

2024.5.X

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/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 3 months ago

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!

Code owner commands

Code owners of `hue` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign hue` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

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

thephantom commented 3 months ago

same problem here :(

KHV8 commented 3 months ago

Here are some details on the problem. The main part is that

EDIT: After 2024.07.4 the events are also not correct. Hence, this post is not showing correct issue/problem, as this is changed. This lead to the possibility that the problem is not HA related, however related to a change in 2024.07.4 in the relase notes "Bump aiohue to version 4.7.2 "

The "Hue_event" does show up correctly. A long press give the right events in the developertool events. Like below

Initial press
Repeat
Repeat
Short_release
Long_release

This is not what is passed on to the automation in the variables. Here it shows as a

Initial_press
Initial_press
Initial_press
Short_release

I can reproduce this every time.

The file "events" show a print of the developertools eventpage events.pdf

The files "trace..." shows the traces from the automation, same buttom press cycle. trace automation.sovevaerelse_test_hue_kontakt 2024-07-06T07_54_29.083501+00_00.json trace automation.sovevaerelse_test_hue_kontakt 2024-07-06T07_54_29.587199+00_00.json trace automation.sovevaerelse_test_hue_kontakt 2024-07-06T07_54_30.092727+00_00.json trace automation.sovevaerelse_test_hue_kontakt 2024-07-06T07_54_30.435581+00_00.json

Here is the test automation, just to keep it simple. The full blueprint does have a lot of other stuff and triggers on all 4 buttons. However to keep it simple I reproduced in this simple automation.

`alias: 0 Test FoH Switch worng state description: "" trigger:

platform: state entity_id:
- event.sovevaerelse_kontakt_button_4 action:
variables: switch_to_state: "{{ trigger.to_state.attributes.event_type }}" switch_from_state: "{{ trigger.from_state.attributes.event_type }}"
choose:
- conditions:
  - condition: template value_template: "{{ switch_to_state == 'initial_press' }}" sequence: []
- conditions:
  - condition: template value_template: "{{ switch_to_state == 'repeat' }}" sequence: []
- conditions:
  - condition: template value_template: "{{ switch_to_state == 'long_release' }}" sequence: []
- conditions:
  - condition: template value_template: "{{ switch_to_state == 'short_release' }}" sequence: [] mode: queued max: 10`

KHV8 commented 2 months ago

Here is a link to the blueprint for the FoH switches. A number of people using it.

mija87 commented 2 months ago

Thanks, but the issue is also with the blueprint (I use the blueprint already)

KHV8 commented 2 months ago

Yes, the blueprint have the same error as if you do an automation. It relies on the same events.

KHV8 commented 2 months ago

mija87, can you tag this issue as an "error" or "bug". As of now it does not show "error". Not sure how to do this in Guthub,

thephantom commented 2 months ago

is there an solution?

KHV8 commented 2 months ago

@balloob, @marcelveldt, we are a number of people using the FoH switches. The switches have started to deliver wrong states. I’m into testing and checking, can change the blueprint used, however as it looks like it is the integration, then I do not have the knowledge to solve it my self. Hope you will get some time to help out.

marcelveldt commented 2 months ago

@KHV8 Not cool to start pinging people, especially in holiday season. This will get looked at in due course but atm nobody has time available to look at this due to other priorities and holidays. Feel free to fix it whoever wants to and I'll review the PR. Otherwise this will get looked at in 3 weeks.

Hofferic commented 2 months ago

@KHV8 looking at the event log it may be possible to rebuild the blueprint using the FoH switch device id (or a list when using multiple buttons) and listening to the hue_event directly, filtering for the seledted id(s). If it's possible to somehow make the device selecable in a blueprint (I haven't done much in the way of blueprints yet) this might even simplify the blueprint setup because the four buttons don't need to be set up seperately. On the other hand it would require any users not willing to wait for a fix to the integration to re-create their automations.

KHV8 commented 2 months ago

I will try and do an automation based on deviceID to see/test if the events will be correct. If so, the blueprint can be changed. Not sure as the hue_event is already what is used. As I’m in transport this will first be Sunday.

KHV8 commented 2 months ago

@marcelveldt, sorry.

KHV8 commented 2 months ago

Have made some test using the deviceID as trigger. I get the same behavior, only receive "initial_press" and "short_release"

rpzxc commented 2 months ago

@KHV8 @Hofferic Niko Friends of Hue switches, got the same issue yesterday.

I have tried the following:

Restoring the HA to the previous core backup
Re-adding the hue hubs to HA
Re-adding the switches to Hue app
Restoring the last working backup

What I think might have triggered the issue (might been a coincidence too): I installed the CobBee 2 dongle yesterday- but did not do anything with it in relation to Hue (however I have clicked that it joins existing network I think)

Not sure how I can restore this functionality to work. It makes my house unusable, I have around 12 of those switches.

The switches are normally recognized in HA with correct actions but they do not recognize correct actions when pressed.

rpzxc commented 2 months ago

For anybody looking for a workaround, please find below:

Disclaimer: This is ugly and I would prefer a normal long press working. Can this be done differently? Sure Can it be done better? Probably Does it work? Yes

For each long press you need the following: Helper counter 3 automations.

For short press: Button automation: Button release after short press, condition counter below 3, execute action

For long press: Button automation: When helper counter is above 3, execute action

Counter reset automation: Button release after short press, delay 1s, action: reset helper counter

Counter increase: Button press initially, action: increase helper counter by 1.

lajuffermans commented 2 months ago

Same issue here since 2024.7.x

They did update aiohue in this release, isn't it related perhaps?

rpzxc commented 2 months ago

It’s interesting - it mentions in 4.6.2 from Feb “Add missing LONG_PRESS enum member for button events”

I had it working for at least 2 years

kp-bit commented 2 months ago

It’s interesting - it mentions in 4.6.2 from Feb “Add missing LONG_PRESS enum member for button events”

I had it working for at least 2 years

Same here, noticed it didn't work anymore after I came home from vacation and updated HA...

Asom-Velz commented 1 month ago

Same issue here since 2024.7.4 it was working till 2024.7.3 HUE FoH switches stop reporting the button press event_type correvtly. button - event_types: initial_press, repeat, short_release, long_press, long_release are broken and not reporting correctly anymore.

rpzxc commented 1 month ago

Did 2024.8 fixed an issue for anyone?

KHV8 commented 1 month ago

No change in 2024.8.0

Asom-Velz commented 1 month ago

The FoH switches problem is still valid with 2024.8.0 - just tested and revert back to 2024.7.3

wolfgangd4711 commented 1 month ago

Unfortunately same issue here. Not working in 2024.8.0

niteguide commented 1 month ago

I upgraded to Core 2024.8.1 and Supervisor 2024.08.0 and now also have this problem! I hope this gets resolved soon - makes switches kind of useless for some scenarios!

rpzxc commented 1 month ago

Dear all, please refer to https://github.com/home-assistant/core/issues/123282#issuecomment-2284705377 for hopefully good news.

RWSF74 commented 1 month ago

Same issue here, still not working in 2024.8.1. Would be nice if it gets fixed soon (4 Niko FoH switches less usefull atm), thanks in advance! For now I dusted of the good old Hue app, there's more possibilities there right now.

home-assistant / core