feat!: add new bind/reporting/map features

[Nerivec]

• [breaking] cleanup old table interfaces and use full set of data for lqi & routingTable
• add "binding table" API support
• add "clear all bindings" API support
• add "read reporting config" API support with automatic adjustment of cached Z2M bindings from response
• fix Foundation readReportConfigRsp conditions

---

For Foundation configReportRsp, some of the tests look wrong in their expected payloads (mix statuses):

• status should always be != 0x00 unless all attrs were successful, in which case, the payload should be [{status: 0x00}]
• otherwise, the payload should be [{status: 0x01, direction: 0x01, attrId: 0x1234}, {status: 0x02, direction: 0x00, attrId: 0x4321}]

Note that attribute status records are not included for successfully configured attributes, to save bandwidth. In the case of successful configuration of all attributes, only a single attribute status record SHALL be included in the command, with the status field set to SUCCESS and the direction and attribute identifier fields omitted.

Though from #115 (comment) looks like some devices may not be following this properly.

[Koenkk]

@Nerivec ready for merge?

[Nerivec]

Should be good!
This one, we may have to tweak the new features based on what feedback we get from users, since no doubt a thousand different devices will behave a thousand different ways 😰
It's not auto-triggered for now though, so, mitigates that.

[asgothian]

Why was the map information changed in a way that generates a breaking change, when this was (from what I see) completely needless ? I have grabbed Routing and LQI information from a small network with ZH 6.4 and 7.0 to compare - both the change in format and the renaming of certain pieces of information generate unneeded breaking changes.

I would like to understand the reason for this - and if it makes sense to update the underlying data now or wait since more of these changes are in the works.

see the comparison below as to what I mean:

6.4 Structure, LQI:

    {
      neighbors: [
        {
          ieeeAddr: "0x00124b002e105341",
          networkAddress: 0,
          linkquality: 120,
          relationship: 2,
          depth: 0,
        },
        {
          ieeeAddr: "0xd85def11a1001341",
          networkAddress: 4756,
          linkquality: 255,
          relationship: 0,
          depth: 15,
        },
        {
          ieeeAddr: "0x7cb03eaa00a715a9",
          networkAddress: 19641,
          linkquality: 206,
          relationship: 2,
          depth: 15,
        },
        {
          ieeeAddr: "0xa4c138be3ac2b01c",
          networkAddress: 33790,
          linkquality: 224,
          relationship: 2,
          depth: 15,
        },
        {
          ieeeAddr: "0x84182600000ec06a",
          networkAddress: 43810,
          linkquality: 255,
          relationship: 2,
          depth: 15,
        },
      ],
    },

7.0 Structure (LQI), same device)

    [
      {
        extendedPanId: [65,83,16,46,0,75,18,0,],
        eui64: "0x00124b002e105341",
        nwkAddress: 0,
        deviceType: 0,
        rxOnWhenIdle: 1,
        relationship: 2,
        reserved1: 0,
        permitJoining: 2,
        reserved2: 0,
        depth: 0,
        lqi: 120,
      },
      {
        extendedPanId: [65,83,16,46,0,75,18,0,],
        eui64: "0xd85def11a1001341",
        nwkAddress: 4756,
        deviceType: 1,
        rxOnWhenIdle: 1,
        relationship: 0,
        reserved1: 0,
        permitJoining: 2,
        reserved2: 0,
        depth: 15,
        lqi: 255,
      },
      {
        extendedPanId: [65,83,16,46,0,75,18,0,],
        eui64: "0x7cb03eaa00a715a9",
        nwkAddress: 19641,
        deviceType: 1,
        rxOnWhenIdle: 1,
        relationship: 2,
        reserved1: 0,
        permitJoining: 2,
        reserved2: 0,
        depth: 15,
        lqi: 207,
      },
      {
        extendedPanId: [65,83,16,46,0,75,18,0,],
        eui64: "0xa4c138be3ac2b01c",
        nwkAddress: 33790,
        deviceType: 1,
        rxOnWhenIdle: 1,
        relationship: 2,
        reserved1: 0,
        permitJoining: 2,
        reserved2: 0,
        depth: 15,
        lqi: 224,
      },
      {
        extendedPanId: [65,83,16,46,0,75,18,0,],
        eui64: "0x84182600000ec06a",
        nwkAddress: 43810,
        deviceType: 1,
        rxOnWhenIdle: 1,
        relationship: 2,
        reserved1: 0,
        permitJoining: 2,
        reserved2: 0,
        depth: 15,
        lqi: 255,
      },
    ],

What irritates me especially is:

• renaming the ieeeAddr field property to eui64 (as far as I am aware, most of the places where it is referred to it is referred to as ieeeAddress or ieee, not eui64 - even in code which was touched by the same change, the naming deviceIeeeAddress was retained)
• renaming the linkquality field to lqi
• renaming the networkAddress field to nwkAddress

Omitting the enclosing object with its neighbors property for the array is irritating, but not really an issue.

Something similar was done to the routing data (omitting the enclosing object with the neighbors property, renaming the nextHop property to nextHopAddress

These changes basically require code changes in libraries which use the respective functions,
A.

[Nerivec]

It's a cleanup of the old format used before the ZDO revamp months ago. We were still creating objects, remapping needlessly, had duplicated typing, etc. The API now uses the ZDO data directly, avoiding all this, and automatically providing the extra data that was omitted before.

[asgothian]

It's a cleanup of the old format used before the ZDO revamp months ago. We were still creating objects, remapping needlessly, had duplicated typing, etc. The API now uses the ZDO data directly, avoiding all this, and automatically providing the extra data that was omitted before.

Thanks for clarifying this. Can you give me a rough idea which areas of the ZH interface / routines are next on the list, so I can prepare the zigbee adapter for the coming change - it makes it a lot easier for me if I have an idea what is coming.

A.

[Nerivec]

We mark PRs with ! (e.g. feat!: xyz) as soon as we run into a breaking change (or try to at least). Next month should get the ZCL spec revamp for e.g. (big one, been pending for a while).
We do this when we have some time to spare, so, no schedule exists.