WebSocket notifications only partly implemented? about deconz-rest-plugin HOT 30 CLOSED

I added websocket support to homebridge-hue v0.5.11. It's so cool to see HomeKit updated in realtime.

from deconz-rest-plugin.

When my last dimmer switch was finally discovered by the deCONZ rest api, the WebSocket reported:

{"e":"added","r":"sensors","sensor":{"config":{"on":true,"reachable":true},"ep":1,"etag":"1496499cd752fe8145ce36d79f8f7875","id":"1","manufacturername":"Philips","mode":1,"modelid":"RWL021","name":"RWL021 1","state":{},"swversion":"5.45.1.16265","type":"ZHASwitch","uniqueid":"00:17:88:01:10:xx:xx:xx-01-0006"},"t":"event"}

from deconz-rest-plugin.

Sorry for the late response.

The current implementation is indeed quite basic. Your suggestions in 1) and 2) are already planned to be implemented in near future releases: so that groups, sensors, lights and configuration attribute changes will be reported via WebSocket.

As for 3) the variant b) will be used (only changes will be reported) to keep overload minimal for larger installations.

from deconz-rest-plugin.

hello,

for my sails.js app - i would need this information as well - i do not have any sensors only osram lights (72 so far) - but the light's can be turned on off through normals switches (which are connected to DSS (digitalstrom)) at the moment i have an interface from dss to deconz through simple curl commands - but my app has no information on light state changes than - so i poll the deconz to show the correct state in my app as well - so i would highly appreciate if i could change this to push instead of polling - so my app has realtime information on the light state changes...

further i have some lights - which are controlled through motion sensor (power off the light completly) and i would need an event if a light is lost and if a light is on again so i can than change some parameters like color/brightness/... once the light is on again

thanks
holli

from deconz-rest-plugin.

Hi all, the Websocket support for light resource updates is committed and will be part in the next beta release (hopefully next week).

@holli73 notification when a light is powered on should be covered by that, however when a light loses power it takes time until the event is fired.

from deconz-rest-plugin.

Thanks Manuel! Looking forward to the next beta.

from deconz-rest-plugin.

@manup - i did compile it and did some test - so i receive now a websocket event for light on/off - but i can not differentiate where this is coming from - f.ex.:

Object {e: "changed", id: "1", r: "lights", state: Object, t: "event"}e: "changed"id: "1"r: "lights"state: ...

i only put this on my raspberry pi where i have only one osram surface available at the moment - but how can i see if a single light was turned on/off or a group command was used on/off?

it looks like the ws event is always the same regardless if it is a group or direct light action?
would it be possible to add this information as well?

f.ex. within my bathroom i have 19 spots and i use group commands to turn on/off change parameters - so all lights are effected in that group - but this would cause 19 ws events instead of one?

so it would be cool to have an event source as well like (group, lightLost, lightConnected, singleLight,...) and if f.ex. group the id send should be the group id.

thanks
holli

from deconz-rest-plugin.

Looks like it's coming from /lights/1 ("r": "lights", "id": 1). It's an event that the light state has changed, not that some API command was given. It would also be issued when the light is changed through a gateway rule or switch or sensor bound directly to the light. And yes, you would get 19 events, one for each spot, for your bathroom.

It looks like the event message got scrambled in your post. What does it report under state? Only the changed on attribute or the full state? What if you PUT a state of {"on":true,"bri":127}? Does it generate a single event with both attributes, or two events?

from deconz-rest-plugin.

f.ex. within my bathroom i have 19 spots and i use group commands to turn on/off change parameters - so all lights are effected in that group - but this would cause 19 ws events instead of one?

Yes currently there will be one event for each changed state attribute (this should be combined into one message for all attributes per light in future). The source of the change is not visible, but similar to light state all action updates for groups will be implemented soon to the event system.

When the light reachable state is false it should be reported as true shortly after the light is powered on; should because I'm not sure if I did implement it already ;) (need to check this)

from deconz-rest-plugin.

Hi, where can i download the new Beta Version to test it ?

from deconz-rest-plugin.

@dghh - as long there is no download here you must compile it on your own and copy the lib as described in the mainpage here.

@manup - i did pull again and now i get group information verry cool.
but why do a get the light events as well on group calls?

i can ignore the light's but just want to point that out here - it looks like a group command will fire the light's event as well but i'm not sure if this is desired.

