deconz-rest-plugin: turn off with transition (fade out) stopped working in home assistant deconz addon

Tbh, I don’t have enough info to assess whether there’s a bug in deCONZ or not. Also the “me too” remarks don’t help, with similar symptoms in a completely different setup (e.g. recalling a ZIgbee scene, or updating the action of a groups resource).

As I said before, Zigbee doesn’t take a transition time with an Off command, so you would have to use a Off with Effect command, or a Move to Level (with On/Off). To make matters worse, not all ligts implement these commands correctly, which resulted in lot of ugly whitelisting in the legacy code.

To fully analyse this issue, I would need to know:

1. What lights does this concern? Ideally screen dump of the Basic cluster and listing of the lights resource;
2. Check in the GUI how the light reacts to:

• Off;
• Off with Effect;
• Move to Level (with On/Off) with a level of 0 and a transition time of, say 20 (2s).

1. Check whether the light is exposed by legacy code or through DDF, in which case, attach the DDF.
2. The precise body to the PUT of the state of the lights resource.
3. The Zigbee commands sent by deCONZ as a result of the PUT (either from the deCONZ log or from a Zigbee sniffer).

If the behaviour changes between versions, we need to understand whether that’s because 4) has changed (in which case the API client does something else), or because 5) has changed.

Does this mean there is no bug and we need to change de DDF for the bulbs which encounter this problem?

Possibly, when:

• 2 shows that the light behaves as intended to Off with Effect, but not to Off;
• 3 shows that the device is exposed by legacy or by a DDF without off_with_effect;
• 4 shows that the PUT body sent by HA hasn’t changed;
• 5 shows that the Zigbee commands sent by deCONZ did change (from Off with Effect to Off).

Yes, but when you reboot it probably stops working.

You mean about the Bronze status? Exactly, that’s how I figured that it’s the culprit.

So keep it on gold. No problem with that.

@Mimiix When I know what to ask and how to formulate the question, then I generally do ask on Discord. This topic is however quite above me, and I don’t want to be that guy with the question “How do I create DDF” because I’m -honestly- not really interested how the sausage is made, I just want to see it working (I am however happy to provide helpful data to someone with better understanding of this whole thing). Secondly, I’m still not really sure what the issue is, as in current and previous versions there was no DDF for my Osram bulbs, however before they were working properly and now they are not. Something somewhere changed between 2.19x and 2.20.x that impacted this change and I really do not know how to get that information.

See https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6316.

So here is my situation. And to be honest, the more I look into it, the less sense it makes. To briefly summarize, my problem is with dimming to Off state from HA. Last version of deCONZ that worked properly in my case was v2.19.3, so below I’ll reference it vs the last one (v2.21.2).

1. I have a bunch of Osram CLA60 TW bulbs, here’s info for one of them:

"22": {
        "capabilities": {
            "alerts": [
                "none",
                "select",
                "lselect"
            ],
            "color": {
                "ct": {
                    "max": 370,
                    "min": 153
                },
                "modes": [
                    "ct"
                ]
            }
        },
        "colorcapabilities": 16,
        "config": {
            "groups": [
                "0",
                "6"
            ]
        },
        "ctmax": 370,
        "ctmin": 153,
        "etag": "41b84fc6ae4d491ceca7a37150a7d7a1",
        "hascolor": true,
        "lastannounced": "2023-05-07T09:23:33Z",
        "lastseen": "2023-05-08T10:07Z",
        "manufacturername": "OSRAM",
        "modelid": "CLA60 TW OSRAM",
        "name": "Boravak TV light",
        "state": {
            "alert": "none",
            "bri": 166,
            "colormode": "ct",
            "ct": 370,
            "on": false,
            "reachable": true
        },
        "swversion": "V1.05.10",
        "type": "Color temperature light",
        "uniqueid": "7c:b0:3e:aa:00:af:78:ef-03"
    }

1. In the deCONZ GUI all of the commands work as expected (On, Off, Toggle, Off with effect, Move to level(with On/Off)), on both versions.

2. There is no DDF associated with this bulb. Does it mean that it uses generic “color_temperature_light.json” or something else?

