Delay when turning off Ikea Tradfri Control Outlet

[rchl]

Describe the bug

After triggering the "off" state for the power outlet, it takes about a second before the outlet actually switches off (LED goes off and the relay switches).

This started to happen after upgrading the outlet to version 2.3 and didn't seem to be a problem with the previous 2.0 version. This is the state of the node after upgrade:

That said, I can see that I can still trigger the old, fast turn off from deconz:

I'm not sure why a "delayed" off would be needed for a power plug as it's not like it can fade out a connected light device or anything.

Steps to reproduce the behavior

1. Upgrade IKEA Tradfri Control Outlet to version 2.3
2. Turn ON and then turn off the outlet. For example:

curl -i -X PUT \
   -H "Content-Type:application/json" \
   -d \
'{
  "on": true,
}' \
 'http://192.168.0.110:40850/api/<api-key>/lights/5/state'

curl -i -X PUT \
   -H "Content-Type:application/json" \
   -d \
'{
  "on": false,
}' \
 'http://192.168.0.110:40850/api/<api-key>/lights/5/state'

Expected behavior

The outlet turns off immediately.

Screenshots

Environment

• Host system: Raspberry Pi
• Running method: Home Assistent deCONZ Add-on
• Firmware version: (26660700)
• deCONZ version: (2.16.1)
• Device: ConBee II
• Do you use an USB extension cable: (yes)
• Is there any other USB or serial devices connected to the host system? If so: Which? Zwave Aeotec

deCONZ Logs

Additional context

[Mimiix]

I am not sure where this would be a bug in deCONZ. I'll check with the devs. The device Firmware is changed, perhaps that's the issue more here and that we need to adjust there.

[rchl]

Thanks for the initial response.

My thinking was/is that the previous version of the outlet's firmware didn't support "delayed" turn off so deconz didn't use it while now it does. And since deconz API exposes those devices as lights, maybe it defaults to "delayed" alternative.

It's just a speculation though and I have no way of confirming that as I don't have any outlets with 2.0 firmware anymore.

[Mimiix]

I am not sure if it works that way, nevertheless: That's why I've asked the devs to check it out. deCONZ would just use what it was using.

[Smanar]

Ok, so it s a mystery for me ^^. I realy don't see why it can be faster using the GUI than using the API. A thing you can try with log (deconz / help / debug view) with "ZCL", can you make the request with deconz then with the API.

15:40:38:484 ZCL cmd-req nwk: 0x40FF, profile: 0x0104, cluster: 0x0006 cmd: 0x01

