Hi,
I'm controlling my lights with the Logitech Harmony Companion hub and remote. After updating from 2.04.35 to 2.04.40 the remote is not longer working. I thing there is a problem with the latest deCONZ library.

Hello:
I recently Acquired a Raspbee as well as a FLS-PP Ip Bundle (RGB) with LED Light Strip through the Dresden Elektronik Website. I configured the Raspberry Pi as mentioned in the guide and through deCONZ I am able to see the Raspberry Pi as the coordinator and the FLS-PP as an End-Device. Through the deCONZ app I am able to operate and change parameters and values of the LED strip, as well as turning it on and off.
The problem is, when I try to operate the lights through the Web App, it won't respond to the commands (it won't turn off and on the light, it won't change colour, etc.). The lightstrip is in a group and the latest update of the Web App is installed (2.04.18).
Is there something wrong I am doing? Or how can I fix this?

I just want to know if it possible to get a quick guide of how to implement the handling of other devices into the REST Api Plugin.

Like the request in Issue #5 I want to have more devices controlled by the API. There is no need to show them in the web interface or group them, they just should react on http requests.

Since you already use the REST API I would recommend to clone the repository and extend the API with the needed thermostat functionality.

This is exactly what I am on to do now, but already rest_lights.cpp and light_node.cpp have over 2000 lines of code and it is hard to figure out what to copy and what to change to get it done.

A short guide would be really helpful!

Hi,

I'm trying to get one of these to work and be visible in the REST endpoint:
https://www.amazon.de/gp/product/B01JJJ52JQ/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

What needs to be done? I can see the device in deCONZ GUI as such, but nothing in the REST. I've tried fiddling with the zcl files, but with no success

I am trying to set up RaspBee on ODroid-C2 (armhf) architecture. Is there any place where i can get binaries for it?

When I create a CLIP sensor, it's config and state attributes are empty. Trying to PUT {"on": true} to config returns an error 6, parameter, on, not available, but config.on is created anyway. Trying to PUT {"flag": true} to state gives no error, but nothing happens. Trying to put a valid attribute, but for another sensor type (e.g. state.temperature for a CLIPGenericFlag sensor), is also accepted.

Hi,

I couldn't find where deCONZ writes log files. Can they only be seen from UI or are they written to the disk somwhere?

Thanks

When accessed over IPv4, a GET of https://dresden-light.appspot.com/discover returns an empty array, [], even though a deCONZ gateway has been registered.

To reproduce:

curl -4 -s -H "Content-Type: application/json" "https://dresden-light.appspot.com/discover"

returns

[]

At the same time,

curl -6 -s -H "Content-Type: application/json" "https://dresden-light.appspot.com/discover"

returns (my formatting and masking)

[
  {
    "internalipaddress": "192.168.xxx.xxx",
    "internalport": 80,
    "id": "b8:27:eb:xx:xx:xx",
    "name": "pi",
    "macaddress": "b8:27:eb:xx:xx:xx"
  }
]

Today I installed the Ubisys D1 - I had to pull a neutral wire from the ceiling light point to the switch location. The light endpoint (indeed ZHA) is recognised immediately by deCONZ.
I added the light to the Trådfri remote group and now control my dining table lamp through that remote - very cool.

However, the two Dimmer switch endpoints of the D1 don't appear in the deCONZ REST API (v2_04_40). I wired two pulse switches to their inputs, just to see how they'd work. Not sure I'm gonna really need them, but I would be cool if they worked. The first input is still bound to the light itself (factory default) and works as documented.

Hi,
I was wondering if the support for some of the Xiaomi sensor is coming?
Especially the motion detector and the Xiaomi Aqara Smart Light.
Do you have any ETA for it?
Thank you!

Just running a little NodeJS program to monitor the deCONZ web socket messages. Potentially, this is brilliant functionality, but the current implementation seems very limited, see my observations below.

I would like to get rid of polling completely. May I suggest the following functionality:

1. WebSocket would send an event for any change (create, delete, attribute value change) to any resource (except config.localtime and config.utc). At a minimum, WebSocket would send an event for any change to a sensor or light state.
2. WebSocket would send different events for a change to a resource (top level) attributes, a change to a resource state attributes, a change to a resource config attributes.
3. WebSocket would either a) include the full resource/object, including all (top level, state, config) attributes, b) only the changed attributes, or c) no attributes at all. With c) I would just use the event as trigger to GET the resource. With b) I would be able to keep my cache up to date. With a) I wouldn't even need a cache, and forward the event directly to HomeKit.

