Proposal how to handle duplicate zigbeeModels

[middelink]

Greetings,

I recently bumped into an Aliexpress Lonsonho? 1-gang switch which reports TS0001 as its zigbee model ID. So I joined it to my network and it reported itself as a "CR Smart Home Valve Control". That cannot be right... Well, it is. It seems there is no handling for duplicate zigbee Models, the assumption being, like model numbers, that all manufactures work together to have each zigbeeModel unique.. Right :) For now it looks like TS0001 will be the one device having this issue, with 3 manufactures, as there is already a different TS0001 commented out. But there is no guarantee it will not happen for other devices.

So I can see only one way to solve this, by including the manufacturer Name in the FindByZigbeeModel() search. Downside is that existing devices don't have manufactures listed, so it needs to fall back to the current behavior if that is the case. We can change the uniqueness test to assert that the zigbeeModel is unique per manufacturer.

So, how to add this manufacturer name? Keep in mind, as we allow multiple zigbeeModels per device, we need multiple zigbeeManufactuerers as well, which need to pair up.
E.g. { zigbeeModel: ['TS0012', 'TS0001'], zigbeeManufactuerer: ['Something', 'Spooky'], }
or we encode it in the model name with a special separator.
E.g. { zigbeeModel: ['TS0012/Something', 'TS0001/Spooky'], }
or, uhm. tuples?
E.g. { zigbeeModel: [ ['TS0012','Something'], ['TS0001','Spooky'] ], }

I think I prefer the first, as it reads the simplest and as devices.js needs to be maintained by non-programmers, simplest is a good criteria...

Any thoughts? Suggestions? I'm happy to provide patches if this meets approval.

[Koenkk]

These devices are actually all from TUYA, the problem is that the manufacturerName is also the same :(

[middelink]

Ah, you're saying the Zemismart TS0001 == CR Smart Home TS0001 == my "Wireless Smart Switches" TS0001? :(

If so, can we at least combine to one entry with the same fromZigbee and toZigbee entries? or do they differ as well? :(

Let me for prosperity sake include the database entry, so we can figure out if the others are really identical or not:

{"id":43,"type":"Router","ieeeAddr":"0xec1bbdfffe0f96d1","nwkAddr":21142,"manufId":0,"manufName":"_TYZB01_seqwasot","powerSource":"Mains (single phase)","modelId":"TS0001","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":256,"inClusterList":[0,3,4,5,6],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"TS0001","manufacturerName":"_TYZB01_seqwasot","powerSource":1,"zclVersion":3,"appVersion":66}},"genOnOff":{"attributes":{"onOff":0,"onTime":0,"offWaitTime":0}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001949ee82","endpointID":1}]}},"appVersion":66,"zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":null}

[Koenkk]

What type of device is your TS0001? Can you provide an URL?

[middelink]

It's a 1-gang, L+N switch for EU, (so it fits existing EU home wall mounts)
https://www.aliexpress.com/item/4000298926256.html

[Koenkk]

Taken from here: Koenkk/zigbee-herdsman-converters#810 (comment)

database.db for Zemismart:

{"id":2,"type":"Router","ieeeAddr":"0xec1bbdfffe687fad","nwkAddr":45897,"manufId":0,"manufName":"_TYZB01_3xe7wzpw","powerSource":"Mains (single phase)","modelId":"TS0001","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":256,"inClusterList":[0,3,4,5,6],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"TS0001","manufacturerName":"_TYZB01_3xe7wzpw","powerSource":1,"zclVersion":3,"appVersion":66}}},"binds":[]}},"appVersion":66,"zclVersion":3,"interviewCompleted":true,"meta":{}}

As you can see the manufacturerName is the same, AFAIK the part after _TYZB01_ is always random and can even differs per device.

[middelink]

Yeah, I guess there is not much to gain except for making the name look prettier. Ow well, lets table this then till we really bump into a double modelID :)

Feel free to close the topic if you agree.

[Koenkk]

I would like to keep this open to gather more database.db entries for these devices (to see if we can find a pattern in it).

