Events for custom dimmer device

[dagroe]

I posted this on the discord first and was told this might be a better place, so here it is:

I am trying to build my own dimmer switch and use it in my network running deconz (via homeassistant addon) using the conbee II stick. I'm stuck at getting button events (or any deconz event) into home assistant.

Device

I'm trying to build a simple dimmer switch. My hardware is an EBYTE E72-2G4M20S1E module, which uses the TI CC2652P. I flashed the standard TI simpleLink Zigbee Router Switch example onto the module and set my own manufacturer name and modelId, as well as tried out a few different settings (endpoints, clusters, etc.).

Here is what I have set for the device

• Product name: Dimmer RT01
• Manufacturer: DG Electronics
• Model identifier: RT01
• Device type:
  • Switch

Screenshots

Basic

I am able to join the device onto my network. The device output tells me it has one binding to my coordinator ClusterId 0x0006 Endpoint 0x01

I then created a new DDF file with a basic ZHASwitch entry, no bindings.

{
  "schema": "devcap1.schema.json",
  "manufacturername": "DG Electronics",
  "modelid": "RT01",
  "vendor": "DG Electronics",
  "product": "Dimmer",
  "sleeper": false,
  "status": "Silver",
  "path": "/devices/dg_electronics.dimmer.json",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x08",
        "0x0000"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent"
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ]
}

With that I am able to see the device as switch in phoscon, but cannot assign it to a light group and I don't get button events in HA (or in phoscon API view

Then I copied the button_maps.json from master, added a new entry, and saved it to /data/.local/share/dresden-elektonik/deCONZ/devices/button_maps.json:

"dgElectronicsDimmer": {
    "vendor": "DG Electronics",
    "doc": "DG Electronics Dimmer",
    "modelids": ["RT01"],
    "buttons": [
        {"S_BUTTON_1": "On/Off"},
    ],
    "map": [
        [1, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"]
    ]
},

When I press a button my device sends a request to the coordinator. It uses the TI API call zclGeneral_SendOnOff_CmdOn to send a ZCL command:

endpoint: 0x08
target address: 0x0000
cluster: 0x0006
command: 0x02
direction: 0x00 client -> server
disableDefaultRsp: true

I can see the request in deconz debug as

APS-DATA.indication srcAddr: 0x6a67, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 159, rssi: -74

What am I missing to correctly register the device and see deconz events in HA?

[Smanar]

Hello, I m seing the device is a router ? It 's a wired switch ? that receive order ? But on cluster list it look like a battery one, that send order.

It use as output cluster the 0x0006 and 0x008, we generally need to bind them to the coordinator, for the device send request to it. But according what you are saying, perhaps not usefull for the 0x0006.

Do you have some logs about the button map, on loading or when using a button ? (visible with the flag "info_l2" and "info")

On my side, I did not know it was possible to use DDF for battery switches (and on my side the path for the json is /usr/share/deCONZ/devices/button_maps.json on raspberry)

[dagroe]

Yes, the device is set as router since it is wired. What do you mean by receive/send order?

I suppose 0x0006 is bound to the coordinator, at least that is what my device is saying. I haven't looked into 0x008 yet, but I could also disable that cluster for now.

I do not have logs regarding button_maps, I'll try and see if something regarding button_maps appears in logs. I couldn't see anything when I click the button and I see the APS data logged as mentioned above.

I thought the .local/share/dresden-elektonik/deCONZ/devices/button_maps.json overrides the button_map.json in /usr/share/deCONZ/devices/, is that correct? I assumed /usr/share/deCONZ/devices/button_maps.json will be reset when the docker container restarts. I got the locations from here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3397#issuecomment-706752190

Thanks for your help :)

[Smanar]

So you are right for the path. But there is something no clear for me.

Wired switch are bulbs, so we send request to them to turn off or on, so they need to have the cluster 0x0006 as input cluster. Battery switch are "sensor" so they send request when we use them, using the output cluster.

It's schematized, but can be a problem for exemple when you will use group feature.

[dagroe]

Ah, I see. Well, it's a switch/sensor, like the IKEA remote just with a single button and powered by wire rather than a battery. So output cluster should be fine.

I can also bind my device to a light bulb using the deconz bind dropbox, that works like it should.

[Smanar]

OK, so I understand now.

But I'm worried to don't see anything about the button map. I will ask to other devs if the DDF is not bypassing it.

