Skip to content
Cossid edited this page Mar 6, 2024 · 26 revisions

FAQ

How do I put my device into slow-blink AP mode?

First, it is important to distinguish that there are two Tuya pairing modes:

  • EZ Mode which makes the device blink quickly, sometimes referred to smart pairing mode.
  • AP Mode which makes the device blink slowly and broadcast a unsecured AP (ex: SmartLife-1A2B)

Every device must be put into EZ Mode before it can be put into AP Mode. Most devices can be put into pairing mode in one of two ways:

  • Devices with buttons: long press (press and hold) the primary button, usually the power or toggle button, until the device starts blinking
  • Devices without buttons: power-cycle the device by turning them off for approximately one second, followed by on for approximately 1 second, a set number of times. Usually this number is 3, but some device required 4 or 5, consult the instructions that came with your device.

Once a device is in EZ Mode, you must repeat the same process, and the device should switch to AP Mode Some devices allow you to go straight to AP Mode by doing the off/on process 6 times without pausing, but some do not.

See https://support.tuya.com/en/help/_detail/K9hut3w10nby8 for more information.


What is the difference between cutting and flashing?

Cutting keeps the existing Tuya software/operating system on your device and lets you use the original functionality, with the exception that it will no longer connect to Tuya's cloud service at all. You can use local alternatives to control your device such as LocalTuya or TinyTuya. Firmware flashing replaces the original firmware with the custom firmware you provide. Currently ESPHome via LibreTiny and OpenBK7231T_App are viable options for Beken-based devices.


Can I uncut a device and connect it back to Tuya?

No, cutting is permanent, as the secret values shared with Tuya are removed and cannot be recreated. If that functionality no longer meets your needs, you may need to consider a 3rd party firmware instead.


I have already cut my device, but it is not working as expected, what should I do?

You can cut a device as many times as you want with no repercussions. However, flashing your device is permanent, and there is no easy way back. You can try selecting any other device that shares the same profile with your device. If there is only one available, and it does not work, 3rd party firmware flashing may be your only viable option.


What is the difference between a profile and a schema?

A profile is something shared by a group of (but not all) devices. A schema is usually specific to a device model. The profile is the core of the exploit used by Tuya-CloudCutter, but the schema is what ensures you have proper local control for cut devices. Several classes of devices may share a profile with similar devices (such as bulbs may share a profile with other bulbs, or plugs may share a profile with other plugs), but each device has a schema that instructs Tuya's firmware how to control the device, so even if two bulbs have the same features and profile, they may have different schemas.


I plan to use a 3rd party firmware, do I need to worry about device schemas?

No, the schema is only relevant when cutting a device. To flash a device that shares an existing profile, choose By firmware version and name. It will first instruct you to choose a firmware version, then a manufacturer, then a model. For firmware flashing, you may choose any manufacturer and model, it will not make any difference, only the firmware version matters.


How do I find out what firmware version my device has?

The only currently known way is to pair your device with the SmartLife app (or whatever branded app your device uses), select the device, select the pencil icon (sometimes displayed as 3 dots instead) in the upper-right-hand corner, and select Device Update. Do not worry, this will not automatically start an update, it will take you to a screen that will show one or two versions. The Main Module version is what you need to know.

If your device instantly instructs you to update, you may not be able to see your current version, it may only show you the available version to update to. You can only assume a lower version is currently installed. It may be difficult to get to the pencil menu because of a prompt to update, but that Update Firmware button will take you to the same Device Update screen.

If your device is not supported by manufacturer and model, you may use this information to instead choose By firmware version and name where the version number must match, and if there are multiple, the name must best match the device function you are trying to update. Please note this method is generally not recommended for cutting as the device may not have full functionality. We generally only recommend this option for flashing 3rd party firmware.


I'm not sure what module is in my device, how do I find out?

Tuya ships devices with many modules, with Beken, Realtek, and Espressif being the most common. You can determine if your device is Espressif or Beken/Realtek by putting your device into AP Mode and getting the BSSID (note, not the SSID. A BSSID is a MAC address in the form of ??:??:??:??:??:??) with a wifi analyzer and look it up with a mac address lookup database such as macaddress.io. If the address is not found or says the vendor company name is Espressif Inc the device is Espressif and not supported by Tuya-CloudCutter. If the vendor company name is Tuya Smart Inc, the device is either Beken or Realtek. There is currently no way to distinguish between the two by BSSID.

Beyond BSSID, the Tuya firmware version number may give a hint to which module is present.

Espressif and Realtek devices are not supported by Tuya-CloudCutter.


I have flashed an incorrect firmware and my device no longer responds, what can I do?

The only solution to a bad flash is to serial flash the device. Once the device has been successfully OTA flashed once, it cannot be flashed by Tuya-CloudCutter again.


I have a lot of the same device to flash, how can I make the process easier?

Unfortunately, only one device can be flashed at a time. Tuya-CloudCutter has some input parameters that can make device selection quicker, but you must complete the process once with the normal input method (without needing more advanced instructions). Once you have done one device, you can then use the -p parameter and the -s parameter if you are cutting or the -f parameter if you are flashing custom firmware.

