How To : get more settings available in REST client

Phoscon App General Support
1

Product : ConBee II
Version : 2.12.06 / 19/08/2021
Firmware : 26660700

Home Domotica system : Domoticz (beta channel)
Hardware : raspberry pi 4

I have installed a Tradfri driver and it works, however there are settings in the driver that I can edit through deCONZ but I cannot find them in the REST client. (especially the transition time)

rest
rest1421×679 125 KB

Domoticz is using the deCONZ bridge (https://github.com/Smanar/Domoticz-deCONZ) that uses the REST api to communicatie. It seems that the REST api does not expose all settings but only a subset.

Can these (writable) attributes somehow be added to the REST client ? If so, how should that be requested ?

2

Not all attributes are accessible throught the API. There is too much, easier to use the GUI.
But for the transition time you have it, this setting is not visible but you can just add it in the request itself.

But by defaut domoticz use “transitiontime” = 0 if there is no “bri” in the json, perhaps because of that

Transition time in 1/10 seconds between two states. Note that not all states support a transition time. For example, a transition time when setting

on

will be ignored as the Zigbee On and Off commands do not support transition times. In general, light attributes that support a range of values support transition times, while boolean values do not.

You can try with making tests using direclty the API ( Getting Started - deCONZ REST-API ), if it works for your device and if it’s only the missing parameter, I can make a hack in the domoticz plugin (using comment on the device widget on domoticz can add this one on the request)

3

I tested my Tradfri dimmer with the following: (starting from light OFF)

[PUT http://192.168.199.20:8088/api//lights/4/state](PUT http://192.168.199.20:8088/api//lights/4/state)

{"on": true, "bri": 250, "transitiontime": 200}

Light switches ON at lowest dimming possibility and dims up in 20 seconds to 250 (nearly 100%)

{"on": true, "bri": 0, "transitiontime": 200}

Light dims back to lowest dimming possibility but remains ON (at lowest dimmed possibility)

– Then dim back to bri 250 –

{"on": false, "bri": 0, "transitiontime": 200}

Light dims back to lowest dimming possibility but and then switches OFF

When dimming from Domoticz in deCONZ log I only see

12:28:08:029 HTTP API PUT /api//lights/4/state - 127.0.0.1
12:28:08:030 Text Data: {“on”: true, “bri”: 254}

Transition time is missing. However, then I would have expected the default setting from the driver to be used, and that is not the case. Somehow, when the transitiontime is not in the data, it defaults to 0 and still overrules the driver’s setting

Added logging from deCONZ from the command initiated from the REST client.:

12:46:41:069 HTTP API PUT /api/<api key>/lights/4/state - 192.168.199.113
12:46:41:070 Text Data: 	{"on": true, "bri": 250, "transitiontime": 200}
12:46:41:071 ApiMode: 0
12:46:41:072 [{"success":{"/lights/4/state/on":true}},{"success":{"/lights/4/state/bri":250}}]
12:46:41:138 delay sending request 164 dt 0 ms to 0xCC86ECFFFE9A6167, ep: 0x01 cluster: 0x0006 onAir: 1
12:46:41:138 delay sending request 166 dt 0 ms to 0xCC86ECFFFE9A6167, ep: 0x01 cluster: 0x0008 onAir: 1
12:46:41:223 	0xCC86ECFFFE9A6167 force poll (2)
12:46:41:240 delay sending request 166 dt 0 ms to 0xCC86ECFFFE9A6167, ep: 0x01 cluster: 0x0008 onAir: 1
12:46:41:279 ZCL attribute report 0xCC86ECFFFE9A6167 for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
12:46:41:292 ZCL attribute report 0xCC86ECFFFE9A6167 for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
12:46:41:360 delay sending request 166 dt 0 ms to 0xCC86ECFFFE9A6167, ep: 0x01 cluster: 0x0008 onAir: 1
12:46:41:387 	0xCC86ECFFFE9A6167 force poll (2)
12:46:41:464 	0xCC86ECFFFE9A6167 force poll (2)


12:47:01:445 Device TTL 888 s flags: 0x7
12:47:01:555 ZCL attribute report 0xCC86ECFFFE9A6167 for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000

Exactly 20 seconds after the command was given, the device seems to report back. I do not know the exact meaning, but I can imagine it is the response on being finished with the transition and/or being switched ON

4

Good question, If you look at the GUI on the request “move to level” you need to specify a value for transition time, idk how to use to use the driver’s setting.

From the specification the attribute 0x0010 is to be used for the other cluster, the 0x0006

The OnOffTransitionTime attribute represents the time taken to move to or from the target level when On of
Off commands are received by an On/Off cluster on the same endpoint. It is specified in 1/10ths of a second.
The actual time taken SHOULD be as close to OnOffTransitionTime as the device is able. N.B. If the device
is not able to move at a variable rate, the OnOffTransitionTime attribute SHOULD not be implemented.

So IDK if it s the same thing.

BTW what are you need ? You need a fixed transition time used with a “set level” request ?
If it s that I can add a hidden setting on the domoticz widget. But it will be fixed ?

5

Smanar, I am not so deep into all this zigbee.

The spec says it should use this 0x0010 when an On of Off is received. When I use the rest client with 20 seconds transition time, in the deCONZ display I can see the 0x0001 Remaining Time is counting down, but I cannot see the 200 1/10th of seconds setting.

Is it possible whe there is no transition time in the json with the “bri”, that the value of 0x0010 attribute is used ? That value can be read by deCONZ, but not from the REST api or Domoticz. Then I guess it should be added somewhere in the deCONZ software.

6

When you make the request

{"on": true, "bri": 250, "transitiontime": 200}

You are not using the cluster on/off, so from that I m understand, you don’t use this setting.

Try to make a test using the GUI in the cluster 0x0006, just the “on” or “off” request.
Can be too the request “move to level (with off/on)” from the cluster 0x0008.

The request use the “move to level” request in the cluster 0x0008 and there is a field “transition time”, and IDK if putting something here can make the use of the attribute 0x0010

Edit:
I have perhaps found something

If the Transition time field takes the value 0xffff then the time taken to move to the new level SHALL instead
be determined by the OnOffTransitionTime attribute. If OnOffTransitionTime, which is an optional attribute,
is not present, the device SHALL move to its new level as fast as it is able.

Can you tried with the GUI but using 65535 as transition time ?

7

I have tried from the deCONZ gui in cluster control 0x0008 (Level Control Cluster) the “Move to level” with level either 0 or 254 and transition time 65535. I have changed the OnOff Transition Time attribute to 100 (==10sec). Pressing the exec button then indeed dims up or down using the 10 seconds.

In the REST API client I then tried

{"on": true, "bri": 0} --or-- {"on": true, "bri": 254}

and

{"on": true, "bri": 0, "transitiontime":65535} --or-- {"on": true, "bri": 254, "transitiontime":65535}

Both do not honor the 10 seconds dimming time. The first without “transitiontime” switches nearly immediately, the one with 65535 seems to get stuck (remaining time stays fixed at 65287 which is 248 difference from 65535)

8

Edit:
So it work using the GUI but not using the API ?

I think it 's because this “lock”

        const uint tt = map[param].toUInt(&ok);
        if (ok && tt <= 0xFFFF)
        {
            valueOk = true;
            hasTransitionTime = true;
            taskRef.transitionTime = tt > 0xFFFE ? 0xFFFE : tt;
        }
    }
9

Correct: It works with the GUI but not with the API.

I am not sure where the code comes from but it dissallows transition time to become -0xFFFF ever
EDIT: meanwhile I found the code snippet

tt > 0xFFFE ? 0xFFFE : tt

I also not aware of the spec, but is 0xFFFE allowed as transition time ?

10

Yep at least in 2 place the code prevent the use of the value 0xFFFF.

but is 0xFFFE allowed as transition time

I think yes for 6553 s ^^

I have asked on dev discord, no reactions. Do you have a linux machine with full OS to test a code modification ?

11

6553,4 seconds waiting for the light to go Off :laughing: That’s a boring wait (> 1.8 hours)

I run my deconz on a raspberry pi 4, so yes that is a full OS “machine” but maybe not what you meant. I can create a VM on my PC if necessary. But then probably I need some instructions what to do and what to test.

12

I mean you don’t use docker or OS “light”.

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing
So for you, after having installed deconz :

sudo apt install deconz-dev
git clone --branch test_transitiontime https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

You have my code change here https://github.com/Smanar/deconz-rest-plugin/commit/064f882adb87f7e568ca41c10ddcfaa4d238b3af

And I don’t found how to see the request in logs, I hope the modification will change something.

But be sure you are using the last deconz version, because it will update your lib file to the lastest possible.

13

I have deCONZ v2.12.6, Qt 5.11.3, GCC 8.3.0 (C++201402), commit d39d01, firmware 0x26660700

this is my “production” machine. I need to be sure that I can build back to present situation and how to do that before I can use it to test.

EDIT: Will take some days to get time for this

14

Had a short readup on https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf

Chapter 3.10.2.3 Attributes … Maybe the 0xFFFE mistakenly was taken from Identifer 0x0012 or 0x0013 instead of the correct 0xFFFF from 0x0010

15

Ha yes right, I think too.

I have deCONZ v2.12.6, Qt 5.11.3, GCC 8.3.0 (C++201402), commit d39d01, firmware 0x26660700

this is my “production” machine. I need to be sure that I can build back to present situation **and** how to do that before I can use it to test.

EDIT: Will take some days to get time for this

The new deconz version have implemented DDF, so I realy think it s better to start from the new one, lot of changes on deconz since your version.

There is no danger if you rebuild the library, you can just make a backup of the previous file libde_rest_plugin.so in another folder and make a rollback if you have issue.
This code will just recompile the library used by deconz. It don’t have impact on network config or device database.
But using a new library version on an older deconz version can be more random, deconz is moving a lot ATM.

16

Happy new year ^^
Some news from your tests ?