If you run Tuya or Smart Life Wi-Fi devices and want LocalTuya or tuya-local to control them over the LAN, you need each device’s local key. The documented way to get it runs through the Tuya IoT Developer Platform, which means a developer account, a cloud project, and, for many people, an expired trial or subscription prompt along the way.
You can now get a Tuya local key without a developer account in two ways. One is built into tuya-local, and the other is a small community tool that logs in by QR code through the Smart Life or Tuya Smart app. Both work according to their own documentation, but “no developer account” does not mean “no cloud”. This article compares the two and spells out what each one still touches.
Everything here comes from the tool’s README, its announcement thread on the Home Assistant community forum, its issue tracker, the tuya-local README, and Home Assistant’s Tuya integration docs. I have not run the tool, and this site has not audited it. Treat it as a third-party hobby project, not an official Tuya path.
Why the developer-account route became a wall
Our own Tuya local key extraction guide covers the IoT Platform route and the subscription fix. That route is still the established one. The friction is that it asks you to create a developer identity with Tuya, link your app account to a cloud project, and manage Access ID and Access Secret credentials, all to read a string that sits on a device in your own house.
If that is acceptable to you, stay on that route and read the guide. The alternatives below are for people who would rather not create the extra account, and who understand the trade they are making.
The routes that skip the developer account
There are two. They differ in how much extra software you install and what each one keeps afterwards. The IoT Platform route is in the table as the baseline.
| Route | Extra tool | Developer account | Where the key ends up |
|---|---|---|---|
| IoT Platform (baseline) | None, or tinytuya’s wizard to automate it | Yes, plus a linked app account | Copied from the portal, or written to devices.json |
| tuya-local cloud-assisted setup | None, built into the integration | No, app login only | Stored in the integration config for local control |
| QR-login key tool | Third-party add-on, Docker container or CLI | No, QR scan in the app | Shown in the tool, exportable as CSV or JSON, cached on disk |
tinytuya’s wizard sometimes gets listed as an alternative, but it reads keys from the same IoT Platform Cloud Development project. It saves you the copy-paste, not the account. See tinytuya local control without Home Assistant.
The built-in tuya-local option deserves a plain mention because it needs no extra tool at all. Per its README, you log in through the Tuya or SmartLife app, the integration pulls the connection data, and the auth token expires after a few hours and is not saved. After setup, control is local using the device ID and local key. If you are choosing between the two, I think the built-in login is the better default, because it adds no third-party software that holds a session into your Tuya account. Which integration consumes the key is a separate question, answered in LocalTuya vs tuya-local.
How the QR login works
The tool is a community project (vineetchoudhary/tuya-local-key), announced on the Home Assistant forum on 2026-07-26 and described there as version 2.1 as of September 2026. It ships as a Home Assistant add-on, a Docker container, or a CLI, for amd64 and arm64. According to the README, it retrieves local keys and full device metadata with no IoT Platform account, cloud project, Access ID or Access Secret.
It is not a back door. The tool’s own description says it signs in with Tuya’s official device-sharing SDK, using Home Assistant’s public app registration. That is the same user-code-and-QR login Home Assistant’s core Tuya integration uses, so if you have set that integration up, you have seen this screen. Because the registration is Home Assistant’s, the login may appear in the app under that name rather than the tool’s.
The flow, as documented, goes like this.
- Find your user code in the Smart Life or Tuya Smart app. Home Assistant’s Tuya integration docs place it under Me, then the settings gear, then Account and Security, at the bottom of the page.
- Enter that user code in the tool. It generates a QR code.
- Scan the QR code in the app and confirm the login. The code expires within a minute or two, so have the app open first.
- The tool returns your device list, with sessions cached so you are not asked to scan again every time.
For each device the output includes the UUID, category, IP address, and local key, plus the full fields the SDK returns and the datapoint mappings. You can export to CSV or JSON, and the tool can alert you when devices are added, removed or renamed, or when a key rotates.
What “no developer account” still means
This is a cloud login. The tool needs access to Tuya services to fetch keys, and it holds a session into your Tuya account while it does. Run it only on your home LAN, and treat its stored data like a credential.
The announcement thread describes an offline mode that shows a cached device list when the Tuya cloud is unreachable. That list is cached on disk for three days, per the thread. Sessions and lists are stored encrypted, but the README itself says the encryption keys are stored alongside the encrypted cache files. I would read that as limited protection against anyone who can read the cache directory, which is the README’s own disclosure and not the result of an independent audit.
Optional HTTP Basic Auth exists for reaching the tool from another machine. Per the README, it is bypassed when you reach the tool through Home Assistant ingress, so your Home Assistant login is the gate in that case.
On maturity, the repository showed a single open issue at the time of research (#7, a feature request to display the local protocol version) and none closed. No reports of Tuya blocking or breaking the tool turned up in the tracker or the thread. For a young, single-maintainer project, that absence is thin evidence of durability. The thread also reports that an earlier v1.3 failed on Proxmox and was fixed in v1.5, which is a reminder that it is still early.
What stays local afterwards
Once you have the key, the cloud part is done. Neither route is needed again for day-to-day control, and the thread states that local keys do not expire with the login session. That does not mean they never change. Re-pairing a device issues a new key, which is covered in why a Tuya local key changed.
Getting the key locally also does not make the device silent. The tuya-local README says plainly that using the integration does not stop devices from sending status to the Tuya cloud. If you want that traffic stopped, that is a network job, covered in blocking a Tuya device from the internet. And if your current integration is the thing that stopped working, see LocalTuya broken on recent Home Assistant before spending time on keys.
Limits of the QR-login tool
Per the README, the tool has some hard boundaries.
| Device type | What you get |
|---|---|
| Bluetooth-only devices | No retrievable local key |
| Sub-devices under a gateway | They share the gateway’s key |
| Devices without LAN capability | Not supported |
| Devices not visible in the app | Not listed |
The tool also does not use local-network discovery, so it will not find devices on its own. It only lists what your account already knows about. Tuya Zigbee devices are a different case altogether, since they are paired through a Zigbee coordinator and do not need a local key at all. See Tuya Zigbee devices and local keys.
Trust and cleanup checklist
Based on the tool’s own documentation and the general risk of a third-party tool holding an account session, a sensible routine looks like this.
- Run it on the home LAN only, not on a public host or a shared server.
- Leave Basic Auth on if anything other than Home Assistant ingress can reach it.
- Export the keys you need, and store them somewhere you already trust for secrets.
- Delete the tool’s cache directory when you are done. That removes the tool’s copy of the session. Whether Tuya also expires it on the server side isn’t documented in these sources.
- Remove the add-on or container if you do not plan to run it again.
- Look in the app’s account settings for a way to review or remove authorised logins. None of the sources here documents one, so don’t count on it.
Which route to pick
If you are comfortable with the IoT Platform and just want the established path, use the extraction guide. If you plan to use tuya-local anyway, try its built-in cloud-assisted login first, since it needs no extra software. If neither fits, and you accept a third-party tool with a short track record, the QR-login tool is the option that avoids the developer portal. Whichever you choose, the key itself is a local-control credential for that device, so keep it out of screenshots and shared configs.
FAQ
Can I get a Tuya local key without a Tuya IoT developer account?
Yes, by two documented routes. One is tuya-local’s built-in cloud-assisted login. The other is the community QR-login tool. Both involve logging in to the Tuya cloud through the app.
Where do I find my Tuya user code in the Smart Life app?
Per Home Assistant’s Tuya docs, under Me, then the settings gear, then Account and Security, at the bottom.
Does getting the local key by QR login send my data to Tuya?
The login and key fetch go through Tuya’s cloud, so yes, that part is a cloud interaction. The tool’s README does not claim otherwise. After you have the key, local control does not need that login, but devices may keep reporting status to the cloud unless you block them.
Do Tuya local keys expire or change?
The thread says they do not expire with the login session. They do change when a device is re-paired.
Do Bluetooth or Zigbee Tuya devices have a local key?
Bluetooth-only devices have no retrievable one per the README. Zigbee devices go through a coordinator and do not need one.
Verification
What this research verified. These sources, as of September 2026: the tool’s README, its forum thread and Home Assistant’s docs for the login flow, user code location, output fields, cache behaviour and limits. The tuya-local README for that integration’s login and token behaviour. A description of the tool for the device-sharing SDK mechanism.
What stays local. After the key is in hand, control through LocalTuya or tuya-local runs over the LAN.
What still depends on the vendor. The key fetch itself, and any status reporting your devices send to Tuya unless you block it.
What to check after setup. Confirm the keys work in your integration, delete the tool’s cache, and remove the tool if you are done with it.
What was not verified. Nothing here was tested on a bench, and the tool was not audited. Its long-term reliability is unknown, and so is whether Tuya can revoke this kind of session from the app. Whether Tuya tolerates this login over time is worth watching in the repository’s issue tracker.