No logs like

[INFO] - No button map for: [INFO] - Button %u - %s%s, endpoint: 0x%02X, cluster: %s, action: %s, payload: %s, zclSeq: %u\n [INFO] - No button handler for:

BTW, can you show the entry created in the API ? you are sure having a ZHASwitch ?

[dagroe]

Which entry in API do you mean?

The DDF in Editor?

[dagroe]

Just to make sure I have the correct setup: Where do I need to bind my output cluster to? I assume I have to bin my 0x0006 cluster to the configuration tool address 0x0000, endpoint 0x01, cluster 0x0006 correct?

If so, when I also want to send LevelControl commands, do I bind my 0x0008 cluster also to 0x0006 of the coordinator?

[Smanar]

Nope in the API, to see the result. If the DDF is working the node name need to change from 0xXXXX to a real name, and you will be able to see it in the API, for exemple using third app or phoscon (in help / API Information / sensors)

If the entry is not created can explain the issue.

And I have asked to other devs, it s possible to make DDF for battery switches, so we have hopes ^^

Here there is one of them https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/wiser/fuga_4button_battery_switch.json He have so many endpoint, but on your, you have only the 0x08, so something normal for me can be as result

    {
      "bind": "unicast",
      "src.ep": 8,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 8,
      "cl": "0x0008"
    },