Here we can see deconz is making the cmd 0x01 on the cluster 0x0006, it the "Fast on" request or (0x00 the Fast off")

[ebaauw]

Before the DDFs, the API would send Off with Effect on {"on": false}, but, I think, only for Hue lights/devices. It should send Off for other devices. Could you check how quickly the outlet turns off when sending {"on": false; "transitiontime": 0}? That should force an Off.

I would expect this to be handled by the DDF eventually, preferably in a declarative way (providing a setting whether to use. Off with Effect).

[rchl]

A thing you can try with log (deconz / help / debug view) with "ZCL", can you make the request with deconz then with the API.

I get a cmd-req log line when triggering the command from the On/Off Cluster page but not when making Off request through the REST API.

Could you check how quickly the outlet turns off when sending {"on": false; "transitiontime": 0}? That should force an Off.

Actually I was experimenting with that argument before also but it didn't change the behavior. It's still slow. Just confirmed again with the request below:

curl -i -X PUT \
   -H "Content-Type:application/json" \
   -d \
'{"on": false, "transitiontime": 0}' \
 'http://192.168.0.110:40850/api/<api-key>/lights/5/state'

BTW, this is the entity info:

{
    "etag": "abcdf...",
    "hascolor": false,
    "lastannounced": "2022-06-03T12:51:52Z",
    "lastseen": "2022-06-03T17:38Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI control outlet",
    "name": "Ikea wall socket",
    "state": {
        "alert": "none",
        "on": false,
        "reachable": true
    },
    "swversion": "2.3.089",
    "type": "On/Off plug-in unit",
    "uniqueid": "xx:xx:..."
}

[rchl]

If I understand the code correctly then it applies ONOFF_COMMAND_OFF_WITH_EFFECT for all IKEA devices other than "KNYCKLAN receiver" (issue #4964).

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/674d17143b0467d8a9d14d6f876cee753aa445b1/rest_lights.cpp#L1448-L1452

[Smanar]

Ha yes ^^.

I don't know why ikea and philips need ONOFF_COMMAND_OFF_WITH_EFFECT instead of ONOFF_COMMAND_OFF ?

And I don't think it can be solved using DDF.

[rchl]

From Git history:

Fix IKEA lights not turn off in scenes and IKEA unicast off commands

IKEA firmware has a bug that it ignores the off setting in a scene. As workaround unicast Off With Effect commands are send to IKEA lights which are off in a scene.

In same fashion plain off commands to IKEA lights are changed to use Off With Effect command.

The group recall scene code was refactored to be more dense and properly handle color loop.

2d7660ef20fa8193836fb9e944f1ef71df45b741

[rchl]

@manup Could you clarify what was the bug that that commit was supposed to fix? I'm not sure what "scene" is in context of deconz/zigbee. To be able to verify whether the bug still applies and in which situations it is necessary to understand the original issue better.

[rchl]

Ping.

Any idea if this logic could be changed to ONOFF_COMMAND_OFF for Ikea? Or if not for Ikea in general then to be made more specific so that it only applies to Ikea in certain cases when it's needed?

I'm not quite sure which case specifically it meant to fix so not sure how to even test if it's still an issue.

The delay is annoying when turning off my kettle as it feels very unresponsive and I can't be sure if it's gonna turn off or not. :)

[Smanar]

On my side I don't think it s posible using DDF without adding a full part of code to use a new parameter. Using a hack in the code will take 1 line, but not sure it will be autorised.

If you are not using HA or other docker, I can explain you how to edit the code for you. but you will loose your changes after every new deconz update.

[rchl]

Thanks for the offer but I'd like an official solution so that i don't have to maintain my own version. Also, it's not like the problem is specific to me.

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

[rchl]

Not stale

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

[rchl]

The bot is over eager to close issues. This is still valid but I'm tired of pinging the issue just to keep it alive.

[Mimiix]

It also pings me and other devs to remind that it's ongoing :) That's why we have it. I'm happy to put a backlog sign on it to make it stop auto-closing, but that might bury it.

[rchl]

I would be willing to help with a PR but the only safe thing I can think of is to white-list this specific device like currently done for KNYCKLAN receiver.

[Mimiix]

I'll ask Manuel to check it.

[manup]

As @ebaauw mentioned in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6104#issuecomment-1146203490 this is related to the Off with Effect command. We need a declarative way to specify this in the DDF as we can't trust what devices expose.

However as I've recently learned there is much more to this topic. It's all centered around the ZLL Global Scene Control attribute which brings a bit of complexity to the matter. We can not simply always send Off with Effect command, because depending on the current value of Global Scene Control we need to send different commands to turn a device on/off:

• On
• On with recall global scene
• Off
• Off with effect

Not doing this results in the device simply ignoring the command — remember we had reports in the past lights not turning on/off?

To add to the complexity the Global Scene Control attribute gets affected by various other commands, so ideally we need to be sure to always know the current state and use attribute reporting for that where supported.

... all this is horrible for group commands.

The alternative is to always send both Off and Off with Effect commands, but bet this brings other troubles on the table.

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

[rchl]

Can we pin this to eliminate stale bot? Regardless of how this is gonna be handled, I think that it's still an issue and should be kept open for visibility.

Thanks for detailed explanation BTW.

[Mimiix]

I'm happy to do that, However, every time the bot does this we all get a reminder. If I put it on backlog, it will not do that and it's likely it gets forgotten.

[OptimusGREEN]

Would this delay be the cause of it not showing off in home assistant somethimes? If I turn it off from home assistant, its almost like its not recieving the state as off back from deconz and still shows as on. It does show off in phoscon app though, but only after a second or two.

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

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

[ebaauw]

Bloody bot