Just because you don’t like duplicates, doesn’t mean someone isn’t allowed create them. My apps Lotus Lantern, duoCo Strip and LotusLamp X are also 1:1 copies of eachother, just with a different icon/name.
Also, for Zigbee devices it doesn’t really matter which driver you pick while pairing because Homey will automatically find the right driver for the device based on device manufacturer/model.
With over 330 Tuya devices, it’s impossible for me to physically own them all. I rely on reverse engineering and YOUR feedback. Please always provide the Homey diagnostic code when reporting a bug.
Well don’t think it’s any good to ex: use a wall socket id as a motion detector.
But it doesn’t really matter since when people pair it as a motion sensor, Homey will automatically pair it as a wall socket since that’s where the model ID is listed. So it doesn’t matter which one you pick when pairing a device, Homey will always pick the driver based on manufacturer/model ID. Even when you pair the Tuya motion sensor as an IKEA light bulb, Homey will still pair it as a Tuya device.
Hey all,
Thanks for the patience — I know this thread has been frustrating for a lot of you.
Supporting 330+ Tuya Zigbee devices is genuinely messy. The same manufacturer names can map to completely different product IDs and variants, which means pairing duplicates and wrong drivers still happen. It’s not ideal, and I’m not hiding that.
I can’t physically own every device. I actually had to sell my Homey for personal/financial reasons, so I now rely heavily on your diagnostic codes when something breaks. That’s just the reality of it.
What I’m actively working on right now:
Repository: GitHub - dlnraja/com.tuya.zigbee: new updated version · GitHub
Test version: https://homey.app/a/com.dlnraja.tuya.zigbee/test/
Please always include the Homey diagnostic code + manufacturerName + modelId (TS… / _TZ…) when reporting issues. I’ll keep fixing in code first. Thanks for sticking with this.
Now, I also want to clear up a common misunderstanding about how Homey actually selects the right driver for a Zigbee device.
When you pair a Zigbee device, Homey does NOT rely on what you manually select in the pairing list. Instead, it uses the device’s fingerprint — specifically the manufacturerName and modelId (also called productId) that the device reports during the Zigbee interview process.
Here’s what happens behind the scenes:
So even if you pair a Tuya motion sensor by selecting “IKEA light bulb”, Homey will still detect its real fingerprint and pair it as a Tuya device. The user’s selection during pairing is purely for UX flow — it doesn’t override the automatic driver selection.
The REAL challenge with Tuya devices is that many different physical products share the exact same manufacturerName + modelId pair. When that happens, Homey can’t distinguish them automatically. This isn’t a bug in the app — it’s a limitation of how Zigbee device identification works, and it requires smart fallback strategies to handle gracefully.
So how can you actually help improve device support?
The developer has been upfront: with 330+ Tuya Zigbee devices supported, it’s impossible for one person to physically own and test every single variant. That’s why your diagnostic data is absolutely essential.
Here’s the fastest way to get useful data:
Use Homey’s official Zigbee Developer Tools:
Once there:
This JSON is exactly what developers need to create or fix a driver. Posting this along with your bug report makes it 10x easier to solve the problem.
If you can’t use the Developer Tools, you can also:
Remember: Homey’s driver selection is based ONLY on manufacturerName and modelId. If your device shares these with another product, providing detailed logs is the ONLY way to help distinguish them.
The app already uses a universal fallback approach to map unknown variants into working templates, but it can only improve with your feedback and data.
And finally, regarding the duplication issue that several people have mentioned:
The core problem is that Tuya frequently reuses the same manufacturerName + modelId pair across completely different physical devices. For example, a wall socket, a motion sensor, and a temperature sensor might all report as “_TZE200_abc123 / TS0601”.
Homey has no way to know the difference — it just sees the same fingerprint and applies the first matching driver it finds.
So what are we doing about it?
Smart fallback logic: The app can be improved to try multiple compatible drivers and validate actual capabilities after pairing (e.g., checking which clusters respond, which DPIDs send data). This is already being worked on.
Community contributions: With a proper CONTRIBUTING.md guide and clear documentation, users who own specific devices can add their device fingerprints and mapping rules directly. This turns the problem into a collaborative effort.
Manual override: An option to manually change the driver from the device settings would help users fix misidentified devices without waiting for an app update.
Diagnostic reporting: Using the Zigbee Developer Tools interview JSON, users can provide exact cluster and attribute data, making it possible to create precise mapping rules.
The goal isn’t to blame anyone — it’s to work together. With 330+ devices, this is becoming a community-driven project. Every log, every interview JSON, every GitHub issue with proper data gets us closer to a stable experience for everyone.
Thanks again for your patience and contributions. 
@Peter_van_Werkhoven thanks for the diagnostic code.
I looked at 96c19859 - the app was running out of memory (heap), not a simple SOS bug. I just pushed a fix soon so the live fingerprint feed from GitHub Pages stops loading huge files into Homey settings.
When the new Test build is up (9.0.541), please update and send a new diagnostic if it still crashes. Sorry for the hassle.
Hi Dylan Good evening,
App is not crashing anymore and Waterdetector sensor is working receiving data in Homey and triggering the Flow now 
SOS and Smartbutton still no response in Homey and Flow’s.
Contact sensors not tested yet.
Diagnostic code ace66ff9-0a41-44e0-abf4-bf0850b689ae
Thanks for fixing so far and good night.
Best regards Peter.
Sorry to report you that the Waterdetector sensor is not responding anymore now.
Diagnostic code ec514112-f5de-4399-b90a-5b1bd62d5bb8
First — genuine respect for taking on a project at this scale. Broad Tuya/Zigbee coverage is a lot of surface area to maintain, and it’s a real service to people who’d otherwise have no driver at all.
To be clear, I’m not against official/community apps in general — Philips Hue, Aqara, Meross, Shelly all work great for me and I use their official apps happily. It’s specifically the switches and a handful of sensors below where I ended up building my own, for context/comparison in case it’s a useful data point:
I maintain a personal Homey app for ~110 physical devices (43 distinct manufacturerId/productId combos across 36 drivers) - not on the official Homey App Store, published as test only, but the source is public on GitHub.. My switches are Zemismart — when they launched their own official Homey app, mine weren’t supported. I naively offered my own working code anyway (even though I’d used AI to help build it) — I genuinely wanted the support to come from the official app, hoping their team could take it further than I had at the time, since my driver back then was pretty basic. Never got a response, and the official app still doesn’t cover my switches today. My own driver has grown a lot since — persistent backlight that survives a power cut (now with a flow card to query/force it too), Power-On behavior both globally and per-gang like Tuya’s own devices offer, and a flow trigger that fires specifically on reconnect-after-power-cut.
Similarly, on the Sonoff side: the reference app I started from had my ZBMINIR2 units typed as a light instead of a socket(fixed only recently), and turbo mode didn’t work when I first added it — it looks like it works there now too. I ended up building my own MINI-ZB1GP (energy metering) and MINI-ZBD (dry contact) drivers, since neither is in that app yet, plus an Aqara FP1 driver.
So I ended up validating everything myself: Wireshark captures on the Tuya, Sonoff/iHost and Hubitat networks, cross-referenced against Hubitat, ZHA and zigbee2mqtt source. Z2M’s own approach reinforces why that matters at scale — even with a huge device base, it matches on specific manufacturerId, not just shared clusters.
I started from Johan Bendz’s Tuya app as a base, but a lot of my devices didn’t work on his drivers as-is — getting them reliable meant going through debug logs, repeated pair/re-pair cycles, eliminating cross-link bugs between multigang sub-devices, and quieting unnecessary Zigbee chatter (e.g. Time cluster (0x000A) polling nobody needed). That per-device validation is the part that’s hard to scale with device count — not a knock on the effort here, just what it actually took to get my own devices reliable. Happy to compare notes if it’s useful.
Thank you for sharing such detailed feedback and your testing experience. We really appreciate the time and effort you’ve put into developing and validating these drivers.
We’re sorry that your previous attempt to share your Zemismart driver did not receive a response.
Could you tell me which Zemismart switch you were testing?
We’ll forward your feedback and the specific device support issue to our technical team for further review. Your experience with manufacturer IDs, device validation, and Zigbee traffic is very useful for us.
Hi @Gabriel_Pedrosa_Mach,
Thanks a lot for the kind words and for taking the time to share your detailed feedback!
You’ve pinpointed the exact reality of maintaining Tuya at scale: per-device validation, handling cluster quirks (like disabling the redundant 0x000A time cluster polling), and ensuring reliable multi-gang state synchronization. It really is a lot of surface area to maintain, so I truly appreciate the comparison and the deep dive into your own implementation.
I’d be very glad to compare notes and share insights, especially regarding your approach to backlight persistence and power-on behavior. Feel free to PM me if you’d like to exchange technical ideas or check out the code base
Hi @Zemismart_Official,
Thank you for following up on this!
The specific switch I am referring to is:
Model / Product Reference: ZB-L03C-H
Zigbee Model ID: TS0043
Type: 3-Gang Wireless Scene Switch (battery-powered CR2032 wall remote)
I had previously contacted your team (Aries Lou) back in June 2025 regarding this model (AliExpress Order #3055457170131038) to support single click, double click, long press, and battery monitoring on Homey Pro, but it wasn’t added to the official app at the time.
I have working driver implementations and device fingerprints that handle event triggers and optimize Zigbee traffic. Please let me know how best to share these logs and details with your technical team so we can get this device officially supported!
Thanks, @dlnraja — glad the comparison was useful, happy to go deeper.
One caveat up front: this all applies to Tuya devices on standard ZCL clusters. The EF00 (proprietary cluster) devices don’t behave the same way, so this specific approach doesn’t carry over to those.
For backlight/power-on persistence: on power restore, Tuya ZCL devices report all their current state at once — power-on state, switch/momentary mode, backlight, per-gang state per powerOnBehavior — within a very short window. I use that burst itself as the reconnect-after-power-cut signal, rather than any explicit “I just rejoined” event. If the device comes back reporting a state that doesn’t match what’s configured in Homey (e.g. backlight on when the setting says it should stay off), I detect that a power loss just happened and re-force the configured values instead of trusting what the device reported on boot.
For multi-gang: some attributes are only settable/readable on EP1 (the main device), so I built a connectedDevices()helper that maps which sub-devices belong to a physical unit and which one is EP1. I also mirror a few power-on attributes as read-only fields on the device page, just so the configured state is visible without opening Settings — Homey hides some of that until you drill in.
I also built my own availability layer on top of this (a lib, not Homey’s built-in unavailable flag) — it distinguishes devices that lost power, are switched off, or simply stopped responding from a device that actually left the Zigbee network. Homey’s own “unavailable” state only reflects the latter; it doesn’t tell you which of those situations you’re actually in.
I also added Zigbee traffic and rejoin reports in the app’s settings page, so I can see this burst behavior and reconnect events directly without digging through logs — happy to share screenshots of what that looks like if useful.
Source’s public if you want specifics: GitHub - gpmachado/com.gpm.homesuite: Homey app for Zigbee/Tuya devices — switches, sensors, plugs and more · GitHub
Hi @Zemismart_Official, following up with additional switches I’ve validated on my own driver. Some of these are Zemismart-branded directly; others I bought in Brazil under the “Novadigital” brand (a local distributor that resells Chinese hardware, in some cases whitebranded from other manufacturers) — flagging both in case some overlap with your own product line:
| Gangs | Zigbee Model ID | Manufacturer IDs |
|---|---|---|
| 1 | TS0001 | _TZ3000_ovyaisip, _TZ3000_pk8tgtdb |
| 2 | TS0002 | _TZ3000_ywubfuvt, _TZ3000_kgxej1dv, _TZ3000_jjdkhueq |
| 3 | TS0003 | _TZ3000_yervjnlj, _TZ3000_vjhcenzo, _TZ3000_qxcnwv26, _TZ3000_eqsair32, _TZ3000_f09j9qjb, _TZ3000_fawk5xjv, _TZ3000_ok0ggpk7 |
| 4 | TS0601 | _TZE200_shkxsgis, _TZE284_shkxsgis, _TZE204_aagrxlbd |
| 6 | TS0601 | _TZE200_r731zlxk, _TZE284_r731zlxk |
All working reliably on my own driver (backlight persistence, per-gang power-on behavior, etc. as discussed above). Happy to share fingerprints/DP mappings if that speeds things up on your end.
Thanks for such transparent and actionable technical feedback!
The multi-gang cross-linking and state bleeding is definitely one of the trickiest parts on Homey’s Zigbee implementation, especially when mapping sub-devices/endpoints cleanly across fresh pairing cycles. Adding command jitter and retry logic on unacknowledged frames is a great strategy to prevent collision issues on the mesh.
That’s also a very solid sniffing workflow with the CC2531/zboss setup — capturing the key exchange on a genuine Tuya hub makes decoding ZCL payloads in Wireshark so much cleaner than guessing behavior from raw logs.
I’ll look into hardening multi-gang endpoint isolation and pacing command bursts in the driver pipeline. If you have any specific packet dumps or code snippets regarding your jitter/retry handler, I’d be happy to check them out!
Hi @dlnraja ,
I have updated the interview data with formatted text, have you perhaps had time to look at this?
Thank you!
Hi Gabriel, thanks for going deeper — the ZCL vs EF00 split is the important bit.
I tightened the multi-gang path so endpoint 2 stays on onoff.gang2, and commands are paced with a bit of jitter plus retry if there’s no ack. Power-restore dumps are coalesced so they don’t overwrite each other. Time 0x000A on battery remotes is answer-if-asked, not polled.
If a device still bleeds after a fresh pair, send me manufacturerName + modelId and I’ll check that couple. Happy to look at a small capture too.
yes sure
Appreciate you digging into the endpoint isolation.
On gang2: I get why onoff.gang2-style capability instances mirror the physical Tuya layout more closely, but in practice it creates real friction for the end user. Several controls crammed into one tile is harder to read and act on at a glance. You can’t assign an individual name per gang — Homey only lets you rename the device itself, not a capability instance inside it, so every gang shares one generic name. And quick actions (the one-tap on/off from the device list, widgets, Google Home/Alexa voice control) don’t work per-gang that way — they’re built around a device’s single canonical capability, not arbitrary instances bundled onto one device. Splitting into separate sub-devices per gang solves all three: independent names, independent tiles, and working quick actions for each.
On the retry/jitter question — correcting myself here, I mixed these up in my first pass: they’re two separate mechanisms, not one combined handler.
- Retry: _onCapabilityOnOff sends the on/off command, and on failure retries up to 3 attempts total with a fixed 350ms delay between them before giving up and marking the device unreachable. It exists in two places — the general version in TuyaZclBase.js (used by the NovaDigital/1CH-relay family) and a separate, more elaborate version in SmartPlugBase.js (online vs. offline branching, single quiet attempt when already offline).
- Jitter: unrelated to retry — applyJitter() randomizes the reporting-interval maxInterval by ±10% so devices don’t all report in lockstep, and SmartPlugBase.js separately jitters its startup delay (2–8s) for the same reason. No jitter in the retry delay itself, it’s fixed.
Happy to send a fresh pcap if a specific manufacturerName/modelId combo keeps bleeding after re-pair — let me know which one to prioritize.
(Edited this reply — my first pass was typed quickly on my phone and I misremembered which file some of this lived in. Also updated the README on my repo since we started this thread — it now documents each lib file and what it’s responsible for.)
unfortunately the app is crashing again.