Here are my observations:

I'm getting messages for my Hue motion sensors:

{"e":"changed","id":"22","r":"sensors","state":{"presence":false},"t":"event"}
{"e":"changed","id":"32","r":"sensors","state":{"lightlevel":0},"t":"event"}
{"e":"changed","id":"42","r":"sensors","state":{"temperature":1847},"t":"event"}

I'm receiving these messages when the sensor (state?) is refreshed, even when the reported state attribute hasn't changed. I would expect lastupdated (which has changed) to be reported in the message, or the message to appear only when the reported state attribute actually has changed value. With the current functionality, I would only be able to use the event as a trigger to GET the full sensor state (which is still better than polling the sensor).

While trying out CLIP sensors, I delete one and received a message:

{"e":"deleted","r":"sensors","sensor":{"id":"4"},"t":"event"}

However, I don't receive any message when creating a sensor, nor when changing a sensor name.

When changing a light state, I don't receive any message.

I have two OSRAM E14 Colour temperature lights (from the time before Philips released their E14 bulbs). I cannot set their colour temperature using a scene.

Here's the transcript of what I do (using my ph.sh bash script, which is just a wrapper around curl):

$ ph_put /groups/240/action '{"on":true,"bri":254,"ct":370}'
$ ph_put /groups/240/scenes/1/store '{"transitiontime":4}'
$ ph_get /groups/240/scenes/1
{
  "lights": [
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "244",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "241",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "242",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "243",
      "on": true,
      "transitiontime": 4
    }
  ],
  "name": "default",
  "state": 0
}
$ ph_put /groups/240/action '{"on":true,"bri":1,"ct":250}'
$ ph_put /groups/240/scenes/1/recall
$ ph_get /lights/243/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "ct",
  "ct": 370,
  "on": true,
  "reachable": true
}

The scene seems to contain the correct light states. When recalling the scene, the API reports the issued values (from the scene). However, the OSRAM bulbs actually have a ct value of 153. After having polled the lights, deCONZ reflects this:

$ ph_get /lights/243/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "ct",
  "ct": 153,
  "on": false,
  "reachable": true
}

Oddly this works, when using a similar setup for my Hue extended color lights. I'm not sure if this is caused by the OSRAM bulbs, or whether it's deCONZ issue with colour temperature lights. It might be related to issue #30 point 3: I see colorloop and xy are specified in the scenes table in the database (my formatting):

[
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "244",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "241",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "242",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "243",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  }
]

Since deCONZ 2.0.0, this repository is out of date.

Building this plugin and applying it to 2.0 breaks the web-app functionality as it's old.

When can we expect to see this repository updated with the latest rest plugin source?

Thanks

I did not complete the final step in the installation manual, but i still have access to the REST plugin. Is it time for an update of the manual, or is there some reason I don't understand for cloning and installing the plugin manually?

When doing a GET /lights, a GET /sensors or a full GET /, deCONZ returns the lights and/or sensors in alphabetical order ("1", "10", "11", ..., "19", "2", "20", ...), rather than in numerical order ("1", "2", "3", ... "9", "10", ...).

Hello,
I understand there is no headless version of deCONZ today. Any plans for that?

Thanks

When I keep deCONZ running overnight, it seems to "lose" lights. These "lost" lights show up red in the deCONZ GUI. Executing a command or reading the attributes from the Cluster Info panel fails. In the REST API, the light shows state.reachable as false. Changing the light state through the REST API returns error 3 (resource not available).

The only remedy to this situation seems to exit and restart deCONZ. When I disconnect deCONZ from the RaspBee, I tries to reconnect but crashes while discovering the lights. I do get core dumps for these crashes (30MB, still 5MB when gzipped).

After restarting deCONZ, the REST API only shows resources for the lights discovered in this session. It does immediately show all the sensor resources for the devices discovered in previous sessions.