You can bind from a cluster/endpoint/address to a endpoint/address (no cluster, you can see gateway cluster, it haven't 0x0006 or 0x0008)

[dagroe]

ok, great. I can see the device in the API, so I guess the DDF is working. I'll try adding the bindings to the DDF tomorrow.

I'm not sure whether the button_maps are working correctly. I added a new map entries:

"dgElectronicsDimmer": {
            "vendor": "DG Electronics",
            "doc": "DG Electronics Dimmer",
            "modelids": ["RT01"],
            "buttons": [
                {"S_BUTTON_1": "On/Off"}
            ],
            "map": [
                [1, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"],
                [2, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"],
                [3, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"],
                [4, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"],
                [9, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"]
            ]
        }

I expected to get an error, since [9, "0x08", "ONOFF", "TOGGLE", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Toggle"] should be invalid, but I couldn't see any error. I'll do some more testing.

[Smanar]

Can try too without button_maps modification. you need to have this error message

[INFO] - No button map for:

Visible with "info_l2"

Can you share the device josn visible in the API ?

[dagroe]

I removed the custom button_maps.json. I added the suggested bindings to the DDF:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "DG Electronics",
  "modelid": "RT01",
  "vendor": "DG Electronics",
  "product": "Dimmer",
  "sleeper": false,
  "status": "Silver",
  "path": "/devices/dg_electronics.dimmer.json",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x08",
        "0x0000"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent"
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 8,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 8,
      "cl": "0x0008"
    }
  ]
}

I don't see any button_maps message (with INFO and INFO_L2 ticked in deconz debug view) for my device (there was one message about a different device on my network).

Here is my device's entry in phoson API viewer:

{
    "config": {
        "on": true,
        "reachable": true
    },
    "etag": "e72c1393042f0309452701c9faad3e91",
    "lastannounced": null,
    "lastseen": "2022-03-17T20:01Z",
    "manufacturername": "DG Electronics",
    "mode": 2,
    "modelid": "RT01",
    "name": "Schalter",
    "state": {
        "buttonevent": null,
        "lastupdated": "none"
    },
    "swversion": "202203151",
    "type": "ZHASwitch",
    "uniqueid": "00:12:4b:00:25:79:23:3b-08"
}

I ordered a second conbee 2 stick to setup a new network for further debugging. My current network has many nodes, so it will be easier to test with only my device in a new network.

[Smanar]

Realy strange, can you just share some logs when pressing a button, just with "info" and "info_l2" and "aps"

APS-DATA.indication srcAddr: 0x6a67, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006,

dstAddrMode: 2 > I found only mode 1 and 3 ^^

    enum Constans
    {
        GroupAddressMode = 0x01,
        ExtendedAddressMode = 0x03
    };

Can compare with the working one ?

"uniqueid": "00:12:4b:00:25:79:23:3b-08"

ZHAswitch are more

"uniqueid": "00:17:88:01:10:49:55:03-02-fc00"

      "uuid": [
        "$address.ext",
        "0x08",
        "0x0000"
      ],

Try using the cluster 0x0006 instead of the basic one 0x0000, If I m right it will add the cluster to your uniqueid, I had an issue recently with bad cluster defined at this place.

[dagroe]

Thanks for looking into this. I tried to look into the code myself but I am a bit confused.

First: I see that my Hue Dimmer sends two dstAddrModes:

20:09:21:626 APS-DATA.indication srcAddr: 0x563d, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 215, rssi: -67
20:09:21:628    asdu: 016901
20:09:21:666 APS-DATA.indication srcAddr: 0x563d, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0xFC00, lqi: 215, rssi: -67
20:09:21:668    asdu: 1d0b1068000100003000210000

and my IKEA 5-button remote sends dstAddrMode: 1. Well, I understand that the Hue dimmer works a bit differently. So I might need to look into changing the mode for my requests.

I am still a bit confused as to what the mode means.

What you quoted seems to be the address mode of a binding entry (2.4.4.4.4 Zigbee spec).

0x00 = reserved
0x01 = 16-bit group address for DstAddr and DstEndpoint not present
0x02 = reserved
0x03 = 64-bit extended address for DstAddr and DstEndp present
0x04 – 0xff = reserved

So there 2 doesn't make sense. However I think we are dealing with dstAddrMode regarding APS not binding.

For APSDE-DATA.indication I found this definition (2.2.4.1.3.1 Zigbee Spec)

0x00 = reserved
0x01 = 16-bit group address for DstAddress; DstEndpoint not present
0x02 = 16-bit address for DstAddress and DstEndpoint present
0x03 = 64-bit extended address for DstAddress and DstEndpoint present.
0x04 = 64-bit extended address for DstAddress, but DstEndpoint NOT pre- sent.
0x05 – 0xff = reserved

and for APSDE-DATA.request this (2.2.4.1.1.1 Zigbee Spec)

0x00 = DstAddress and DstEndpoint not present
0x01 = 16-bit group address for DstAddress; DstEndpoint not present
0x02 = 16-bit address for DstAddress and DstEndpoint present
0x03 = 64-bit extended address for DstAddress and DstEnd- point present
0x04 – 0xff = reserved

deconz API has this enum (https://phoscon.de/deconz-cpp/da/d4d/namespacedeCONZ.html#a185371c0124f183d2f20e91e4b6590ce):

ApsNoAddress = No addressing specified.
ApsGroupAddress = 16-bit group address mode
ApsNwkAddress = 16-bit network address mode
ApsExtAddress = 64-bit extended IEEE address mode
ApsNwkExtAddress =16-bit network address mode and 64-bit extended IEEE address mode (since protocol version 0x010B)

So here a 2 would make sense, however I couldn't really see how this would affect what is happening in void DeRestPluginPrivate::apsdeDataIndication(const deCONZ::ApsDataIndication &ind), but maybe that's the wrong place to look? Maybe someone on the dev team known more about that?

Anyway I guess I'll have to look into what my device is doing regarding binding.

I also changed the DDF to use cluster: 0x006 for the ID, as you suggested and tried it using a fresh installed ubuntu and new conbee 2 stick and deconz setup. Same result. Here are some logs with INFO, INFO_L2, APS, and APS_L2:

0x00212effff080b90 is my coordinator, 0xa497 is my device. I clicked my button once, waited a bit, and then clicked a couple of times.

23:09:33:959 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:09:38:959 GW firmware version: 0x26580700
23:09:38:960 GW firmware version shall be updated to: 0x26660700
23:09:40:421 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -31
23:09:40:421    asdu: 111d02000a0a00
23:09:40:424 Websocket 192.168.0.22:39358 send message: {"attr":{"id":"2","lastannounced":null,"lastseen":"2022-03-18T22:09Z","manufacturername":"DG Electronics","modelid":"RT01","name":"Switch 2","swversion":"202203151","type":"ZHASwitch","uniqueid":"00:12:4b:00:25:79:23:3b-08-0006"},"e":"changed","id":"2","r":"sensors","t":"event","uniqueid":"00:12:4b:00:25:79:23:3b-08-0006"} (ret = 324)
23:09:41:523 APS-DATA.request id: 250, addrmode: 0x03, addr: 0x00124b002579233b, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
23:09:41:524    asdu (length: 2): 4a00
23:09:41:756 APS-DATA.confirm id: 250, status: 0x00 SUCCESS
23:09:41:756 APS-DATA.confirm request id: 250 -> confirmed, timeout 11941565
23:09:41:767 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -31
23:09:41:767    asdu: 4a00020002900b08ffff2e210082d900feff9ffd90b0eb12020252900b08ffff2e2100900b08ffff2e210000002802ffe0
23:09:41:767 APS-DATA.indication request id: 250 -> finished
23:09:41:768 APS-DATA.request id: 250 erase from queue
23:09:41:768 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0xA497
23:09:43:960 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:09:48:618 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -31
23:09:48:618    asdu: 111e02000a0a00
23:09:52:459 sql exec SELECT conf FROM zbconf ORDER BY rowid desc limit 1
23:09:52:459 Idle timer triggered
23:09:52:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:52:460 Force binding of attribute reporting for node Switch 2
23:09:53:460 Idle timer triggered
23:09:53:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:53:461 Force binding of attribute reporting for node Switch 2
23:09:53:960 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:09:54:460 Idle timer triggered
23:09:54:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:54:460 Force binding of attribute reporting for node Switch 2
23:09:55:459 Idle timer triggered
23:09:55:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:55:460 Force binding of attribute reporting for node Switch 2
23:09:56:459 Idle timer triggered
23:09:56:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:56:460 Force binding of attribute reporting for node Switch 2
23:09:57:363 APS-DATA.request id: 253, addrmode: 0x03, addr: 0x00212effff080b90, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
23:09:57:364    asdu (length: 2): 4b00
23:09:57:374 APS-DATA.confirm id: 253, status: 0x00 SUCCESS
23:09:57:374 APS-DATA.confirm request id: 253 -> confirmed, timeout 11957405
23:09:57:378 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 5, rssi: 0
23:09:57:379    asdu: 4b00010001900b08ffff2e21003b237925004b120097a4250001ff
23:09:57:379 APS-DATA.indication request id: 253 -> finished
23:09:57:379 APS-DATA.request id: 253 erase from queue
23:09:57:379 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
23:09:57:460 Idle timer triggered
23:09:57:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:57:461 Force binding of attribute reporting for node Switch 2
23:09:58:459 Idle timer triggered
23:09:58:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:58:460 Force binding of attribute reporting for node Switch 2
23:09:59:460 Idle timer triggered
23:09:59:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:09:59:460 Force binding of attribute reporting for node Switch 2
23:10:00:460 Idle timer triggered
23:10:00:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:00:460 Force binding of attribute reporting for node Switch 2
23:10:01:460 Idle timer triggered
23:10:01:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:01:460 Force binding of attribute reporting for node Switch 2
23:10:02:460 Idle timer triggered
23:10:02:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:02:460 Force binding of attribute reporting for node Switch 2
23:10:03:459 Idle timer triggered
23:10:03:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:03:460 Force binding of attribute reporting for node Switch 2
23:10:03:959 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:10:04:460 Idle timer triggered
23:10:04:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:04:460 Force binding of attribute reporting for node Switch 2
23:10:05:460 Idle timer triggered
23:10:05:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:05:460 Force binding of attribute reporting for node Switch 2
23:10:06:460 Idle timer triggered
23:10:06:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:06:461 Force binding of attribute reporting for node Switch 2
23:10:07:459 Idle timer triggered
23:10:07:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:07:460 Force binding of attribute reporting for node Switch 2
23:10:08:460 Idle timer triggered
23:10:08:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:08:460 Force binding of attribute reporting for node Switch 2
23:10:09:460 Idle timer triggered
23:10:09:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:09:460 Force binding of attribute reporting for node Switch 2
23:10:10:459 Idle timer triggered
23:10:10:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:10:460 Force binding of attribute reporting for node Switch 2
23:10:11:459 Idle timer triggered
23:10:11:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:11:460 Force binding of attribute reporting for node Switch 2
23:10:12:459 Idle timer triggered
23:10:12:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:12:460 Force binding of attribute reporting for node Switch 2
23:10:12:724 APS-DATA.request id: 255, addrmode: 0x03, addr: 0x00124b002579233b, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
23:10:12:724    asdu (length: 2): 4c00
23:10:12:921 APS-DATA.confirm id: 255, status: 0x00 SUCCESS
23:10:12:921 APS-DATA.confirm request id: 255 -> confirmed, timeout 11972765
23:10:12:930 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -31
23:10:12:931    asdu: 4c00020002900b08ffff2e210082d900feff9ffd90b0eb12020252900b08ffff2e2100900b08ffff2e210000002802ffe0
23:10:12:931 APS-DATA.indication request id: 255 -> finished
23:10:12:931 APS-DATA.request id: 255 erase from queue
23:10:12:931 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0xA497
23:10:13:460 Idle timer triggered
23:10:13:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:13:460 Force binding of attribute reporting for node Switch 2
23:10:13:960 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:10:14:460 Idle timer triggered
23:10:14:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:14:461 Force binding of attribute reporting for node Switch 2
23:10:15:459 Idle timer triggered
23:10:15:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:15:460 Force binding of attribute reporting for node Switch 2
23:10:16:460 Idle timer triggered
23:10:16:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:16:460 Force binding of attribute reporting for node Switch 2
23:10:17:460 Idle timer triggered
23:10:17:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:17:460 Force binding of attribute reporting for node Switch 2
23:10:18:459 Idle timer triggered
23:10:18:459 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:18:460 Force binding of attribute reporting for node Switch 2
23:10:19:459 Idle timer triggered
23:10:19:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:19:460 Force binding of attribute reporting for node Switch 2
23:10:19:900 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -30
23:10:19:900    asdu: 111f02000a0a00
23:10:20:363 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -30
23:10:20:364    asdu: 112002000a0a00
23:10:20:459 Idle timer triggered
23:10:20:459 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:20:460 Force binding of attribute reporting for node Switch 2
23:10:20:774 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -30
23:10:20:775    asdu: 112102000a0a00
23:10:21:186 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -30
23:10:21:187    asdu: 112202000a0a00
23:10:21:460 Idle timer triggered
23:10:21:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:21:460 Force binding of attribute reporting for node Switch 2
23:10:21:598 APS-DATA.indication srcAddr: 0xa497, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -31
23:10:21:598    asdu: 112302000a0a00
23:10:22:459 Idle timer triggered
23:10:22:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:22:460 Force binding of attribute reporting for node Switch 2
23:10:22:963 Master: read param with arg 0x19
23:10:22:969 Device TTL 4794 s flags: 0x7
23:10:23:459 Idle timer triggered
23:10:23:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:23:460 Force binding of attribute reporting for node Switch 2
23:10:23:959 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
23:10:24:459 Idle timer triggered
23:10:24:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:24:460 Force binding of attribute reporting for node Switch 2
23:10:25:459 Idle timer triggered
23:10:25:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:25:460 Force binding of attribute reporting for node Switch 2
23:10:26:460 Idle timer triggered
23:10:26:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:26:460 Force binding of attribute reporting for node Switch 2
23:10:27:459 Idle timer triggered
23:10:27:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:27:460 Force binding of attribute reporting for node Switch 2
23:10:28:459 Idle timer triggered
23:10:28:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:28:460 Force binding of attribute reporting for node Switch 2
23:10:28:684 APS-DATA.request id: 6, addrmode: 0x03, addr: 0x00212effff080b90, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
23:10:28:684    asdu (length: 2): 4d00
23:10:28:693 APS-DATA.confirm id: 6, status: 0x00 SUCCESS
23:10:28:694 APS-DATA.confirm request id: 6 -> confirmed, timeout 11988725
23:10:28:699 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 255, rssi: -31
23:10:28:699    asdu: 4d00010001900b08ffff2e21003b237925004b120097a4250001ff
23:10:28:699 APS-DATA.indication request id: 6 -> finished
23:10:28:699 APS-DATA.request id: 6 erase from queue
23:10:28:699 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0x0000
23:10:29:460 Idle timer triggered
23:10:29:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:29:461 Force binding of attribute reporting for node Switch 2
23:10:30:460 Idle timer triggered
23:10:30:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:30:460 Force binding of attribute reporting for node Switch 2
23:10:31:463 Idle timer triggered
23:10:31:463 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:31:463 Force binding of attribute reporting for node Switch 2
23:10:32:460 Idle timer triggered
23:10:32:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:32:461 Force binding of attribute reporting for node Switch 2

[dagroe]

I tried with dstAddrMode: 1 but same result.

[Smanar]

ApsNoAddress = No addressing specified.
ApsGroupAddress = 16-bit group address mode
ApsNwkAddress = 16-bit network address mode
ApsExtAddress = 64-bit extended IEEE address mode
ApsNwkExtAddress =16-bit network address mode and 64-bit extended IEEE address mode (since protocol version 0x010B

Yeah, so can be 0 - nothing 1 - broadcast 2 - unicast

Not realy clear for me too, have you tried with "zcl" logs ?

But there is other thing that boring me, the device is the "switch 2" ?

23:10:24:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:24:460 Force binding of attribute reporting for node Switch 2

It's like deconz can set it, or the device never make report to the gatewayt, as the device is powered it s not configured as sleeping device (on hardware side) ? On the DDF you have posted I can see the bind but not the report setting

• go on the binding tab
• drag the cluster 0x0006 on the left panel (already done)
• drag and drop the attribute 0x0000 on the right panel
• set the report with min 1, max 300

[dagroe]

attribute 0x0000 on which cluster?

Both 0x0006 and 0x0008 don't have any attributes, so I cannot set anything for reporting

[Smanar]

Ha yes right, sorry, I forget was output cluster.

You have too replaced the 0x0000 by 0x0006 here, to have a more complete uniqueid ?

      "uuid": [
        "$address.ext",
        "0x08",
        "0x0000"
      ],

[dagroe]

Yes, I did change the ID.

[dagroe]

Since I was not sure if my device is not working properly, I setup a new homeassistant install with ZHA integration using my conbee stick, and I get events from my device just fine. So the issue must be somewhere in the communication with deconz. Still hope I can make that work.

[Smanar]

And just to test, if you try to set the "sleeper" to true ?

[dagroe]

set sleeper to true. This reduces the logs of

23:10:24:460 Force read attributes for ZHASwitch SensorNode Switch 2
23:10:24:460 Force binding of attribute reporting for node Switch 2

but the rest is still the same.

What about the type in the simpleDescriptor, does it matter? Right now it's set to ZCL_DEVICEID_DIMMER_SWITCH 0x0104.

[Smanar]

This type is more for light device, for sensor you are using a ZHASwitch.

[dagroe]

Tried setting it to ZCL_DEVICEID_LEVEL_CONTROL_SWITCH 0x0001 but no change in behavior.

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

[dagroe]

The issue hasn't been fixed but I do not know what else to try to fix it.

The only solution so far for me is to use home assistant ZHA instead of deconz.

[Mimiix]

Re-opening on request.

@Smanar can you take a look again?

[Smanar]

Hu , I don't remember the problem. You have a DDF (if you can past the last version pls),

But when you use the device, there is nothing in logs about the buttonevent stuff ?

The only visible log is

APS-DATA.indication srcAddr: 0x6a67, srcEp: 0x08 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 159, rssi: -74

Perhaps the fonction DeRestPluginPrivate::checkSensorButtonEvent() is not trigged.

One usefull test is (to trigger it)

        if (ind.dstAddressMode() == deCONZ::ApsGroupAddress || ind.clusterId() == VENDOR_CLUSTER_ID || ind.clusterId() == IAS_ZONE_CLUSTER_ID || zclFrame.manufacturerCode() == VENDOR_XIAOYAN ||
            !(zclFrame.frameControl() & deCONZ::ZclFCDirectionServerToClient) ||
            (zclFrame.isProfileWideCommand() && zclFrame.commandId() == deCONZ::ZclReportAttributesId))
        {

But there is not enought information in the only logs available

ind.dstAddressMode() == deCONZ::ApsGroupAddress > false ind.clusterId() == VENDOR_CLUSTER_ID || ind.clusterId() == IAS_ZONE_CLUSTER_ID || zclFrame.manufacturerCode() == VENDOR_XIAOYAN > false

For other ...

No more information with more logs ? (ZCL ?)

Can you try to add the device on a zigbee group ? Perhaps possible with the old webapp ( in phoscon / help )

[dagroe]

I tried again by setting up a fresh deconz install in a new Ubuntu VM.

I am not sure what I did differently, but now it just works. I got the no button_map for log and when I added a button map, I also got the events in phoscon.

So next I will try to replicate this in my production system. That will take be a bit since I am currently busy with other stuff, but I will let you know how it goes.

Thanks again for the help.

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