Troubleshooting parse not called for Zigbee power strip

⚙️ Custom Apps and Drivers Custom Drivers
,
1

I'm trying to write a custom driver for a Jinvoo Zigbee Power Strip with model number SM-SO301-UZ. It appears to be the same hardware as the Useelink with the same model number. I tried using @bertabcd1234's driver but found that it did not work out of box for me, unsure if that's due to changes to Hubitat since it was last updated or due to differences between the Jinvoo model and the Useelink one. The version on github does have a typo in it that prevents import so I don't think it was fully tested, but I'm trying to use it as a starting point.

The fingerprint from the Useelink driver does not match my device (leading it to be a generic "Device" on pairing), so I updated it as follows based on the device info I saw when pairing with my hub, and repairing the device does select the correct device type now. I also changed the USB endpoint from 07 to 05.

// Original, from github
fingerprint profileId: "0104", endpointId: "01", inClusters: "0000,000A,0004,0005,0006", outClusters: "0019", model: "TS0115", manufacturer: "_TYZB01_vkwryfdr"
// Updated, works with the Jinvoo device
fingerprint profileId: '0104', inClusters: '0000,0006,0003,0004,0005,E001', outClusters: '', manufacturer: '_TZ3000_cfnprab5', model: 'TS011F', deviceJoinName: 'Jinvoo Power Strip'

Device pairing info showed as follows:

Manufacturer:    _TZ3000_cfnprab5
Endpoint 01 application:    64
Endpoint 01 endpointId:    01
Endpoint 01 idAsInt:    1
Endpoint 01 inClusters:    0000,0006,0003,0004,0005,E001
Endpoint 01 initialized:    true
Endpoint 01 manufacturer:    _TZ3000_cfnprab5
Endpoint 01 model:    TS011F
Endpoint 01 profileId:    0104
Endpoint 01 stage:    4
Endpoint 02 endpointId:    02
Endpoint 02 idAsInt:    2
Endpoint 02 inClusters:    0000,0006,0003,0004,0005,E001
Endpoint 02 initialized:    true
Endpoint 02 profileId:    0104
Endpoint 02 stage:    4
Endpoint 03 endpointId:    03
Endpoint 03 idAsInt:    3
Endpoint 04 endpointId:    04
Endpoint 04 idAsInt:    4
Endpoint 05 endpointId:    05
Endpoint 05 idAsInt:    5

The Useelink driver and the built-in generic multi-endpoint driver both do not seem to do anything at all. I cannot control the state using the Hubitat device commands and the state does not update when I use the physical power button. I expected that when I pressed the power button which turns the outlets on and off that the parse(String) function would be called, but it is not, on either the main device or any of the child devices. This is my first foray into groovy and Hubitat drivers but am I correct in thinking that parse should be called when the physical device state changes? Since it is not, how do I troubleshoot that?

I believe the device itself is functional as I was able to pair it with my SmartThings hub previously and turn one of the outlets on and off, although I could only control the first outlet.

1 Like
2

This is the driver I use for my actual power strip, and I tested all functionality. I'm not sure how the typo in String slipped in, but that is the kind that would prevent saving/compilation rather than showing up at runtime. I used the driver and tested all I could, as noted in the other thread.

