[feature request] DDF - optional basic cluster identifications

General
1

Currently you can only identify a device by Manufactur Name and Model ID.

For example, Aqara has for their smart plugs different addresses for the power output within the same Model ID, so you can’t use both at the same time currently.

But, they fill other fields like 0x0001 (Application version) and 0x0006 (Date Code) (images attached to show the differences)

173224389-9b4ef4eb-d399-43b9-8b3d-a432988f6a78
173224381-63a153f0-5145-4a3e-892d-a45b457dfa6a

So, would it be possible to add optional identification options for Application Version and/or Date Code in case you have the same model but with different firmware?

1 Like
2

You know exacly what is the difference ?
different cluster or different attribute ?

3

Yes.

Working native with deconz:
Cluster 0B04 (Electrical Measurement)

image
image486×774 52.7 KB

(Active Power 0x050B)

New, not working, only with custom DDF as they use xiaomi special attributes

        {
          "name": "state/power",
          "refresh.interval": 30,
          "parse": {
            "at": "0x00f7",
            "eval": "Item.val = Attr.val",
            "fn": "xiaomi:special",
            "idx": "0x98"
          }
        }


        {
          "name": "state/consumption",
          "refresh.interval": 30,
          "parse": {
            "at": "0x00f7",
            "eval": "Item.val = Attr.val * 1000",
            "fn": "xiaomi:special",
            "idx": "0x95"
          }
        },
4

Arf, cluster change, not sure using both will be possible in DDF.
And they have same cluster on both version ? Not possible to reconize them just with cluster list ?
IDK if the fingerprint used in DDF can be used as filter.

5

yep, the one that uses xiaomi specials also has 0B04 (Electrical Measurement) but the value is permanent 0 for 0x050B.

6

Calling in other devs to check here as well.

7

Does it now also have the 0xFCC0 lumi specific cluster? If yes, what’s the value of attribute 0x0009?

8

Yes, value of 0x0009 is 1

9

Ok. Can you re-read the active endpoints and the simple descriptors? Select the node and do a right click on it for that action. I’d expect the clusters to change.

10

done. 0x0B04 and 0x0702 were gone after re-read of simple descriptors. after a short time of 2-3 minutes they appeared again, so clusters are as before.

11

I’m not sure if this is completely true but I’m currently playing around with this device and I only get a permanent 0 on the Electrical Measurement cluster if the Zigbee coordinator responded with Xiaomi manufacturing codes on pairing.

It seems like that if the coordinator responds with 0x0 and 0x0, the active_power readout magically starts working. I’m guessing the ConBee responds with Xiaomi manufacturing codes for all Xiaomi devices? (Maybe try older ConBee firmware (without the E1 sensor patch) to see if that works for you.)

(Testing using a CC2652 stick)

12

Also, the plug that reports the constant 0 for active power on the Electrical Measurement cluster: Which (special) endpoint, cluster, and attributes are used to get power consumption (+ special Xiaomi manufacturer code?)?

Edit: Nvm, seems to be the Xiaomi special stuff.

13

Interesting discovery, but I’m not sure if I understand what you mean by that. Can you elaborate a bit or share a screenshot?

14

I only tried this once (and I’m mostly using test versions of HA/ZHA) but when I used a TI CC2652 coordinator without this patch https://github.com/Koenkk/Z-Stack-firmware/blob/0cea4d898afaa26ec1fe8550fd6cd6469b332ee4/coordinator/Z-Stack_3.x.0/firmware.patch#L2025-L2037 that’s required for Xiaomi E1 devices for example, the plug seemed to work with no issues (active_power properly reporting).

I would guess newer ConBee firmware versions also include a patch to respond with Xiaomi manufacturer codes (at least when a Xiaomi device is paired). However, to get proper behavior out of this plug, responding with other manufacturer codes on pairing, seems to do the trick.

15

That is indeed the case regarding the firmware, interesting. Ordered now one for some play…

16

nice catch about that manifacturing codes on pairing.

my older smart plug was indeed paired months ago with an older ConBee firmware, so it lacked the Lumi specific Cluster (0xFCC0). For me its not an issue to have active power not being updated, as I have an updated DDF for that plug that reads the xiaomi attributes and publishes them via api instead.

I’ve just re-paired the old one and now have the 0xFCC0 cluster to and it runs with my customized DDF, rather than with the default one.

One thing you just need to change is the reporting interval; thats with 5minutes too long for me, so I changed it to 30 (have this already done with the other smart plug without any issues).