I still have the RaspBee configured as router on the Hue bridge network. The lights that deCONZ has "lost", can be accessed from the Hue bridge.
My ZIgBee network contains 58 nodes: the RaspBee, the Hue bridge, 39 lights (mostly Philips Hue, some Osram, some innr, and one Ikea), 10 Hue motion sensors, 6 Hue dimmers, and 1 Ikea remote. Typically, the innr lights are the first to get "lost", but ultimately, this doesn't seem related to the light brand nor type.

As an aside: the Hue bridge regularly shows some random lights with state.reachable as false. I suspect this happens when the bridge doesn't receive an answer when polling the light. Typically the light state can be updated through the Hue bridge anyway, and state.reachable becomes true again in a couple of minutes, when the bridge receives an answer, the next time it polls the light.

hello,

it tried to compile the latest commit and it looks like the deconz.h file is missing in git?

/home/pi/DeConz/deconz-rest-plugin
pi@rasp-eg-verteilerkasten ~/DeConz/deconz-rest-plugin $ make
make -f Makefile.Release
make[1]: Entering directory '/home/pi/DeConz/deconz-rest-plugin'
g++ -c -pipe -Wno-attributes -Wall -Wno-attributes -O2 -std=c++0x -Wall -W -D_REENTRANT -fPIC -DDECONZ_DLLSPEC=Q_DECL_IMPORT -DARCH_ARM -DARCH_ARMV7 -DUSE_WEBSOCKETS -DGW_SW_VERSION=\"2.04.41\" -DGIT_COMMMIT=\"7b398f49b439114ee4a52794577c7661f771a379\" -DGW_MIN_RPI_FW_VERSION=0x260b0500 -DGW_MIN_DERFUSB23E0X_FW_VERSION=0x22030300 -DGW_DEFAULT_NAME=\"deCONZ-GW\" -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_SERIALPORT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/arm-linux-gnueabihf/qt5/mkspecs/linux-g++ -I. -isystem /usr/include -I../.. -I../../common -isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-linux-gnueabihf/qt5/QtWebSockets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtWidgets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtSql -isystem /usr/include/arm-linux-gnueabihf/qt5/QtNetwork -isystem /usr/include/arm-linux-gnueabihf/qt5/QtSerialPort -isystem /usr/include/arm-linux-gnueabihf/qt5/QtGui -isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -Irelease -I. -o release/authentification.o authentification.cpp
In file included from authentification.cpp:11:0:
de_web_plugin_private.h:24:20: fatal error: deconz.h: Datei oder Verzeichnis nicht gefunden
 #include <deconz.h>
                    ^
compilation terminated.
Makefile.Release:377: recipe for target 'release/authentification.o' failed
make[1]: *** [release/authentification.o] Error 1
make[1]: Leaving directory '/home/pi/DeConz/deconz-rest-plugin'
Makefile:34: recipe for target 'release' failed
make: *** [release] Error 2

i did search the complete pi/root directories but this file is not available.

best regards
holli

Setting the light state to {"on": true, "bri": 1} on a Extended color light (Philips Hue) or dimmable light (innr, ubysis) turns off the light. When setting {"on": true} afterwards, the light does come on at minimal brightness.

Setting only {"bri": 1} leaves the light on.

For Color temperature lights (OSRAM, IKEA) setting the light state to {"on": true, "bri": 1} leaves the light on, as expected.

Hi,

From time to time when I have done updates to the rest api, replaced the library and rebooted the pi all my devices are gone. I have even to reset all settings to be able to reconnect my devices. Is this a known issue? Is there anything I can do to avoid this (close down in a proper way (how)?, save setting and re-load if problem occurs?,...)?

This is a question rather than an issue but I don't know how to label the issue blush.

Regards

I found some more differences in error reporting between the deCONZ API and the Hue API.

When trying to create a username (POST /api) while the link button has not been pressed, the Hue bridge returns HTTP status code 200 OK with a body of:

[{"error":{"type":101,"address":"/","description":"link button not pressed"}}]

When trying to create a username while the gateway is still locked, the deCONZ REST API plugin (v2.04.40) returns HTTP status code 403 Forbidden. It still returns the error in the response body, but note the different value for address:

[{"error":{"address":"","description":"link button not pressed","type":101}}]

When trying to access a resource with an invalid username (e.g. GET /api/invalid/lights/1), the Hue bridge returns HTTP status code 200 OK with a body of:

[{"error":{"type":1,"address":"/lights","description":"unauthorized user"}}]

