165 posts / 0 new
Last post
Dean Roddey
Reacting to tap switches

Though, for the average user, it's nice to be able to set up rules within the Hue and trigger them with a tap switch (or I presume that's how it works.) For customers of automation system produtcs like ours (www.charmedquark.com), there is much more interest in allowing the automation system to react to such things. Most all lighting systems support this kind of things for switches that aren't controlling an actual load directly, so that the user can use those switches to invoke actions within the automation system. The obvious reason for wanting to do that is that we can provide vastly broader control options, since we can control pretty much anything in the home.

It would be awfully nice if the Hue support some sort of async reporting mechanism, and could report such events. It would make the Hue system far more interesting to the automation world. We can currently control the Hue, and that's nice since it can be integrated into the user's automation solution. But going the other way would be very nice as well.

Obviously this raises some issues with a straight call/response interface. But you could have an option to maintain a persistent HTTP connection and send asynchronous HTTP responses for that kind of thing. As long as it's only enabled upon request from the control system, it would be backwards compatible.


Developers Support
Reacting to tap switches

Hi Dean

thank you for the suggestion. The main focus of the hue system is lighting control for which the current implemented call/response interface is adequate.

So we did not yet see the reason to trigger events external to the hue system.


Hue support


even for  lighting control

even for  lighting control the current api is not realy sufficient and adequate if the hue system is to be integrated into an overall home or building automation system. it is a pita to periodicaly poll the bridge only to be able to have the current status represented in the home automation system.

it would be so much better and resource preserving if the bridge would push status changes to an external system instead of requiring the polling aproach which just breaks down for two digit number of lights.


on top of this it would allow to use the tap switch as a trigger to more than just the hue lights.


I would like this feature also, was originally thinking of a HTTP callback feature for the sensors, but after reading this I can see uses for the same thing for switches.
Since the API is so easy to learn and use already, I find myself wanting to do more, sometimes you want to do more than turn on lights when you flip switch or trigger a sensor. Having another sensor just to do that seems redundant. (Since when is a lockin not a good idea?)

URL: /api/<username>/sensor/<id>

Method: PUT

Example body:

{ "callbackurls" : ['http://example.com/events'] }


then when sensor (or switch) is triggered the bridge sends the state to the callbackurls

this seems to be the simplest version of event handling that fits with the current API.


+1 for this feature.

Even for "own" (Philips-system) use cases: 
e.g. if you have a Tap-switch and a tablet with the hue-app - polling the light states is required at the moment.

For the protocol: Websockets could be a nice solution.

Just my 2 cents ;-)


Dean Roddey
Websockets would be fine. Or

Websockets would be fine. Or the ability to support persistent HTTP connections and to ask for async HTTP reports to be sent. Websockets would probably be the more likely supported two way scheme, whereas unsolicted HTTP msgs may be less likely to be supported. We do have some devices that do the latter and we can handle it fine. But those products that are using canned HTTP support libraries may not be able to deal wtih it, I'm not sure.

Of course either of those also optionally gets you encrypted communications support, which in this day and age is not a trivial matter. And you certainly don't want the overhead of TLS encryption when trying to do fast polling on a non-persistent connection.


Reacting to tap switches


I was a bit disaponted when I read the original answer to this question. I am working on the OpenNetHome home automation system, which already has integrated support for Philips Hue lights.

The Philips Hue API for rules specification allows you to specify a REST resource and a body to invoke as a result of a triggering a rule (such as pressing a button on a tap switch). Since OpenNetHome has a REST interface I assumed that it would be possible to specify an external REST resource to be invoked. As it turns out, the API gives an error: "Rule actions contain errors or multiple actions with the same resource address or an action on a unsupported resource"

I thought this was a bug in the API, but now I realize it is probably intentional. Could you please reconsider this? I think it would bring great value to the Tap-switches if they could also control other home automation functions and it would not even require any API changes. All you would have to do is to allow specification of external REST resources in rules.

Best regards

/Stefan, OpenNetHome

It's disappointing that we

It's disappointing that we are reduced to polling to get the state of hue lights.  This is something that one of Philips' competitors in this field (company starts with B, product starts with W) got right: they use UPnP for instant status reporting, which is a heavyweight but tested technology.  It works great.

The tap isn't available where I live, so it's academic, but I'm only going to buy home automation stuff that plays well in a federated system.  Polling is not playing well.

with the newly announced

with the newly announced sensors (motion, door/window, temp/humidity) it is even more important to have a push api. 

without such a connection to the outside (of hue) world there is a lock in that will make these sensors not very interesting.. 

Developers Support
Reacting to tap switches

As you can understand, unfortunately we cannot disclose information and timeline for future features.   All we can say is that the hue team is aware of the need for event triggers to external resources. 

The hue system is continually improving and we welcome any suggestions which will be taken into consideration for future releases.

Reacting to tap switches

Ok, fair enough. That sounds hopeful at least. If you do allow external REST resources, please allow more complex bodies in the request as well. OpenNetHome is ready to integrate support for this feature if it becomes available.

as the maintainer of the hue

as the maintainer of the hue module for the open fhem home automation system i'm also happy to hear that you at least think about this.

and of course i'm equally ready to support these features.

+1 for the ability to trigger

+1 for the ability to trigger external stuff from the taps. 

As fare as I'm concerned, I have a very hackish setup with old X10/RF wall mounted switches that ultimately command a dozen hues and a few X10 lamps and devieces. I would be glad to replace the X10 switches by Philips switches, but only if I can also command the X10 part of the setup somehow. Switches are more or less useless in any hybrid setup without this.

Basically, WebSocket, http POSTs to external arbitrary REST resources, UPNP broadcasts, anything over IP will do.

another +1 for external actions/events/push!

I'm in almost the same boat as nethome above.  I have been tinkering/working on a hue automation project, and after my first read-through of the API, I had assumed I would be able to create a rule with an action that performed an HTTP PUT on an external web service (e.g. the one I'm writing).  I was very disappointed to discover, when I tried it today, that I got an error:

		"error": {
			"type": 608,
			"address": "",
			"description": "Rule actions contain errors or multiple actions with the same resource address or an action on a unsupported resource"

I know security is probably a consideration in this, but you know... if it's good enough for the hue bridge to be able to accept HTTP requests from other devices on the local network, why can't it dish them out as well?  That only seems sensible.  And it would fit into my plans for triggering my own actions based on the Tap switch very nicely.  As things are, with polling being the only option to determine when a switch has been pushed, it's really taken the wind out of my sails.

The open API is FANTASTIC -- kudos Philips! -- and it has gotten me motivated to start tinkering in home automation... but more transparency on the roadmap (in that same spirit of openness) would always be welcome. ;-)  So I'm really looking forward to any future announcements from Philips in this regard.

And +1 again for external actions !

As said above the current API is pretty cool but it could be awesome with the possibility to launch external actions. At least HTTP requests inside the local network. Lot of new possibilities would be available with this Hue Tap !

Best regards.

And +1 again for external actions !

And +1 again for external actions !

ZigBee sniffer?

I'm new to the ZigBee protocol but is it possible to detect the HUE tap switch's zigbee signal as it gets transmitted to the HUE bridge?

If so, I realize it would not be as graceful as responding to events pushed from the HUE bridge but at least it would keep you from polling the bridge constantly...

I have a similar project where I would like to respond to the HUE tap to turn on non-zigbee lights in addition to the HUE ones.. 


My main interest in Hue is writing my own code for it — including custom actions triggered by buttons. It would be awesome if the bridge could make a custom HTTP request to a device on the network in response to a button press, or if I could establish a long-lived TCP connection from another device to the bridge.

I'd also like to control some old non-Hue (LiFX) bulbs and non-smart bulbs connected to a smart dimmer. It'd be great if this were built-in, but I'd settle for having to use a program running on another system. Unfortunately, it doesn't look like this is possible. I'm super disappointed.

+1. As mentioned above,

+1. As mentioned above, polling is not a good approach if responsive, fluid UI is desired. Does not work with tap switch too. Please provide async notification mechanism - telnet, or REST Streaming like on Nest, or something else - as long as it works.

Dean Roddey
I was would personally argue

I was would personally argue against anything that requires the Hue to connect in an outward direction. Some automation systems may not deal well with this. They will assume that any drivers make the connection to the device, not the other way around. Particularly given they already have to make a connection anyway, it might be awkward to also have to have a separate listening connection. Some may not allow for listening sockets in the driver, assuming connections are outgoing (for security reasons.)

So, either a two way connection or a connection from the automation system on a separate socket purely for async notifications would be the most widely supportable scenario. The easiest, given that there's always a web server and HTTP is supported is to just allow the automation system to make an HTTP 1.1 (persistent) connection to the Hue, and to request that the Hue send async msgs. It just requires that responses have an id that links to them to the original request, so that asyncs can be identified. It would be backwards compatible since it wouldn't happen unless asked for, and HTTP 1.0 connections can still be used.

Even for those systems that still decide to poll, persistent connections would be much more efficient.

If the above isn't possible, then other (probably widely supportable) scenarios would be:

1. A separate port purely for sending asyncs. The mere fact of connecting to it starts them coming. They could be JSON msgs easily enough, essentially chunks of what is already being returned from the poll, maybe with a different wrapper. That would make it easier to process the data from either polling or async (we still have to do an initial poll to get into sync on startup, so having to use comletely different code to store the same data would suck.)
2. Maybe configure a multi-cast address for sending out changes via UDP. Even systems that don't allow for a socket listener within a device driver probably should support UDP sockets. It has the advantage of never worrying about getting out of sync wrt to message boundaries as exists in a stream connection without explicit packetization mechanisms.


Agree with no outward

Agree with no outward connections. Solution #1 which you described is what nest calls REST Streaming - you create persistent HTTP connection and receive chunks of JSON every time something changes on the bridge. Works great.

+1 to webhook-style calls

I would also love to see the ability for rules to trigger external HTTP calls to integrate with other systems and services without having to resort to polling (and thus tasking the bridge with superfluous “are we there yet” requests). The way you currently specify actions is a natural fit for so-called webhooks if the `address` would allow for arbitrary URLs. Writing listeners for such webhooks is relatively easy with every system or service that accept POST requests with JSON payloads. This could range from web application frameworks like Flask, Node JS, a simple PHP script, or embedded systems based on Arduino or Raspberry Pi. Triggers for such rules could be button presses on the Tap or Dimmer Switch, but also any of the CLIP sensors.

Those URLs could point to services on the local LAN for in-home integration. E.g. home controllers in a heterogenius environment, supporting not only Hue, but also Z-Wave, 433MHz RF, Bluetooth LE, etc, or the Arduino example above. Systems for logging events or metrics (e.g. Logstash) often support webhook-style calls.