[dzungpv]

@Koenkk just a note for Z-Stack 3.1.0-3.5.0, Model ID is not a require one, you can see it here http://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/875025
They have other way to handle what a device is, you can check TI Sensor to cloud project.

[middelink]

Hmm, that is interesting. Looking through the the NXP ZCL, I also see the attribute is indeed not mandatory. (my only reference i had handy).

I'm unable to find anything useful on "TI Sensor to cloud" except a bunch of Bluetooth and 1352 development boards. Do you have a link handy?

[Koenkk]

I was thinking that maybe we can distinguish between devices when they have different endpoints, or different supported clusters, appVersion, zclVersion, etc.

But even this is identical for these 2 devices, however this may not be the case if two devices are sharing the modelID where one is a bulb and the other one is just a switch. The switch would then e.g. not support the brightness cluster.

[carldebilly]

That's how SmartThings is working... there's a feature called fingerprinting which is doing that: https://docs.smartthings.com/en/latest/device-type-developers-guide/definition-metadata.html#fingerprinting

[middelink]

Hi,

Interesting, but that will be a fairly big configuration shift. Instead of well, findByModelID(), the function now needs to be given the full device, in order to match on some (/every possible [1])? attribute. It would save a tremendous amount of support though, as most devices would just fall into place and one when ppl complain "the battery voltage is always empty", we can hunt down what is special about it.

So the device list will now be a list of "handlers", say "Generic Light", with the proper fromZigbee and toZigbee lists and whats not. Such a handler will also have a (list of) finger prints, which needs to be intelligently matched against the devices. And the more matches a finger print has the more preferential it will be, say the Common Light matches just on inclust[6], a Common Dimmable Light matches on incluster [6,8] and a "Common Dimmable Colortemp Light` maches on incluster [6,8,0x300]. But since Ikea has to be special, it can have a "Ikea Dimmable Colortemp Light" which might have a specialized fromZigbee in there.

What will be crucial here is that at interview time, when we have a bunch of more information than we retain in the database (I think), we need to find the correct handler and either retain it's handler_id in the device database, or keep enough of the attributes[1] around so we can find the same handler for the device over and over again.

It might be possible to go a step further and discover multiple handlers for a device, for example, if a device is both a relay (on/off) and a switch (on/off switch) or even multiple switches. That way most of out current devices would collapse into a few on/off handlers (a single ssIasZone and ssIasWd handler, yes!) and some specialized battery voltage/percentage handlers. Downside is that the configuration would be harder to explain to a casual "editor", as their device would be all over N handlers. On the other hand, it should be easy enough to make a test which yells loudly when two handlers have the same fingerprints. Maybe we should even require some database entry to be added for each device, so we can assert each device will always end up with at least one handler.