(This typo is likely one I just fixed it on my hub and assumed it was something I did when saving -- for example, it's pretty common for me to just hit T instead of Cmd+T to open a new tab, etc.).

This will only happen if a Zigbee device is configured correctly, i.e., to send data to the hub. With either driver you tried, have you run the "Configure" command (normally called on pairing, but necessary to call after you switch from "Device" and generally a good idea with any driver)? That may help.

Otherwise, I won't be much help with this particular device since I don't have one.

1 Like
3

The problem with _TZ3000_cfnprab5 is not on driver level.

For unknown reasons, this and some other Tuya based devices that use a new Tuya Zigbee SoC module will not stay paired to HE hub. After 15-30 seconds these devices will send a Zigbee leave command and will change its NWK. If HE is still in pairing mode, it will detect a new device and start all over again. When the pairing process finishes, the device will not be connected to HE anymore.

This happens during the pairing process to HE, and can not be controlled on driver level. The final result is that the device is no longer paired to HE, so nothing can be received or sent to the device after the first 60 seconds.

I can confirm this - the same devices that do not 'like' HE pairing, work without any problems with SmartThings, Z2M and probably all other ZIgbee coordinators. I am checking regularly the information on the Web for similar problems in other HA systems, but nothing similar is even reported.

The problem is specific for HE only

6 Likes
4

@bertabcd1234 Thanks, that's helpful - mostly wanted to make sure I was starting with working code.

After 15-30 seconds these devices will send a Zigbee leave command and will change its NWK.

Hmm, that's frustrating. I'll do a little more experimentation and poking around.

5

Interesting, if I leave the device paired to my Hubitat but put it back into pairing mode by holding down the power button, I do see parse logs show up, but only while the device is blinking (in pairing mode). They are all catchall descriptions. This is the final one, parsed:

[
raw:catchall: 0000 8021 00 00 0040 00 5C44 00 00 0000 00 00 7200, 
profileId:0000, 
clusterId:8021, 
clusterInt:32801, 
sourceEndpoint:00, 
destinationEndpoint:00, 
options:0040, 
messageType:00, 
dni:5C44, 
isClusterSpecific:false, 
isManufacturerSpecific:false, 
manufacturerId:0000, 
command:00, 
direction:00, 
data:[72, 00]
]
1 Like
6

Update - I found a SmartThings driver that works well enough for now. I also found this one although I haven't tried it. The second one is much more complex than the first, and I don't see any Tuya magic happening in the first.

I see devices with this manufacturer have to do some "Tuya magic" to work properly, not just with Hubitat:

Guessing there's some sort of attributeRead/attributeWrite combination that would make this work a la the Hubitat driver above but I'm not sure how to determine what the parameters should be.

1 Like
7

Hi @christi ,

The TuyaMagic does not help to keep these new devices paired to HE.
It works for some other Tuya devices like TS004F, TS011F, etc.. to unlock some features that are otherwise not available - like energy/power reporting, individual control of the multi-gang switches, etc... but this is not the case with _TZ3000_cfnprab5. And the proof is that it stays paired to ST hub with the stock Edge drivers, without any special custom drivers / no magic spells. It pairs as a switch, stays connected and you can turn all the sockets on/off. If you use Mariano's driver (or the other one that you have found), you will have individual control of all sockets.

This is already implemented in the Tuya Zigbee Metering plug driver, also here : hubitat-muxa-fork/drivers/zemismart-zigbee-multigang-switch.groovy at development · kkossev/hubitat-muxa-fork · GitHub
but the Tuya magic spell does not help to keep the _TZ3000_cfnprab5 device connected. It must not leave the HE zigbee network first, then controlling it will be an easy task.

I am afraid that these of the new Tuya devices, including this one, which have a SoC _TZ3000_xxxxxxx and the firmware/application version is 64 do require some Zigbee 3.0 protocol version specific responses from the ZIgbee coordinator, which HE does not send during the pairing process.

Update May 2024 : this driver is now available for installation and update from HPM.

1 Like
8

Wait - are you saying that your power strip is paired stably to Hubitat with this SmartThings driver (presumably edited to make it HE compatible)? Or is it stably paired to SmartThings?

9

This is an Edge Lua driver and works in ST only.

I have stated this several times already - these Tuya Zigbee devices, which are problematic in HE work flawlessly with the SmartThings hub.

1 Like
10

My bad - I didn't actually look at the driver. And was shocked that the device was stable with HE. Makes more sense that it was stable on ST .....

1 Like
11

That's a shame, we must make it work in HE! :slight_smile:

1 Like
12

Sorry for the confusion, I meant that I was able to get the outlet to work with my SmartThings hub (not flawlessly, but good enough) using the community driver I shared. It does NOT work flawlessly with the built-in drivers in SmartThings, which was why I was trying to get it to work with Hubitat. The default behavior in SmartThings is that only a single outlet is controllable out of the 5 (4 plugs and a combo of 4 usb slots as one endpoint) and all others are powered off, which is certainly not flawless or even acceptable.

I suspect that there is a way to get it to work with Hubitat and based on my findings with the tuya magic commands in other places linked previously, the problem is not unique to Hubitat. I'll continue trying to experiment. If anyone has any more info about the tuya magic stuff that would be helpful.

I am afraid that these of the new Tuya devices, including this one, which have a SoC _TZ3000_xxxxxxx and the firmware/application version is 64 do require some Zigbee 3.0 protocol version specific responses from the ZIgbee coordinator, which HE does not send during the pairing process.

Do you think this is a problem that would need to be fixed in HE or can that be part of a driver?

13

This. And Hubitat is a ZHA1.2 coordinator. Not a Zigbee 3.0 coordinator.

1 Like
14

I am trying to find what are the differences between HE and ST during the initial Zigbee pairing process.

One difference is that in response to the Node Descriptor Request from the device, HE responds with Stack Compliance Revision: 21. while both ST (v3) and Tuya Gateway respond with Stack Compatibility Revision: 22

image
image1783×808 74.7 KB

Same 'Stack Compliance Revision: 22' is reported by Aqara E1 hub

image
image822×825 37.4 KB

I made the Aqara P1 and Aqara FP1 working with HE by forcely sending a 'falsified' Node Descriptor Response, copied from Aqara Zigbee hub response. This hack worked for Aqara, but does not work now for the new Tuya devices based on a new SoC , respectively new Zigbee stack.

3 Likes
15

Another difference: Zigbee 3.0 Route Request from the device and the Route Reply response sent by SmartThings V3 hub:

image
image1823×682 60.4 KB

With HE, the device does not sent a Route Request at all.

Not receiving an answer from the Zigbee coordinator to the previously sent broadcast could be the reason to leave the pairing procedure, change the NWK, and start again.

Seems like these new Tuya devices require Zigbee 3.0 coordinator, although the specs say ".... Older implementation based on the R21 specification are still compatible with the new R22 specification" Tuya is well known to not fully follow the standards... or have a ''special' interpretation.

2 Likes
16

I have the "same" power strip. It's looks exactly like the Jinvoo, but without branding. It does have the same model but was purchased from aliexpress in January 2022. It does change its 16 bit address fairly regularly, but remains connected and controllable. When you buy Tuya, you never know what firmware or SOC you will receive. I got lucky, the HE generic zigbee multi endpoint device driver works perfect and I can control all outlets and the USB ports(all USB go on/off together)

Here's my info

Pairing Info
Manufacturer: _TYZB01_vkwryfdr
Endpoint 01 application: 42
Endpoint 01 endpointId: 01
Endpoint 01 idAsInt: 1
Endpoint 01 inClusters: 0000,000A,0004,0005,0006
Endpoint 01 initialized: true
Endpoint 01 manufacturer: _TYZB01_vkwryfdr
Endpoint 01 model: TS0115
Endpoint 01 outClusters: 0019
Endpoint 01 profileId: 0104
Endpoint 01 stage: 4
Endpoint 02 application: unknown
Endpoint 02 endpointId: 02
Endpoint 02 idAsInt: 2
Endpoint 02 inClusters: 0004,0005,0006
Endpoint 02 initialized: true
Endpoint 02 manufacturer: unknown
Endpoint 02 model: unknown
Endpoint 02 profileId: 0104
Endpoint 02 stage: 4
Endpoint 03 application: unknown
Endpoint 03 endpointId: 03
Endpoint 03 idAsInt: 3
Endpoint 03 inClusters: 0004,0005,0006
Endpoint 03 initialized: true
Endpoint 03 manufacturer: unknown
Endpoint 03 model: unknown
Endpoint 03 profileId: 0104
Endpoint 03 stage: 4
Endpoint 04 application: unknown
Endpoint 04 endpointId: 04
Endpoint 04 idAsInt: 4
Endpoint 04 inClusters: 0004,0005,0006
Endpoint 04 initialized: true
Endpoint 04 manufacturer: unknown
Endpoint 04 model: unknown
Endpoint 04 profileId: 0104
Endpoint 04 stage: 4
Endpoint 07 application: unknown
Endpoint 07 endpointId: 07
Endpoint 07 idAsInt: 7
Endpoint 07 inClusters: 0004,0005,0006
Endpoint 07 initialized: true
Endpoint 07 manufacturer: unknown
Endpoint 07 model: unknown
Endpoint 07 profileId: 0104
Endpoint 07 stage: 4
17

Hi.
Anyone could help me with this?
What would be the best solution for this device to work?
Zigbee2mqtt?
Any other?
I'm stuck with three of them atm.

18

what hub do you have, C7 or C8 ?

19

I Have C-8

20

Hmm, I'm pretty sure that the testing above by Kkossev was done on a C7 which has a different zigbee chip. The new C8 has a new Zigbee 3.0 stack and you could get lucky. My strip used the zigbee multi-endpoint driver.
What happens if you try to pair one of the devices?
If it doesn't work Z2M would likely work, check their DB for compatible devices