power: drive Tasmota plugs and HTTP relays; v500: continuous handshake

[widgetii]

Prerequisite for the low-level NAND ECC study of OpenIPC/firmware#2285 and #2519, which needs unattended power cycling on two bench DUTs.

power: drive Tasmota plugs and plain HTTP relays

• New DEFIB_POWER_TYPE=tasmota (/cm?cmnd= API; off / wait / on, each switch confirmed from the plug's reply) and DEFIB_POWER_TYPE=http (on/off GET URLs, e.g. a local bridge for a cloud-only Sonoff; secrets in the URLs are redacted from logs and errors, user:pass@ is sent as Basic auth).
• agent upload --power-cycle was ignored on the HiSiliconStandard path. It now powers off, starts the handshake while the camera is dark, powers on, and re-cycles once if the bootrom stays silent for 15 s. Takes --poe-port / comment discovery for RouterOS; pulse-only controllers (Vectis) are sequenced like RecoverySession.

protocol/v500: keep the handshake on the wire continuously

• The handshake sent one 14-byte frame and then sat idle for up to 100 ms, so the bootrom's short listen window was missed on boards with healthy flash. It now sends back-to-back 8-frame bursts, scans the RX stream for the reply, and drains its TX queue before the HEAD stage.

transport/socket: bytes_waiting() sees unread data

• It only counted bytes already pulled into _buf, so polling callers (drain_input, the CV6xx and V500 handshakes) were blind on socket://, tcp:// and rack://.

Review (Qodo) — all six findings addressed

1. Socket handshake blind → fixed in SocketTransport.bytes_waiting() (root cause, also affected CV6xx/drain_input), with a socketpair test that fails on the old code.
2. RouterOS empty port → --poe-port + comment discovery.
3. Vectis pulse-only → supports_independent_power capability, pulse ordered by protocol style, RFC 2217 transport attached.
4. Relay secrets in logs → redacted.
5. Unverified Tasmota cycle → each step verified. Note: verifying by polling during a Backlog ... Delay is harmful on Tasmota 14.3 — commands sent during the Delay cut it short (~4.5 s → ~2 s off) and the mains-powered camera then never booted, so Backlog was dropped altogether.
6. TX backlog after the reply → flush_output() before settle + flush_input().

Verification

• pytest 944 passed, ruff, mypy, make -C agent test, JS tests.
• hi3516ev300 + Sonoff Micro via HTTP bridge: agent upload --power-cycle → READY.
• GK7205V510 (GD5F1GM7 NAND, vendor firmware) + Tasmota plug: burn --power-cycle caught the bootrom 3/3 consecutive runs, full 292 KB upload each. Before the V500 fix it never caught it in a 120 s run.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add HTTP power controllers and improve bootrom handshake capture

✨ Enhancement 🐞 Bug fix 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Add Tasmota and generic HTTP power controllers for unattended bench power cycling.
• Make standard HiSilicon agent uploads power-cycle before handshaking, with one retry.
• Send continuous V500 handshake bursts to catch short bootrom listen windows.

Diagram

graph TD
  CLI["Recovery CLI"] --> Factory["Power factory"] --> Tasmota["Tasmota controller"] --> DUT["Bench device"]
  Factory --> HTTP["HTTP relay"] --> DUT
  CLI --> Protocol["Bootrom handshakes"] --> Serial["Serial transport"] --> DUT

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use only the generic HTTP controller for both relay types

• ➕ Fewer backend implementations to maintain.
• ➕ One configuration model for HTTP-controlled devices.
• ➖ Cannot provide Tasmota-specific Backlog timing, state verification, or authentication-warning handling without rebuilding those features elsewhere.

Recommendation: Keep separate controllers behind the existing PowerController factory. Generic URLs suit simple relays, while Tasmota needs device-specific commands and response validation to make power cycling dependable.

Files changed (11) +920 / -26

Enhancement (3) +275 / -1

factory.pyRegister Tasmota and HTTP controllers +11/-1

Register Tasmota and HTTP controllers

• Dispatches the two new DEFIB_POWER_TYPE values and updates the factory's configuration guidance and unknown-type error.

src/defib/power/factory.py

http.pyAdd a URL-driven HTTP relay controller +86/-0

Add a URL-driven HTTP relay controller

• Implements on and off GET requests with configurable URLs and timeout. Converts HTTP and connection failures into power-controller errors.

src/defib/power/http.py

tasmota.pyAdd a Tasmota smart-plug controller +178/-0

Add a Tasmota smart-plug controller

• Supports relay selection, optional credentials, checked on/off commands, and plug-timed Backlog cycles that poll until power returns. Rejects authentication warnings and malformed or unexpected replies.

src/defib/power/tasmota.py

Bug fix (2) +149 / -22

app.pyPower-cycle standard agent uploads into the handshake +110/-7

Power-cycle standard agent uploads into the handshake

• Wires the configured controller into non-CV6xx agent uploads, starting the handshake while the device is off and retrying once after a 15-second timeout. Reports power errors, closes the controller, and broadens power-cycle option help.

src/defib/cli/app.py

hisilicon_v500.pyKeep V500 handshake frames flowing +39/-15

Keep V500 handshake frames flowing

• Replaces single-frame sends followed by long waits with repeated eight-frame bursts and scans buffered serial input for replies. Flushes residual responses before firmware transfer.

src/defib/protocol/hisilicon_v500.py

Tests (4) +451 / -0

test_agent_upload_power.pyTest power-to-handshake sequencing and retries +104/-0

Test power-to-handshake sequencing and retries

• Checks that handshaking starts before power-on, timeouts trigger a fresh cycle, failed attempts terminate, and power-on errors cancel the handshake task.

tests/test_agent_upload_power.py

test_power_http.pyTest HTTP relay configuration and requests +101/-0

Test HTTP relay configuration and requests

• Covers factory selection, required URLs, timeout parsing, on/off order, host-timed cycling, and HTTP or connection failures.

tests/test_power_http.py

test_power_tasmota.pyTest Tasmota commands, cycles, and errors +198/-0

Test Tasmota commands, cycles, and errors

• Covers configuration, relay addressing, credentials, response validation, Backlog timing and polling, and HTTP or connection errors.

tests/test_power_tasmota.py

test_protocol_v500.pyTest V500 burst handshakes and RX scanning +48/-0

Test V500 burst handshakes and RX scanning

• Adds scripted serial tests for boot noise, split replies, repeated bursts, and flushing leftover handshake responses.

tests/test_protocol_v500.py

Documentation (2) +45 / -3

CLAUDE.mdList the new power backends +2/-1

List the new power backends

• Adds Tasmota and generic HTTP relays to the repository's power-subsystem overview.

CLAUDE.md

README.mdDocument smart-plug and HTTP relay setup +43/-2

Document smart-plug and HTTP relay setup

• Adds environment configuration and CLI examples for both controllers. Explains plug-timed versus host-timed cycles and single-outlet limitations.

README.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. V500 handshake hangs on network serial links ✓ Resolved

Description

The V500 handshake gates read() on bytes_waiting(), but SocketTransport.bytes_waiting() counts
only _buf, which normal socket reads do not populate. On tcp:// and socket:// transports,
bootrom replies remain unread in the socket while the handshake keeps sending bursts and can
busy-spin the event loop.

Code

src/defib/protocol/hisilicon_v500.py[R89-91]

+                waiting = await transport.bytes_waiting()
+                if waiting > 0:
+                    buffer += await transport.read(waiting, timeout=0.01)

Evidence

SocketTransport.bytes_waiting() returns the length of its internal buffer rather than unread
socket data, and read() does not fill that buffer. The new guard therefore prevents the operation
that fetches incoming socket bytes on both supported socket URL schemes; the previous handshake
called read(14, timeout=0.1) directly.

src/defib/transport/socket.py[118-119]
src/defib/transport/socket.py[64-88]
src/defib/transport/serial_platform.py[134-157]
src/defib/protocol/hisilicon_v500.py[87-93]
src/defib/transport/socket.py[55-76]
src/defib/transport/socket.py[113-114]
src/defib/transport/serial_platform.py[128-155]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The V500 handshake gates reads on `bytes_waiting()`, which does not reflect unread socket data for `tcp://` and `socket://` transports. Bootrom replies consequently remain unread while the handshake continues sending bursts.
## Fix Focus Areas
- src/defib/protocol/hisilicon_v500.py[86-93]
- src/defib/transport/socket.py[55-76]
- src/defib/transport/socket.py[118-119]
## Recommended Fix
Replace the `bytes_waiting()` gate with a bounded, timed read inside the existing `TransportTimeout` handler, such as `buffer += await transport.read(256, timeout=0.01)`, so every Transport implementation can receive replies. Add a socket-transport handshake test. Optionally, make `SocketTransport.bytes_waiting()` perform a non-blocking receive into `_buf`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Agent upload power cycling fails on PoE switches ✓ Resolved

Description

_power_cycle_into_handshake passes "" to both power operations, while agent upload neither
discovers the RouterOS PoE interface nor accepts a --poe-port option. When `agent upload
--power-cycle uses the default RouterOS controller, _set_poe('')` cannot match an interface and
raises PoE interface not found at the first power-off, before upload proceeds.

Code

src/defib/cli/app.py[R1311-1313]

+        log(f"Powering off via {power.name()}{suffix}...")
+        await power.power_off("")
+        await asyncio.sleep(off_duration)

Evidence

The helper supplies an empty port name to the controller, while RouterOS uses that name to query and
set PoE and raises if no interface matches. The burn path resolves the interface before cycling, but
agent upload does not.

src/defib/power/routeros.py[300-312]
src/defib/power/routeros.py[360-364]
src/defib/cli/app.py[151-180]
src/defib/cli/app.py[1079-1097]
src/defib/cli/app.py[1311-1320]
src/defib/power/routeros.py[298-315]
src/defib/cli/app.py[143-170]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Agent upload passes an empty interface name to RouterOS power operations, causing the default backend to fail at the first power-off.
## Fix Focus Areas
- src/defib/cli/app.py[1079-1097]
- src/defib/cli/app.py[1174-1185]
- src/defib/cli/app.py[1203-1217]
- src/defib/cli/app.py[1283-1338]
## Recommended Fix
Expose a `--poe-port` option or discover the RouterOS interface as burn does by calling `find_port_by_comment` with the serial device label. Pass the selected port into `_power_cycle_into_handshake` and use it for both `power_off` and `power_on`, including retries.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Vectis users cannot cycle agent power ✓ Resolved

Description

The new standard agent-upload path calls power_off() and power_on() on every selected
controller, while VectisController implements neither operation and raises PowerControllerError
for both. With DEFIB_POWER_TYPE=vectis, agent upload --power-cycle fails at the first power
operation rather than using Vectis's shared-transport pulse.

Code

src/defib/cli/app.py[R1311-1312]

+        log(f"Powering off via {power.name()}{suffix}...")
+        await power.power_off("")

Evidence

The factory permits Vectis selection, but its off/on methods explicitly reject these calls and its
pulse method requires special handling for a live recovery connection.

src/defib/cli/app.py[1174-1179]
src/defib/cli/app.py[1311-1320]
src/defib/power/vectis.py[87-126]
src/defib/power/factory.py[27-34]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The standard agent-upload sequence invokes unsupported off/on methods on Vectis.
## Fix Focus Areas
- src/defib/cli/app.py[1192-1227]
- src/defib/cli/app.py[1283-1338]
- src/defib/power/vectis.py[87-126]
## Recommended Fix
Handle pulse-only controllers explicitly, attach the live RFC2217 transport when appropriate, and sequence their `power_cycle()` with the handshake instead of calling off/on.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Relay credentials appear in logs ✓ Resolved

Description

HttpRelayController._get_sync() logs each configured URL verbatim and includes the same URL in
HTTP and connection-error messages. If an on/off GET URL contains a password or query token, using
the relay exposes that credential through logs or a displayed failure.

Code

src/defib/power/http.py[R75-76]

+    def _get_sync(self, url: str) -> None:
+        logger.info("http relay GET %s", url)

Evidence

The backend accepts arbitrary URLs from the environment and emits those exact strings before
requests and on failures.

src/defib/power/http.py[39-63]
src/defib/power/http.py[75-86]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Arbitrary configured relay URLs are emitted verbatim in logs and errors, including embedded credentials.
## Fix Focus Areas
- src/defib/power/http.py[75-86]
## Recommended Fix
Log a redacted endpoint or operation label, and apply the same redaction to error messages while retaining the HTTP status and useful response detail.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. A rejected plug cycle looks successful ✓ Resolved

Description

TasmotaController.power_cycle() discards the Backlog command's reply and checks only whether a
later state query reports ON. If an API-compatible plug rejects or does not support Backlog
while its relay was already on, the method reports a completed cycle without ever turning the camera
off.

Code

src/defib/power/tasmota.py[R101-104]

+        await self._cmnd(f"Backlog {cmd} OFF; Delay {delay}; {cmd} ON")
+        # The backlog runs asynchronously on the plug.  Wait for the relay
+        # to come back so callers can rely on "power is on" afterwards.
+        deadline = time.monotonic() + delay / 10 + self._timeout

Evidence

The Backlog response is ignored, and the first ON state query returns success regardless of whether
the preceding OFF or Delay commands executed.

src/defib/power/tasmota.py[98-113]
src/defib/power/tasmota.py[127-140]
tests/test_power_tasmota.py[46-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Tasmota cycle treats an already-on relay as proof that an unchecked Backlog command executed.
## Fix Focus Areas
- src/defib/power/tasmota.py[98-113]
## Recommended Fix
Validate the Backlog response for command rejection before polling, and add a test where Backlog is rejected while the relay remains ON.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View medium (1)

6. Leftover handshake frames can break the upload ✓ Resolved

Description

Each loop pass writes a 112-byte burst without waiting for the bytes to leave the host, and after a
reply the code only sleeps 0.1 s and flushes input. Frames still queued in the OS or the RFC 2217
link keep reaching the bootrom, which delays the HEAD frame and lets late replies be read as ACK or
NAK bytes.

Code

src/defib/protocol/hisilicon_v500.py[R104-105]

+                await asyncio.sleep(0.1)
+                await transport.flush_input()

Evidence

SerialTransport.write returns once data is handed to the OS, and RFC 2217 writes are unpaced with
a no-op flush_output. The standard protocol paces its flood with a 50 ms read after each burst.

src/defib/transport/serial.py[87-133]
src/defib/transport/rfc2217.py[158-174]
src/defib/protocol/hisilicon_standard.py[136-146]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Unpaced handshake bursts pile up in the TX queue. After the reply, the remaining frames keep reaching the bootrom and their replies get mixed into the HEAD stage.
## Fix Focus Areas
- src/defib/protocol/hisilicon_v500.py[86-105]
## Recommended Fix
Pace the writes to about the burst's wire time, for example by awaiting a timed read each iteration. After a reply, call `await transport.flush_output()` before the settle sleep and `flush_input()`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