I guess the handlers also need to way to inform the higher up zigbee2mqtt stack what this handler supports (not just a text field supports, but a list of constants), so the correct home assistant configuration objects can be created. Hopefully these are pretty generic (should be as the from/toZigbee should have massaged the device into a "normal" workflow.

Maybe we can even leverage the full SmartThings definitions, their capabilities can then project into Home Assistant items, possible augmented by attributes. Although I could not find their devices database online, so that might prove futile if it isn't public and freely available. Oh, and it would need some kind of specialized parser for the format as well. So scrap that.

Thoughts?

[1] looking at the smartthings page, it seems they only use the in/out clusters and the manufacturer and modelid as entries. Which might be identifying enough.

[Koenkk]

I don't think we should go that far and I want to go for a much simpler approach as the zigbeeModel has worked fine for now (with over 550+ supported devices). It's also much more readable and easier to understand. There are 2 known cases now where it was not sufficient:

• OP of this issue -> turns out that even the endpoints and supported clusters are the same -> impossible to distinguish
• Paul Neuhaus Q-MALINA doesn't work correctly (timeouts) #2677 : possible to distinguish using fingerprint below

Let's say we have 2 device definitions:

// device A
{
  zigbeeModel: ["mymodelID"],
  ...
},
// device B
{
  zigbeeModel: ["mymodelID"],
  fingerpint: {endpoints: {1: {inputClusters: ["genBasic", "genLevelCtrl"]]}}
  ...
}

• fingerprint is optional and will only be added once we run into zigbeeModel duplications (so only very few devices will have this)
• following device {modelID: "mymodelID", endpoints: {1: {inputClusters: ["genBasic", "genLevelCtrl", "lightingColorCtrl"]}}} -> will match with device A
• following device {modelID: "mymodelID", endpoints: {1: {inputClusters: ["genBasic", "genLevelCtrl", ]}}} -> will match with device B

[TilmanK]

I'm not sure if this is going to work for my device from #2677. The device also identifies itself as being capable of handling HSV attributes. I'd need to check logs/traffic, but I'm pretty sure that the Hue bridge doesn't have a DB like Z2M.

Probably, Paul Neuhaus just uses the same Jennic Zigbee interface over and over again. (Pretty bad for a €329 light...)

[Koenkk]

@TilmanK so it also has lightingColorCtrl (aka 768) in inClusterList?

[TilmanK]

I'd need to capture that traffic again, since I didn't get the appropriate message (I need to move the stick closer...).

But like I said, my Hue bridge also thinks that it supports color and happily reads color properties:
Frame 1013: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface \.\pipe\zboss_sniffer, id 0
ZBOSS dump, IN, page 0, channel 25
IEEE 802.15.4 Data, Dst: 0x0001, Src: 0x000a
ZigBee Network Layer Data, Dst: 0x0001, Src: 0x000a
ZigBee Application Support Layer Data, Dst Endpt: 64, Src Endpt: 2
ZigBee Cluster Library Frame, Command: Read Attributes Response, Seq: 121
Frame Control Field: Profile-wide (0x18)
Sequence Number: 121
Command: Read Attributes Response (0x01)
Status Record
Attribute: Color Temperature (0x0007)
Status: Success (0x00)
Data Type: 16-Bit Unsigned Integer (0x21)
Color Temperature: 250 [Mired] (4000 [K])
Status Record
Attribute: Enhanced Current Hue (0x4000)
Status: Success (0x00)
Data Type: 16-Bit Unsigned Integer (0x21)
Enhanced Hue: 7072
Status Record
Attribute: Current Saturation (0x0001)
Status: Success (0x00)
Data Type: 8-Bit Unsigned Integer (0x20)
Saturation: 171
Status Record
Attribute: Current X (0x0003)
Status: Success (0x00)
Data Type: 16-Bit Unsigned Integer (0x21)
X: 0,4110
Status Record
Attribute: Current Y (0x0004)
Status: Success (0x00)
Data Type: 16-Bit Unsigned Integer (0x21)
Y: 0,3958
Status Record
Attribute: Color Mode (0x0008)
Status: Success (0x00)
Data Type: 8-Bit Enumeration (0x30)
Color Mode: Hue and Saturation (0x00)
Status Record
Attribute: Color Loop Active (0x4002)
Status: Success (0x00)
Data Type: 8-Bit Unsigned Integer (0x20)
Active: False

I'll be sure 100% when I find the time to capture the logs for the timeout issue.

[Koenkk]

No need to sniff, you can find it in database.db.

[TilmanK]

{"id":29,"type":"Router","ieeeAddr":"0x00158d0002a6d294","nwkAddr":41527,"manufId":4151,"manufName":"Neuhaus Lighting Group ","powerSource":"Mains (single phase)","modelId":"NLG-RGBW light ","epList":[1,2],"endpoints":{"1":{"profId":49246,"epId":1,"devId":4096,"inClusterList":[4096],"outClusterList":[4096],"clusters":{},"binds":[]},"2":{"profId":49246,"epId":2,"devId":528,"inClusterList":[0,4,3,6,8,5,768],"outClusterList":[0,25],"clusters":{"genBasic":{"attributes":{"modelId":"NLG-RGBW light ","manufacturerName":"Neuhaus Lighting Group ","powerSource":1,"zclVersion":1,"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20150821","swBuildId":"1001-0007"}}},"binds":[]}},"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20150821","swBuildId":"1001-0007","zclVersion":1,"interviewCompleted":true,"meta":{},"lastSeen":1579971066266}

Yes :/ Like I said, I believe they are using the same Zigbee module for every device.

[middelink]

So it has 768 (Colour Control Cluster) which includes attributes for HSV. So I think it would work. In this case the device fingerprint would contain something like this:

{
  zigbeeModel: ["NLG-RGBW light"],
  fingerpint: {endpoints: {2: {inputClusters: ["genBasic", "genOnOff", "genLevelCtrl", "lightingColorCtrl"]}}
  ...
}

it seems that endpoint 1 only contains touchlink and endpoint 2 the interesting parts of the device. I also find it interesting the inclusters on ep2 are completely unsorted. guess they made their own zigbee stack. Which seems reasonable for the 329 euri expense :)

[middelink]

So, to return to the original thread, I summarize:

1. add fingerprint attributes to all duplicates entries, allowing them to specify all attributes from a device. Note I'm allowing for all kind of attributes, even though many of them never be used, but for the user to bump into an identical device (model, clusters), they want to discern on say appversion or datecode without waiting for a new dev release.
2. new function in zigbee-herdsman-converters to find a device by well, device(entity? what is the right nomenclature here?). It will try a normal map-lookup on just the zigbeeModel, if it hits more than one device, it checks the fingerprints.
3. adjust tests to yell about devices which are not unique, either by zigbeeModel without fingerprints or by multiple zigbeeModels with fingerprints which match.

And finally, as a general statement, zigbeeModel is actually just another fingerprint attribute, it does not require the special handling we give it here.

Ok? good plan?

[Koenkk]

@TilmanK but if I understand correctly, this device does not support colour right?

[TilmanK]

@Koenkk You do. I have contacted the vendor. They asked for a picture of my coordinator. That’s going to be fun...

I guess we can’t identify the devices correctly. Should we add something to the docs about this?

[Koenkk]

Yes, feel free to create a pr for it.

[BastiaanNaber]

I bought a Lonsonho 2 way wall switch: https://www.aliexpress.com/item/4000298926256.html?spm=a2g0s.9042311.0.0.27424c4dJg7Xdr

Which reports itself as a TS0002 which is also reported by the Zemismart ZM-CSW002-D.

The database.db entry:

{"id":10,"type":"Router","ieeeAddr":"0xec1bbdfffe9303fe","nwkAddr":54693,"manufId":0,"manufName":"_TYZB01_6sadkhcy","powerSource":"Mains (single phase)","modelId":"TS0002","epList":[1,2],"endpoints":{"1":{"profId":260,"epId":1,"devId":256,"inClusterList":[0,3,4,5,6],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"TS0002","manufacturerName":"_TYZB01_6sadkhcy","powerSource":1,"zclVersion":3,"appVersion":66}},"genOnOff":{"attributes":{"onOff":0}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001936657c","endpointID":1}]},"2":{"profId":260,"epId":2,"devId":256,"inClusterList":[0,3,4,5,6],"outClusterList":[25],"clusters":{"genOnOff":{"attributes":{"onOff":0}}},"binds":[]}},"appVersion":66,"zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1580552729474}

Using the 1.9.0 devices.js I get this error:

error 2020-02-01 11:32:11: Failed to configure '0xec1bbdfffe9303fe', attempt 2 (Error: Timeout - 54693 - 1 - 2 - 6 - 7 after 10000ms
at Timeout.object.timer.setTimeout [as _onTimeout] (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)

[Koenkk]

@BastiaanNaber probably the same story as the 1 gang switch, technically devices are identical and based on the fingerprint not distinguishable. That also means it should already work. Please try again with the latest zigbee2mqtt dev branch, it has improved logging so we can see where things go wrong.

I've created an overview of the duplicate device ids': https://docs.google.com/spreadsheets/d/1SVIVH6kcuKCCEcFn5h7svuYbE2rF_AVl1IH0360ztSc/edit?usp=sharing

As you can see Lonsoho 1 gang is identical to the Zemismart ZM-L01E-Z (1 Gang)

[stale]

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.

[middelink]

poke, not stale, just slow.

[artem-dudarev]

I just faced the model ID conflict with this Lonsonho wired switch:
https://www.aliexpress.com/item/4000298926256.html
Its model ID is TS0601, which is the same as for some curtain motor, and of course, these are absolutely different devices with different capabilities.
Record from database.db:

{
  "id": 2,
  "type": "Router",
  "ieeeAddr": "0xec1bbdfffe69c0b5",
  "nwkAddr": 6890,
  "manufId": 4098,
  "manufName": "_TZE200_8vxj8khv",
  "powerSource": "Mains (single phase)",
  "modelId": "TS0601",
  "epList": [ 1 ],
  "endpoints": {
    "1": {
      "profId": 260,
      "epId": 1,
      "devId": 81,
      "inClusterList": [ 0, 4, 5, 61184 ],
      "outClusterList": [ 25, 10 ],
      "clusters": {
        "genBasic": {
          "attributes": {
            "modelId": "TS0601",
            "manufacturerName": "_TZE200_8vxj8khv",
            "powerSource": 1,
            "zclVersion": 3,
            "appVersion": 64,
            "stackVersion": 0,
            "hwVersion": 1,
            "dateCode": ""
          }
        }
      },
      "binds": []
    }
  },
  "appVersion": 64,
  "stackVersion": 0,
  "hwVersion": 1,
  "dateCode": "",
  "zclVersion": 3,
  "interviewCompleted": true,
  "meta": {},
  "lastSeen": 1591130632063
}

For every click on one of three buttons, it sends three messages (one per available button):

Received Zigbee message from 'switch4', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"status":0,"transid":13,"dp":257,"fn":0,"data":{"type":"Buffer","data":[1]}}' from endpoint 1 with groupID 0
Received Zigbee message from 'switch4', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"status":0,"transid":14,"dp":258,"fn":0,"data":{"type":"Buffer","data":[0]}}' from endpoint 1 with groupID 0
Received Zigbee message from 'switch4', type 'commandGetData', cluster 'manuSpecificTuyaDimmer', data '{"status":0,"transid":15,"dp":259,"fn":0,"data":{"type":"Buffer","data":[0]}}' from endpoint 1 with groupID 0

I guess dp contains the button number and data tells if the switch is on or off.

[tabletka-ao]

HI @artem-dudarev
I have the same problem. I bought wall switches X711A (1 gang) , X712A (2 gang).
Did you manage to deal with him?

[artem-dudarev]

@tabletka-ao In general, I've succeeded with configuring the X711A switch. It works fine with my Home Assistant, but I still need to make some changes to use both X711A and X712A at the same time. Since they have the same modelId (TS0601) but different manufacturerName (_TZE200_8vxj8khv and _TZE200_dhdstcqc), I think this can be achieved by using the fingerprint field.

Here is how to reproduce my current configuration:

1. Add the new device descriptor to node_modules\zigbee-herdsman-converters\devices.js. It is important to add it after the existing TS0601 curtain motor. When there are multiple descriptors with the same zigbeeModel, the last one takes effect.

    {
        zigbeeModel: ['TS0601'],
        model: 'X711A',
        vendor: 'Lonsonho',
        description: '1 gang switch',
        supports: 'on/off',
        fromZigbee: [fz.tuya_switch_new, fz.ignore_time_read],
        toZigbee: [tz.tuya_switch_state],
        endpoint: (device) => {
            // Endpoint selection is made in tuya_switch_state
            return { 'l1': 1, 'l2': 1, 'l3': 1 };
        },
    },

2. Add tuya_switch_new after the existing tuya_switch in node_modules\zigbee-herdsman-converters\converters\fromZigbee.js

    tuya_switch_new: {
        cluster: 'manuSpecificTuyaDimmer',
        type: 'commandGetData',
        convert: (model, msg, publish, options, meta) =>
        {
            const dp = msg.data.dp;
            const state = msg.data.data[0] ? 'ON' : 'OFF';

            switch (dp) {
            case 257: // 0x01 0x01:
                return { state_l1: state };
            case 258: // 0x01 0x02:
                return { state_l2: state };
            case 259: // 0x01 0x03:
                return { state_l3: state };
            }
        }
    },

3. Add a line to lib\extension\homeassistant.js after TS0601 if you are using Home Assistant

    'X711A': [switchEndpoint('l1')],
    'X712A': [switchEndpoint('l1'), switchEndpoint('l2')],

[Koenkk]

@artem-dudarev be cautious to identify this based on the manufacturerName as this can differ for every tuya device. It will be better to differentiate based on the clusters, you can find a database.db entry of the curtain motor here: Koenkk/zigbee-herdsman-converters#1159 (comment)

[DomiStyle]

Maybe someone could also post the database.db entry for the TS0601 curtain motor to check if they're 100% identical with the owvfni3. @cchalong @jeholsa

#3088

[dzegarra]

Is there's no easy way to generate a universal identifier I propose the following:

• In configuration.yaml, allow users to override the device model (the codes in devices.js) of any paired device id.
• If the device model identified (using the current algorithm) matches 2 or more models in devices.js:
  • Choose the first one.
  • Print in the console a hint of the problem and a link to the official docs to learn how to solve it in case the first chosen model is not the correct one.

[Koenkk]

@dzegarra that should indeed be done when the fingerprint doesn't provide an outcome https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L4832. If you have a concrete example we can work on this.

[tabletka-ao]

@Koenkk examples switches with modelid of the curtain motor

Switch 1 gang
Model: X711A,
Manufacturer: Lonsonho

{
  "id": 3,
  "type": "Router",
  "ieeeAddr": "0xec1bbdfffe69e0a4",
  "nwkAddr": 19914,
  "manufId": 4098,
  "manufName": "_TZE200_8vxj8khv",
  "powerSource": "Mains (single phase)",
  "modelId": "TS0601",
  "epList": [
    1
  ],
  "endpoints": {
    "1": {
      "profId": 260,
      "epId": 1,
      "devId": 81,
      "inClusterList": [
        0,
        4,
        5,
        61184
      ],
      "outClusterList": [
        25,
        10
      ],
      "clusters": {
        "genBasic": {
          "attributes": {
            "modelId": "TS0601",
            "manufacturerName": "_TZE200_8vxj8khv",
            "powerSource": 1,
            "zclVersion": 3,
            "appVersion": 64,
            "stackVersion": 0,
            "hwVersion": 1,
            "dateCode": ""
          }
        }
      },
      "binds": []
    }
  },
  "appVersion": 64,
  "stackVersion": 0,
  "hwVersion": 1,
  "dateCode": "",
  "zclVersion": 3,
  "interviewCompleted": true,
  "meta": {},
  "lastSeen": 1591682041454
}

Switch 2 gang
Model: X712A,
Manufacturer: Lonsonho

{
  "id": 2,
  "type": "Router",
  "ieeeAddr": "0xec1bbdfffe76c09f",
  "nwkAddr": 54292,
  "manufId": 4098,
  "manufName": "_TZE200_dhdstcqc",
  "powerSource": "Mains (single phase)",
  "modelId": "TS0601",
  "epList": [
    1
  ],
  "endpoints": {
    "1": {
      "profId": 260,
      "epId": 1,
      "devId": 81,
      "inClusterList": [
        0,
        4,
        5,
        61184
      ],
      "outClusterList": [
        25,
        10
      ],
      "clusters": {
        "genBasic": {
          "attributes": {
            "modelId": "TS0601",
            "manufacturerName": "_TZE200_dhdstcqc",
            "powerSource": 1,
            "zclVersion": 3,
            "appVersion": 64,
            "stackVersion": 0,
            "hwVersion": 1,
            "dateCode": ""
          }
        }
      },
      "binds": []
    }
  },
  "appVersion": 64,
  "stackVersion": 0,
  "hwVersion": 1,
  "dateCode": "",
  "zclVersion": 3,
  "interviewCompleted": true,
  "meta": {},
  "lastSeen": 1591649605846
}

[Koenkk]

@cchalong since you have a TS0601 curtain motor, could you share the data/database.db entry of it?

[Koenkk]

#3821 (comment) shows another device using TS0601 as model ID. Unfortunately the endpoints, cluster, profile IDs and devIDs are exactly the same. There must be some other way TuYa identifies these devices. @kirovilya do you perhaps know how?

[Foroxon]

@Koenkk Looks like "manufName" are different for different devices

[kirovilya]

Unfortunately, I do not have these devices. in our chat users also complain that some switches are defined as "curtains".
Tuya - this is not Livolo, should be solution :)
it would be ideal to record a sniff log of pairing with a native gateway for curtains and for a switch. then compare them

