Binding information has wrong cluster names

[sjorge]

What happened?

While messing around with bindings, I noticed that the info has the wrong cluster names (reporting looks fine).
I also noticed that the text label in the database.db entry are also the wrong one.

What did you expect to happen?

The names to be correct

How to reproduce it (minimal and precise)

Have a device that uses manufacturer specific clusters.

Here is the reporting view, the info here looks correct, it is indeed this develcoSpecificAirQuality cluster.

While looking at the binding info:

It is listed as manuSpecificPhilips2 which shares the same ID 0xFC03, both have the manufacturingCode set so there should not be any confusion.

This also the case for the entry in database.db

{
  "id": 106,
  "type": "EndDevice",
  "ieeeAddr": "0x0015bc003600176d",
  "nwkAddr": 62219,
  "manufId": 4117,
  "manufName": "frient A/S",
  "powerSource": "Battery",
  "modelId": "AQSZB-110",
  "epList": [
    1,
    38
  ],
  "endpoints": {
    "1": {
      "profId": 49353,
      "epId": 1,
      "devId": 1,
      "inClusterList": [
        3,
        5,
        6
      ],
      "outClusterList": [],
      "clusters": {},
      "binds": [],
      "configuredReportings": [],
      "meta": {}
    },
    "38": {
      "profId": 260,
      "epId": 38,
      "devId": 770,
      "inClusterList": [
        0,
        1,
        3,
        32,
        1026,
        1029,
        1070,
        64515
      ],
      "outClusterList": [
        3,
        10,
        25
      ],
      "clusters": {
        "genBasic": {
          "attributes": {
            "modelId": "AQSZB-110",
            "manufacturerName": "frient A/S",
            "powerSource": 3,
            "zclVersion": 1,
            "dateCode": "20220428 22:28",
            "develcoPrimarySwVersion": {
              "type": "Buffer",
              "data": [
                4,
                0,
                1
              ]
            },
            "develcoPrimaryHwVersion": {
              "type": "Buffer",
              "data": [
                1,
                1,
                0
              ]
            }
          }
        },
        "genPollCtrl": {
          "attributes": {
            "checkinInterval": 14400
          }
        },
        "manuSpecificPhilips2": {
          "attributes": {
            "measuredValue": 397,
            "resolution": 1
          }
        },
        "msTemperatureMeasurement": {
          "attributes": {
            "measuredValue": 1950,
            "tolerance": 20
          }
        },
        "msRelativeHumidity": {
          "attributes": {
            "measuredValue": 3820,
            "tolerance": 200
          }
        },
        "genPowerCfg": {
          "attributes": {
            "batteryVoltage": 29,
            "batteryAlarmState": 0
          }
        }
      },
      "binds": [
        {
          "cluster": 32,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b00228120b5",
          "endpointID": 1
        },
        {
          "cluster": 64515,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b00228120b5",
          "endpointID": 1
        },
        {
          "cluster": 1026,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b00228120b5",
          "endpointID": 1
        },
        {
          "cluster": 1029,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b00228120b5",
          "endpointID": 1
        },
        {
          "cluster": 1,
          "type": "endpoint",
          "deviceIeeeAddress": "0x00124b00228120b5",
          "endpointID": 1
        }
      ],
      "configuredReportings": [
        {
          "cluster": 64515,
          "attrId": 0,
          "minRepIntval": 60,
          "maxRepIntval": 3600,
          "repChange": 10
        },
        {
          "cluster": 1029,
          "attrId": 0,
          "minRepIntval": 60,
          "maxRepIntval": 600,
          "repChange": 300
        },
        {
          "cluster": 1,
          "attrId": 32,
          "minRepIntval": 3600,
          "maxRepIntval": 43200,
          "repChange": 100
        },
        {
          "cluster": 1026,
          "attrId": 0,
          "minRepIntval": 60,
          "maxRepIntval": "3600",
          "repChange": "10"
        }
      ],
      "meta": {}
    }
  },
  "hwVersion": "1.1.0",
  "dateCode": "20220428 22:28",
  "swBuildId": "4.0.1",
  "zclVersion": 1,
  "interviewCompleted": true,
  "meta": {
    "configured": 1198563592
  },
  "lastSeen": 1677428613937,
  "defaultSendRequestWhen": "active"
}

Zigbee2MQTT version

1.30.1-dev commit: 6afcb97

Adapter firmware version

20221226

Adapter

zzhp-lite

Debug log

No response

[Koenkk]

@nurikk I think we should remove the cluster information from the frontend and make the frontend request it from z2m, what do you think?

[nurikk-sa]

@nurikk I think we should remove the cluster information from the frontend and make the frontend request it from z2m, what do you think?

yep, this would be great. getting clusters from z2m rather that depending on zhc will solve problems with outdated dependencies

[Koenkk]

@nurikk-sa

• I don't think it makes sense to publish to bridge/info, should we make a separate request for this?
• Does this remove all the dependencies from the frontend to zhc/zh?
• To solve this issue, the following logic has to be implemented in the frontend. If it supports cluster X, first try to find cluster X with the device manufacturerCode, if that doesn't exist, pick the first matching without taking into account the manufacturerCode.

[nurikk]

@nurikk-sa

• I don't think it makes sense to publish to bridge/info, should we make a separate request for this?
• Does this remove all the dependencies from the frontend to zhc/zh?
• To solve this issue, the following logic has to be implemented in the frontend. If it supports cluster X, first try to find cluster X with the device manufacturerCode, if that doesn't exist, pick the first matching without taking into account the manufacturerCode.

1. yes, separate api call would work
2. yes, its the only reason we have dependencies on zhc
3. I don’t quite understand this point

[Koenkk]

@nurikk the problem is that a clusters can have the same ID. Take e.g. 0xFC03 which maps to both develcoSpecificAirQuality and manuSpecificPhilips2. For a Philips device it should show manuSpecificPhilips2 since the manufacturerCode of this cluster equals the manufacturerCode of the device, not the develcoSpecificAirQuality as is currently being done.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sjorge]

Unstale

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sjorge]

Unstale

[nurikk]

Hi!
Can you attach complete state.json file from Settings -> Tools -> Download state ?

[sjorge]

state.json.zip

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sjorge]

Still present, unstale

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days