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

Apps
,
1850

Update: v7.4.5 pushed to Test Channel!

I’m excited to share the latest build, which brings significant improvements and bug fixes, particularly for a wide range of Tuya devices. With this update, we’ve enhanced our Local-Direct First and Shadow-Pulsar safe-syncing capabilities, ensuring a smoother experience for everyone.

For those using the app, you’ll find that the new integrations are already live. We’ve added support for various device types, including vision (generic_tuya), test (diy_custom_zigbee), and button (diy_custom_zigbee/generic_diy). The correct driver selection is crucial and depends on the productId, such as TS0001 or TS0002. If you encounter any issues, simply remove and re-pair your device, making sure to select the appropriate device type during the process.

This update aims to streamline your interactions with Tuya devices, making it easier than ever to manage your smart home setup. As always, your feedback is invaluable, so feel free to share your experiences or any issues you encounter. Happy testing!

1851

Hi Dylan same issue as before I don’t see the new version online, still the previous version 7.4.1 published there.

Have a nice day, regards Peter.

1852

Dylan,

Again: the version mention isn’t available in the teat channel. Version 7.4.1 is to be downloaded. And that one crashes on my Homey all the time.

At other users too?

Strange: the Tuya Zigbee app of Johan Bendz suddenly crashes too on my Homey! So weird whats going on with the Zigbee hardware.

Anybody else having trouble?

1853

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.

1854

Can you please check what version you get. This is what I see following your link.

IMG7114
IMG71141320×2731 226 KB

Version 7.4.1, uploaded 20 hours ago.

1855

There is still 7.4.1 version available, no 7.4.4v….:-/

1856

v7.4.5 is up on test.

Improvements and bug fixes

Covers a huge range of Tuya devices at this point.

1857

Nope, 7.4.1

Again, please click the link you’ve just posted. Check whether what you think you publish on the test channel really becomes available.

1858

This is all being handled by some AI that just seems to make up stuff.

1859

Don’t understand what you say, what do you mean?

1860

It’s an AI that is posting these messages (and also writing most of the app).

1861

Hi,

Anyone had any success adding the Tuya Occupancy Sensor zg-204zp successfully?

Interview info

“ids”: {
“modelId”: “TS0601”,
“manufacturerName”: “_TZE200_ka8l86iu”
},
“endpoints”: {
“ieeeAddress”: “a4:c1:38:fe:d1:7c:f5:5b”,
“networkAddress”: 10763,
“modelId”: “TS0601”,
“manufacturerName”: “_TZE200_ka8l86iu”,
“endpointDescriptors”: [
{
“status”: “SUCCESS”,
“nwkAddrOfInterest”: 10763,
“_reserved”: 18,
“endpointId”: 1,
“applicationProfileId”: 260,
“applicationDeviceId”: 1026,
“applicationDeviceVersion”: 0,
“_reserved1”: 1,
“inputClusters”: [
0,
3,
1280,
61184,
1
],
“outputClusters”:
}
],
“deviceType”: “enddevice”,
“receiveWhenIdle”: false,
“swBuildId”: “0131122025”,
“capabilities”: {
“alternatePANCoordinator”: false,
“deviceType”: false,
“powerSourceMains”: false,
“receiveWhenIdle”: false,
“security”: false,
“allocateAddress”: true
},
“extendedEndpointDescriptors”: {
“1”: {
“clusters”: {
“basic”: {
“attributes”: [
{
“acl”: [
“readable”
],
“id”: 0,
“dataTypeId”: 32,
“name”: “zclVersion”
},
{
“acl”: [
“readable”
],
“id”: 1,
“dataTypeId”: 32,
“name”: “appVersion”
},
{
“acl”: [
“readable”
],
“id”: 2,
“dataTypeId”: 32,
“name”: “stackVersion”
},
{
“acl”: [
“readable”
],
“id”: 3,
“dataTypeId”: 32,
“name”: “hwVersion”
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 4,
“dataTypeId”: 66,
“name”: “manufacturerName”,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”
],
“id”: 5,
“dataTypeId”: 66,
“name”: “modelId”
},
{
“acl”: [
“readable”
],
“id”: 7,
“dataTypeId”: 48,
“name”: “powerSource”
},
{
“acl”: [
“readable”,
“writable”
],
“id”: 18,
“dataTypeId”: 16,
“name”: “deviceEnabled”
},
{
“acl”: [
“readable”
],
“id”: 16384,
“dataTypeId”: 66,
“name”: “swBuildId”
},
{
“acl”: [
“readable”
],
“id”: 65533,
“dataTypeId”: 33,
“name”: “clusterRevision”
},
{
“acl”: [
“readable”
],
“id”: 6,
“dataTypeId”: 66,
“name”: “dateCode”
}
],
“commandsGenerated”: “UNSUP_GENERAL_COMMAND”,
“commandsReceived”: “UNSUP_GENERAL_COMMAND”
},
“identify”: {
“attributes”: [
{
“acl”: [
“readable”,
“writable”
],
“id”: 0,
“dataTypeId”: 33,
“name”: “identifyTime”,
“value”: 0
},
{
“acl”: [
“readable”
],
“id”: 65533,
“dataTypeId”: 33,
“name”: “clusterRevision”,
“value”: 1
}
],
“commandsGenerated”: “UNSUP_GENERAL_COMMAND”,
“commandsReceived”: “UNSUP_GENERAL_COMMAND”
},
“iasZone”: {
“attributes”: [
{
“acl”: [
“readable”
],
“id”: 0,
“dataTypeId”: 48,
“name”: “zoneState”,
“value”: “enrolled”
},
{
“acl”: [
“readable”
],
“id”: 1,
“dataTypeId”: 49,
“name”: “zoneType”,
“value”: “motionSensor”
},
{
“acl”: [
“readable”
],
“id”: 2,
“dataTypeId”: 25,
“name”: “zoneStatus”,
“value”: {
“type”: “Buffer”,
“data”: [
1,
0
]
}
},
{
“acl”: [
“readable”,
“writable”
],
“id”: 16,
“dataTypeId”: 240,
“name”: “iasCIEAddress”,
“value”: “18:69:0a:ff:fe:65:c0:fe”
},
{
“acl”: [
“readable”
],
“id”: 17,
“dataTypeId”: 32,
“name”: “zoneId”,
“value”: 0
},
{
“acl”: [
“readable”,
“writable”,
“reportable”
],
“id”: 61441,
“dataTypeId”: 32,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“writable”,
“reportable”
],
“id”: 19,
“dataTypeId”: 32,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”
],
“id”: 65533,
“dataTypeId”: 33,
“name”: “clusterRevision”,
“value”: 1
}
],
“commandsGenerated”: “UNSUP_GENERAL_COMMAND”,
“commandsReceived”: “UNSUP_GENERAL_COMMAND”
},
“powerConfiguration”: {
“attributes”: [
{
“acl”: [
“readable”,
“reportable”
],
“id”: 32,
“dataTypeId”: 32,
“name”: “batteryVoltage”,
“value”: 30,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”,
“reportable”
],
“id”: 33,
“dataTypeId”: 32,
“name”: “batteryPercentageRemaining”,
“value”: 200,
“reportingConfiguration”: {
“status”: “NOT_FOUND”,
“direction”: “reported”
}
},
{
“acl”: [
“readable”
],
“id”: 65533,
“dataTypeId”: 33,
“name”: “clusterRevision”,
“value”: 1
}
],
“commandsGenerated”: “UNSUP_GENERAL_COMMAND”,
“commandsReceived”: “UNSUP_GENERAL_COMMAND”
}
},
“bindings”: {}
}
}
}

1862

So you mean it’s not @dlnraja writing those messages about publishing a new testversion? But seems to me he wants to know why people react to those messages?

I hope he succeeds in correcting the app, it used to work like expected. After the recent changes a lot of errors occur.

1863

Maybe im also AI, but i still see version 7.4.1…

312596
3125961440×3120 243 KB

1864

Everything I see here has the hallmark of a developer that’s using vibe coding (using an “AI”) to work on an app, and also to post here and to handle feedback posted here.

But AI’s aren’t faultless, which is why suddenly messages were being posted with version numbers (“v22.0.0”) that make no sense at all.

And it’s also why things seem to break with every new app version, because that’s what most vibe coding tools just do.

Of course, I might be completely wrong about this and it’s just human error :man_shrugging:t3:

1865

Hi Robert, Dylan is a human being and at this moment he is working on a complete architectural rewrite of the app V7… So we have to be patience I think also because he’s just started a new job so he’s got not the whole day anymore to work on it, he’s even working @ nighttime by the looks of it.

Regards Peter and good luck to Dylan we have to have faith in him :blush:

1866

Good to know, but why he writes that new build is up and we can see still old broken version?

1867

I know they are a human being, I’m just explaining how I think that this app is being developed and how I think some of the strange things (like why no one is able to find the app versions in the app store that are said to be published there) can be explained.

1868

Yes Robert you are right, he told in the beginning that he uses AI to write the app and he managed to get device’s working and I presume Dylan will explain why these strange version numbers appear and why the version numbers he announced aren’t visible.

Have a nice evening and let’s hope for the best and everything is going to work smoothly :blush:

Best regards Peter.

1869

Update: v7.4.5 pushed to Test Channel!

Yeah, the version numbering gets a bit confusing because I’m always pushing test builds first. v7.4.5 is in Test right now, but public stable is v7.4.1. If you’re not in the Test channel, you won’t see the newer one yet. Keep in mind the Test channel is managed by Athom, and sometimes there’s a delay before the build I push becomes available for download. It’s out of my direct control, but v7.4.5 should appear soon—typically within a day or so. For those with the DIY custom Zigbee modules, those are already in the app on the Test channel. Just remove and re-pair, making sure you pick the right device type during pairing—sometimes the interview picks a generic sensor first, so double-check you’ve selected the correct driver. If you don’t have test channel access yet, you need to join the “Homey Testers” group on the Athom forum.

Those crashes sound like a Zigbee stack fight. If you’ve got both my app and Johan’s installed, they’re battling for the same devices. You gotta pick one, completely remove the other from Homey—including all its paired devices—and then reboot. That should stabilize it. I cross-referenced your diagnostics against our schema and it’s a classic dual-driver conflict. If Johan’s app is still crashing after that, it’s likely due to leftover device entries; check the Homey logs for specific errors.