[kirovilya]

Sniff log should show the transmission of parameters by which the Tuya gateway determines which device it interacts with. It seems that the model name is no longer a defining parameter for Tuya.

[artem-dudarev]

#3821 (comment) shows another device using TS0601 as model ID. Unfortunately the endpoints, cluster, profile IDs and devIDs are exactly the same.

@Koenkk I don't see any problem here. If there are four identical thermostatic valves, why would they have different properties?

_TZE200_ckud7u2l - thermostatic valve
_TZE200_8vxj8khv - one gang switch
_TZE200_dhdstcqc - two gang switch

[Koenkk]

@Foroxon @artem-dudarev it seems that the manufacturer name is indeed different, I initially thought that this would also differ per device type but #3821 (comment) shows 4 times the same for the valve so that seems to be an invalid assumption.

@nukusinji since you added initial support for the TS0601 curtain, can you share the data/database.db entry of your device?

[kirovilya]

Let's use manufacturer as part of the fingerprint for these devices. Like here: https://github.com/iquix/Smartthings/blob/master/devicetypes/iquix/tuya-window-shade.src/tuya-window-shade.groovy#L27-L30

[artem-dudarev]

I think findByDevice() should try to find the device by fingerprint first - this will allow adding new devices without knowing the database.db record for the existing device defined with zigbeeModel.

