Thanks Mariano. I have migrated across most of my devices. For some reason, these Smart Plugs are still picking up the old Zigbee Switch DH and not picking up your Edge driver. Any ideas?
Data * application: 01
Added to this driver version
───────────────────────────────────────────────────
Name Zigbee Switch Mc
Version 2022-10-20T09:47:59.853934965
───────────────────────────────────────────────────
- id: "3A SMart/LXN-1S27LX1.0"
deviceLabel: 3A SMart Switch
manufacturer: 3A SMart Home DE
model: LXN-1S27LX1.0
deviceProfileName: single-switch
This device was added time ago to this driver
───────────────────────────────────────────────────
Name Zigbee Multi Switch and Child Mc
Version 2022-10-20T09:52:35.56515183
───────────────────────────────────────────────────
This device is added fine to driver Zigbee Switch Mc.
may be have you a custom DTH with this fingerprints?
Hmm, I don’t have any custom DTHs. Deleted them all a couple of weeks ago. I’ll keep trying
I think you’re haveing an issue similar to mine, posted HERE
Still unsolved, maybe with the new firmware (I’m still on 44.9).
Ore when they’ll pull DTHs completely. It is annoying though.
Yes, very similar, but at least mine is picking up the stock Zigbee Switch DH, and it executes locally anyway, so I’m not really affected much.
Apart from some roller blinds, these plugs are my only devices not on Edge drivers, and it just bugs me.
Hi mariano, can you add this device?
Its 4 chanel relay (i have similer one that work with your driver).
Thanks
Hi @OferDV
Added to this driver version, but is a single switch nit a 4 channel switch
───────────────────────────────────────────────────
Name Zigbee Switch Mc
Version 2022-10-20T15:01:19.419945775
───────────────────────────────────────────────────
- id: "TS0001/_TZ3000_ajv2vfow"
deviceLabel: TS0001 Switch
manufacturer: _TZ3000_ajv2vfow
model: TS0001
deviceProfileName: single-switch
Hi @Mariano_Colmenarejo Could you please add this one when you have time?
It’s a Tuya Smart Plug (Australian model)
Data
Thanks.
Hi @RebelMagpie
This device was added some days ago in driver Zigbee Swtich Power Mc
Please could you try this driver version, may be it works fine
───────────────────────────────────────────────────
Name Zigbee Multi Switch and Child Mc
Version 2022-10-21T11:00:22.576036175
───────────────────────────────────────────────────
I just has to say Wowwwww
you solved it!!!
now its working great!!
thankss a lot!!!
For those who need implemente the solution.
In the solution, thank very much the help of the developer @Trakker2 kkossev from hubitat, who has it implemented in his hubitat DTH.
He confirmed, I need to read basic cluster 0x0000, these six attributes during pairing, to unlock these Tuya devices.
tuyaBlackMagic() {return zigbee.readAttribute(0x0000, [0x0004, 0x000, 0x0001, 0x0005, 0x0007, 0xfffe], [:], delay=200)}
Thanks to @nayelyz and the smartthings team for focusing on finding a way to send the reading of the 5 attributes in a single command, which was essential for unlocking and that cannot be sent without modifying the read_attribute function of the lua libraries.
I made the modification to apply it in the driver Zigbee Multi Switch and Child Mc and passed it to @nayelyz and I don’t know if it could be implemented in the default libraries in the future
Call to modified read_attribute_function
local attr_ids = {0x0004, 0x0000, 0x0001, 0x0005, 0x0007,0xFFFE}
device:send(read_attribute_function (device, data_types.ClusterId(0x0000), attr_ids))
Modified read_attribute_function included in the driver code:
local function read_attribute_function(device, cluster_id, attr_id)
print("<<<< attr_id >>>>",utils.stringify_table(attr_id))
--local read_body = read_attribute.ReadAttribute({ attr_id })
local read_body = read_attribute.ReadAttribute( attr_id )
local zclh = zcl_messages.ZclHeader({
cmd = data_types.ZCLCommandId(read_attribute.ReadAttribute.ID)
})
local addrh = messages.AddressHeader(
zb_const.HUB.ADDR,
zb_const.HUB.ENDPOINT,
device:get_short_address(),
device:get_endpoint(cluster_id.value),
zb_const.HA_PROFILE_ID,
cluster_id.value
)
local message_body = zcl_messages.ZclMessageBody({
zcl_header = zclh,
zcl_body = read_body
})
return messages.ZigbeeMessageTx({
address_header = addrh,
body = message_body
})
end
This is incredible !!!
How did kkossev find that solution ?
What are this attributes are for ? Can this be found in Tuya documentation ?
THANKS FOR HELPING THE COMMUNITY
I didn’t ask.
They also use this solution in zigbee2mqtt
In the documentation they talk about these basic cluster attributes, but I didn’t see anything that says that they must be read.
In fact, in the pairing smartthing already obtains part of them, the manufacturer, model, and firmware versions.
But the secret that he told me is that you have to read them by sending a single command to read the six attributes.
This was not necessary on older devices or from other manufacturers that use Tuya as well
Attributes:
| ID | Name | Data type (ID) | Range | Default |
|---|---|---|---|---|
| 0x0000 | ZCLVersion | uint8 (0x20) | 0x00 to 0xff |
0x03, used for connection to Tuya-enabled Zigbee gateways. |
| 0x0001 | ApplicationVersion | uint8 (0x20) | 0x00 to 0xff | For example, 0b 01 00 0001 indicates 1.0.1, that is, 0x41 represents version 1.0.1. This attribute is used for OTA updates. When an OTA update is initiated, the gateway reads the version number of the update and pushes it to the Zigbee device. After the Zigbee device is restarted after the update, the gateway reads the current version to check for the update result. The firmware can only be updated to a higher version. This attribute is used for connection to Tuya-enabled Zigbee gateways. |
| 0x0002 | StackVersion | uint8 (0x20) | 0x00 to 0xff | 0x02 |
| 0x0003 | HWVersion | uint8 (0x20) | 0x00 to 0xff | 0x01 |
| 0x0004 | ManufacturerName | string (0x42) | 0 to 32 bytes | The value of this attribute is 16 bytes in length, consisting of 8-byte prefix and 8-byte PID.0 to 7 bytes: _TZ3000_.8 to 16 bytes: The PID, the unique identifier of the Zigbee product you create on the Tuya IoT Development Platform. This field determines the UI and feature display on the mobile app. You can use the default PID if you do not require a custom one. This attribute is used for connection to Tuya-enabled Zigbee gateways. |
| 0x0005 | ModelIdentifier | string (0x42) | 0 to 32 bytes |
SM000x represents switch (with neutral). SM001x represents switch (no neutral). x represents the number of channels. For example, SM0003 and SM0013 represent 3-gang switch (with neutral) and 3-gang switch (no neutral) respectively. This attribute is used for connection to Tuya-enabled Zigbee gateways. |
| 0x0007 | PowerSource | enum8 (0x30) | 0x00 to 0xff | * 0x01: Represents switch (with neutral). This attribute is used for connection to Tuya-enabled Zigbee gateways. 0x03: Represents switch (no neutral). This attribute is used for connection to Tuya-enabled Zigbee gateways. |
| 0xFFFD | ClusterRevision | uint16 (0x21) | 0x0000 to 0xffff | 0x0001 |
Awesome, thanks. I didn’t have that one installed. Works great.
Like a charm!
First moment morning didnt work, but wasnt loaded yet.
Great job, AGAIN!!
Hi @Mariano_Colmenarejo , it’s taken me a few days to try and add my 4-gang switch.
A few couple things, the first couple are minor: You have called this FeiBit 2 Switch, and I think it should called FeiBit 4 Switch", and the ID is called “FeiBit/FB56-ZSW1JKJ2.7”, but the “-” in the middle should be a “+”. The actual model is “FB56+ZSW1JKJ2.7” with a “+”.
More importantly, it only connects to the main switch, and not the subsequent child switches. This is what I see in the app:
The driver worked perfectly for the 2-gang and 3-gang light switches.
Please let me know if I can give you any more info to resolve.
This is not important, you can change it with the name you want
The Id is for use by the driver, it has nothing to do with the device.
It can be any non-repeated identification text, but it does not support the “+” character and I changed it to “-”
Can you switch to the Zigbee Thing Mc driver to see the endpoints and clusters it uses?
If the app does not allow you to change the driver, then you can see it with the CLI in the pairing log
Thanks @Mariano_Colmenarejo. I am one of those affected with the blank screen driver change bug.
What’s the CLI command to view the pairling log? I have the CLI set up, but it’s a bit of a mystery to me.
I’m happy to wait until Samsung fixes the app to enable driver changes if that’s easier.
@Mariano_Colmenarejo I downgraded back to an earlier version of the client and changed the driver to Zigbe Thing mc. Here is what is shows:
Please let me know if you need me to get you any more information.
