Tuya SmartLife-EE19 Wi-Fi Sensor: Local OTA Access, Temperature/Humidity Detection, and Soft AP Configuration

User question

An unknown PCB of an unknown Wi-Fi sensor/MCU (black box -- BB) does not have a physical access. Hard breaking is possible. The BB's labels and its description supplied are absent/obsolete. The BB has LED blinking in three ways: the 1st -- 50 times per 30 sec during 3 minutes, the 2nd -- 11 times per 30 sec during 3 minutes, and the 3rd -- short double blinks after dark pausing also during several minutes.

The first mode does not provide any response while searching Bluetooth and/or Wi-Fi. The second mode provides only the single connection per 3 minutes for any local Wi-Fi station and allows free reading of some attributes: Access point MAC: 80:64:7C:B6:EE:18; SSID: SmartLife-EE19; Security: None; Channel: 6; IP/CIDR//GW[DNS]: 192.168.175.101/24//1[1], 192.168.175.100/24//1[1], 192.168.43.37/24//1[1], 192.168.1.128/24//1[8.8.8.8, 8.8.4.4].

The BB must include a temperature sensor (at least). However, the sensor detection fails during the mentioned Wi-Fi connection.

Is it possible to reveal the temperature/humidity device within the BB and soft AP configuration via local (not cloud) OTA method?

Artificial Intelligence Response

Direct answer to the question

• Short answer: Not via the device’s “SmartLife‑XXXX” soft‑AP alone. In AP (pairing) mode Tuya/SmartLife devices do not expose sensor data or their datapoint schema, and they accept only provisioning/handshake traffic. However, a local, no‑cloud OTA is sometimes possible if the device’s Tuya firmware is vulnerable to the public tuya‑cloudcutter method. If it is not vulnerable, you will need physical access to identify the sensor and/or reflash.
• Key points:
  • Your SSID “SmartLife‑EE19” and OUI 80:64:7C identify the platform as Tuya. (macvendorlookup.com)
  • In AP mode, Tuya devices exchange only provisioning packets (UDP 6666/6667, TCP 6668) and do not publish temp/humidity. (support.tuya.com)
  • Local OTA without cloud is feasible only if tuya‑cloudcutter supports your firmware; otherwise, opening the device (UART/JTAG) is required. (github.com)

Detailed problem analysis

• Identification from your evidence:
  • AP MAC 80:64:7C:B6:EE:18 → OUI belongs to Tuya Smart Inc.; SSID “SmartLife‑EE19” follows Tuya’s AP‑mode naming (suffix generally tracks MAC end). A one‑digit mismatch is common because many modules use different MACs for STA vs AP (often ±1 in the last byte). (maclookup.app)
  • Channel 6, open AP, single client allowed, 3‑minute window → Tuya AP pairing. Private 192.168.175.x addressing is also seen on Tuya APs. (reddit.com)
• Why you cannot “see” the temperature/humidity while connected to SmartLife‑EE19:
  • AP mode is a provisioning state. The Wi‑Fi SoC listens for the phone/app to deliver Wi‑Fi credentials and a pairing token over UDP 6666/6667, then closes the AP and joins your LAN; it does not expose sensor telemetry or device schema in this mode. (support.tuya.com)
• Realistic local paths: 1) Software‑only, no cloud, no opening:
  • Try tuya‑cloudcutter. It exploits known weaknesses in many BK7231/Tuya firmwares to push custom firmware locally during pairing, with no Tuya cloud. Success is device/firmware‑dependent and requires a matching “profile.” If it works, flash OpenBeken; then you can read the sensor locally (HTTP/MQTT) and/or sniff TuyaMCU dpIDs directly. (github.com) 2) Software‑only, using cloud once (not your preference):
  • Provision with Smart Life just once, extract device local key and dpIDs (tinytuya/LocalTuya/Tuya‑Local), then control/read locally on your LAN thereafter. This still needs that initial cloud bind to obtain the key and schema. (github.com) 3) Hardware (“hard breaking”):
  • Open the enclosure, identify the module (e.g., BK7231N/T WBxS/CBxS, older ESP‑based TYWE3x, or RTL8710 family), attach UART, dump flash, and either parse firmware for dpIDs/sensor driver strings or replace with OpenBeken/Tasmota as appropriate. This is the most reliable when OTA vectors are closed. (github.com)

Current information and trends

