turn off with transition (fade out) stopped working in home assistant deconz addon

[prof7bit]

Describe the bug

turn off with transition (fade out) stopped working in home assistant. I don't know what happens when i use the rest api directly because I have downgraded the deconz addon again to avoid the bug. I have not found any way in home assistant to restore previous behavior (fade off a zigbee light) without downgrading the deconz addon.

Steps to reproduce the behavior

in Home Assistant call the turn_off service with

"data": {
  "transition": 10
}

Expected behavior

Light will fade to black during 10 seconds, after this the light is off and the stored brightness in the bulb is 1 (if you turn it on the next time)

Actual behavior

Light will switch off immediately and the stored brightness remains at 255

Environment

• Host system: proxmox + Home Assistant (2022.11.5) + Deconz-Addon 2.20.0 or 2.20.1 (not sure, have downgraded again)

I could not find anything suspicious in the change log, but the turn-off with transition behavior has definitely changed, With the afforementioned version I am completely unable to do a fade-off transition.

Fade from one brightness to another works, but fade-off seems impossible, at least from within home assistant.

[prof7bit]

Since I did not find anything in the change logs, maybe one of the devs can remember whether there have been some changes in the way the transitions are handled, maybe this gives a clue as to whether the home assistent integration needs a change (or has already been silently changed while I did not update HA for other reasons).

[Mimiix]

I would like to ask you to test the rest api first.

The Home assistant integration is not the scope of this repository.

[prof7bit]

But has there been a breaking change? I did not upgrade anything HA-related for almost two months, but the bug appeared 4 days ago when I upgraded deconz, and it was fixed again after I downgraded deconz. So some kind of change must have happened in the handling of transitions.

[Mimiix]

Not that I know of. Again, when a bug report is placed we are asking to test issues as far as possible. Your posting a bug with home assistant and haven't tested the rest api. Now we can't determine where the issue might be.

[1doubleDD1]

I can second this issue. I'm still on HA 2022.11.4, meaning HA hasn't updated in more than 2 months, but have recently updated deConz from 2.19.1 to 2.19.3 and then to 2.20.1. Can't say exactly in which version this problem occurred, as I only noticed it today (I use transition to off on only 1 light that's a bit out of sight). If I can somehow assist, please do let me know, but at the moment I need to figure out how to downgrade deConz do older versions to see if the problem still exists.

EDIT: I just downgraded to 2.19.3 and transition to off works perfectly.

[dof250]

I'm also having the same issue. Transition to off doesn't work anymore. Issue is there when using Node-Red deCONZ plugin or Home Assistant

[esbenlydiksen]

I see the same issue on my system.

[ebaauw]

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.

[1doubleDD1]

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?

'Tis a good question, not sure how to check and reply to that. Most of my bulbs are old Osram E27 Dimmable or Tunable white. In the release notes for 2.20.x however I haven't seen anything related to Osram.

EDIT: I just checked deConz Wiki list of DDF supported devices, and there are none of Osram devices listed.

[dof250]

I'm using only Philips (Signify) Hue lights. I maybe have an example that helps. I have a group off lights above the dining table named Eettafel. It's contains 6 lights (Eettafel 1 to 6). While using deCONZ in node-red and sending a transition 0 or 60 (6seconds) using the group it works and fades out or turns off instantly. When sending the same command to Eettafel 1 it always uses a 1 seconds transition to off and ignores my input.

[dimitripb]

I second this issue. It can be reproduced with the Phoscon app. Create a scene with one bulb and brightness 0. Enter a transition of 10 s and turn on the bulb. Then activate the created scene. The bulb will enter off state within 1 second instead of 10. So it's not a problem in Home Assistant or Node Red.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[dimitripb]

Is there another issue addressing this bug? This one will be closed in several days but I can not find a related issue. Although this issue was created with a HA and Node Red context it IS reproducible within Phoscon (as described in my earlier post).

[Mimiix]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

As you replied now, Stale gets removed tonight automatically.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[lindhe]

Please keep open.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[prof7bit]

Still not fixed.

[dimitripb]

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

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

[ebaauw]

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).
3. Check whether the light is exposed by legacy code or through DDF, in which case, attach the DDF.
4. The precise body to the PUT of the state of the lights resource.
5. 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).