-p is the slug of the device you wish to use. This will match the name of the device directory in the device-profiles directory. This will only be present after selecting the device once through the normal methods.

Cutting: -s SSID PASSWORD will pass your SSID and password in so you don't have to manually type it later. If your SSID or PASSWORD contain spaces, you will need to quote each value. Some special characters may need escaping. If that is a problem, use the regular input mode instead.

Custom Firmware Flashing: -f is the filename (without any path, ex: bk7231t_app.ota.ug.bin) that exists in the custom-firmware directory.


Tuya-CloudCutter stops my DNS, but then fails to download docker images or profile data, how can this be resolved?

Some Linux distributions use loop-back DNS queries, where they run their own DNS daemon on 127.0.0.1 and generate their own DNS resolver chain. This is a bit outside of the scope for Tuya-CloudCutter to resolve on it's own, it will only do the bare minimum of making sure it can exploit DNS requests during the exploit process by asking to stop the current DNS daemon. To work around this, you generally have two options:

  1. Run Tuya-CloudCutter choosing no when requested to kill the service at port 53, let it build the docker image, then select your device mfg/make/firmware version, then cancel out with CTRL+C when it asks for device interaction. Then run again, selecting yes to killing the service at port 53.
  2. Add an external nameserver to your /etc/resolve.conf DNS configuration file. This will likely be overridden the next time your DNS service starts back up. Valid options may be nameserver 1.1.1.1, nameserver 8.8.8.8, or nameserver 9.9.9.9

After you complete the Tuya-CloudCutter process, you may need to restart your OS or DNS service to resume normal internet functionality.


What custom firmware options are available?

There are custom firmware projects already available for BK7231 (in alphabetical order):

If your app/project/firmware is not listed here, and you want it to be, this wiki is user editable, or open an issue and we will add it.


I have flashed a 3rd party firmware, how can I configure my device?

For devices with direct matching profiles and schema, CloudCutter provides device configuration data if available, though not all devices provide that data. This is a configuration conversion and is not guaranteed to work or may need some tweaking based on known device functionality. Some devices may have multiple modules and different configurations. These are meant to be used as templates and adjusting to match your exact device is left to you.

If you used a device that only matches profile, the pins may not match, and you may need to probe your device either physically or with a pin scanner such as ESPHome Kickstart which lets you bind to pins on-the-fly to monitor device interaction.

If a CloudCutter device has no device_configuration section or has user-config-ty, iot-config-ty, or common-ty in the profile name, the device is likely TuyaMCU controlled and you must set up a TuyaMCU module on RX1/TX1 to control the device.


My device gets stuck after DHCP, what can I do?

If CloudCutter pauses after a device requests DHCP information, the device is having issues with your wireless network, or the timing of its availability. Sometimes this is simply a timing issue because your CloudCutter device is sending data to the device's AP mode then quickly switching to its own AP mode, and packets can sometimes get lost/missed in this process. When this happens, try the following procedure:

  • Keep CloudCutter running
  • Put the target device back into pairing mode. You can either continue using slow-blink mode, or use fast-blink mode here if it is more convenient. If the device doesn't show up in the SmartLife app using fast-blink, you may need to use the slow-blink mode instead.
  • Open the Smart Life app on an Android or iOS app and follow these steps:
    • Manually add a device, select Socket (Wi-Fi) no matter which device you have.
    • When asked to enter wifi credentials, use:
      • SSID: cloudcutterflash
      • Password: abcdabcd
    • Select next until it asks you to select the indicator light or beep method and choose Slow-Blink
      • If you are using a branded app, you may have to change the option in the upper right hand corner from EZ Mode to AP Mode
    • Depending on your version of the SmartLife app, the next parts may appear different;
      • If you immediately see a countdown timer, navigate to your phone's WiFi settings, and connect to the device's A- prefixed hotspot, then return to the app
      • If you get a screen connect to the device's hotspot, open Go to Connect and connect to the device's A- prefixed hotspont, then return to the app. If it gives you the option to Confirm hot spot connection, next at the bottom of the screen, choose that option.
  • The device will not connect to the Smart Life app, this is normal. The device has been cut, so it will no longer actually connect to Smart Life cloud services, but it should now re-connect to the CloudCutter AP and continue where it left off, including re-requesting DHCP information. If all of this fails, you might consider seeking an older version of SmartLife from a reputable source (such as APKPure, no such option for IOS users) to complete this process, version 4.8.2 is known to work with these instructions.

Note, your phone may force you to connect to the cloudcutterflash AP in order to send the information to the device. This is fine an will not harm anything, but you will see more unusual requests in your log as a result.


I received a gateway mismatch message but, but it appears to be correct, what can I do?

The issue stems from NetworkManager not properly clearing out AP profiles, and the message actually has line returns it it, which is why it is unable to match despite looking correct. You can resolve this by either running with the -r parameter, which will reset NetworkManager and it's profiles, or you can remove the stale NetworkManager profiles in /etc/NetworkManager/system-connections