[Koenkk]

@artem-dudarev I'm not sure about that, this will have a big downside when the fingerprint doesn't exactly match and it will fallback to the zigbeeModel which will lead to wrong identification (and confusion). This can easily happen for the TuYa devices as one specific device can have multiple manufacturerName. I think a better way to deal with this in the future is to also ask for the data/database.db entry when supporting a new TuYa device or immediately start using the fingerprint as identification method.

[artem-dudarev]

@Koenkk As far as I understand, the fingerprint feature was introduced to resolve the issue with duplicating zigbeeModels, which means that fingerprint should be a more precise identifier than zigbeeModel. And nothing prevents to build such a precise identifier because fingerprint can contain multiple attributes of the device.

When zigbeeModel is checked first, it's even impossible to add both X711A and X712A switches via the external converter because both of them have zigbeeModel TS0601 and this model conflicts with the existing curtain motor.
If I want to override the curtain motor with switches, I have to use zigbeeModel, but this means I can add only one of two switches, otherwise the second switch will override the first one. So overriding doesn't work. Not to mention the fact that in this case the curtain motor cannot be used at all.
On the other hand, I can add both switches with fingerprints, but this also doesn't work because the curtain motor will be found instead of switches by zigbeeModel.
That's why I think the fingerprint should be checked first. This resolves all the issues with duplicate zigbeeModels and it doesn't require to change definitions for existing devices.

As for Tuya devices, I believe different manufacturerNames belong to different devices. They might look very similar but they are still different devices (from different vendors, for example) that have firmware based on the Tuya framework.

[Koenkk]

@artem-dudarev after seeing the same issue in Koenkk/zigbee-herdsman-converters#1162 I'm convinced that identification through fingerprint should be done first indeed. Implemented this now, thanks for the discussion.

As I believe the OP issue has been fixed by introducing identification via fingerprint, I assume this can be closed now.