02.02.2022, 14:53
(This post was last modified: 02.02.2022, 14:54 by gjniewenhuijse.)
Can anyone help me to setup an evenstream connection?
Migration Guide to the new Hue API - Philips Hue Developer Program (meethue.com)
The V2 API supports proactive notifications on changes through Server-Sent Events (SSE) under the /eventstream endpoint:
curl --insecure -N -H 'hue-application-key: <appkey>' -H 'Accept: text/event-stream' https://<ipaddress>/eventstream/clip/v2
Events have an id, timestamp, type (‘update’, ‘add’, ‘delete’, ‘error’), and data field which contains the changed properties of the resource in the same format as a GET response on the same resource type. The following is an example event stream that would result from turning a light on and off:
id: 1617322504:0
data: [{"creationtime":"2021-04-02T00:15:04Z","data":[{"id":"4413c8fd-6643-48b5-ad02-59453edf8a61","id_v1":"/lights/1","on":{"on":true},"type":"light"}],"id":"19845c30-2e4c-4205-a7b4-8bd496f3407d","type":"update"}]
id: 1617322505:0
data: [{"creationtime":"2021-04-02T00:15:05Z","data":[{"id":"4413c8fd-6643-48b5-ad02-59453edf8a61","id_v1":"/lights/1","on":{"on":false},"type":"light"}],"id":"bea68344-a36c-4bfd-a658-97830e4e2b1a","type":"update"}]
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.
Currently 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, you will get multiple events grouped in a single container.
Migration Guide to the new Hue API - Philips Hue Developer Program (meethue.com)
The V2 API supports proactive notifications on changes through Server-Sent Events (SSE) under the /eventstream endpoint:
curl --insecure -N -H 'hue-application-key: <appkey>' -H 'Accept: text/event-stream' https://<ipaddress>/eventstream/clip/v2
Events have an id, timestamp, type (‘update’, ‘add’, ‘delete’, ‘error’), and data field which contains the changed properties of the resource in the same format as a GET response on the same resource type. The following is an example event stream that would result from turning a light on and off:
id: 1617322504:0
data: [{"creationtime":"2021-04-02T00:15:04Z","data":[{"id":"4413c8fd-6643-48b5-ad02-59453edf8a61","id_v1":"/lights/1","on":{"on":true},"type":"light"}],"id":"19845c30-2e4c-4205-a7b4-8bd496f3407d","type":"update"}]
id: 1617322505:0
data: [{"creationtime":"2021-04-02T00:15:05Z","data":[{"id":"4413c8fd-6643-48b5-ad02-59453edf8a61","id_v1":"/lights/1","on":{"on":false},"type":"light"}],"id":"bea68344-a36c-4bfd-a658-97830e4e2b1a","type":"update"}]
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.
Currently 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, you will get multiple events grouped in a single container.