Symptom
A Tuya Wi-Fi device using protocol 3.4 works locally for hours or weeks, then becomes unavailable. Logs show error 914 ("Check device key or version"), often after 900 (invalid JSON response) or 901/905 (unable to connect / unreachable). The Smart Life app may still control it through the cloud.
What the error codes mean (TinyTuya)
| Code | Message |
|---|---|
| 900 | Invalid JSON Response from Device |
| 901 | Network Error: Unable to Connect |
| 905 | Network Error: Device Unreachable |
| 914 | Check device key or version |
Don't jump to "the key changed"
914 is also what you see when the local key really changed after re-pairing. But on a device you didn't re-pair, the long-running discussion in Tuya Local's tracker points elsewhere:
- The maintainer describes devices that get into a state where they reject new connections until they are power-cycled. The integration can't recover them.
- From users' logs, the maintainer observed occasional recoverable 900 errors turning into permanent 914 errors after two happened in a row.
- The maintainer attributes this to the devices' closed-source firmware and made several changes to avoid triggering it. Users report mixed results across releases, so it isn't fully resolved.
What to do
- Power-cycle the device (switch it off at the mains or unplug it). If local control comes back, the key was fine.
- Only if it still fails, re-fetch the local key (see the local-keys procedure), and check the protocol version.
- Enable debug logging for the integration and keep the log from the moment the device drops. The maintainer uses such logs to find avoidable triggers.
- Keep Wi-Fi reception good. The maintainer suspects that reconnections can leave stale connections behind on the device.
- For critical devices, plan for this: an automation that alerts you when the entity becomes unavailable, or a smart plug upstream you can cycle.