Smarthome: [Hue Binding]: add support for Sensor API

[ddudnik]

This issue is cloned from https://github.com/openhab/openhab2-addons/issues/1260 since Hue Binding is maintained in eclipse/smarthome repository.

Original issue description by @regnets

I purchased a Philips Hue Dimmer (http://www2.meethue.com/de-de/productdetail/philips-hue-dimmer-switch) and this thing is not supported ootb from the hue binding as far as i can tell.

However the Philips API provides an interface for accessing those devices
http://www.developers.meethue.com/documentation/sensors-api

Support for these devices would be great! However we will need a faster polling period for the sensors, as the API is still not providing any form of callback or external events.

Additional description from me:

With the appearance of Hue motion detector the support for Sensor API makes even more sense now. Even if implemented with polling. I guess it should work more or less fine from UX perspective for this new Hue motion detector which is in fact a multi-sensor providing: motion sensor, daylight sensor and (unadvertised) temperature sensor.

Since I got myself one of those, I would be up for the task :)

[regnets]

If you need an additional tester i would be glad to support you!

[hfanieng]

👍

[regnets]

Any progress on this? Do you need help or a tester?

[ddudnik]

@regnets no progress so far as I'm aware. Have to do https://github.com/eclipse/smarthome/issues/2601 first.

[kaikreuzer]

See here: https://github.com/eclipse/smarthome/issues/2601
This issue is a pre-requisite that has to be done first.

Edit: Damn, @ddudnik was 2 seconds faster ;-)

[michaelkoetter]

I'd be interested in this as well, however with the current API the only solution would be to do "rapid polling" for sensor state which makes me cringe :wink:

Philips announced a new API, although they don't mention sensors yet - but maybe this will be usable: https://developers.meethue.com/entertainment-blog

Another option might be to support the deCONZ REST API (RaspBee/ConBee hardware), which emulates a hue bridge and adds a websocket:
http://dresden-elektronik.github.io/deconz-rest-doc/websocket/

[overdrive69]

Hello i Think #2601 is closed.
Are there any news for this one?

[kaikreuzer]

Another option might be to support the deCONZ REST API

Well, this is clearly not an option for the hue binding itself (which should work with the hue bridge).
A dedicated RaspBee binding (https://github.com/eclipse/smarthome/pull/1353) has unfortunately been abandoned.

[michaelkoetter]

Ah I didn't see that PR... thanks for the pointer, I'll have a look at what's there.

[Simiil]

Hi,
I started working on a polling sensor support for the binding, and it seems to work pretty well so far.
So far the binding represents each light registered on the bridge as a single thing, which makes sense for the lights and makes the ZLL mapping possible. For the sensors however there are often more than one sensor registered for one physical thing. For instance, the presence sensor registers a ZLL Presence sensor, a ZLL Temperature Sensor, and a ZLL Light Level Sensor.

Should each of those Sensors be represented by a separate thing, as it is done so far? or should each physical sensor be represented by one single thing, which would make more sense IMO but would involve a fairly large refactoring, and break the generic ZLL mapping (which is currently not relevant anyway, because AFAIK the ZLL specification does not include sensors)?

[thedannymullen]

@simiil I am thinking separate thing for each sub sensor. This is because the hue bridge supports 3rd party sensors. Some don’t have temp or light. This is my opinion as it seemed in my mind easiet way to integrate.

[cweitkamp]

@Simiil Thank you very much for working on this feature. If you need someone for testing please ping me or upload your code / the *.jar file here.

I second the approach to handle each sensor separately even if they are combined in one physical device.

Why do you thing ZigBee does not support sensors? IIRC we can use the following list

| Device Type | Device ID |
|------------------|---------------|
| Light Sensor | 0x0106 |
| Occupancy Sensor | 0x0107 |
| Temperature Sensor | 0x0302 |
| Colour Controller | 0x0800 |
| Colour Scene Controller | 0x0810 |
| Non-Colour Controller | 0x0820 |
| Non-Colour Scene Controller | 0x0830 |

See e.g. https://www.nxp.com/docs/en/user-guide/JN-UG-3114.pdf (page 71ff) or https://www.nxp.com/docs/en/user-guide/JN-UG-3076.pdf (page 25ff).

[kaikreuzer]

Should each of those Sensors be represented by a separate thing, as it is done so far? or should each physical sensor be represented by one single thing

Usually, a thing should always correspond to the physical device, i.e. it should be something that the user can individually add to and remove from the system.

How does the hue bridge deal with it? Does a single device with presence/lightlevel/temperature sensor appear as three sensors with different IDs in the hue API (i.e. /api/<username>/sensors/1, /api/<username>/sensors/2, /api/<username>/sensors/3)?
If so, what does it do upon a DELETE call for one of these sensors?

[Simiil]

@cweitkamp You're right of course, it seems that i looked at the wrong documentation.

@kaikreuzer The hue bridge has each technical sensor as a separately registered sensor. For instance, registering a motion sensor creates 4 separate sensors (presence, temperature, lightlevel and a generic sensor), each with their own ID. Doing a DELETE requests deletes that one sensor item, and keeps all others.

[kaikreuzer]

Ok, thanks for these infos. Then I fully agree with you that modelling it as separate Things makes sense here as we would not really stand a chance to know that they are actually a single device.

[Simiil]

Sorry for the confusion, its my first pull request on github and the first pull request went wrong. The second should be ready for review