Bug: powerTapo mishandles outlet argument and subprocess index formatting, causing incorrect CLI calls and feature parsing failures for multi-outlet devices like the P304M. #192
Description
Problem/Opportunity
The current implementation stores outlet as a string and appends it directly to subprocess calls, resulting in invalid arguments (e.g., '1' instead of 1).
This breaks --index handling in the kasa CLI and prevents per-outlet power control or monitoring.
Additionally, _get_state and getPowerLevel contain inconsistent parsing logic that doesn’t properly handle multi-socket responses.
The module needs type normalization and command construction fixes to support power strips reliably.
Steps to reproduce
No response
Expected Behavior
- outlet accepted as an int (0-based), sanitized, and passed as a plain numeric string to --index.
- When an outlet is set, on/off affect only that outlet; no extra global command is sent.
- _get_state() reliably reports the configured outlet’s state (JSON first; fallback parses State (state): True/False).
- getPowerLevel() returns watts using feature current_consumption (with --index for strips), or clearly reports “not available” without crashing.
Actual Behavior
- Passing outlet=0 treats it as “no outlet” and skips the strip path; quoted indices ('1') cause Invalid value for '--index'.
- powerOn() with an outlet set turns the target outlet and the whole strip on.
- _get_state() fails to map child states correctly (undefined slotIndex, wrong tokenization), often misreporting or crashing.
- Power monitoring per outlet isn’t retrieved; commands don’t use the new feature current_consumption path.
Notes (Optional)
No response