4&5) Below is a c/p of deCONZ log for HTTP & APS & APS_L2 for both versions. I manually run parts of the HA automation that turns light on, and couple of seconds later turns it off with transition set to 10s. (Bulb is number 22 and it’s MAC address is 0x7cb03eaa00af78ef)

2.19.3

ON

11:41:09:998 HTTP API PUT /api/93A612956E/lights/22/state - xxx.xxx.xxx.200
11:41:09:999 Text Data: 	{"bri":166,"on":true}
11:41:09:000 ApiMode: 0
11:41:09:000 APS-DATA.request id: 147, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0008, ep: 0x01 -> 0x03 queue: 0 len: 6 tx.options 0x04
11:41:10:001 	asdu (length: 6): 117204020000
11:41:10:002 [{"success":{"/lights/22/state/on":true}},{"success":{"/lights/22/state/bri":166}}]
11:41:10:066 APS-DATA.request id: 146, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x03 queue: 1 len: 3 tx.options 0x04
11:41:10:067 	asdu (length: 3): 117301
11:41:10:067 APS-DATA.confirm id: 147, status: 0x00 SUCCESS
11:41:10:068 APS-DATA.confirm request id: 147 -> erase from queue
11:41:10:114 aps request id: 147 finished, erase from queue
11:41:10:121 APS-DATA.request id: 148, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0008, ep: 0x01 -> 0x03 queue: 1 len: 6 tx.options 0x04
11:41:10:122 	asdu (length: 6): 117400a60400
11:41:10:124 APS-DATA.confirm id: 146, status: 0x00 SUCCESS
11:41:10:126 APS-DATA.confirm request id: 146 -> erase from queue

.....not really sure what this part is, something color related, but it's the same bulb so I included it....

11:41:12:743 APS-DATA.request id: 165, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0300, ep: 0x01 -> 0x03 queue: 0 len: 9 tx.options 0x00
11:41:12:744 	asdu (length: 9): 107600070008000140
11:41:12:820 APS-DATA.confirm id: 165, status: 0x00 SUCCESS
11:41:12:821 APS-DATA.confirm request id: 165 -> erase from queue
11:41:12:853 aps request id: 165 finished, erase from queue

OFF

11:41:17:519 HTTP API PUT /api/93A612956E/lights/22/state - xxx.xxx.xxx.200
11:41:17:520 Text Data: 	{"bri":0,"on":false,"transitiontime":100}
11:41:17:521 ApiMode: 0
11:41:17:522 APS-DATA.request id: 202, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0008, ep: 0x01 -> 0x03 queue: 0 len: 6 tx.options 0x04
11:41:17:522 	asdu (length: 6): 117904006400
11:41:17:523 [{"success":{"/lights/22/state/on":false}}]
11:41:17:602 APS-DATA.confirm id: 202, status: 0x00 SUCCESS
11:41:17:603 APS-DATA.confirm request id: 202 -> erase from queue
11:41:17:642 aps request id: 202 finished, erase from queue
11:41:17:711 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -45
11:41:17:712 	asdu: 18b90a000020a5
11:41:18:006 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -45
11:41:18:008 	asdu: 18ba0a000020a0
11:41:19:030 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 244, rssi: -45
11:41:19:032 	asdu: 18bb0a0000208f

In this version the bulb switches Off in 10s as it should. I’m not sure but haven’t found anything related to it in log with timestamp 10s after the Off command.

2.21.2

ON

12:00:51:737 HTTP API PUT /api/93A612956E/lights/22/state - xxx.xxx.xxx.200
12:00:51:738 Text Data: 	{"bri":166,"on":true}
12:00:51:738 ApiMode: 0
12:00:51:739 APS-DATA.request id: 25, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x03 queue: 0 len: 3 tx.options 0x04
12:00:51:739 	asdu (length: 3): 111901
12:00:51:740 [{"success":{"/lights/22/state/on":true}},{"success":{"/lights/22/state/bri":166}}]
12:00:51:798 APS-DATA.request id: 26, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0008, ep: 0x01 -> 0x03 queue: 1 len: 6 tx.options 0x04
12:00:51:799 	asdu (length: 6): 111a00a60400
12:00:51:800 APS-DATA.confirm id: 25, status: 0x00 SUCCESS
12:00:51:800 APS-DATA.confirm request id: 25 -> erase from queue
12:00:51:818 aps request id: 25 finished, erase from queue
12:00:51:861 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 240, rssi: -45
12:00:51:862 	asdu: 18e10a00001001
12:00:51:881 APS-DATA.confirm id: 26, status: 0x00 SUCCESS
12:00:51:882 APS-DATA.confirm request id: 26 -> erase from queue
12:00:51:898 aps request id: 26 finished, erase from queue

