From a wrong Amazon click to two weeks of flawless automated watering: a Tuya BLE → Zigbee saga
Full credits to Claude and Gemini for pulling me through this and making this summary. IRL this took several weeks. Learn from my mistakes.
This is the product in question. The system was Raspberry Pi 5 8gb running HAOS
aliexpress.com
TL;DR
Accidentally bought the Bluetooth version of a Tuya dual-zone irrigation timer instead of the Zigbee one. Spent days deep-diving into the tuya_ble Home Assistant integration's source code, confirmed a real upstream bug/gap (missing SecKey retrieval), gave up on BLE, bought the Zigbee version instead, hit a different set of problems there, eventually nailed down the fix, and it's now run the sprinklers reliably for 2+ weeks unattended (including a holiday) and counting.
Chapter 1: The Bluetooth Detour
The device: a Tuya "YZD02B" dual irrigation timer / 2-zone water valve — BLE version, no hub, no Wi-Fi. Category ggq on Tuya's backend, product ID jntxv3q4.
Goal: control both valves locally from Home Assistant on a Raspberry Pi (HAOS), no cloud dependency.
What we (Claude and Gemini) tried, roughly in order:
Installed the community tuya_ble HACS integration (ha-tuya-ble/ha_tuya_ble)
Hit immediate "no unconfigured devices found," then got it paired but every entity sat on "Unavailable"
Chased down: country/datacenter mismatch, wrong Tuya cloud credentials, Bluetooth adapter conflicts, ble_monitor interference, signal strength (RSSI), two-radio contention between the Pi's onboard Bluetooth and an ESPHome BLE proxy, the Tuya Smart app competing for the BLE connection, and local_key rotation every time the device got re-paired with the app
Found the exact merged fix for this product ID: PR #256 "Support YZD02B irrigation timer", confirmed it was installed and active
Wrote a standalone bleak test script to rule out hardware/signal entirely — confirmed the raw Bluetooth link was rock solid (stable 10+ second connections, clean service/characteristic enumeration) on both Windows and the Pi itself
Read the integration's actual source (tuya_ble.py, const.py, security.py) line by line to figure out why every real session still died right after connecting, at a request called FUN_SENDER_DEVICE_INFO
What we found: the device requires a second credential — a "SecKey" — on top of the normal local_key, for its v2/FD50 protocol handshake. Without it, the integration silently falls back to the wrong encryption key/security flag, and the device drops the connection every time, regardless of signal strength, radio hardware, or app conflicts.
Where it stumped us: per the integration's own author, commenting directly on PR #255 "Support Tuya BLE SecKey authentication":
"There currently is no user-facing place in Smart Life or Tuya Smart where this BLE protocol-v2 secKey can be copied, and the regular Tuya OpenAPI response may omit it... I will not document raw secrets or an unsafe extraction workflow."
So this wasn't user error — it's a genuine gap: the key exists, the device needs it, and there's currently no safe/supported way for an end user to retrieve it. The author is building a separate tool (tuya-mobile) to solve this properly via the authenticated mobile app API, but it wasn't ready. If anyone finds this post because they're stuck on the exact same error, that project might be worth checking on — hopefully it's shipped by the time you read this.
Outcome: returned the BLE unit, bought the Zigbee version of the same product line instead.
Chapter 2: The Zigbee Version — A Different Kind of Headache
Running ZHA on an isolated USB coordinator (TI CC2652, znp radio type).
Symptom: paired fine, worked for about a day, then went quiet. Oddly, it kept reporting status correctly (valve state, countdown, battery) the whole time — it just stopped accepting commands.
The investigation:
Ruled out mesh/range as the obvious cause — LQI was decent (100+), and reports were arriving fine, so the radio link looked healthy on paper.
Ruled out EZSP-style Zigbee network key rotation (a real known issue, but only applies to Silicon Labs/ezsp coordinators — ours was TI/znp, which doesn't do this by default).
Used the excellent ZHA Toolkit add-on to actually query the device directly — found it was failing with NWK_NO_ROUTE: the coordinator genuinely had no path back down to the device. As a sleepy battery end device, it can't self-heal a dead route; it has to actively reassociate.
A manual re-pair restored the route, but then valve commands still silently did nothing — turned out the real culprit was that the device's command-handling cluster (Tuya's proprietary 0xEF00) wasn't being negotiated at all after a route failure.
The fix: ZHA Toolkit ships a service literally called zha_toolkit.tuya_magic — a known community workaround that sends a specific init sequence many Tuya Zigbee devices need to fully activate their command cluster. Running it immediately (re)exposed a working TuyaReplacementCluster with a real valve_on_off_1 attribute we could read and write.
Confirmed via direct code search that ZHA's quirk library does properly support this exact device/manufacturer string (_TZE284_fhvpaltk / TS0601) in zhaquirks/tuya/tuya_valve.py — there's also a related community thread on this device at zha-device-handlers#4082 if you hit something similar.
The actual fix that made it stick, going into a 2-week unattended holiday:
Added a second ESP32-C6-based Zigbee router (ESPHome firmware) with an external antenna, physically positioned as close to the balcony as possible, specifically to give this one battery end device a strong, stable parent link instead of a weak direct hop to the coordinator
Ran zha_toolkit.tuya_magic once right after pairing to activate the command cluster
Set up a simple keep-alive automation periodically pinging the device via ZHA Toolkit, so if the link ever did degrade, it'd get caught/nudged before the next scheduled watering rather than silently failing
Result: ran flawlessly for the entire 2-week trip, and has kept working since.
Takeaways for anyone else going down this road
Check twice before buying a Tuya "smart" device that it's Zigbee, not Bluetooth, unless you order it with the hub (under select color section on AliExpress) and if you specifically want BLE-only/offline-first and are prepared to possibly hit integration gaps like this one.
Tuya's cheap Zigbee devices very often use the proprietary 0xEF00 manufacturer cluster instead of standard Zigbee clusters — if reporting works but commands don't, look at zha_toolkit.tuya_magic and check whether a proper quirk exists for your exact manufacturer string before assuming it's unsupported.
For battery-powered Zigbee end devices placed somewhere marginal (balconies, outdoors, through walls), a dedicated nearby router matters more than almost anything else — dead/weak routes are the single most common cause of "works for a bit then goes silent."
Sometimes the honest answer from a maintainer ("there's currently no safe way to get this credential") is the actual end of the road for a given path, and that's fine — pivoting to a better-supported protocol was ultimately the right call here.
Bonus: the balcony garden is thriving.
12 comments
Mentions
From a wrong Amazon click to two weeks of flawless automated watering: a Tuya BLE → Zigbee saga Full credits to Claude and Gemini for pulling me through this and making this summary. IRL this took several weeks. Learn from my mistakes. This is the product in question. The system was Raspberry Pi 5 8gb running HAOS aliexpress.com TL;DR Accidentally bought the Bluetooth version of a Tuya dual-zone irrigation timer instead of the Zigbee one. Spent days deep-diving into the tuya_ble Home Assistant integration's source code, confirmed a real upstream bug/gap (missing SecKey retrieval), gave up on BLE, bought the Zigbee version instead, hit a different set of problems there, eventually nailed down the fix, and it's now run the sprinklers reliably for 2+ weeks unattended (including a holiday) and counting. Chapter 1: The Bluetooth Detour The device: a Tuya "YZD02B" dual irrigation timer / 2-zone water valve — BLE version, no hub, no Wi-Fi. Category ggq on Tuya's backend, product ID jntxv3q4. Goal: control both valves locally from Home Assistant on a Raspberry Pi (HAOS), no cloud dependency. What we (Claude and Gemini) tried, roughly in order: Installed the community tuya_ble HACS integration (ha-tuya-ble/ha_tuya_ble) Hit immediate "no unconfigured devices found," then got it paired but every entity sat on "Unavailable" Chased down: country/datacenter mismatch, wrong Tuya cloud credentials, Bluetooth adapter conflicts, ble_monitor interference, signal strength (RSSI), two-radio contention between the Pi's onboard Bluetooth and an ESPHome BLE proxy, the Tuya Smart app competing for the BLE connection, and local_key rotation every time the device got re-paired with the app Found the exact merged fix for this product ID: PR #256 "Support YZD02B irrigation timer", confirmed it was installed and active Wrote a standalone bleak test script to rule out hardware/signal entirely — confirmed the raw Bluetooth link was rock solid (stable 10+ second connections, clean service/characteristic enumeration) on both Windows and the Pi itself Read the integration's actual source (tuya_ble.py, const.py, security.py) line by line to figure out why every real session still died right after connecting, at a request called FUN_SENDER_DEVICE_INFO What we found: the device requires a second credential — a "SecKey" — on top of the normal local_key, for its v2/FD50 protocol handshake. Without it, the integration silently falls back to the wrong encryption key/security flag, and the device drops the connection every time, regardless of signal strength, radio hardware, or app conflicts. Where it stumped us: per the integration's own author, commenting directly on PR #255 "Support Tuya BLE SecKey authentication": "There currently is no user-facing place in Smart Life or Tuya Smart where this BLE protocol-v2 secKey can be copied, and the regular Tuya OpenAPI response may omit it... I will not document raw secrets or an unsafe extraction workflow." So this wasn't user error — it's a genuine gap: the key exists, the device needs it, and there's currently no safe/supported way for an end user to retrieve it. The author is building a separate tool (tuya-mobile) to solve this properly via the authenticated mobile app API, but it wasn't ready. If anyone finds this post because they're stuck on the exact same error, that project might be worth checking on — hopefully it's shipped by the time you read this. Outcome: returned the BLE unit, bought the Zigbee version of the same product line instead. Chapter 2: The Zigbee Version — A Different Kind of Headache Running ZHA on an isolated USB coordinator (TI CC2652, znp radio type). Symptom: paired fine, worked for about a day, then went quiet. Oddly, it kept reporting status correctly (valve state, countdown, battery) the whole time — it just stopped accepting commands. The investigation: Ruled out mesh/range as the obvious cause — LQI was decent (100+), and reports were arriving fine, so the radio link looked healthy on paper. Ruled out EZSP-style Zigbee network key rotation (a real known issue, but only applies to Silicon Labs/ezsp coordinators — ours was TI/znp, which doesn't do this by default). Used the excellent ZHA Toolkit add-on to actually query the device directly — found it was failing with NWK_NO_ROUTE: the coordinator genuinely had no path back down to the device. As a sleepy battery end device, it can't self-heal a dead route; it has to actively reassociate. A manual re-pair restored the route, but then valve commands still silently did nothing — turned out the real culprit was that the device's command-handling cluster (Tuya's proprietary 0xEF00) wasn't being negotiated at all after a route failure. The fix: ZHA Toolkit ships a service literally called zha_toolkit.tuya_magic — a known community workaround that sends a specific init sequence many Tuya Zigbee devices need to fully activate their command cluster. Running it immediately (re)exposed a working TuyaReplacementCluster with a real valve_on_off_1 attribute we could read and write. Confirmed via direct code search that ZHA's quirk library does properly support this exact device/manufacturer string (_TZE284_fhvpaltk / TS0601) in zhaquirks/tuya/tuya_valve.py — there's also a related community thread on this device at zha-device-handlers#4082 if you hit something similar. The actual fix that made it stick, going into a 2-week unattended holiday: Added a second ESP32-C6-based Zigbee router (ESPHome firmware) with an external antenna, physically positioned as close to the balcony as possible, specifically to give this one battery end device a strong, stable parent link instead of a weak direct hop to the coordinator Ran zha_toolkit.tuya_magic once right after pairing to activate the command cluster Set up a simple keep-alive automation periodically pinging the device via ZHA Toolkit, so if the link ever did degrade, it'd get caught/nudged before the next scheduled watering rather than silently failing Result: ran flawlessly for the entire 2-week trip, and has kept working since. Takeaways for anyone else going down this road Check twice before buying a Tuya "smart" device that it's Zigbee, not Bluetooth, unless you order it with the hub (under select color section on AliExpress) and if you specifically want BLE-only/offline-first and are prepared to possibly hit integration gaps like this one. Tuya's cheap Zigbee devices very often use the proprietary 0xEF00 manufacturer cluster instead of standard Zigbee clusters — if reporting works but commands don't, look at zha_toolkit.tuya_magic and check whether a proper quirk exists for your exact manufacturer string before assuming it's unsupported. For battery-powered Zigbee end devices placed somewhere marginal (balconies, outdoors, through walls), a dedicated nearby router matters more than almost anything else — dead/weak routes are the single most common cause of "works for a bit then goes silent." Sometimes the honest answer from a maintainer ("there's currently no safe way to get this credential") is the actual end of the road for a given path, and that's fine — pivoting to a better-supported protocol was ultimately the right call here. Bonus: the balcony garden is thriving.