Deconz-rest-plugin: Short guide on how to use other devices than Lights and Sensors

[cfrahnow]

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!

[manup]

Hi, right now there is no guide other than studying the REST API plugin code. Making a guide to include a certain device is difficult because we try to keep things as generic as possible to prevent writing driver code for each device.

Do you have a specific device in mind, maybe I can give some advice?

[cfrahnow]

Hey, thanks for your quick answer!
Currently I am trying to get the INNR Smart Plug working.
Later on I will try to get on to the Window Sensor.
I also could use other devices that do the same if you already have working code for that.

[ebaauw]

I would expect the innr smart plug to be supported as a light. The OSRAM plugs are. However, on their website innr warn that their smart plug don't connect to a Philips Hue bridge where the OSRAM plugs do.

I'd be very interested in your experiences with the door/window sensor.

Would it be an idea to start a guide collectively on the Wiki for this repository?

[cfrahnow]

I would expect the innr smart plug to be supported as a light.

Unfortunately it is not supported as a light. But i found the spot where the type is figured out so i just added my plug as a light as well as the sensor (See my commit). All clusters that lights have in common with the plug are now supported.
But since I think this is just a dirty hack, I will now try to make other devices independend of lights.

Would it be an idea to start a guide collectively on the Wiki for this repository?

I think it would. But an update was promised 6 days ago for the next few days. I think starting before that update is not useful.

Some general refactoring of the code would be cool, since functions with more than 500 lines of code are really really hard to read and understand.

[ebaauw]

But i found the spot where the type is figured out so i just added my plug as a light as well as the sensor (See my commit)

Brilliant - I want to (try and) add the temperature sensor in the Hue motion sensor and disable the switches deCONZ sees in them, see issue #20.

Do you currently support the sensor as a light as well?

[cfrahnow]

Do you currently support the sensor as a light as well?

Yes, but the sensor and lights only have clusters like the basic cluster in common. So I cannot interact with it.

By the way, don't be shocked by the huge change in the commit. It is just copied from light, and all light types replaced with the plug and the sensor.

[manup]

Hi, I've checked your commit, according to the ZigBee HA specification the Innr device id 0x0051 is a Smart Plug. Since this device supports the on/off server cluster 0x0006 it should be sufficient to add the device type in the function addLightNode() in the HA Profile filter.

To keep it generic the proper define for the device id should be added to de_web_plugin_private.h under generic devices:

#define DEV_ID_HA_SMART_PLUG 0x0051

The Nyce window sensor is a ZHA IAS Zone, this is a bit more complicated, but should just work with the next update because we added general support for IAS Zone devices, you can have a look then how it's done.

[manup]

Small correction: the device id should also be added in the light_node.cpp setHaEndpoint() method.

[cfrahnow]

Cool, this is exactly what I did in that commit, with the exception of naming it INNR_SMART_PLUG instead of DEV_ID_HA_SMART_PLUG.

[cfrahnow]

@manup Do you already have a date for the update? ASAP would be sooooo nice!

[manup]

It won't be long, I currently check that nothing is broken in the WebApp due the API advancements and refactoring — after that the code and binary will be published. Depending on the weather and party situation on weekend this may take 2–5 days :) As usual the documentation of the new features like various switches and sensors will take a few days longer.

[cfrahnow]

Firstly thanks for the updates. Now more devices can be found, which is great!

The Nyce window sensor is a ZHA IAS Zone, this is a bit more complicated, but should just work with the next update because we added general support for IAS Zone devices, you can have a look then how it's done.

Does that work already? And if yes, how is it done? (Is it possible to call a url when the sensor recognizes a change without actively asking it continously?)

[manup]

Thanks, improving the switches and sensors support is very important to us. I don't have the Nyce sensor for testing but it won't work with the last beta version 2.04.40 since the sensor is not in the supported device list yet.

Can you please provide the following:

• Nyce manufacturer code, visible in Node Info panel
• basic cluster model identifier

I'll add them to the supportedDevices array code. Therefore in the next beta release, the sensor should be recognized.

Beside polling via GET /api/<apikey>/sensors/<id> the presence signal can be catched without delay with the new Websocket feature.

http://dresden-elektronik.github.io/deconz-rest-doc/websocket/

[cfrahnow]

• Manufacturer code: 0x10b9
• Model Identifier (from the Basic Cluster): 3011

[cfrahnow]

Hey,

I'll add them to the supportedDevices array code. Therefore in the next beta release, the sensor should be recognized.

do you already know, when the next beta will come out? Or how much efford does it take to do it myself? Because basically I need this functionality until tomorrow.

[manup]

The beta will be released in the next days. But if it is of any help I can push the related updates to the repo and you can compile the plugin by yourself?

[cfrahnow]

This would really help if it includes the update to make the NYCE window/door sensor work. Otherwise I will wait for the release.

[manup]

The related commits are up. When the network is open, the sensor must be rejoined to the network after reset it to factory new; then a new presence sensor should be created.

Not sure how to reset the sensor though, but the doc should help:

http://nycesensors.com/wp-content/uploads/2016/03/NCZ-3011-C4-Install-Guide-2014-11-19.pdf

[cfrahnow]

Thank you very much, the sensor is now found. When GETing \api\sensors\id
It responds with
{ "config":{"on":true,"reachable":true}, "ep":1, "etag":"24aa1b73cf318d8534de83ea7d52b929", "manufacturername":"NYCE", "modelid":"3011", "name":"ZHAPresence 1", "state":{}, "swversion":"b80", "type":"ZHAPresence", "uniqueid":"00:0d:6f:00:0c:ef:48:1c-01-0500" }
And the device blinks orange-green-orange for a while and then switching to orange-red-orange. Regarding your link this means it is stuck in configuration and then searching for a network. Any ideas why?

[buzzdev]

@manup Hi Manu, i've just bought RaspBee and ConnBee. Could you please invite me to your documentation repo? Thanxs

[manup]

@manup Hi Manu, i've just bought RaspBee and ConnBee. Could you please invite me to your documentation repo? Thanxs

Done, I'll close this issue for now.