thanks
holli

from deconz-rest-plugin.

@holli - thanks, i have compiled the source and now it´s running.

I think it is correct that if you trigger a group also the corresponding lights in this group getting triggered. So you have automatically the state of the lights too updated. The same with scenes. Calling a scene the affected lights and groups get all triggered. (every group in which this special light is, i assume)

Thanks manup. Everything runs very smooth at the moment with the WebSockets!

from deconz-rest-plugin.

I did compile the source as explained in the README.md on the mainpage but still only get sensors and no lights state changes with websockets. Do I have to compile a special version?

from deconz-rest-plugin.

I guess you checked out from tag 2.04.40 as stated in the README.md?

For the light websocket events you will need to compile the more up-to-date master branch.

cd deconz-rest-plugin
git checkout -b mybranch master

There is also a more recent binary with version 2.04.44 available (12 June 2017).
http://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.04.44-qt5.deb

The beta release and README.md will be updated in a few days to reflect these.

from deconz-rest-plugin.

Thanks @manup it's working now! I would appreciate more modifications like @ebaauw suggested. While compiling I got some errors related to file/ directory ownership. Maybe something related to the Makefile?

from deconz-rest-plugin.

I'm now running deCONZ v2.04.45. Websockets seems reliable for sensor, light, and group state changes.

I still have some issues, but I don't think they're related to the websocket function:

• lastupdated contains the local time instead of the UTC time;
• For the Hue motion sensor, I get two messages per five minutes (reporting interval) for the presence value of a Hue motion sensor. I think that's because the attribute reporting for the battery updates the presence instead of the battery level.
• I've created a group for the Trådfri remote containing the Trådfri bulb in the Web interface. When I press a remote button, the light responds as expected, and a websockets message for the button event is issued immediately. The messages for the light and group state, however, are delayed by several seconds/minutes. I think that's because the light/group state is only updated on the next poll cycle? When updating a light through rules on the gateway, or when updating a light directly from the API, the messages are issued immediately, as expected.
• No messages for a CLIP sensor, but then the state remains empty, see issue #31.

from deconz-rest-plugin.

v2.04.47:

• lastupdated is in UTC.
• I now receive notifications for the CLIP sensor state change;

from deconz-rest-plugin.

v2.04.52: When changing a light'sstate.xy I receive two websocket notifications (one for x and one for y) instead of one (for xy). Also, the value reported is the raw attribute value from the 0x0300 cluster, not the normalised value in the range 0.0...1.0 as used by the REST API. I don't always get events when colormode changes, even when it's updated in the light state.

As I mentioned in #30, the deCONZ gateway uses different values for colours than the Hue bridge.

When I PUT {"on":true,"bri":255,"xy":[0.5106,0.415]} to /lights/231/state, I receive the following websocket events:

Sat Jul 15 2017 18:57:10: /lights/231/state: {"bri":255}
Sat Jul 15 2017 18:57:10: /lights/231/state: {"x":33331}
Sat Jul 15 2017 18:57:10: /lights/231/state: {"y":27090}

The light state is then:

{
  "alert": "none",
  "bri": 255,
  "colormode": "xy",
  "ct": 0,
  "effect": "none",
  "hue": 0,
  "on": true,
  "reachable": true,
  "sat": 0,
  "xy": [
    0.510593,
    0.414988
  ]
}

Note the previous values for hue, sat, and ct, the issued value for bri, and the more or less issued values for xy.

As deCONZ is polling the light, I receive additional events:

Sat Jul 15 2017 19:00:58: /lights/231/state: {"bri":254}
Sat Jul 15 2017 19:01:00: /lights/231/state: {"hue":13158}
Sat Jul 15 2017 19:01:00: /lights/231/state: {"sat":205}
Sat Jul 15 2017 19:01:00: /lights/231/state: {"x":33326}
Sat Jul 15 2017 19:01:00: /lights/231/state: {"y":27089}
Sat Jul 15 2017 19:01:00: /lights/231/state: {"ct":459}

After these, the light state is:

{
  "alert": "none",
  "bri": 254,
  "colormode": "xy",
  "ct": 459,
  "effect": "none",
  "hue": 13158,
  "on": true,
  "reachable": true,
  "sat": 205,
  "xy": [
    0.510516,
    0.414973
  ]
}

Note the now corrected values for bri, hue, sat, ct and slightly modified values for xy.