In this case, deCONZ returns status 403 Forbidden, again with an error in the response body, again with a different address:

[{"error":{"address":"api/invalid/lights/1","description":"unauthorized user","type":1}}]

I think the values for address should be changed to match the Hue API. As for the 403 status, I'm no HTTP expert so I'd better RTFM, or in this case the HTTP/1.1 spec (RFC 2616):

10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.

I'm not overly thrilled with the differences between the Hue and deCONZ APIs, but, looking at the spec, deCONZ behaves correctly.
I'm not too sure about the "request SHOULD NOT be repeated" part in the second statement for the create user. Typically, an app will want to repeat this request until the gateway has been unlocked.

Hi,
If I establish an web socket connection to the gateway all seems to be fine. however it seem that the first event after establishing a new connection get lost in most try’s.
For instance, If I switch off or on a group with two lights I get events for one of the lights and the group but the first light don’t got an event. On a second cycle all event’s are received as expected. That behaviour occurs in 9 of 10 cases. I tried it with chrome on Mac and Android, Safari and also with an client from the Chrome Webstore.
As an workaround it would be cool to emit an event to a newly connected client or better to implement the possibility to send some „Hello“ to the server and get an „World!“ back.
As I’m not an Developer, just an enthusiast, feel free to correct me. It could absolutely possible that I missed something.

I've finished my compatibility testing of the /lights resource against the Hue bridge API, see the Wiki. I've found the following differences, for which I would need to make changes to my Hue application:

1. deCONZ exposes state.bri for On/off plug-in units (and I assume On/off lights) that don't support brightness.
2. deCONZ exposes state.ct for Colour lights that don't support colour temperature;
3. deCONZ exposes state.hue, state.sat, and state.xy for Colour temperature lights, that don't support colour;
4. deCONZ exposes state.effect for lights that don't support colour (On/off plug-in units, Dimmable lights, Color temperature lights);
5. Setting "bri": 0 turns off the light. On the Hue API, this sets the light to minimal brightness. Note that setting "bri": 254 in deCONZ doesn't turn the light on.
6. deCONZ seems to convert the values of the corresponding ZigBee attributes for state.hue, state.sat, and state.xy, where the Hue API uses the raw values;
7. deCONZ exposes manufacturer instead of manufacturername;

In response to M-SEARCH, the deCONZ REST plugin identifies itself as SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.8.0 (upnp.cpp, line 128). However in the ssdp:alive message, it uses SERVER: FreeRTOS/6.0.5, UPnP/1.0, IpBridge/0.1 (line 89).