For external URLs it literally opens up a world of possibilities. Many online services take webhook-style calls to trigger some action. Examples include PagerDuty for triggering incidents resulting in someone getting paged, posting messages to Slack, as well as custom webhook listeners hosted outside the home. IFTTT has recently added the Maker Channel, and its webhook Trigger makes it even easier to hook up other actions (but please don't only support IFTTT).

Webhooks are the most basic integration point to external services I can think of. I believe other solutions, like persistent TCP connections for streaming, or websockets, would probably more involved to implement on the bridge, but such things can be build on top of webhook calls by a proxy service. This also goes for securing calls to the outside world with authentication and transport level encryption (TLS), if that would be required.

As I see it, the CLIP sensor APIs are a great integration point into Hue, and external triggers with webhook-style calls would be their ideal complement to talk to the outside world.


This is very important for me, and something I assumed would be part of the bridge. I'd like to have a single dimmer switch activate a light scene that includes both hue lights and a connected outlet. There doesn't appear to be any way to support this otherwise.

As someone who deals with API

As someone who deals with API's of almost every product line there are a few ways this is implemented across them.  My favorite is Websocket by far as it can be made to work regardless of network environments in many cases depending on how they are implemented. 

1. Telnet - A persistent telnet connection is opened and data is passed back and forth as needed.  This is what Lutron RadioRA2 and Homeworks uses which is an extremely high-end system.  Telnet isn't secure, no - but it's only feeding you data about the lights and their states.  Security shouldn't be a huge concern.  This is by far the easiest method to implement. 

2. REST Streaming - This is using the EVENT Source protocol that HTTP Provides which essentially persists the connection with special header information.  As stated previously, this is what Nest uses.  it is a bit more complex than telnet but does offer a secure and controlled environment.  On the LAN this probably isn't necessary but it does work.

3. Long-Polling - this is what the old apple tv uses (and probably the new one).  The Apple Remote app essentially makes a HTTP Query which is told to "keep alive" - this isn't the same as the Event Source solution but it is very similar.  Essentially the call does not return until new data is available at which point the call must be re-made.  This is fairly complex and probably not something that is a good idea, but it does work well.  With my environment I had to setup threads with this as it would hold everything up if I did not.

4. Websocket - Websocket - it works like telnet but has security, works over HTTP Protocols, is modern, is great - love it! Awesome!  Do it!  Problem is not every system can support web sockets yet.   Oh well, their fault for not keeping up with the times!

5. HTTP Calls - This is actually not a bad method at all - it requires the device listening for events simply runs a TCP/HTTP Server on a specific port.  The Bridge could make HTTP Calls to it with specified data whenever events occur.  This is extensible and works well and most hardware can run it.  In my mind while Websocket provides benefits, based on how this environment would be setup - this is the method it should deploy.  You should be able to do something similar to Nest - connect a 3rd Party via oAuth 2.0.  The user would confirm they are ok with you connecting their Hue to a 3rd party.  Once done, you would specify an IP Address - you could fairly easily lock it to the LAN for security if you wanted to. Then the Hue bridge POST's events to the IP Given whenever they occur - making sure it doesn't listen to the servers headers (so accidental things like keep-alive dont break things down).  

Hue Team, please implement this feature.  It is important to extend what is possible with your product line.  What you have already done is great but there is so much more that can be done!  I mean with 16 Mililon Colors you could even use an API such as this to communicate data (hah, half joking).  Really the goal would be to be able to react to various things with events within home automation to make a system which is smarter and more responsive.  Without these features this product can never really compete with the higher-end solutions and will continue to feel like it's in the early 2000's with the way the API works. 


This really needs to be

This really needs to be addressed by the Hue team. It will add a lot of value to the Hue switches.

++ on that request

I need this feature for getting my curtains to start closing when I switch on my hue lights. Please create this feature. Thanks




New to Hue, This is such a basic thing it took me a while to find out calling anything external is not supported. Perhaps it is usefull to make a page with (current) Hue limitations for new devs/users.


Dear API maintainers,

thanks for the API, but I also would love to see websockets or external hooks in actions, which one would think should be trivial to implement:

    "address": "https://my-web.hook.com/?action=foo",
    "method": "PUT",
    "body": {
        "event": "TAP-1"

// nothing wrong with GET
    "address": "https://my-web.hook.com/?action=foo&event=TAP-1"


Developers Support
Websockets / External hooks


Thanks for the input.

This is a valuable feature, which we also would like to have in our system. The development team is analyzing this feature, but there are no guarantees when or if and how it will be implemented. When we have more information we will let you know.

Hue Developer Support - Niek

Edgar Manuel Ra...
Websockets / External hooks

Hi Hue Developer Support

The Philips Hue motion sensor is a great member of the Philips Hue ecosystem, but it does not have support for external systems, like Apple HomeKit or custom projects.
It would be fantastic if the system could hook external resorces like:

  "name": "livingroom motion detected",
  "conditions": [
      "address": "/sensors/11/state/presence",
      "operator": "eq",
      "value": "true"
      "address": "/sensors/11/state/presence",
      "operator": "dx"
  "actions": [
      "address": "",
      "method": "PUT",
      "body": {


Another new Hue developer - I'd love to see this.

I'd love to add the ability to have Hue Tap trigger scenes in my Home Assistant based home system (which already integrates with Hue but also has zwave and other light switches). In fact some of my hues are also on Zwave switches (so the wall switches still work).

Details here of the software here  https://home-assistant.io/

If Hue supported actions for rules that could could trigger external urls - it would be a very  easy to integrate.

+1 for this with Home

+1 for this with Home Assistant. 


subscribing to get notifications based on change to trigger other things would be a really great feature.

Does anyone know how many

Does anyone know how many calls I can do per second to a lights status with bridge v2? I just want to synch a Z-wave light to a Hue light as far as on-off goes...

Developers Support


Here you can find more information on the performance of the Hue system, it depends on how many Zigbee message you send. http://www.developers.meethue.com/documentation/hue-system-performance

Hue Developers Support - Niek

+1 Please. Polling for light

+1 Please. Polling for light state is quite innefficient. Being able to receive pushed notifications of changes in state would help integrators enourmously. 

+1 for send outward http request

Any update on this subject. Is the hue team already able to implement this feature / remove the limit to use external ip address?


+1 for triggers

All I'm trying to do is control hue lights with hue taps (toggling in particular), but with about 20 lights, 7, taps, and a couple of hue switches, having the swiches controlling overlapping lights (i.e. tap1 and tap2 can operate on the same light with different actions) which requires 2 rules per tap button (toggle), a bunch of CLIP Generic flag sensors, and compound logic in conditions (which does not exist),  I'll run out  my rules fast and it's a real headache.  Just let me give the bridge a local http server ip, block it if the bridge and server are not on the same subnet and it's not a private network ip range (for security) and allow rule to call a page on that server.  Then all I need is a rule on sensorID, buttonID, dx that calls my page and I can update my lights server side about 100 easier because I can just get the status of what I need and uses if statements and loops on my sever side script.

Honestly, the ball has been dropped when I'm thinking about ditching my brige and using an Arduino with a Zigbee to do the same thing.

Exampe on how to do polling


So I thought I would share some extreme basic pyhton code (can easily run on raspberry or the likes) that polls the Bridge and checks for state change in a sensor (read: button) so you can do other things then just controlling hue lights based on a button click.

You can change the interval, but like 0.1 or 0.5 seconds seems to work fine. is my IP of the bridge and "monitor" is the API username I created

Where the print State is you can do your own code based on the new value. 


import urllib2
import time

def SensorState( SensorName ):

  s = "buttonevent\":"
  a = urllib2.urlopen("" + SensorName ).read()
  b =  a.find(s) + len(s)
  e = a.find(",",b)

  return a[b:e];

while 1 == 1:

 lastState = SensorState("2")
 while (SensorState ("2") == lastState):

 print "State Changed!" + SensorState("2")


+1 for triggers/webhooks

That API is awesome. It's just hard to integrate it with other home systems without being able to adequately know about Hue system changes.

+1 for triggers/webhooks

I'd also very much like to have this functionality. The current polling is not adequate to have the light status react immediatly to the Hue Tap. 

For example, i use it together with Smartthings and whenever i use the Hue Tap, the lights do not get updated for several minutes unless doing a manuell refresh.


Please add this. I bought Phillips hue over belkin specifically because of its Open API, but its only open in one way. Please allow rules to send HTTP requests.

(I feel outbound HTTP requests make the most sense to solve this, as the system is already HTTP REST based)


I'd love to have this feature so that an external automation engine like FHEM or OpenHAB could control the A/V equipment when pushing a button on the Tap to activate the home cinema mode...

with fhem you can set the

with fhem you can set the polling intervall to a low value like 1 second. there are some users that use it reqsaonably successfull.

but a real push api would be much much better.

You may be able to create

You may be able to create something that acts like a Homekit phone,
then you can subscribe to lamp event changes and trigger on that :-)


Webhooks or websocket connection for live status or changes would be great

Ok without a question this

Ok without a question this NEEDS to be added... there are a few ways it is done elsewhere:


1. Lutron RadioRA2 / Homeworks QS -- Telnet -- You connect to it and authenticate then just wait for discussion on the socket.  This isn't very secure but likely not a big deal in these cases

2. Websocket - Definitely a great solution although a bit heavier load on the unit.  Nice part of this is if you can configure it as a Websocket Client -- boom you have the ability for peopel to make their own remote API's without needing Philips to provide it or without needing to have philips pay the bill for the bandwidth

3. MQTT - Meh, but still nice - If Philips hue would be able to connect to the Amazon AWS IoT Gateway then this could be really cool though as it provides shadow capabilities and handlign for remote communications even when internet fails 

4. Webhooks - Ok ... this is already built in.. .just allow external webhook rules! SIMPLE AS THAT -- although the others are better in almost every way, this sounds like something you guys could put together in a week

polling is ABSOLUTELY ridiculous and it is not plausible if you have anything more than 1-2 lights... Philips - what you fail to realize is that this is the single feature you are missing that makes your product an "absolute no" when looking at doing a whole house of lighting... even in simple systems its awesome to have but you will never sell 30-50-100 hue lights or strips when there is no instant reporting of state.

I would like to have a JSON

I would like to have a JSON based hook to changes too. I've implemented a polling mechanism for the buttons and found that I need to have a polling interval of maximum half a second before the reaction of my program feels lagging. As of today I do not have such a need for the light states, but if I do, I think it will beome very inefficient to ask the light states of the 30+ bulbs in my home each half second.


but you will never sell 30-50-100 hue lights

They did in my home...

Are there any news concerning

Are there any news concerning this topic? I can't imagine that, there is no possiblity to trigger custom events with the hue tap?

now that there are more and

now that there are more and more manufacturers starting to produce zigbe lightlink compatible switches( gira, jung, bush jaeger, dresden) it is more importand than ever to have a push api that allows to integrate zll switches into an exisiting home automations system.

if philips will not step up to this one of the other manufacturers wil and this will be the main argument to choose this product instead of the hue bridge.

this would be very sad as phillips has (despite the hickups wit certain firmware versions) done a realy realy good job creating an open api and a community around it. 

my hue module for the fhem home automation system has more than 700 users with more than 7000 lights and this is the single most requested feature.


+1 for this feature. Just


+1 for this feature. Just found out I can't do external requests.

Doesn't matter what form it comes in. REST to external addresses seems like the easiest to just enable. But whatever it turns out to become, push would be very much appreciated.

Edit: Just to explain why it would probably be easy to implement this. It looks like this feature is already built in to the bridge, just seems you can't use external addresses. See the actions at the rules API documentation, looks like it already sends REST/HTTP calls. http://www.developers.meethue.com/documentation/rules-api

Log in or register to post comments