Add eWeLink Manufacturer Specific Cluster

[jamesonuk]

There is a Sonoff manufacturer specific cluster which currently appears as 64529 when viewed in the UI

I have essentially gone through https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/sonoff.ts looking for everything under cluster 0xfc11 and also incorporated the two new values from Koenkk/zigbee-herdsman-converters#7130

Converter Definitions

``` binary({ name: 'tamper', cluster: 0xFC11, attribute: {ID: 0x2000, type: 0x20}, description: 'Tamper-proof status', valueOn: [true, 0x01], valueOff: [false, 0x00], zigbeeCommandOptions: {manufacturerCode: 0x1286}, access: 'STATE_GET', }), enumLookup({ name: 'illumination', lookup: {'dim': 0, 'bright': 1}, cluster: 0xFC11, attribute: {ID: 0x2001, type: 0x20}, zigbeeCommandOptions: {manufacturerCode: 0x1286}, description: 'Only updated when occupancy is detected', access: 'STATE', }), binary({ name: 'child_lock', cluster: 0xFC11, attribute: {ID: 0x0000, type: 0x10}, description: 'Enables/disables physical input on the device', valueOn: ['LOCK', 0x01], valueOff: ['UNLOCK', 0x00], }), binary({ name: 'open_window', cluster: 0xFC11, attribute: {ID: 0x6000, type: 0x10}, description: 'Automatically turns off the radiator when local temperature drops by more than 1.5°C in 4.5 minutes.', valueOn: ['ON', 0x01], valueOff: ['OFF', 0x00], }), numeric({ name: 'frost_protection_temperature', cluster: 0xFC11, attribute: {ID: 0x6002, type: 0x29}, description: 'Minimum temperature at which to automatically turn on the radiator, ' + 'if system mode is off, to prevent pipes freezing.', valueMin: 4.0, valueMax: 35.0, valueStep: 0.5, unit: '°C', scale: 100, }), numeric({ name: 'idle_steps', cluster: 0xFC11, attribute: {ID: 0x6003, type: 0x21}, description: 'Number of steps used for calibration (no-load steps)', access: 'STATE_GET', }), numeric({ name: 'closing_steps', cluster: 0xFC11, attribute: {ID: 0x6004, type: 0x21}, description: 'Number of steps it takes to close the valve', access: 'STATE_GET', }), numeric({ name: 'valve_opening_limit_voltage', cluster: 0xFC11, attribute: {ID: 0x6005, type: 0x21}, description: 'Valve opening limit voltage', unit: 'mV', access: 'STATE_GET', }), numeric({ name: 'valve_closing_limit_voltage', cluster: 0xFC11, attribute: {ID: 0x6006, type: 0x21}, description: 'Valve closing limit voltage', unit: 'mV', access: 'STATE_GET', }), numeric({ name: 'valve_motor_running_voltage', cluster: 0xFC11, attribute: {ID: 0x6007, type: 0x21}, description: 'Valve motor running voltage', unit: 'mV', access: 'STATE_GET', }), numeric({ name: 'valve_opening_degree(version >= v1.1.4)', cluster: 0xFC11, attribute: {ID: 0x600B, type: 0x20}, description: 'Valve open position (percentage) control. ' + 'If the opening degree is set to 100%, the valve is fully open when it is opened. ' + 'If the opening degree is set to 0%, the valve is fully closed when it is opened, ' + 'and the default value is 100%, ' + 'The valve opening degree should be greater than or equal to the valve closing degree.', valueMin: 0.0, valueMax: 100.0, valueStep: 1.0, unit: '%', }), numeric({ name: 'valve_closing_degree(version >= v1.1.4)', cluster: 0xFC11, attribute: {ID: 0x600C, type: 0x20}, description: 'Valve closed position (percentage) control. ' + 'If the closing degree is set to 100%, the valve is fully closed when it is closed. ' + 'If the closing degree is set to 0%, the valve is fully opened when it is closed, ' + 'and the default value is 100%. ' + 'The valve opening degree should be greater than or equal to the valve closing degree.', valueMin: 0.0, valueMax: 100.0, valueStep: 1.0, unit: '%', }) ```

