Closed ddudnik closed 5 years ago
If you need an additional tester i would be glad to support you!
👍
Any progress on this? Do you need help or a tester?
@regnets no progress so far as I'm aware. Have to do https://github.com/eclipse/smarthome/issues/2601 first.
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 ;-)
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/
Hello i Think #2601 is closed. Are there any news for this one?
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.
Ah I didn't see that PR... thanks for the pointer, I'll have a look at what's there.
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)?
@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.
@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).
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?
@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.
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.
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
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
Additional description from me: