That part is confusing me. Last time I checked the Hue Smart Button was not supported by the official integration, which was the reason to start using this integration in the first place. If this has changed, I’m unable to find any information about it.
This part is about the hue sensor integration, (not about the new separated hue remote integration). So what you need (hue remote) is not part of the official integration.
If you only use remote entities you should be save to remove the hue sensor integration, replace it by the hue remote integration and everything should be fine.
1 Like
next HA will have the switches integrated (tap switch and dimmer switch, not sure about FOH or smart button though)
1 Like
Ok, so after updating to 0.108 the hue remote custom component won’t be needed any more (for the devices you mentioned).
I guess there will be doubled entities if we update without removing the component before. Am I right? What’s the right way to update without having double entities after it. Also it would be interesting I the official integration generates the same entity names (so that all automations still work).
no, the automation will not work, because the remotes won’t be the same (hue ‘remotes’ dont act like true HA remotes, they probably will become sensors again…), and use a different approach for the events.
check: https://github.com/home-assistant/core/pull/33277
and https://github.com/home-assistant/core/pull/33476
didn’t checkup on this the last couple of changes, so please read, and see what the update will bring 
(I’ll hold on to the CC for a while, because core Hue entities go unavailable too often to be reliable for automations and other logic in my setup)
1 Like
That’s how I got my Philips friend of hue wallswitch (Feller) running. The following functions work perfectly:
- on/off on the same button
- on/off same device on different wallswitch
- use 12 different trigger on 4 buttons
- 4 release (short push)
- 4 press (long push)
- both upper button together (release + press)
- both lower button together (release + press)
- the press and release trigger will not double triggering, by using just the press
Hey guys,
I’ve seen this question been asked multiple times but haven’t found an answer yet.
How can we trigger automations based on double or triple button presses on dimmer switch?
Thank you
update on this:
core Hue devices (not entities) for remotes are now available. Events are registered, and can be used for the automations (note that the polling frequency is not immediate, but 1-5 seconds)
you can bring the events to the frontend using @azogue 's CC Eventsensor:
he even made a CC to up the polling frequency if you must (do at your own risk, since this sets the core Hue updating to a higher frequency that adviced by Balloob/Core dev team.)
1 Like
You have to remove to and from from the state trigger and then use state as a condition instead. For double press you can compare current state to previous state to see if they’re the same. Triple press would be a lot more difficult - you’d probably have to create an entity to store intermediate press states for each switch, or use Appdaemon or NodeRed.
One thing to note is that because only events are fired and no entity is created nothing is updated in the state machine and therefore there’s no way to compare current state to previous state - this is especially important with the kinetic switches where there is no hold state; you get a press state and release state and you need to compare the time difference between the two to filter between a quick press and a hold.
you can use the eventsensor I mentioned, which does create these in the state machine:
though keeping in mind the timing architecture HA core is using.This only records releases (I think).
If you need spot on timing using the Hue switches, you should move to something like Deconz, which pushes the events to HA when they happen
So does this mean in order to use the core hue devices we will need the custom component you mentioned above?
Currently I use the custom component discussed in this thread (hue remotes advanced).
@Mariusthvdb What are the pros and cons of both options? I currently don’t understand why moving from one option to the other one would make sense. In the end I would be using a custom component in both cases, right?
Thanks in advance.
my opinion: best to use core software. simply because of the support of the core dev’s.
If core doesn’t offer certain functionality, use CC.
in this case, Hue remotes, we now have some remote functionality in core (devices and events) and have the new CC for eventsensor to bring that to states/frontend. Albeit in default slower polling frequency than the CC for hueremote. So, you might miss a possible quick push here and there, and only have release events, not push events.
so, yes, you’d be using a CC either way, unless going with the deconz, which is Core, or using the current events for the remotes, which are core also. Id first try that, and change to either there option depending on your needs…
hope this helps
If you really need those, you should either use the hueremote CC. Or, if you really ask me, use the Hue app. which is faultless.
Of course, if you need the remotes to control other things than lights, you can either up the frequency with the other new CC I pointed to, knowing you interfere with core HA.
Or as others have said, use a pushing device like the deconz. But then you need to take the remote out of the Hue ecosystem.
2 Likes
Hi there.
I use HassOS 3.13, Home Assistant 0.108.6. I use a Hue Bridge v2 with latest firmware.
Digging through the various sources, it seems that the built-in Hue support is almost great. I have multiples Hue Dimmer switches, as well as multiple Senic Friends of Hue switches (https://www.senic.com/friends-of-hue-smart-switch)
I was able to create a Automation that uses the Dimmer Switch and the built-in Hue support. (Yeah! 
)
However I fail to create Automations for the Friends of Hue switches. Using the built-in support, the UI gives me " There are no automations available for this device. "
Going further: So I installed Hue-remotes-HASS (https://github.com/robmarkcole/Hue-remotes-HASS) and enabled it as described in the README. Now the remotes and switches are found twice: 1) in the Entities list with Integration “hueremote” and 2) in the Devices list with integration “Philips Hue”
Any advice, what I am missing? How to enable triggers for the FoH switches?
Best,
Jens
You might want to check the GitHub, as I think an addition to the core Hue integration is in the works for the FOH remotes. Not sure if these are the same as yours, but please check.
The Hue_remotes_hass imho has always been a wrong turn, since it creates entities of the domain ‘remote’ (and with a toggle that doesnt do anything) while they should have been sensors for the events they recorded. As they used to do before the move to ‘remote’.
You can still use that older CC, but beware it does interfere with the Hub more than is expressed to be desirable (once per 0.5 seconds, though you can lower that in the CC easily). Hammering the Hub, as it was called…
So, best would be to check if your switches are among the shorty supported ones, and if not, file a FR to add them.
(Meanwhile you could carefully install the CC remotes, and ignore the double entries, since they are not of the same domain anyways)
Thanks a lot for your quick reply. I will check GitHub an see if I where is a place to add my Senic FoH switches.
How would I go about this? It seems that the things listed in “remote” are pretty useless. How to add a button press on a “remote” as a trigger in a automation?
that’s rather easily done tbh, depending on the path you choose. With the current core devices, you can create an automation via the GUI, or if you are up to it, use the eventsensor by @azogue, he lists a few automations in his GitHub repo.
for the CC hueremotes it is about the same, since that creates states and attributes for the remote you can use as trigger. It does so for all presses and releases, while the eventsensor and core only do so for releases (because of the timing mentioned before, making only the releases reliable to trigger from)
It looks like the Friends of Hue Switches (reported as FOHSWITCH) in the iOS App were added 3 days ago with this commit. https://github.com/home-assistant/core/commit/5dcac36b78cf69b83955c4068016c371a5273008
Given the fast pace of releases in the last week, I will wait for 0.108.7 to be released which will hopefully include the support. Thanks a lot Marius!
I am running latest Hue remotes advanced CC on 0.109.5 that is installed via HACS. Now that this CC is ”archieved” I am trying to uninstall it via HACS but no luck. Can’t reinstall CC either. On HACS I get info saying archieved and unable to install/uninstall. I also tried to delete the CC folder and configuration.yaml but this doesn’t disappear from HACS. Any ideas how to uninstall this?
Same here. Unable to uninstall. Manually deleted all files in the CC folder but still cannot delete the folder as it says it’s not empty (no files displayed, however). In one of the several attempts to uninstall via HACS, there was a message that uninstall was not allowed while background processes were ongoing. 
Not possible to open an issue on the remotes repository so flagging in HACS may be the only remaining option.
Same here. I also deleted the folder and files. Did a restart and HACS complained that HueRemote was missing.
I started a topic the other day asking about it not seeing this one. Still no answers yet.