I am very old school and struggle with TypeScript and functional programming so be gentle 😬

There are two things that are confusing me

1. there are exports at the bottom of https://github.com/Koenkk/zigbee-herdsman/blob/master/src/zcl/definition/manufacturerCode.ts that are for a few manufacturers but they are already included in the array so should already be included by the first line of the export ????
2. Are these purely UI metadata in that it will give the cluster a name in UI and allow the attributes to show up in the Dev console or should the actual Sonoff converter be reworked to reference these changes???

[Nerivec]

The manuf code doesn't seem to be Sonoff exactly, but Coolkit (eWeLink).

  <mapping code="0x1286" translation="Shenzhen CoolKit Technology Co., Ltd"/>

https://github.com/SiliconLabs/gecko_sdk/blob/911f6cdefccbae03bc66e8c790ceb7e67ca07417/app/zcl/manufacturers.xml#L574

  <mapping code="0x1321" translation="Shenzhen Sonoff Technologies Co., Ltd."/>

https://github.com/SiliconLabs/gecko_sdk/blob/911f6cdefccbae03bc66e8c790ceb7e67ca07417/app/zcl/manufacturers.xml#L633

Confirmed with random products on csa-iot.org:

• https://csa-iot.org/csa_product/ewelink-smart-bridge-9/
• https://csa-iot.org/csa_product/smart-home-hub/

[jamesonuk]

The manuf code doesn't seem to be Sonoff exactly, but Coolkit (eWeLink).

Agreed and I must admin I made a presumption and pulled this out of the converter definition
zigbeeCommandOptions: {manufacturerCode: 0x1286},

I have a just sniffed my network and I can see attributes being reported from the cluster but I am not sure how I confirm what manufacturer code it should be linked to.

[Nerivec]

Probably something like this to be consistent with the name attached to the ID, but let's see what @Koenkk says 😉