OFF

12:00:56:980 HTTP API PUT /api/93A612956E/lights/22/state - xxx.xxx.xxx.200
12:00:56:981 Text Data: 	{"bri":0,"on":false,"transitiontime":100}
12:00:56:983 ApiMode: 0
12:00:56:985 APS-DATA.request id: 65, addrmode: 0x03, addr: 0x7cb03eaa00af78ef, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x03 queue: 0 len: 3 tx.options 0x04
12:00:56:986 	asdu (length: 3): 111e00
12:00:56:987 [{"success":{"/lights/22/state/on":false}}]
12:00:57:055 APS-DATA.confirm id: 65, status: 0x00 SUCCESS
12:00:57:056 APS-DATA.confirm request id: 65 -> erase from queue
12:00:57:096 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 248, rssi: -45
12:00:57:097 	asdu: 18e40a00001000
12:00:57:097 APS-DATA.request id: 65 erase from queue
12:00:57:116 APS-DATA.indication srcAddr: 0x53f4, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -45
12:00:57:117 	asdu: 18e50a000020a6

In this version the bulb switches to Off immediately.

Now, I’m no expert in this matter, but I do not see any differences between the versions. If my assumption from 3) is correct, there are differences between .json files in old vs new versions (here I’m comparing old vs 2.20.1 as it’s the first one where it no longer works properly)

2.19.3
{
    "schema": "subdevice1.schema.json",
    "type": "$TYPE_COLOR_TEMPERATURE_LIGHT",
    "name": "Color temperature light",
    "restapi": "/lights",
    "order": 11,
    "uuid": ["$address.ext", "0x01"],
    "items": [
        "config/ctmax",
        "config/ctmin",
        "state/alert",
        "state/reachable",
        "state/bri",
        "state/colormode",
        "state/ct",
        "state/on"
    ]
}

2.20.1
{
    "schema": "subdevice1.schema.json",
    "type": "$TYPE_COLOR_TEMPERATURE_LIGHT",
    "name": "Color temperature light",
    "restapi": "/lights",
    "order": 11,
    "uuid": ["$address.ext", "0x01"],
    "items": [
        "cap/alert/trigger_effect",
        "cap/bri/move_with_onoff",
        "cap/color/capabilities",
        "cap/color/ct/max",
        "cap/color/ct/min",
        "cap/on/off_with_effect",
        "config/bri/execute_if_off",
        "config/bri/startup",
        "config/color/ct/startup",
        "config/color/execute_if_off",
        "config/on/startup",
        "state/alert",
        "state/reachable",
        "state/bri",
        "state/colormode",
        "state/ct",
        "state/on"
    ]
}

However, although newer json has more items, including “move with onoff” among other, it doesn’t work properly in my case. Or I might be completely wrong and something else is used instead of this generic jsons?

Anyhow, any help would be appreciated, I’d like to resolve this issue to be able to continue to update deCONZ going forward. THANKS!

Still not fixed.

What lights does this concern? Are these exposed through DDF or through legacy code? Was the DDF updated in v2.20, to include cap/on/off_with_effect?

Note that you cannot specicy a Transition Time to the Zigbee Off command. Instead, you need to use Off with Effect. However not all devices support this command, notably some plugs, but also some exotic lights.

By default the legacy code sends Off with Effect when "on": false is PUT. When "transitiontime": 0 is included, it sends Off. It also sends Off for some whitelisted devices that don’t support Off with Effect.

As of v2.20, the DDF code sends Off, unless cap/on/off_with_effect is included in the DDF.