Reset light when deleted from the API

[ebaauw]

The Hue bridge factory resets a light, when the light is removed from the API, through a DELETE of the corresponding /lights resource. I think the deCONZ REST API plugin should do the same, especially for Hue lights, that don't support a power-on/off sequence to reset them.

Sniffing the Hue bridge, it sends a ZDP Leave Request:

IEEE 802.15.4 Data, Dst: 0x0024, Src: 0x0001
ZigBee Network Layer Data, Dst: 0x0024, Src: 0x0001
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
    Destination: 0x0024
    Source: 0x0001
    Radius: 30
    Sequence Number: 153
    [Extended Source: PhilipsL_01:01:05:8c:26 (00:17:88:01:01:05:8c:26)]
    [Origin: 1]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
    Frame Control Field: Data (0x00)
    Destination Endpoint: 0
    Leave Request (Cluster ID: 0x0034)
    Profile: ZigBee Device Profile (0x0000)
    Source Endpoint: 0
    Counter: 96
ZigBee Device Profile, Leave Request, Device: PhilipsL_01:04:34:2c:ff
    Sequence Number: 29
    Extended Address: PhilipsL_01:04:34:2c:ff (00:17:88:01:04:34:2c:ff)
    .0.. .... = Remove Children: False
    0... .... = Rejoin: False

The bulb responds with a ZDP Leave broadcast:

IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x0024
    Frame Control Field: 0x8841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 108
    Destination PAN: 0x65d1
    Destination: 0xffff
    Source: 0x0024
    [Extended Source: PhilipsL_01:04:34:2c:ff (00:17:88:01:04:34:2c:ff)]
    [Origin: 3]
    Frame Check Sequence (TI CC24xx format): FCS OK
ZigBee Network Layer Command, Dst: Broadcast, Src: 0x0024
    Frame Control Field: 0x1209, Frame Type: Command, Discover Route: Suppress, Security, Extended Source Command
    Destination: 0xfffd
    Source: 0x0024
    Radius: 1
    Sequence Number: 96
    Extended Source: PhilipsL_01:04:34:2c:ff (00:17:88:01:04:34:2c:ff)
    ZigBee Security Header
    Command Frame: Leave
        Command Identifier: Leave (0x04)
        ..0. .... = Rejoin: False
        .0.. .... = Request: False
        0... .... = Remove Children: False

[SwoopX]

Hm, wouldn't it make sense to implement that for all routing devices (I know not all might support it)?

[ebaauw]

Maybe. I haven’t checked whether the Hue bridge sends anything when deleting a /sensors resource. Preferably, any device (that supports it) should be reset. I don’t know ZDP too well, in particular whether end devices are supposed to react to a Leave Request.

[hellcry37]

up for this, it has my vote

[Smanar]

But if the device don't support this feature, what we can have as problem ? For me it will work or not, but I don't imagine a problem we can have if the device don't support the command And I think I know another manufacture that use this feature.

[SwoopX]

But if the device don't support this feature, what we can have as problem ? For me it will work or not, but I don't imagine a problem we can have if the device don't support the command

Well, as I see it, we wouldn't have a problem at all. If the device supports it, all good. If not, you most likely receive an unsupported command response and that's it, nothing happens.

[Smanar]

Well, as I see it, we wouldn't have a problem at all. If the device supports it, all good. If not, you most likely receive an unsupported command response and that's it, nothing happens.

I m thinking same, it can only be good (or useless).

[ebaauw]

I'll be bloody damned! Checking the code, it turns out this has already been implemented in the REST API plugin! I should have RTFM: You need to supply a body of {"reset": true} to the DELETE of /lights/# or /sensors/#. It's not documented for /sensors, though. Just deleted and rejoined a Hue bulb without power cycling it nor resetting it with a Hue dimmer switch (see captured packets below).

I think we should make this the default behaviour, when the body is not present, and use {"reset": false} for the current behaviour. @manup would you agree?

Of course, we still need to delete the resources when the node is deleted from the GUI. I've been experimenting with GUI events in the STD OTAU plugin: now the table highlights the node you select on the map, so this should be doable.

IEEE 802.15.4 Data, Dst: 0xa921, Src: 0x0000
ZigBee Network Layer Data, Dst: 0xa921, Src: 0x0000
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
    Destination: 0xa921
    Source: 0x0000
    Radius: 10
    Sequence Number: 131
    [Extended Source: dresden-_ff:ff:01:04:1e (00:21:2e:ff:ff:01:04:1e)]
    [Origin: 1]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
    Frame Control Field: Data (0x00)
    Destination Endpoint: 0
    Leave Request (Cluster ID: 0x0034)
    Profile: ZigBee Device Profile (0x0000)
    Source Endpoint: 0
    Counter: 93
ZigBee Device Profile, Leave Request, Device: PhilipsL_01:04:34:2c:ff
    Sequence Number: 1
    Extended Address: PhilipsL_01:04:34:2c:ff (00:17:88:01:04:34:2c:ff)
    .0.. .... = Remove Children: False
    0... .... = Rejoin: False

IEEE 802.15.4 Data, Dst: Broadcast, Src: 0xa921
ZigBee Network Layer Command, Dst: Broadcast, Src: 0xa921
    Frame Control Field: 0x1209, Frame Type: Command, Discover Route: Suppress, Security, Extended Source Command
    Destination: 0xfffd
    Source: 0xa921
    Radius: 1
    Sequence Number: 92
    Extended Source: PhilipsL_01:04:34:2c:ff (00:17:88:01:04:34:2c:ff)
    ZigBee Security Header
    Command Frame: Leave
        Command Identifier: Leave (0x04)
        ..0. .... = Rejoin: False
        .0.. .... = Request: False
        0... .... = Remove Children: False

[hellcry37]

glad to hear it: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1923

[ebaauw]

Make sure to delete any links from /resourelinks resources on delete, see https://github.com/ebaauw/homebridge-hue/issues/669.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ebaauw]

Bump