After I PUT /lights/1/state with {"on":true,"bri":255,"xy":[0.5106,0.415]} on the Hue bridge, it reports the light state as:

{
  "on": true,
  "bri": 254,
  "hue": 34182,
  "sat": 254,
  "effect": "none",
  "xy": [
    0.5106,
    0.415
  ],
  "ct": 153,
  "alert": "select",
  "colormode": "xy",
  "reachable": true
}

Note the corrected bri value, the issued xy values and the previous values for hue, sat, and ct.

After it's polled the light, it reports:

{
  "on": true,
  "bri": 254,
  "hue": 13195,
  "sat": 210,
  "effect": "none",
  "xy": [
    0.5106,
    0.415
  ],
  "ct": 463,
  "alert": "select",
  "colormode": "xy",
  "reachable": true
}

Note the now corrected values for hue, sat, and ct. Also note different values from deCONZ.

from deconz-rest-plugin.

I don't always get events when colormode changes, even when it's updated in the light state.

Might be related to #53: recalling a scene with ct seems to issue xy values instead.

from deconz-rest-plugin.

v2.04.52: When changing a light'sstate.xy I receive two websocket notifications (one for x and one for y) instead of one (for xy). Also, the value reported is the raw attribute value from the 0x0300 cluster, not the normalised value in the range 0.0...1.0 as used by the REST API.

Yes the xy values must be combined and normalized I'll change the resource event handler to execute the transformation.

I don't always get events when colormode changes, even when it's updated in the light state.

I put it on the review list, should be fixed in the next releases.

As I mentioned in #30, the deCONZ gateway uses different values for colours than the Hue bridge.

I'm afraid it will never match exactly the hue bridge values, but the polling of light states will be refactored to improve correctness and performance when retrieving the actual values.

The really hard part here is the that every product uses different calculations, some don't update all values only the ones which were changed, some update values with weird results.

from deconz-rest-plugin.

I'm afraid it will never match exactly the hue bridge values, but the polling of light states will be refactored to improve correctness and performance when retrieving the actual values.
The really hard part here is the that every product uses different calculations, some don't update all values only the ones which were changed, some update values with weird results.

By "products" do you mean: lights or gateways (like deCONZ or the Hue bridge)? I do not understand why deCONZ would need to do colour calculations. Can you please help me understand this?

From what I observe from the Hue bridge API, there's three different modi to set colour: ct, hue / sat, and xy. I still haven't setup the ZigBee sniffing, so I don't know what ZigBee commands the Hue bridge actually sends to the light, but it would seem it sends the command corresponding to the mode, only updating the attributes corresponding to the mode:

• ct sets the Color temperature attribute (0x07);
• hue and sat set the Enhanced current hue (0x4000) and Current saturation (0x01);
• xy sets Current x (0x03) and Current y (0x04).

Anyways, the Hue bridge only updates the cached state attributes corresponding to the mode. It looks like the light actually computes the other values and the bridge only reports these after it has polled the light. It won't update colormode from polling.

I never understood the use of hue and sat as these values seem to depend on the primaries used by the light, so I only use ct and xy in my homebridge plugin, converting HomeKit's Hue and Saturation values into xy and back.

Now the funny part: when specifying values the light cannot display, the behaviour differs for ct vs xy. For ct the bridge reports the actual value immediately; for xy only after polling the light. See e.g. the following transscript:

$ ph_get /lights/1
{
  "state": {
    "on": true,
    "bri": 254,
    "hue": 13195,
    "sat": 210,
    "effect": "none",
    "xy": [
      0.5106,
      0.415
    ],
    "ct": 463,
    "alert": "select",
    "colormode": "xy",
    "reachable": true
  },
  "type": "Extended color light",
  "name": "Living Room 1",
  "modelid": "LCT003",
  "manufacturername": "Philips",
  "uniqueid": "00:17:88:01:00:xx:xx:xx-0b",
  "swversion": "5.50.1.19085"
}
$ ph_put /lights/1/state '{"xy":[0.0,0.0]}'
$ ph_get /lights/1/state
{
  "on": true,
  "bri": 254,
  "hue": 13195,
  "sat": 210,
  "effect": "none",
  "xy": [
    0.0,
    0.0
  ],
  "ct": 463,
  "alert": "select",
  "colormode": "xy",
  "reachable": true
}
$ sleep 120
$ ph_get /lights/1/state
{
  "on": true,
  "bri": 254,
  "hue": 47104,
  "sat": 254,
  "effect": "none",
  "xy": [
    0.167,
    0.04
  ],
  "ct": 153,
  "alert": "select",
  "colormode": "xy",
  "reachable": true
}
$ ph_put /lights/1/state '{"ct":463}'
$ ph_get /lights/1/state
{
  "on": true,
  "bri": 254,
  "hue": 47104,
  "sat": 254,
  "effect": "none",
  "xy": [
    0.167,
    0.04
  ],
  "ct": 463,
  "alert": "select",
  "colormode": "ct",
  "reachable": true
}
$ sleep 120
$ ph_get /lights/1/state
{
  "on": true,
  "bri": 254,
  "hue": 13239,
  "sat": 208,
  "effect": "none",
  "xy": [
    0.509,
    0.4149
  ],
  "ct": 463,
  "alert": "select",
  "colormode": "ct",
  "reachable": true
}
$ ph_get /lights/30
{
  "state": {
    "on": true,
    "bri": 1,
    "ct": 451,
    "alert": "select",
    "colormode": "ct",
    "reachable": true
  },
  "type": "Color temperature light",
  "name": "Bathroom 1",
  "modelid": "LTW013",
  "manufacturername": "Philips",
  "uniqueid": "00:17:88:01:02:xx:xx:xx-0b",
  "swversion": "1.15.2_r19181",
  "swconfigid": "B7A3ED0F",
  "productid": "Philips-LTW013-1-GU10CTv1"
}
$ ph_put /lights/30/state '{"ct":500}'
$ ph_get /lights/30/state
{
  "on": true,
  "bri": 1,
  "ct": 454,
  "alert": "select",
  "colormode": "ct",
  "reachable": true
}

Apart from scaling xy from float to uint16, I don't see any evidence of nor reason for colour calculations in the Hue bridge. In fact, their API documentation explains in length how this should be done by the application instead, converting RGB to CIE 1934 and back.

I think from a user experience perspective, the Hue bridge, or any gateway (hint ;-), should read the light state shortly (?) after sending a command to change it, to reflect the actual values, rather than guessing (and often missing) these and waiting for the next polling cycle. Especially when you use a long transition time, e.g. set a state of {"on": false, "transitiontime": 600} the bridge first reports the light as off, then again as on at reduced brightness, updating the brightness each time it polls the light, until it reports off after 10 minutes (and some polling delay). Or when updating the lights through group resources. I'm not sure what the impact will be on the ZigBee network load, though.

from deconz-rest-plugin.

Is it correct understood that in the current implementation i don't get a group event when the state changed on it ? I seem to only get {"e":"changed","id":"5","r":"groups","state":{"any_on":false},"t":"event"}but no real event on the state of the "on"

from deconz-rest-plugin.

I get them. Please note that a group's state.any_on only changes when the first light goes on, or the last light goes off.

from deconz-rest-plugin.

@ebaauw i know, that's why i did not want to rely on it. I swear i have seen them but not anymore for some reason, maybe something happened in the last(s) commits @manup ?

from deconz-rest-plugin.

Just checked: Two IKEA lights in a group, any_on works.

from deconz-rest-plugin.

I'm seeing events when a light's state.reachable becomes true, but not when it becomes false. For sensors, I'm seeing events both when config.reachable becomes true and when it becomes false.

from deconz-rest-plugin.

With v2.04.76 web socket notifications for changes to a sensor state or config seem complete, combining all attributes in a single notification. I still wonder if the notification should contain all attributes, or all changed attributes.

A notification appears for each sensor resource created when pairing a ZigBee sensor, and when deleting a ZigBee or CLIP sensor resource, but not when creating a CLIP sensor.

Notifications for changing a light or group state are still on the todo list.

from deconz-rest-plugin.

For me it would be sufficient to have only the changed attributes in the websocket. That is how I treat them anyway?

from deconz-rest-plugin.

I still wonder if the notification should contain all attributes, or all changed attributes.

For me it would be sufficient to have only the changed attributes in the websocket. That is how I treat them anyway?

See PR #198: through /config/websocketnotifyall you can set whether to include all attributes or only the changed attributes in the web socket notification.

from deconz-rest-plugin.

Closing the oldest issues for know to tidy up the tracker and duplicates in newer issues.

from deconz-rest-plugin.