[APP][Pro] Universal TUYA Zigbee Device App - test

[Gabriel_Pedrosa_Mach]

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.

[Zemismart_Official]

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.

[dlnraja]

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

[dlnraja]

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!

[Gabriel_Pedrosa_Mach]

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

[Gabriel_Pedrosa_Mach]

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.

[dlnraja]

Hi @Gabriel_Pedrosa_Mach,

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!

[PresentSky]

Hi @dlnraja ,

I have updated the interview data with formatted text, have you perhaps had time to look at this?

Thank you!

[dlnraja]

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.

[dlnraja]

yes sure

[Gabriel_Pedrosa_Mach]

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.)

[Zemismart_Official]

Thank you very much for sharing all these details and for the work you’ve already done on your own drivers. This is really helpful for us.

If possible, could you also share the driver files, fingerprints, and DP mappings you are currently using? This would help our engineers reproduce and verify your implementation more quickly.

i think link from github will be fine.

[Zemismart_Official]

@dlnraja

Hi @Gabriel_Pedrosa_Mach,

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!

thanks you , i will forward to our team.

[Zemismart_Official]

Could you tell me which Zemismart switch models each of these corresponds to? For example, the 606 series, 808 series, ZMS-206, etc.

thanks in advance.

[Gabriel_Pedrosa_Mach]

hanks for forwarding it! The switches I’ve been testing correspond to the TB25 series — TB25-1, TB25-2, TB25-3, TB25-4 and TB25-6 (1 to 6 gang), plus a 4-gang ZCL variant and a touch model. The touch model actually uses the exact same driver code as the others — I only split it into a separate driver because of its icon/artwork file, not because of any functional difference. That said, the code isn’t tied to exact model numbers — any device sharing the same clusters and functions should work with it as-is.

To be clear about scope, my driver goes well beyond basic on/off:

• Shows sibling gangs in the device’s advanced settings — which one is the main device and which are the linked sub-devices, with the placeholder “connected switches” text replaced live by whatever name the user gave each device. Switch mode and backlight are only configurable from the main device, since they’re shared settings across the whole switch.
• Detects network rejoin after a power loss
• Re-applies backlight state at that moment, if the user prefers it off
• Configures pulse/inching mode
• Reports network activity — message count in the last hour and last 24h, plus which device is sending the most messages (stats)
• Automatic retry on failed commands
• Already translated into several languages

One thing I deliberately left out: countdown/timer. On Homey that’s easily done with flows instead, so I didn’t see a need to bake it into the driver itself.

One honest caveat: the SVG icons/artwork were done pretty roughly on my end — there’s definitely room for improvement there if anyone wants to help polish the graphics.

[Peter_van_Werkhoven]

Hi Dylan Good afternoon, is the app using to much memory, because Flow’s don’t run and device’s are difficult to start I noticed since yesterday.

Diagnostic code e181bc15-ebb8-4a6f-a08a-b00b5fe71552

Also non of the devices still not function normal in your app. SOS, Smartbutton, Waterdetector and Door/Window sensors.

Diagnostic code 4577486f-4233-4106-9dcf-dc1fe4dc43ab

Good luck and thanks again for your effort, Peter.

[Peter_van_Werkhoven]

Hi Dylan Good afternoon you achieved it the SOS buttons finally work again, great job

Before I had to disable the app last night because Flow’s didn’t run and I also couldn’t switch off devices manually in Homey, this morning I updated the app to version 9.0.596 and deleted the SOS, Waterleak sensor and Smartbutton, restarted Homey and re-add the device’s and SOS working again and others not.

Diagnostic code 1cf775a2-be97-4b3c-88c4-c29c83bf11d4

Thanks and have a nice day, good luck Peter

[Zemismart_Official]

for the 4 gang ZCL, you mean the module :ZMS-206 ? the one with screen

thanks for your reply!

[Gabriel_Pedrosa_Mach]

The 4gang zcl device is a device sold in Brazil with the new digital brand. It is a 4-key touch device. In my repository there is his interview. com.gpm.homesuite/Homey_Interview/4G touch/_TZ3000_lwthnp7j.txt at main · gpmachado/com.gpm.homesuite · GitHub

It has the list of clusters, my app has already mapped the functions, provides a time cluster server, apparently the ZCL (novadigital 1,2,3 and novadigital 4gang touch) has a shared lib and only changes the settings for the number of gangs. The same with the novadigital 4 and 6 gang (Tuya Ef00).

[smarthomesven]

@Gabriel_Pedrosa_Mach

In my repository https://github.com/gpmachado/com.gpm.homesuite/Homey_interview there is his interview

That one returns a 404. I think you mean https://github.com/gpmachado/com.gpm.homesuite/tree/main/Homey_Interview?