[dimitripb]

Thanks! That helps a lot. I will checkout your suggestions. I am not fully into Zigbee so I hope you can help me when I am stuck.

[dimitripb]

Answer on question 1: I only have some IKEA light and they are all affected. Below the screen dumps and resources:

  "14": {
    "capabilities": {
      "alerts": ["none", "select", "lselect"],
      "color": {
        "ct": {
          "max": 454,
          "min": 250
        },
        "modes": ["ct"]
      }
    },
    "colorcapabilities": 16,
    "config": {
      "groups": ["0"]
    },
    "ctmax": 454,
    "ctmin": 250,
    "etag": "c1b85accd33e089c1a2c8783545be534",
    "hascolor": true,
    "lastannounced": "2023-05-06T18:15:12Z",
    "lastseen": "2023-05-06T18:45Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRIbulbE27WSglobeopal1055lm",
    "name": "Lamp trappenhuis",
    "state": {
      "alert": "none",
      "bri": 209,
      "colormode": "ct",
      "ct": 344,
      "on": false,
      "reachable": true
    },
    "swversion": "1.0.012",
    "type": "Color temperature light",
    "uniqueid": "50:32:5f:ff:fe:dc:7c:91-01"
  }

 "13": {
    "capabilities": {
      "alerts": ["none", "select", "lselect"],
      "color": {
        "ct": {
          "max": 65279,
          "min": 0
        },
        "modes": []
      }
    },
    "colorcapabilities": 0,
    "config": {
      "groups": ["0", "5"]
    },
    "ctmax": 65279,
    "ctmin": 0,
    "etag": "44b7a656c1552204650814abaa890555",
    "hascolor": true,
    "lastannounced": "2022-10-22T15:27:50Z",
    "lastseen": "2023-05-06T18:44Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI bulb GU10 WS 400lm",
    "name": "Spot 1 huiskamer",
    "state": {
      "alert": "none",
      "bri": 254,
      "colormode": "ct",
      "ct": 250,
      "on": false,
      "reachable": true
    },
    "swversion": "2.3.087",
    "type": "Color temperature light",
    "uniqueid": "00:0b:57:ff:fe:e7:ac:03-01"
  }

  "1": {
    "capabilities": {
      "alerts": ["none", "select", "lselect"],
      "color": {
        "ct": {
          "max": 65279,
          "min": 0
        },
        "modes": []
      }
    },
    "colorcapabilities": 0,
    "config": {
      "groups": ["0", "12"]
    },
    "ctmax": 65279,
    "ctmin": 0,
    "etag": "9ce9474d00d0e1430aeeea7f9c9e6185",
    "hascolor": true,
    "lastannounced": "2023-02-02T07:19:44Z",
    "lastseen": "2023-05-06T18:42Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI bulb E27 WS opal 1000lm",
    "name": "Lamp eettafel",
    "state": {
      "alert": "none",
      "bri": 254,
      "colormode": "ct",
      "ct": 250,
      "on": false,
      "reachable": true
    },
    "swversion": "2.3.095",
    "type": "Color temperature light",
    "uniqueid": "68:0a:e2:ff:fe:90:21:8b-01"
  }

  "3": {
    "capabilities": {
      "alerts": ["none", "select", "lselect"]
    },
    "config": {
      "groups": ["0"]
    },
    "etag": "06a3ab54773788115e6145548c587746",
    "hascolor": false,
    "lastannounced": "2023-04-16T20:23:22Z",
    "lastseen": "2023-05-06T18:39Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI bulb E27 WW 806lm",
    "name": "Lamp halletje",
    "state": {
      "alert": "none",
      "bri": 254,
      "on": false,
      "reachable": true
    },
    "swversion": "2.3.093",
    "type": "Dimmable light",
    "uniqueid": "58:8e:81:ff:fe:11:8a:70-01"
  }

[dimitripb]

Question 2: TRADFRIbulbE27WSglobeopal1055lm

Off: result: fading to off in about 1 second

Off with effect: Effect identifier: Dying light Effect variant: 20% dim up in 0.5s then off in 1s result: working as expected

Effect identifier: Delayed all off Effect variant: Fade off in 0.8s result: working as expected