The Philips Hue bridge includes a line hue-bridgeid: 001788FFFExxxxxx (the bridge's mac address on the IP network), which makes it easier to identify the bridge. Could deCONZ use something similar?

I have a serious problem with the gateway at the moment.

Without any other changes on the raspberry the gateway switches after booting (or even while online) from port 8080 to port 80.

It seems also that some process starts the deCONZ automatically, maybe more than onetime.

I cannot find anything in the usual folders that are responsible for automatical (re-)starting of processes/programs.

As i run a webserver on port 80, the webserver is not working. Also i didn´t understand why/how deCONZ can use port 80 if it is occupied by the webserver.

I have three questions:

• how can i make 100% shure that, whoever starts deCONZ, deCONZ will use port 8080 or any other but 80 ?
• what are all the folders where some software from deCONZ is installed ?
• was there a change in the last two releases that can be responsible for this behaviour ?

deCONZ was running the last 4-5 weeks without any interruption....

Not sure if this has to do with rest-plugin or deconz itself, or maybe just the ballast-pp. Anyway here is the issue. I send bri, hue and sat to the bridge using the rest api. All parameters are acknowledged with success, however the ledstrip shows the wrong colour. Sending just the single parameter with the hue value sets the colour right. The behaviour seems only to apply to ballasts, philips hue spots seems to respond fine.

Using The colour control cluster in the deconz guy and doing an exec enhanced move to hue sets the colour also right in one go, but I guess this is comparable with just sending a hue command thru the rest api.

This isn't an issue, so my apologies if this isn't the correct place to raise this question.

I would like to use my RaspBee module to control HA profile thermostatic radiator valves (thermostat and temperature measurement clusters). I'm using OpenRemote at the moment to communicate over the REST API to deCONZ, and so I have a question about how best to communicate with my radiator valves.

Am I going to be able to extend the REST API to support my devices, or might I be better off using the C++ API to deCONZ?

Many thanks in advance for any assistance.

Hi,

Is there a updated documentation available? The documentation I can find is http://dresden-elektronik.github.io/deconz-rest-doc/ and parts of the api is as far as I understand not covered.

What I am looking for is documentation of the 'rules' part. Great if I just can get an example.

Regards

It is possible to use the RaspBee as a Router in the Hue bridge ZLL network? I understand that it won't actually talk to the Hue bridge. I'd like deCONZ to discover and interact with the devices connected by to my Hue bridge, without having to connect them to a different ZigBee network.

I suppose would require adding a ZLL endpoint with a ZLL Commissioning cluster to the RaspBee, but the deCONZ Network Settings won't allow me to add an endpoint.

Hello,

I just tried to compile the HEAD version of the rest plugin as described in the README, but the build fails with the following error message:

[...]
g++ -c -pipe -Wno-attributes -Wall -Wno-attributes -O2 -std=c++0x -Wall -W -D_REENTRANT -fPIC -DDECONZ_DLLSPEC=Q_DECL_IMPORT -DARCH_ARM -DARCH_ARMV6 -DUSE_WEBSOCKETS -DGW_SW_VERSION=\"2.04.43\" -DGW_API_VERSION=\"1.0.1\" -DGIT_COMMMIT=\
"f0f3e95c4083d0408acdc2e4c0724421d8b2a35a\" -DGW_MIN_RPI_FW_VERSION=0x260b0500 -DGW_MIN_DERFUSB23E0X_FW_VERSION=0x22030300 -DGW_DEFAULT_NAME=\"RaspBee-GW\" -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB -DQT_SQL_LIB -DQT
_NETWORK_LIB -DQT_SERIALPORT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/arm-linux-gnueabihf/qt5/mkspecs/linux-g++ -I. -isystem /usr/include -I../.. -I../../common -isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-li
nux-gnueabihf/qt5/QtWebSockets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtWidgets -isystem /usr/include/arm-linux-gnueabihf/qt5/QtSql -isystem /usr/include/arm-linux-gnueabihf/qt5/QtNetwork -isystem /usr/include/arm-linux-gnueabihf
/qt5/QtSerialPort -isystem /usr/include/arm-linux-gnueabihf/qt5/QtGui -isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -Irelease -I. -o release/de_web_plugin.o de_web_plugin.cpp
{standard input}: Assembler messages:
{standard input}:61496: Warning: end of file not at end of a line; newline inserted
{standard input}:61575: Error: unknown pseudo-op: `.uleb'
{standard input}:61170: Error: invalid operands (*UND* and .ARM.extab sections) for `-'
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile.Release:500: recipe for target 'release/de_web_plugin.o' failed
make[1]: *** [release/de_web_plugin.o] Error 4
make[1]: Leaving directory '/home/pi/deconz-rest-plugin'
Makefile:34: recipe for target 'release' failed
make: *** [release] Error 2

Compilation of the old versions of the plugin on my old wheezy installation succeeded without any problems. I switched to jessie for the newest version just now.

Can anybody help me?

Thanks,
David

Hi,
i´ve created a schedule which should switch off some lights after 20 seconds, but it doesn´t switch off the lights. Also switch on the lights doesn´t work.

Although the created schedule disappears after 20 seconds in the api (as it should)
Switching the same group on/off manually works.

Create Schedule: (with POST /api/api_key/schedules)
{
"name":"group_8",
"description":"group_8",
"command":{
"address":"xxx.xxx.xxx.xx:8080/api/api_key/groups/8/action",
"method":"PUT",
"body": { "on": false}
},
"time":"PT00:00:20"}

Answer from API:
[{"success":{"id":"25"}}]

Created Schedule:
{"25":{"autodelete":true,"command":{"address":"xxx.xxx.xxx.xx:8080/api/api_key/groups/8/action","body":{"on":false},"method":"PUT"},"description":"group_8","etag":"333d51dea86c3d6902eac1d66d21118e","name":"group_8 25","starttime":"2017-05-29T17:48:19","status":"enabled","time":"PT00:00:20"}}

By the way...websockets (motion, lights, plugs) are working very well in the beta.
Thanks for the good job !

Regards Georg

The scene REST API of the Hue seems to be independent of groups and have their own REST collection.

Are there any plans that deCONZ will add this too? (additionally or replacing the scenes tied to groups)? Looking at the code I did not recognize much technical reasons why scenes must depend on groups.

I could try to adapt the REST plugin by myself if it is not planned or already in progress.

Currently, it is possible to search for a server simply sending a GET request to https://dresden-light.appspot.com/discover.

Is there a way to get the code that is actually running there? Goal is it to do the search offline.

When I delete a user from the whitelist (DELETE /api/<username1>/config/whitelist/<username2>), it no longer shows in the whitelist, but deCONZ still accepts requests for the deleted user (e.g. GET /api/<username2>/lights/1). After a while, deCONZ crashes with a Segmentation fault (core dumped). After restart, the deleted user is back in the whitelist.

Looking in the zll.db database, the users aren't delete from the auth table after doing the API call. It looks like deCONZ crashes when trying to update the database, because of some other activity (in this case, discovering one of my Hue motion sensors). Here's the output of deCONZ --dbg-info=1:

16:22:53:850 SensorNode id: 8 (Washroom Temperature) available
16:22:53:850 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0001 on endpoint 0x02
16:22:53:850 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0402 on endpoint 0x02
16:22:53:850 SensorNode id: 6 (Washroom Light Level) available
16:22:53:850 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0001 on endpoint 0x02
16:22:53:850 discard double entry in binding queue
16:22:53:850 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0400 on endpoint 0x02
16:22:53:851 SensorNode id: 7 (Washroom Motion) available
16:22:53:851 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0001 on endpoint 0x02
16:22:53:851 discard double entry in binding queue
16:22:53:851 0x0017880102xxxxxx (SML001) create binding for attribute reporting of cluster 0x0406 on endpoint 0x02
16:22:53:851 added ZCL value 0x0406/0x0000 for 0x0017880102xxxxxx
16:22:53:869 added ZCL value 0x0400/0x0000 for 0x0017880102xxxxxx
16:22:56:474 Bind response success
16:22:56:496 Bind response success
16:22:56:517 Bind response success
16:22:58:922 save zll database
Segmentation fault (core dumped)

I've put the gzipped core on Dropbox.

deCONZ v2.04.40 on a Raspberry Pi 3 Model B, uname -a reports:

Linux pi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux

Hello!
3rd party apps like the original Philips Hue App can connect and also control brightness and color temperature of the lights. However changing the color does not work.
As far as I could see the 3rd party apps only set the x and y values of the color (in the http JSON Post) and not the hue and saturation. This does not seem to be properly handled by the plugin.

on latest commit..

I can see the map in touchlink, it blinks and resets, but it isn't discovered on the main page. I have the feeling I am doing something wrong here..

Hi,
i´m using deconz-2.04.40 on a raspberry pi 3 with Jessie and a ZigBee addon board.

REST API is working fine (nearly like the HUE api-:) )
Webapplication is also working very fine and fast.