-    manuSpecificSonoff: {
+    manuSpecificCoolkit: {

-        manufacturerCode: ManufacturerCode.SONOFF,
+        manufacturerCode: ManufacturerCode.COOLKIT,

-    /** Sonoff */
-    SONOFF: 0x1286,
+    /** Coolkit (eWeLink / Sonoff) */
+    COOLKIT: 0x1286,

Re: #902

[Koenkk]

Coolkit looks like the proper name indeed. I guess this is what SONOFF internally uses.

[jamesonuk]

Probably something like this to be consistent with the name attached to the ID, but let's see what @Koenkk says 😉

Seems Sonoff is 0x1321 so possibly better to have 0x1286 as Coolkit (Ewelink) but that does then differ slightly from the converters which are in sonoff.ts...

Either way, the question I was getting as is how I know the manufacturer code against the cluster is actually right (or whether it actually matters). I picked the only manufacturer code mentioned in the converter but is this just purely metadata for Z2M or will it only apply if the manufacturer and cluster match? (My understanding is that cluster ID should be globally unique so it shouldn't matter ?)

[Nerivec]

Seems to be the branch for the eWeLink-specific stuff...

[jamesonuk]

https://forum.ewelink.cc/t/just-out-of-curiosity-i-ask/17808
does clarify how it is setup. Coolkit == Ewelink but they don't make devices.
Sonoff make devices that use Ewelink (Although https://ewelinkcommunity.net/2021/10/itead-sonoff-and-coolkit-ewelink-moved-to-new-office/ suggests they are near enough one and the same at some level....)
I have only ever seen a handful of Ewelink devices (primarily WiFi relays) that aren't Sonoff but I guess this is all an aside....

The manufacturer code should indeed by Coolkit / Ewelink but I am not sure about the cluster. At some level does it matter which manufacturer it links to (I could see nothing in the Zigbee packets that includes a manufacturer code only the 0xfc11 cluster)

Would I be right in thinking that this just affects what shows up in the cluster view and the dev console

but isn't used by the converters?

Let me know which manufacturer you want to link the 0xfc11 cluster to and whether it should be called Sonoff or Ewelink manufacturer specific cluster and I will update PR

[Koenkk]

Then let's call it ewelink

[Nerivec]

I've been working on refactoring (and adding missing) manufacture codes (& other ZCL-related data) using full entity names per CSA. This name will get overridden anyway when we get to merge it. 😉

@jamesonuk Manufacturer code + Cluster ID are used to identify clusters when parsing/creating ZCL frames, so it is expected to match if the device is providing it (seems yours isn't). Even though technically Z2M seems to fallback if not matching, likely because many devices don't set manufacturerSpecific in frame control properly...
See

zigbee-herdsman/src/zcl/utils.ts

Line 34 in 4a55f23

function getCluster(key: string | number, manufacturerCode: number = null): TsType.Cluster {

[jamesonuk]

Manufacturer code + Cluster ID are used to identify clusters when parsing/creating ZCL frames, so it is expected to match if the device is providing it (seems yours isn't). _Even though technically Z2M seems to fallback if not matching, likely because many devices don't set manufacturerSpecific in frame control properly...

Still not quite sure getting it but should a manufacturer code be part of the data if the manufacturer specific bit was set in the Frame Control Field?

If the manufacturer code is wrong in cluster.ts (not sure what it is being checked against) does this mean that the details won't be picked up?
Is it checking against the manufacturer code of the device during the interview?
Noticed that the TRV devices which seem to be me the main thing using the manufacturer specific cluster show up as SONOFF

where as some Sonoff temp sensors I have show up as eWeLink

where should I be confirming the manufacturer code? Should it be in the read attributes message or is this something I should be looking up somewhere else (I see genBasic has a manufacturerName attribute but not code)

[Hedda]

The manuf code doesn't seem to be Sonoff exactly, but Coolkit (eWeLink).

https://forum.ewelink.cc/t/just-out-of-curiosity-i-ask/17808
does clarify how it is setup. Coolkit == Ewelink but they don't make devices.
Sonoff make devices that use Ewelink (Although https://ewelinkcommunity.net/2021/10/itead-sonoff-and-coolkit-ewelink-moved-to-new-office/ suggests they are near enough one and the same at some level....)
I have only ever seen a handful of Ewelink devices (primarily WiFi relays) that aren't Sonoff but I guess this is all an aside....

FYI for reference, CoolKit is a separate Chinese manufacturer company called Shenzhen Cool House Technology Co., Ltd. (abbreviated as Cool House Technology) that ITead/Sonoff contacts for much of their Zigbee development (hardware, firmware, and software)

https://www.coolkit.cn/

https://github.com/CoolKit-Technologies

CoolKit's Zigbee radio board and devices/products are also used by otther companies, and it is actually CoolKit that owns eWeLink they offer that as a service to 2000+ other companies too, so it is deffinitly not just Sonoff/Itead.

Note! I have no affiliations to them, but a tip is to try sending specific questions to developer@coolkit.cn and/or sales@coolkit.cn, alternativly perhaps try asking @xsp1989 who I believe might be affiliated or employed with them (and a community contributer).

PS: The only reason I am aware of CoolKit is that I researched them because they make the SM-011 V1.0 / ZYZBP008 radio module and firmware that is used in many Chinese Zigbee gateways/bridges/hubs and a few other Zigbee devices, including the Silicon Labs EFR32MG21 based hubs from ITead/Sonoff as well as eWeLink ZB-GW03 white-label product made for rebranding and their own ZB-GW04 Zigbee Coordinator USB adapter dongle. I also believe that they designed the boards of first Zigbee Coordinator adapter dongles from ITead/Sonoff

[Koenkk]

FYI: Once #971 is merged, we can inject the cluster on the device level

[jamesonuk]

@Koenkk does #1019 make this redundant?
along with #983 ??

[Koenkk]

@jamesonuk yes

[Koenkk]

Not needed anymore because of Koenkk/zigbee-herdsman-converters#7432