tuya/tuyaopen-dev-skills/debug-helper

TuyaOpen Debug Helper

Provides non-blocking serial log capture for agents using tos.py monitor -l. The monitor runs as a background subprocess; the agent reads log output from a file and stops the process when done.

Script location

.agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py

No extra dependencies — uses Python stdlib only.

Quick usage

# Start background monitor (logs to <project_dir>/.target_logging/YYYYMMDD_HHMMSS.log)
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py start -p /dev/ttyACM1
 
# Read last 200 lines (JSON output for agent parsing)
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py --json tail -n 200
 
# Stop monitor (releases serial port)
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py stop

Commands

Add --json before the command for machine-readable output.

Log file location

All logs and session state are written to `<project_dir>/.target_logging/`, where <project_dir> is the directory containing app_default.config (the TuyaOpen project root). The script finds this automatically by searching upward from the current working directory.

This location keeps logs with the project they belong to. The TuyaOpen SDK .gitignore contains .target_logging as an unanchored rule — it matches at any depth in the repository, so logs are always gitignored regardless of where the project lives under the SDK.

<project_dir>/                    e.g. apps/tuya_cloud/switch_demo/
└── .target_logging/              gitignored by SDK .gitignore
    ├── session.json              active monitor session (PID + log path)
    └── YYYYMMDD_HHMMSS.log       auto-named log file per session

Session file

Session state (PID + log file path) is stored in <project_dir>/.target_logging/session.json. Only one monitor session runs at a time — starting a new one automatically stops the previous.

Port selection for T5 dual-UART boards

T5 / T5AI boards expose two serial ports (WCH dual-serial, VID 0x1a86 PID 0x55d2):

• Linux typical: ttyACM0 = flash, ttyACM1 = monitor/log
• Windows typical: lower COM = flash, higher COM = monitor/log

These are common cases, not guarantees. If log output is absent or garbled after start, try the other port.

List available ports:

# Linux / macOS
ls /dev/ttyACM* /dev/ttyUSB* 2>/dev/null
 
# Windows PowerShell
[System.IO.Ports.SerialPort]::GetPortNames()

Typical agent workflow

# 1. Start background monitor
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py \
    --json start -p /dev/ttyACM1
 
# 2. Flash firmware (monitor keeps logging while flash runs on other port)
tos.py flash -p /dev/ttyACM0
 
# 3. Wait for boot, then read log
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py \
    --json tail -n 200
 
# 4. Analyze: look for [ty E], OPRT_ errors, "feed watchdog", "mqtt connected"
 
# 5. Stop when done
$OPEN_SDK_PYTHON .agents/skills/tuyaopen/debug-helper/scripts/monitor_helper.py stop

Log analysis patterns

Related skills

• tuyaopen/dev-loop — full build→flash→monitor→analyze loop (calls this skill)
• tuyaopen/device-auth — serial port needed before writing auth credentials