But, i have big problems to get anything useful out of the websockets. I´m connected to port 443 (seems to be free on my raspberry) and can connect. At least i think so...because there is no error and i get some bytes from the server.

This is my config:

"apiversion":"1.0.0","dhcp":true,"gateway":"192.x.x.x","ipaddress":"192.x.x.x","linkbutton":false,"localtime":"2017-05-06T12:16:05","mac":"x:x:x:x:x","name":"deCONZ-GW","netmask":"255.255.255.0","networkopenduration":60,"panid":62156,"portalservices":false,"proxyaddress":"none","proxyport":0,"swupdate":{"notify":false,"text":"","updatestate":0,"url":""},"swversion":"20440","timeformat":"24h","timezone":"Europe/Berlin","utc":"2017-05-06T10:16:05","uuid":"d0cffba6-d5d0-45e0-ad64-db8330a8a90d","websocketport":443,"whitelist":{"2D6E7F6E20":{"create date":"2017-05-06T07:19:51","last use date":"2017-05-06T10:06:55","name":"deCONZ WebApp"},"B2AC314636":{"create date":"2017-05-05T12:06:46","last use date":"2017-05-06T10:15:58","name":"deCONZ WebApp"},"D2BB70681D":{"create date":"2017-05-05T12:50:00","last use date":"2017-05-06T10:16:05","name":"4711"}},"wifi":"not-installed","wifiappw":"","wifichannel":"1","wifiip":"192.168.8.1","wifiname":"Not set","wifitype":"accesspoint","zigbeechannel":15}

