Is the manufacturer _TZ3000_okaz9tjs ?
The device changes its NWK address during the Zigbee pairing and is not accessible after.
Can you control it On/Off?
This is how many Tuya TS011F plugs work, they require polling for clusters 0x0B04 or 0x0702, so that's OK.
The problem is that it sends ZDO command 'leave' during the pairing and changes NWK.
OK, I will try to reproduce the problem again here with my device some hours later.
Thank you Mike!
This is mine. The only difference seems to be that the plus is UK standard. The device fingerprinting is removed from any custom drivers, so initially it paired as a Device. Nothing is received from the plug after the pairing finishes.
Then manually assigned the Generic Zigbee Outlet driver and paired again. On/Off works only for the short time when HE and the device are still in pairing mode, after the pairing finishes, not control again. Zigbee channel 11.
I can send a PCAP file during the pairing with the the Generic Zigbee Outlet driver later.
For the heck of it add the device fingerprint to your driver, then, add a 5 second delay as the first method in the configure
method, then try inclusion again.
log.warn "running configure in 5 seconds..."
pauseExecution(5000)
If that doesn't work then send me the wireshark capture file
I tried the 5 seconds delay in my driver, but unfortunately, it didn't help...
The PCAP file below is sniffed when _TZ3000_okaz9tjs pairs to HE using the Generic Zigbee Outlet driver.
The device changed the NWK several times:
20:59:43.00 Device Announcement (zbee_nwk.addr eq 0xc4b0)
20:59:44.29 leave
29:59:50.67 Device Announcement (zbee_nwk.addr eq 0x78b4)
20:59:51.58 leave
20:59:56.68 Device Announcement (zbee_nwk.addr eq 0x3a95)
20":59:57.18 leave .....
...
The Zigbee logs show multiple devices during the pairing process ('device', 'b')
https://drive.google.com/file/d/1TiP5BvtBzbE7y5a_q5-NS1BCDHkGFrZp/view?usp=sharing
Don't have an idea why this problem doesn't show up in your environment...
Here are links to other HE users reporting the same problem: link1 link2 link3 link4 link 5 link6 link7
Hope this helps.
This trace isn't the device initially joining the network that I can see, at least I'm not seeing the typical frames that we send.
Please send me the modified outlet driver that you are using that includes the fingerprint added as well as the delay.
The issue is that the device is requesting a trust center link key in frame 377, we send it in frame 379 but the device is not responding, probably as it's busy processing other commands from the driver.
This is why it's important that the device select the correct driver, (not Device), and that that driver not send any configure commands for several seconds so as to give the device time to process the trust center link key that we sent to it.
Hi Mike,
This is the very simple driver that I use for testing. On/Off works with all other Tuya plugs, but _TZ3000_okaz9tjs
Later tonight I will record and compare what are the differences when pairing as a new device between the problematic plug and these that work OK.
If you could provide a capture of the problematic device pairing using your test driver on a hub with no other zigbee devices that may be helpfull.
I tried to move as many as I could of the devices paired to the Dev hub to the main hub, hope the wireshark scan is a bit cleaner now.
/TBH, there was at least one battery device that I couldn't locate where I have put it in my room... probably in some of the drawers (ashamed) /
_TZ3000_cehuw1lw.pcapng is the scan result of another TS011F plug that works fine, initially joining using the test driver.
Filter by NWK 0x16e2
_TZ3000_okaz9tjs(2).pcapng is the problematic device new capture, initially joining using the test driver.
Filter by "zbee_nwk.addr eq 0xb306" in WireShark
My theory is that the problem may be in the Route Request broadcasts (frame 57 as an example) <> Route Reply by HE (frame 60)
I have not seen Route Request / Reply frames when sniffing any other Zigbee device that stay connected to HE. (or have not paid attention until recently)
I see only this _TZ3000_okaz9tjs and one another 4 socket extension plug sending these Route Requests.
_TZ3000_okaz9tjs pairs and is working without a problem with C-8 !
EDIT 04/12/2023 - currently broken in Hubitat platform version 2.3.5.124 
_TZ3000_cfnprab5 pairs and is working without a problem with C-8 !
EDIT 04/12/2023 - currently broken in Hubitat platform version 2.3.5.124
Same problem with a Xenon SM-SO306 power strip:
It is one of the devices that now works as expected with C-8 and the inbuilt Generic Zigbee Multi Endpoint Switch diver, but will not work with the old C-7 hub, because it requires Zigbee 3.0 hub.
Correction: yes, it works fine on the C-8. I 'Rebuild Network' (hadn't done that before) and after removing, repairing and initializing I can now switch all 5 different outlets
interesting. I am on the c-8. but might relate to the updates we discussed in the other thread.
Sadly, I can add the new Sonoff temperature and humidity sensor w/ LCD display to the group of devices which work only with the new C-8 Zigbee 3.0 hub.
Hi @mike.maxwell . I have a Tuya Valve Controller (Model TS0001). I was able to get it to pair on the .125 platform release with my c-8, however, it falls into the second group of Zigbee devices @kkossev pointed out in this thread that do not stay connected to HE because the network ID keeps changing. I'm in the US and willing to ship the device to anyone who wants to take a look.
Out of interest, how did you pair this with the C-8? I had the exact same problem you originally described, namely the same UK strip plug, with the same manufacturer and the same application data in the device details, not working on the C-7 hub.
It's very useful to me to have a strip plug with individually controllable sockets, so I bought a C-8 hub specifically to try to get this working, but I can't even pair the plug now.
I migrated my C-7 to C-8 using the cloud migration tool, which appears to have worked very well. However, the switch still didn't work in the C-8 straight away, so I removed it with a view to pairing it again.
I am now totally unable to add it as a new device and no amount of switching it off for a while/holding down the switch for 5+ seconds is resolving the issue. There doesn't appear to be a way of factory resetting it as far as I can tell?
I see you're saying it now doesn't work again as of 2.3.5.124, but surely I should be able to add the device at the very least? I'm on 2.3.5.125.
I had trouble pairing my Tuya Valve controller on the C-8. What worked for me was to do some resets and rebooting of the Zigbee network. Here is what worked for me (thanks to @Ken_Fraleigh) . It now pairs but on/off still does not work due to the issue I described above.
I removed one of my valves from my C-8 and it also got stuck on the never-ending loop of initializing, telling me to name the device, but the device would go back into pairing mode every time I pushed the devices on/off button. I did get it to rejoin by removing it again, rebuilding the zigbee network, rejoining it and naming it, etc (still didn't work), then I rebooted the zigbee radio, reset (not removed) the device, put the hub back into zigbee pairing mode, and boom it joined properly.
I paired the strip on the first day I got my C-8, it was a week later after the official announcement. I also paired successfully the other problematic TS011F plug (yes, I have an UK socket used with an adapter). And I got very excited then⌠but a few weeks later the consecutive updates related to other Zigbee devices not pairing to the new C-8 (probably with the Hue motion sensor issues fix attempts) broke the successful pairing again.
Download the Hubitat app
