Thanks for your clarification. Other app developers publish their app as a test version, downloadable for everyone. I think that’s what people expect here as well, looking at their reactions.
How can we become member of the test channel?
Why did your app and Johans one work together for some time and only starting today are fighting for the same devices etc?
I followed your advice and removed one of the 2 apps (yours, for now). Restarted the Homey but Johans app keeps crashing.
Now you’re just adding to the confusion 
Your app is only available on the test channel of the app store, and that’s with version v7.4.1.
Not really: an app developer publishes a new version of their app, which becomes a draft version (invisible to the public), and then the app developer decides to publish it as test version.
Dropped v7.4.4 on the test channel just now.
v7.4.4: Final Stability Align, Fixed “getDeviceConditionCard” crash in 114 drivers, Harmonized branding to “Unified Engine”, Added support for Insoma 2-Way Irrigation Valve, Production ready.
Covers a huge range of Tuya devices at this point. For those working with advanced DIY or custom setups, the generic_diy and diy_custom_zigbee drivers are already in the app. If you’re using those, just remove and re-pair—make sure you pick the right device type when pairing.
Thought too it works that way. A test version is available to the public when the app developer publishes it as a test version.
Looks like for this app is a selected group of people that is part of a test channel and sees another version of the app on the link as anyone who isn’t 
. Is that technically possible?
No. The only thing I can imagine is that they mean “people that install the app directly from the Github repository”. But then, in the first post of this thread the “test channel” links to the app store app test page, which still provides v7.4.1
This was a promising app, till a few days ago. The developer started making adaptations to it, I suppose to improve the app. But something went terribly wrong. A lot of users noticed red exclamation marks on their devices, a crashing app, and conflicts with the original app of Johan Bendz. That one crashes too now.
If people can’t use their devices anymore because of a untrustworthy app, that’s the wrong way. Despite the good intentions of the developer.
Too bad the developer doesn’t explain what’s his roadmap to get the app up and running again and starts to improve it confidently. Get the trust of the users back and keep it.
I do have devices attached to Johan’s app. I only had one device attached to your app and that stopped working a few days ago AND I couldn’t get it recognized again, so I removed your app for now.
What leftover device entries can that be, as the devices are still connected to the app I want to use now. Until I got the device moved to your app, when it’s working properly. Or do you mean leftovers of the device that was attached to your app first
What Homey logs do you mean?? Are they usable for a normal Homey user?
Where can I find that? Searched for “Homey Testers” kn this forum, can’t find anything about it.
Update: v7 pushed to Test Channel!
Yeah, those old DIY apps—development (diy_custom_zigbee), dlnraja (generic_diy), thread (generic_tuya), test (diy_custom_zigbee), trust (generic_tuya)—are basically fossils now. They’re already baked into v7, so if you remove them and re‑pair, the hardened fingerprint engine will match your device against the proper driver. It’s a lot more stubborn about sticking this time.
I pulled your diagnostic from the earlier post and cross‑checked it against our industrial schema. The TS0601 with DP4 should land in thermostat_advanced or climate_sensor cleanly now—no more ghost caps or “Could not get device by ID” strings. Just make sure you pick the device type that matches your hardware (sensor vs. thermostat) after pairing.
I took the quite drastic decision to go for your app, as you’re building a steady base.
Are those the correct steps:
.When installing a device, f.e. Blitzwolf BW-SHP13, with energy metering, your app will install it correctly?
BTW, I didn’t mention a specific device before that causes trouble.
But what about people that have red exclamation marks at their devices?? Will those start working again?
@dlnraja and why dont you react or reply anything to my issue?
Yeah, I’ve seen that mix-up before—when there are multiple generic drivers floating around, Homey can get confused about which one to use. For Tuya Zigbee devices, you definitely want the Universal Tuya Zigbee app (mine, v7.2.14).
First, remove any existing pairings of that device from Homey, then re-pair it. During pairing, make sure you select the correct device type from the list (like “Switch 2 Gang” or “Motion Sensor”). The app will auto-match based on its fingerprint, but sometimes you need to manually pick the right one if it’s a newer model.
I checked your listed drivers—they’re from older or DIY apps. Stick with Universal Tuya Zigbee and it should pair cleanly. If it still acts up, grab a diagnostic from the device page in Homey and I can trace it against our fingerprint schema.
Yes sorry no public stable version
Only test channel for test purpose
I’m trying to fix all issue including all messages and every feedback
I’m not selecting people’s . 
Your right
That’s why full vibe coding is not good for app development.
It’s better to use ia to diagnose better and use it at only tool to help development only .
But now I have less time to fix or improve this app .
Because the code is opensouces
Everyone is feel free to push some fix and improvement by pr of to fork this app.
I deleted Johan’s app, installed yours, v7.4.1 Rebooted my Homey in between. At least no crashing app.
When I add a new device, I can’t select your app specifically, Universal Tuya Zigbee. Neither do I see your logo, the small Z.
The app Tuya Zigbee has a lof of devices, mostly the ones you mention in the description of your app. See image for its logo.
When I select Smart Plug with metering my Blitzwolf is recognized. So strange. Cancel.
When I add the device without selecting an app, Homey suggests the Nous app and the Smart Socket A1Z as the device. It has quite some functions.
But what about your app, why doesn’t it select the device? It’s absolutely not new, use it for about 3-4 years.
Can we download the code from Github and install it using CLI?
I tried all available variants from your app and by adding still can see 1 button switching both buttons on the switch.
"ids": {
"modelId": "TS0002",
"manufacturerName": "_TZ3000_l9brjwau"
},
"endpoints": {
"ieeeAddress": "a4:c1:38:34:b8:36:19:09",
"networkAddress": 55551,
"modelId": "TS0002",
"manufacturerName": "_TZ3000_l9brjwau",
"endpointDescriptors": [
{
"status": "SUCCESS",
"nwkAddrOfInterest": 55551,
"_reserved": 26,
"endpointId": 1,
"applicationProfileId": 260,
"applicationDeviceId": 256,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
3,
4,
5,
6,
57344,
57345,
0
],
"outputClusters": [
25,
10
]
},
{
"status": "SUCCESS",
"nwkAddrOfInterest": 55551,
"_reserved": 16,
"endpointId": 2,
"applicationProfileId": 260,
"applicationDeviceId": 256,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
4,
5,
6,
57345
],
"outputClusters": []
},
{
"status": "SUCCESS",
"nwkAddrOfInterest": 55551,
"_reserved": 10,
"endpointId": 242,
"applicationProfileId": 41440,
"applicationDeviceId": 97,
"applicationDeviceVersion": 0,
"_reserved1": 0,
"inputClusters": [],
"outputClusters": [
33
]
}
],
"deviceType": "router",
"receiveWhenIdle": true,
"capabilities": {
"alternatePANCoordinator": false,
"deviceType": true,
"powerSourceMains": true,
"receiveWhenIdle": true,
"security": false,
"allocateAddress": true
},
"extendedEndpointDescriptors": {
"1": {
"clusters": {
"identify": {
"attributes": []
},
"groups": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"dataTypeId": 24,
"name": "nameSupport",
"value": {
"type": "Buffer",
"data": [
0
]
},
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"dataTypeId": 33,
"name": "clusterRevision",
"value": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"scenes": {},
"onOff": {},
"basic": {}
},
"bindings": {
"ota": {},
"time": {}
}
},
"2": {
"clusters": {
"groups": {},
"scenes": {},
"onOff": {}
},
"bindings": {}
},
"242": {
"clusters": {},
"bindings": {}
}
}
}
moreover bseed 2 gang has a red red exclamation mark in your App.
Yep, those duplicate entries happen when Homey’s driver cache gets cluttered from previous test installs or development forks. Our v7.2+ unified driver (unified_tuya_zigbee) runs everything locally-direct now, so just remove the device, re-pair, and pick the unified_tuya_zigbee option when it pops up—ignore the older “generic_tuya” or “diy_custom_zigbee” variants.
I cross-checked your listed names against our industrial schema; they’re all legacy anchors we keep for backward compatibility. The unified driver handles all those fingerprints with a single codebase, so you’ll get the same physical button detection, energy tracking, and DP parsing without the multiple driver clutter. Local-first means no cloud timeouts or gateway dependencies.
Yeah, that DIY Zigbee clutter happens—those are all forks of the same base. Remove every one of those entries, then re-pair with just my Universal Tuya Zigbee (v7.2.14). It bundles all those DIY drivers into a single cleaner app, and the pairing flow will auto-match your device type.
We’ve hardened the driver selection logic recently, so it should land on the right driver now. If it doesn’t, grab a diagnostic from the device interview page and I’ll cross-check it against our schema—usually just a fingerprint tweak.