I´ve included as a test one HUE Bulb and i can switch it, dimm it etc.
But there is no output on the websocket...i´ve expected that there is some kind of JSON output when i switch the bulb on/off.

I´ve tried it with PHP/Python/HTML etc. client sockets, but nothing worked. Only some bytes after the start of the connection.

Output of the client socket (in this case it was a small python script, but looks similar if i use php) and after this nothing more...:

**--- request header ---
GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 192.168.178.40
Origin: http://192.168.178.40
Sec-WebSocket-Key: 3i6eMLAG4U8PWC483MKIIA==
Sec-WebSocket-Version: 13

--- response header ---
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: TeOUveApLCI5/J02aLtp/ctEUNM=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Sa., 06 Mai 2017 10:37:13 GMT
-----------------------**

Can you please advice me (or a kind of php/python example script) how to get a correct client connection to the deconz websockets and get a JSON output if something changes on the zigbee network or in deconz server?

Regards Georg

Hi,
I was wondering if the support of the Hue Tap is coming, do you have any ETA for it?
Thank you!

When I issue a POST to /api/<username>/lights the deCONZ REST API responds: [{"success":{"/lights":"Searching for new devices"}}]. The Wireless Light Control web interface shows that the network is open for new devices. However, when doing a GET of /api/<username>/lights/new, it always returns {"lastscan":"2012-10-29T12:00:00"}, even when the search is active.

When I issue a POST to /api/<username>/sensors, the API responds: [{"success":{"/sensors":"Searching for new devices","/sensors/duration":60}}]. Again, the web interface shows that the network is open. A GET of /api/<username>/sensors/new returns {"lastscan":"active"}. After the search is done, it returns: {"lastscan":"2017-04-21T15:44:57"}.

When I open the network from the Wireless Light Control web interface, /sensors/new reports an active scan, but /lights/new doesn't. When I open the network through POST /lights, /sensors/new doesn't show an active scan. According to Wireshark, the web interface PUTs {"permitjoin": 60} to /api/<username>/config

On the Hue bridge, /lights/new and /sensors/new always return the same value for lastscan, regardless whether the search is initiated from POST /lights or POST /sensors.

Hi...
Is it hard to get Xiaomi Temp/Humidity sensor to work?
I've looked att the code... but I don't know where to start...
My C++ Isn't that good...
I guess I have to add it in 'de_web_plugin.cpp' and 'sensor.cpp'?
it's added to deCONZ... http://imgur.com/a/TwUvH

I've found this in the SmartThings forum... maybe some help?
https://community.smartthings.com/t/xiaomi-zigbee-door-window-sensor-motion-sensor-smart-button-device-type-beta/31948/144

Data comes in as
Parsing 'read attr - raw: 5C14010000240500420E6C756D692E73656E736F725F6874, dni: 5C14, endpoint: 01, cluster: 0000, size: 24, attrId: 0005, encoding: 42, value: 6C756D692E73656E736F725F6874'
Update:
Updated log
Parsing 'humidity: 41.73%'
Parsing 'temperature: 27.24'

I'm new to deCONZ, just received my RaspBee today. I would like to adapt my homebridge plugin for the Philips Hue bridge to work with deCONZ and maybe in the long run ditch the Hue bridge all together.

I managed to connect some of my lights, a Hue tap, a Hue dimmer switch and a Hue motion sensor to deCONZ. The latter isn't supported - I would like to add support for it. Any pointers on how to do that would be much appreciated.

hi. let's say i had a computer (Mac, RPi, BBB, etc.) that ran some unix/linux OS and i had a deRFusb23e0x wireless USB dongle.

what would i need to do to get the rest plugin running?

my goal is to write a node-deaconz-rest package for node.js which will talk to the deRFusb23e0x directly. i suspect that would be quite a bit of work, so the interim project is just to get the rest plugin running on a local server and then use node.js to talk to the REST service.

thanks!