Effect identifier: Delayed all off Effect variant: No fade result: working as expected

Effect identifier: Delayed all off Effect variant: 50% dim down in 0.8s and then fade off in 12s result: working as expected

Move to level (with on/off): result: working as expected. The lights will fading out to off during the given time.

Question 3: TRADFRIbulbE27WSglobeopal1055lm seems to use DDF.

@ebaauw : how do I know device is actually using legacy code or DDF.

[1doubleDD1]

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

4. The precise body to the PUT of the state of the lights resource.
5. 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.

I'd like to help as well, as the issue also affects me and would like to see it properly resolved. v2.19.03 was the last deCONZ version where my OSRAM lights faded to OFF as expected, afterwards obviously something changed. Now, 1, 2 & 3 I was able to figure out how to find, but I'll need a bit of help on where to look for 4 & 5, so I can paste them in as well.

Thanks!

[ebaauw]

how do I know device is actually using legacy code or DDF.

In the GUI, click on the node, next right-click on the node and select Edit DDF from the popup menu. It should popup the DDF editor. Check that the status is Gold. And double-check that DDF Mode in the DDF tab of the Control panel enables at least Gold DDFs.

If there is a DDF, check that on/off_with_effect and bri/move_with_onoff have been listed under Capabilities.

where to look for 4 & 5

4: in the log of the API client, or in the deCONZ log, with HTTP logging enabled; 5: As I mentioned before: in a Zigbee sniffer, or in the deCONZ log with APS and APS_L2 logging enabled.

[dimitripb]

@ebaauw Thanks! Fixed!

Adding on/off_with_effect and bri/move_with_onoff to the capabilities did the job. Three of four bulbs have DDF, so that's easy to fix. I will create pull requests for these.

The one without DDF needs some more research. Or can I just create a bronze or silver DDF with these capabilities?

[1doubleDD1]

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"
    }

2) 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.

3) 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!

[dimitripb]

Adding "on/off_with_effect" and "bri/move_with_onoff" to the DDF fixed all my problems with the Ikea Tradfri bulbs.

@ebaauw Thanks for your help with this! What is the difference between Capabilities items and Config items (in the DDF editor)? Everywhere in the documentation only Config items are explained or shown. Cap items do not seem to exist in the documentation. When I check DDF files on github lots of them have Config items. In my Deconz setup they have only Cap items.

[ebaauw]

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

[dimitripb]

I created these pull requests to update the DDFs for my bulbs.

6966

6965

6964

6963

6967

[1doubleDD1]

Well, I also tried creating DDF for my Osram lights and adding "on/off_with_effect" and "bri/move_with_onoff", but it still doesn't work. :( Of course, it might be due to not really knowing what I'm doing, but I'm still quite sure that DDF is correct and should work. Can it be done on the fly just via "hot reloading" the changed DDF or do I need to also restart/reboot something else? Thanks!

[Mimiix]

@1doubleDD1 Best to ask on the forums in that case ;)

[1doubleDD1]

@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.

[dimitripb]

Can it be done on the fly just via "hot reloading" the changed DDF or do I need to also restart/reboot something else?

Hot reload should be enough. Be sure the status is not Draft anymore. Set it to gold to test it on your own environment.

Probably something changed in the legacy code. That caused a lot of bulbs not functioning properly anymore. It's better to create well functioning DDF files instead of changing the legacy code again. At least in my opinion.

[1doubleDD1]

Thanks @dimitripb for your help! I just love this sort of issues... Same DDF that I created and wasn't working a couple od hours ago, I just tried again and now it's working perfectly. SMH Apparently the same one as in life also applies here, that time heals everything... The status was/and still is in Bronze, apparently it doesn't affect it.

UPDATE: Apparently it's not healed by the time or our Lord and Savior himself, status is the answer. When it's set to Bronze, it doesn't work properly. When I change it to Gold, suddenly it's working as it should. If I switch it to Bronze afterwards, it continue to works as it should... So apparently change to Gold does some magic inside. And yes, only Hot reload is enough.

[Mimiix]

Thanks @dimitripb for your help! I just love this sort of issues... Same DDF that I created and wasn't working a couple od hours ago, I just tried again and now it's working perfectly. SMH Apparently the same one as in life also applies here, that time heals everything... The status was/and still is in Bronze, apparently it doesn't affect it.

