Hi @Mike_Nono
Check this post and the following few: [APP][Pro] Universal TUYA Zigbee Device App - test - #1960 by 4x4_Pete
This App is AI slop at its best. Ticks all the boxes 
I wonder how many devices your app supports, probably only the devices you have? This app supports 330 device types currently, probably way more than your app supports
I have been running a software company for over 30 years and I can see bad code without even looking at it. - …just from observing what happens when something is changed or „fixed“. And this one? Boy oh boy…
Yes, but what I meant is that obviously @dlnraja doesn’t have all of those 330 devices himself, so you’d need to use public implementations or reverse engineering of the protocol in that case which doesn’t always work out correctly when the users f.e. only test the features that they use themselves.
For my own apps, I’ve had countless users who I asked to test if the device worked, they said yes so I published the app. And then, months later, another user reports an issue and I can’t find the cause because the tester definitely said they tested “everything”, and then later on it turns out that they didn’t test all features of the device (probably only the features that they use themselves).
Quite rude to say to someone who dedicates all of his spare time on buildibg a free app, don’t you think?
Yes I looked at it, and while some drivers are unnecessarily complex (like the maintenanceActions array which doesn’t really do anything), I’m sure my code has at least some issues as well. There is no bug-free app, there’s always some issue, in every app. For example, this is my most popular app’s code which I’m sure is also quite messy with its mostly copy-pasted drivers (and I just noticed its readme is outdated too, I’ll have to fix that). But why does that even matter for a hobby project, what do you expect from a free app then?
Athom only has 2 channels options though: live (stable) or test. There’s no “alpha” channel
Hey guys, keep in mind that the developer is receiving all your messages about his app.
You might want to reach out to him directly (via a PM) if you have specific suggestions on how to improve the app.
The naming apo channel is perhaps wrong
Sorry
The code is perhaps ugly and a mess but , it’s more trying recursively fix issues and add patches of each request rather than factorise or clean the code .
Feel free to try to fork the projet to put more clean and oeganise code
Best regards.
Have you seen that some manufacturer use same manufacturernames for multiple devices id and that on some case same manufacturernames+ device id are multiple variants and capacity.
Yes it’s a bit difficult to manages all of these .
I will and continue to do my best to improve that .
But right now because of my less time , and the fact that my homey box is sold because I need money to survive ( job problem ) , it might take longer time
And yes I don’t have time to buy and check each devices and each implementations of code boosted with ai.
Best regards
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.
unfortunately the app is crashing again.
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.
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:
- Cleaning up pairing fingerprints (mfr + productId) so devices land on the right driver
- Fixing crash reports, SOS button issues, and sensor quirks from user feedback
- Keeping Test channel updates coming as often as Athom’s publish process allows
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:
- The device joins the network and Homey performs a “Zigbee interview”
- Homey extracts the manufacturerName and modelId from the device
- Homey checks all installed apps to find a driver whose manifest matches those two values
- If a match is found, that driver is applied automatically — regardless of which option you selected during pairing
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:
- Find your device in the Nodes Table
- Click the “Interview” button
- Wait for the interview to complete
- Copy the JSON that appears — it contains the manufacturerName, modelId, and all clusters/attributes
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:
- Enable debug logging in the Universal Tuya app
- Copy the logs showing Zigbee messages (especially cluster 0xEF00 payloads for Tuya devices)
- Share the manufacturerName (e.g., _TZE200_aoclfnxz) and modelId (e.g., TS0601)
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