• Tuya AP/EZ modes and LAN ports remain as documented by Tuya through 2024–2025 (AP = slow blink, UDP 6666/6667 discovery; LAN control over 6668). (support.tuya.com)
• tuya‑cloudcutter is active and maintained (commits in 2025) and targets primarily BK7231‑class modules; success depends on exact firmware. (github.com)
• For users who avoid custom firmware, LocalTuya/Tuya‑Local provide LAN control once keys are obtained; the ecosystem evolves (2025 fork activity) but the local protocol requirement (device key + dpIDs) is unchanged. (reddit.com)

Supporting explanations and details

• What the AP actually serves:
  • Minimal DHCP on a private /24 (often 192.168.175.0/24); device sits at .1/.100/.101 variants; listens for provisioning traffic and occasionally a small HTTP stub. It will not serve /status or /sensors endpoints for telemetry in stock Tuya firmware. (reddit.com)
• Ports/protocol:
  • UDP 6666/6667 (discovery and encrypted credential/token exchange), TCP 6668 (LAN control once on your network). During AP pairing, only the provisioning exchanges are relevant. (support.tuya.com)
• After custom firmware:
  • OpenBeken exposes a Web UI, MQTT, and drivers for TuyaMCU and I²C sensors (SHT3x/AHT2x/Si70xx/HTU21D, etc.). You can map TuyaMCU UART, decode dpIDs, and publish temperature/humidity locally. (github.com)

Ethical and legal aspects

• Ensure you own the device and are permitted to alter its firmware. Bypassing vendor protections may void warranty and could violate terms if the device was not yours or if used in managed environments.
• Do not connect unknown devices to production networks without isolation; do not sniff other users’ traffic.

Practical guidelines

• Confirm Tuya quickly:
  • While connected to SmartLife‑EE19, set a static IP (e.g., 192.168.175.2/24, GW 192.168.175.1) and scan 192.168.175.0/24; capture UDP 6666/6667 to see Tuya provisioning beacons. (support.tuya.com)
• If you want a pure local OTA (no cloud): 1) Put device into AP mode (your slow‑blink mode). 2) Run tuya‑cloudcutter from a Linux host close to the device; select profiles until you find a match; first step is often a flash dump/backup; if exploitation succeeds, immediately install OpenBeken. (github.com) 3) After OpenBeken boots, join its AP, set your Wi‑Fi, then:
  • If it is a TuyaMCU design (secondary MCU talking over UART), enable TuyaMCU driver and watch logs to learn dpIDs for temperature/humidity/battery.
  • If it is a direct‑sensor design, enable the proper I²C/1‑Wire driver and verify live readings via Web UI/MQTT. (github.com)
• If cloudcutter fails:
  • Open the unit. Identify module silkscreen (e.g., WB3S/CB2S=BK7231; TYWE3S=ESP8266). Attach 3V3 UART, dump flash, search for sensor strings and dpID tables, or flash OpenBeken/Tasmota accordingly. (github.com)
• If you accept a one‑time cloud step (not preferred, but practical):
  • Pair with Smart Life, then use Tuya‑Local/LocalTuya to fetch local key and set up LAN‑only control. Keep device off the Internet afterwards (DNS/null route) if desired. (github.com)

Possible disclaimers or additional notes

• tuya‑cloudcutter does not work on all firmware revisions; success is not guaranteed and depends on a maintained profile for your exact build.
• Some very new Tuya Wi‑Fi stacks may have patched the exploitable paths; in such cases only physical access will work.
• ESP8266‑based OTA via “tuya‑convert” is largely obsolete for new hardware (moved away from ESP or patched PSK); don’t count on it in 2025. (reddit.com)

Suggestions for further research

• During your AP connection window, capture a 3‑minute pcap and share the hexdumps that include fields like productKey/gwId; this helps fingerprint supportability.
• If you open the device, provide high‑resolution photos of both PCB sides and module markings; from that we can give an exact pinout and flashing recipe.
• Monitor tuya‑cloudcutter device/profile lists and OpenBeken release notes for newly supported modules. (github.com)

Brief summary

• Your device is Tuya. AP mode is for provisioning only and will not reveal the temp/humidity sensor or its datapoints. A purely local OTA path exists only if your firmware is vulnerable to tuya‑cloudcutter, in which case you can flash OpenBeken and read the sensor locally. If cloudcutter is not applicable, physical access is required to identify the sensor and/or replace firmware. (support.tuya.com)

If you want, I can provide a step‑by‑step cloudcutter runbook tailored to your capture (pcap) or to the module markings after you open the enclosure.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.