Thx a lot
Hopping and working to fix everything and stabilise it with more ci cd check .
@dlnraja same for me - 2843875e-4948-4bf4-9cb3-961db99ddaf5
Hey everyone. I’ve been closely following the recent reports on the forum regarding the Unknown Device errors, the multi-gang switch synchronization issues, and the random WiFi disconnects. Behind the scenes, I have been working on a complete architectural rewrite of the app. I wanted to give you a quick update on what I am currently implementing for the upcoming v7.0 release, codenamed MAX Local Pro. The fundamental principle of this rewrite is to build a strict anti-corruption layer between Tuya’s non-standard hardware and the Homey core, strictly enforcing a Local-Direct First doctrine.
For the Zigbee engine, I have implemented a universal parser dedicated to the proprietary 0xEF00 cluster. Our new factory intercepts these binary payloads and dynamically routes the Data Points to standard Homey capabilities. To finally solve the unlinked sub-gang control issue on 3 and 4-gang switches, we are migrating to Homey SDK 3’s native dot-notation, using attributes like onoff.1 and onoff.2. This allows the flow engine to treat each button as a completely independent sub-device. I also patched the recurring TS004F physical button issue by adding a hook on the end device announce event, forcing the device to stay in scene mode rather than dropping back to dimmer mode after a deep sleep.
On the WiFi side, we are cutting the cord with cloud execution. The pairing interface is now strictly CSP compliant with zero external calls. To fix the login region issues, I built a waterfall resolution cascade across Tuya’s datacenters, combined with a mandatory TCP probe on port 6668 before saving any manual device. If the local key is invalid, the socket rejects the connection and blocks the creation in Homey. The discovery engine now passively listens to mDNS as a priority, falling back to UDP broadcast and TCP unicast. Once the IP is locked, we maintain a persistent TCP socket with a 10-second heartbeat, guaranteeing execution latency under 50 milliseconds.
I also built the Shadow-Pulsar subsystem, a bidirectional bridge designed to expose your local Zigbee device states back to the Tuya Smart Life app. However, after extensively benchmarking Tuya’s current OpenAPI restrictions—specifically the strict rate limits and the 6-month developer trial expiration issues—I have decided to classify this as an Experimental feature. It will be completely disabled by default in v7.0 to protect your installations from API bans and dropped connections. For power users who understand the Tuya quota limits, it can be enabled via an opt-in toggle. When active, it uses a leaky bucket manager to buffer and deduplicate state updates, sending a maximum of one request every two seconds. It also integrates an echo filter on the MQTT listener, silently destroying webhooks that match a local state change within 2.5 seconds to eliminate the ping-pong effect.
Finally, to ensure global stability, several security mixins are running in the background. A bizarre value blocking filter intercepts and drops mathematically absurd deltas to keep your Insights clean, while a hardware mutex debounces local state confirmations so we don’t trigger Homey flows in an infinite loop. Managing over 13,000 fingerprints requires a hardened CI/CD pipeline, so the injection of new IDs is now fully automated. The critical step in the GitHub Action uses ajv-cli to validate the generated JSON against the official SDK 3 schema, meaning any structural corruption will instantly crash the build before it ever reaches the app store. I am finalizing the code now and will be looking for beta testers once the v7.0 branch is pushed to the test channel.
Dropped v7.0.10 on the test channel just now.
v7.0.8: Fixed issues with device recognition for existing drivers., Added 3 new fingerprints to support additional devices.
Covers a huge range of Tuya devices at this point.
Hi Dylan Good morning, you saying that you just published Ver 7.0.10 but yesterday afternoon we were already at Ver 7.0.11 see my previous post.
What’s going wrong here.
Have a nice day with best regards Peter.
Message was postponed , my Freebox has lost internet yesterday night .
Sorry dude , always test the latest version available
Okay clear 
Hello @dlnraja ,
As I see TZ3000_l9brjwau TS0002 was requested previously but I can not find the 2 gang version. I could only add as a generic one. Could you please check it? Thanks
v7.0.22 is up on test.
v7.0.8: Fixed issues with device recognition for existing drivers., Added 3 new fingerprints to support additional devices.
Covers a huge range of Tuya devices at this point.
Should TZ3000_l9brjwau TS0002 also work? Could not find the proper one.
this diag log is not received on my mailbox i don’t know why.
Do you want me to make another one
Yes please 
New diagnostic code
e293fef3-49ba-45f7-948d-acb12cfbf7f1
New build out — v7.0.22 on test.
v7.0.8: Fixed issues with device recognition for existing drivers., Added 3 new fingerprints to support additional devices.
Covers a huge range of Tuya devices at this point.
@dlnraja Could you please check my request? Do you need me to paste any further information? I tried the new version as well with no luck. TZ3000_l9brjwau TS0002 does not work.
Hi Dylan I tried to re-add my SOS button again but still added as a general ZigBee device after that I did a new Diagnostic request,
Gave me this code now: dc62322d-d7f0-4850-8190-01325628021a
I can remember that I’ve got an error message yesterday while I was trying to get a diagnostic code and then with a retry it was okay and generated a Code, but I can’t remember what the error message said.
Have a nice day and good luck Peter.
Same issue I dont receive your but only other users.
Do you have installed another app recently
