Philips Hue API v2 Events (Server-Side Events)

Avatar
Ricardo Pinto
  • updated

Hello everyone,


First of all, hope you all had a very nice Christmas, with all the beloved ones.


I'm using some Philips HUE sensors, and I was actually using some of them to turn KNX lights on.


The problem, is that we need to constantly pool the API, which is time and resource consuming for the HUE hub and Comfortclick.


Philips HUE updated the API to the v2, and they have some interesting features, like the events, which allows to keep a constant connection to a data stream, and get realtime updates without the need to constantly pool the HUB.


https://developers.meethue.com/develop/hue-api-v2/migration-guide-to-the-new-hue-api/#Event%20Stream (Login needed to see the API docs)


Side note:


I have to trick the HUB about the sensor. The sensor needs to be active, and for that at least one HUE light has to be linked. But on my case I don't want to turn on any HUE light, but rather a KNX light. For that, I link the sensor to a random HUE light, and set the actions to do nothing when detecting movement (so I can just extract the true motion from the json).


Back to the topic:


So I've tested the curl command, and I really get the realtime updates, and it looks awesome.


Problem: I can see this realtime updates on the Windows console, by using the curl command, as stated on their documentation:


curl --insecure -N -H 'hue-application-key: ' -H 'Accept: text/event-stream' https:///eventstream/clip/v2

But, I would like to do this on ComfortClick. I've tested several options, but none of them worked.


Anyone can eventually enlighten me, if it's doable?

Replies 8
Avatar
0
Ricardo Pinto

Yep, it looks like we'll need to wait for an update.

But:

I don't know if the data streams can be useful for other usages. I'm not expecting ComfortClick team to implement data streams just because I would like to use them :-P


So probably this feature can take some time, if any at all...

Fear not, your help was highly appreciated. Thanks for taking some time to test it out.

Best regards,

Ricardo

Avatar
1
Jürgen Jürgenson
Quote from Ricardo Pinto

Hello,

Thanks for the effort, but it's not actually the same.

What you've done is using the regular API, to constantly pool and get to the data, which is time and resource consuming.


That was my old method, still using it for testing purposes.

What Philips Hue allows now on V2, is a constant (most probably TCP) connection, instead of having to pool the hub.

On the core concepts of the hub, it's referred:

"As we have seen, you need to use a GET request to retrieve the state of resources when you first connect to the Hue Bridge. However, while you are connected, other applications and control methods can modify the state of those resources as well. It is important to not try to stay up to date by performing repeated GET requests, as that is bad for the performance of the system and generally gives a laggy user experience. Instead, you can subscribe to retrieving proactive event notifications immediately when something changes. This can be done by leveraging ‘Server-Sent Events’ (SSE) under the /eventstream endpoint:"

"On HTTP1.1, you will need a separate connection for the SSE request and regular requests, but we recommend using HTTP2 to multiplex them over a single connection which is more resource efficient.

There is a 1 second rate limit on the amount of event containers the Bridge will send. If the same property has changed twice within that timeframe, you only get the last state. If multiple resources have changed within that timeframe, then you will get multiple events grouped in a single container."

Don't know how it's implemented, but you can test it out with the curl command, which connects to the data stream and stays on all the time, so it's a constant connection rather than a constant x seconds pooling.

curl --insecure -N -H 'hue-application-key: hue_app_key' -H 'Accept: text/event-stream' https://hue_ip_address/eventstream/clip/v2´


So instead of having to pool the clip constantly via GET, a constant connection is made somehow...


Best regards,

Ricardo

Yeah I get it, but seems like bos does not support the constant steam yet. It does not stay connected without polling rn. We must wait for a update then.

Avatar
0
Ricardo Pinto

Hello,

Thanks for the effort, but it's not actually the same.

What you've done is using the regular API, to constantly pool and get to the data, which is time and resource consuming.


That was my old method, still using it for testing purposes.

What Philips Hue allows now on V2, is a constant (most probably TCP) connection, instead of having to pool the hub.

On the core concepts of the hub, it's referred:

"As we have seen, you need to use a GET request to retrieve the state of resources when you first connect to the Hue Bridge. However, while you are connected, other applications and control methods can modify the state of those resources as well. It is important to not try to stay up to date by performing repeated GET requests, as that is bad for the performance of the system and generally gives a laggy user experience. Instead, you can subscribe to retrieving proactive event notifications immediately when something changes. This can be done by leveraging ‘Server-Sent Events’ (SSE) under the /eventstream endpoint:"

"On HTTP1.1, you will need a separate connection for the SSE request and regular requests, but we recommend using HTTP2 to multiplex them over a single connection which is more resource efficient.

There is a 1 second rate limit on the amount of event containers the Bridge will send. If the same property has changed twice within that timeframe, you only get the last state. If multiple resources have changed within that timeframe, then you will get multiple events grouped in a single container."

Don't know how it's implemented, but you can test it out with the curl command, which connects to the data stream and stays on all the time, so it's a constant connection rather than a constant x seconds pooling.

curl --insecure -N -H 'hue-application-key: hue_app_key' -H 'Accept: text/event-stream' https://hue_ip_address/eventstream/clip/v2´


So instead of having to pool the clip constantly via GET, a constant connection is made somehow...


Best regards,

Ricardo

Avatar
1
Jürgen Jürgenson
Quote from Ricardo Pinto

Same here, I get the same message.

Don't know if the error message is due to the way we try to get the data stream, if it's correct or not. Because I have it on Node-red without any issues.

Needless to say that on Node-red I have a specific philips hue package, made by someone, to listen to the data stream. I was looking forward to do the same on bOS...

Don't worry about not having any sensors, as the data stream actually gets any update from any light, hub, etc. It's basically a constant data stream connection, where the hub dumps everything.

BR,

Ricardo

I got it working for bOS.

I added just the v2 API lights and eventstream. For eventstream I set the read value to 2 sec, min allowed was 1sec. Test if it works for you too. 

Image 4451

Http HueHueHue test(v2).bos

Avatar
0
Ricardo Pinto

Same here, I get the same message.

Don't know if the error message is due to the way we try to get the data stream, if it's correct or not. Because I have it on Node-red without any issues.

Needless to say that on Node-red I have a specific philips hue package, made by someone, to listen to the data stream. I was looking forward to do the same on bOS...

Don't worry about not having any sensors, as the data stream actually gets any update from any light, hub, etc. It's basically a constant data stream connection, where the hub dumps everything.

BR,

Ricardo

Avatar
0
Jürgen Jürgenson

I wanted to test it but I get a "Oops, there appears to be no lighting here" error. Hub itself shows as updated and I can control my light from the hue app and bOS. Also I don't have any sensors only lights.

Avatar
0
Ricardo Pinto

Hello again!

Bumping this thread... anyone has any clue if this is possible?

I can't find any way to intercept the data stream coming from the HUE, so for the time being I'm using Node-red.


Even though it works perfectly, it actually sucks to have an additional software.

I use it to trigger a boolean via bOS RPC, and then I decide what to do on bOS side.

Image 4448


Would be awesome if it this could be possible only with bOS.


BR,

Ricardo

Avatar
0
Ricardo Pinto

Sorry, I've pasted the command with some missing info. Here's the correct curl command:

curl --insecure -N -H 'hue-application-key: hue_app_key' -H 'Accept: text/event-stream' https://hue_ip_address/eventstream/clip/v2

Example of a real time update on the data stream coming from the HUE sensor:

id: 1672012139:0
data: [{"creationtime":"2022-12-25T23:48:59Z","data":[{"id":"b89c6bec-90cf-44fe-8bfb-7bbb886dbc6f","id_v1":"/sensors/38","motion":{"motion":true,"motion_valid":true},"owner":{"rid":"cf9bd628-7c47-44f7-9794-1a08d6baf345","rtype":"device"},"type":"motion"}],"id":"c3f9ec9c-d672-422c-904f-7982d8759a79","type":"update"}]

The ideia would be using this constant connection on ComfortClick to trigger other cool stuff, so we could abandon the constant API pooling. But unfortunately I'm not getting there (probably due to the overconsumption of Christmas treats).

Best regards


Customer support portal powered by UserEcho