UPDATE: Apparently it's not healed by the time or our Lord and Savior himself, status is the answer. When it's set to Bronze, it doesn't work properly. When I change it to Gold, suddenly it's working as it should. If I switch it to Bronze afterwards, it continue to works as it should... So apparently change to Gold does some magic inside. And yes, only Hot reload is enough.

Yes, but when you reboot it probably stops working.

[1doubleDD1]

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.

[Mimiix]

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.

[dimitripb]

@1doubleDD1 if you have a tested and working DDF for your bulbs please create a pull request to integrate it into Deconz: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to-create-a-pull-request-to-submit-a-new-Device-Description-File

[1doubleDD1]

@1doubleDD1 of you have a tested and working DDF for your bulbs please create a pull request to integrate it into Deconz: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to-create-a-pull-request-to-submit-a-new-Device-Description-File

Will do, have 2 more to do and test tomorrow 👍 Thanks

[dimitripb]

@ebaauw

One more question (for my understanding): In de current DDF for devices/ikea/gu10_ws_400lm_light.json ( https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/ikea/gu10_ws_400lm_light.json ) is listed:

  {
                    "name": "config/colorcapabilities",
                    "static": 16
                },
                {
                    "name": "config/ctmin",
                    "static": 250
                },
                {
                    "name": "config/ctmax",
                    "static": 454
                },

I cannot find any Config items called ctmin, ctmax and colorcapabilities. Should these actually be Cap items and is the current DDF wrong? Or do I misunderstand something?

[1doubleDD1]

My guess would be that prior to 2.20 only Config was used, and then Capabilities were introduced (if you check bottom of my big post above with generic DDFs). So I would guess that older DDFs probably should be updated... Also under Cap there are 2 instances of some items like ctmax, one is deprecated and one active.

[1doubleDD1]

Apologies if this is already spamming on the topic, but I'm contemplating the usefulness of "on/off_with_effect" in the DDFs. Once it's included, there is no way to turn the bulb instantly off (without any effect). And quite similar result to off with effect is usage of command off with transition of 1-2sec (which is part of "bri/move_with_onoff" that is already part of DDF). Generally I'm using on/off commands from HA via "Call service" action where it's easy enough to define whether you want or not the transition (I'm aware that this option is not available if one is using "Device command"). And on some lights I prefer the off with transition, on some instant off.

To summarize, if "on/off_with_effect" is included in DDF, user has no possibility to instantly switch the bulb off. However, if it's omitted, user can decide on the desired behaviour (although maybe a bit more complicated). Or am I missing something?

So, should it be included or not? Thanks for any input.

[dimitripb]

@1doubleDD1 In my case (with IKEA bulbs) it IS a capability so it should be added to the DDF. I can turn off my bulbs immediately with "on/off_with_effect" in the DDF. No problem. Maybe with Osram bulbs it's different. Before adding capabilities to the DDF you should test whether the device has actually that capability.

[1doubleDD1]

Maybe I wasn't clear enough, when I test from deconz gui there are on, off, toggle and on/off with effect commands and they all work properly on the bulb (there are 3 off effects available and they all work). However if I include that capability in the DDF, then from HomeAssistant off command behaves as off with effect (fades to off in about 1s). It's like including the capability overrides instant off command.

[dimitripb]

Yes I do understand, but when a bulb has a specific capability, it should be listed in the DDF in my opinion. Omitting could lead to other problems maybe. In my case the bulbs always went off in 1 second instead of immediately when I use HA. I don't know what is best practice in this case. When you buy an Ikea hub and Ikea bulbs turning off is never immediately so I think they are meant to turn off with a transition of 1s.

[prof7bit]

However if I include that capability in the DDF, then from HomeAssistant off command behaves as off with effect (fades to off in about 1s). It's like including the capability overrides instant off command.

This is then probably a problem with the home assistant deconz integration and should be fixed there. But first of all the off-with-effect should be properly supported and usable on all bulbs that support it, then making home assistant use the proper Deconz API for all kinds of bulbs and all kinds of intended behavior would be a home assistant bug.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions[bot]]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.