IKEA has launched some more products in their Trådfri line. I have gotten the lights to work, but not remotes. They also have motion sensors now, which I guess will not work either.

de_web_plugin.cpp has a comment about IKEA remote not being supported yet. Is this because of the web-plugin of the core of deCONZ? Is there some work being put in to make this compatible?

I have managed to get the remote to show up in the deCONZ GUI and it has that blue indicator-dot that blinks when I push buttons. So something seems to be working at least. The logs (using --dbg-aps=2) shows the proper cluster being activated when i push the respective button, but there is nothing indicating if it was (for instance) brightness up or down that was pushed.

Compilation of deconz-rest-plugin (v2.04.35) fails with

de_web_plugin.h:30: Error: Undefined interface
Makefile.Release:224: recipe for target 'release/moc_de_web_plugin.cpp' failed
make[1]: *** [release/moc_de_web_plugin.cpp] Error 1
make[1]: Leaving directory '/usr/local/src/deconz-rest-plugin
Makefile:34: recipe for target 'release' failed
make: *** [release] Error 2

There were no errors when compiling previous versions.

Hi,

I would like to use the software, but the GPIO Pins of my Raspberry are in use,
besides the links of the addon module, you write smth. about a "deRFusb23e0x wireless USB dongle". But unfortunately this one is not linked & my google search wasn't that successful either.

Is it one of the ones listed here: https://shop.dresden-elektronik.de/radiosticks.html ?
Would be really cool if you could provide a link.

Thanks.
Cheers.
Sebastian

Hi..
I'm running deCONZ and openHAB on the same raspberry pi.
On openHAB I have Hue Emulation, so that I can control everything on my Google Home.
I had to setup two IP's, so that both deCONZ and openHAB could show Hue devices...
The thing is that REST API plugin sets servers on all IP's... is there a way I can restrict it to one IP address?

and a side note..
this is my first (getting to know) with ZigBee..
I hope that deCONZ (REST API plugin) will support IKEA's trådfri devices.. including the dimmer :)
by the way, my IKEA trådfri motion sensor is recognized as a light but sets up a group that reacts to it's sensor... took a while before I figured it out :)

Thanx for a great product, and looking forward to the update and code refactoring... :)
Party, then code (or both) ;)

Functions such as - GET /api//lights/ as well as PUT /api//lights//state - return floats for fields such as state.hue state.bri which is incorrect - they should return normal integers !

Hi,

Based on following the instructions.

I cloned this repository and replaced the rest plugin I got with the latest deCONZ installation (2.04.18) with a fresh build from the clone. I suspect that this repo isn't updated. E.g. the 2.04.18 deCONZ installation recognize IKEA of Sweden as a manufacturer but not the fresh build from this repo.

Do you keep this repo up to date?

Also tried "git clone --branch V2_04_18 --depth 1 https://github.com/dresden-elektronik/deconz-rest-plugin.git" but that gives me build errors.

Does the instructions for this repo guarantee me to get a clone that are compatible with the latest version of deCONZ?

When specifying unsupported attributes in a PUT request body, deCONZ silently ignores these attributes, whereas the Hue bridge responds with an appropriate error. For example, when PUTing the following body to /api/<username>/lights/1/state:

{
  "on": true,
  "unsupported": true
}

deCONZ responds with (my formatting)

[
  {
    "success": {
      "/lights/1/state/on": true
    }
  }
]

whereas the Hue bridge responds with (again, my formatting):

[
  {
    "error": {
      "type": 6,
      "address": "/lights/1/state/unsupported",
      "description": "parameter, unsupported, not available"
    }
  },
  {
    "success": {
      "/lights/1/state/on": true
    }
  }
]

When specifying only unsupported attributes, deCONZ returns no response body (not even a body with an empty array).

I found out by accident, trying to PUT {"linkbutton": true} to /api/<username>/config to unlock the gateway. Wireshark revealed that the Wireless Light Control web app actually PUTs {"unlock":60} to unlock the gateway. I probably should have RTFM... Then again, for Hue API compatibility, the deCONZ API should accept {"linkbutton": true} as an alias for {"unlock":60} and {"linkbutton": false} as an alias for {"unlock":0}.

Hi,

as the title says. I have a deRFUSB stick and would really like to use the API instead of the cumbersome GUI.