Files
pilot/CLAUDE.md
Gilles Soulier c5381b7112 Pilot v2: Core implementation + battery telemetry
Major updates:
- Complete Rust rewrite (pilot-v2/) with working MQTT client
- Fixed MQTT event loop deadlock (background task pattern)
- Battery telemetry for Linux (auto-detected via /sys/class/power_supply)
- Home Assistant auto-discovery for all sensors and switches
- Comprehensive documentation (AVANCEMENT.md, CLAUDE.md, roadmap)
- Docker test environment with Mosquitto broker
- Helper scripts for development and testing

Features working:
 MQTT connectivity with LWT
 YAML configuration with validation
 Telemetry: CPU, memory, IP, battery (Linux)
 Commands: shutdown, reboot, sleep, screen (dry-run tested)
 HA discovery and integration
 Allowlist and cooldown protection

Ready for testing on real hardware.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-30 06:23:00 +01:00

150 lines
6.0 KiB
Markdown

# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Project Overview
**Pilot** is an MQTT-based PC control agent for Home Assistant. It publishes system telemetry (CPU, memory, battery, IP) and exposes commands (shutdown, reboot, sleep, screen control) via MQTT. The project has two versions:
- **v1 (Python)**: Legacy implementation in [main.py](main.py), [main_prog.py](main_prog.py), [main-lenovo-bureau.py](main-lenovo-bureau.py)
- **v2 (Rust)**: Active rewrite in [pilot-v2/](pilot-v2/) with improved architecture, unified MQTT contract, and platform abstraction
The v2 rewrite aims to fix v1's hardcoded configuration, lack of authentication/TLS, missing LWT, and OS-specific logic scattered across scripts.
## Development Commands
### V2 (Rust - Active Development)
```bash
# Run unit tests
cd pilot-v2 && cargo test
# Build release binary
cd pilot-v2 && cargo build --release
# Run locally (auto-creates config.yaml from example)
./scripts/run_pilot.sh
# Run in pilot-v2 directory directly
cd pilot-v2 && cargo run
```
### V1 (Python - Legacy)
```bash
# Activate Python virtual environment
source monenv/bin/activate
# Install dependencies
pip install -r requirements.txt
# Run manually (v1)
python3 main.py
# Deactivate virtual environment
deactivate
```
### Testing
```bash
# Send MQTT commands using helper script
python3 scripts/mqtt_send.py --device <device_name> --action shutdown --value OFF
python3 scripts/mqtt_send.py --device <device_name> --action screen --value ON
# Manual MQTT testing
# See docs/tests_mqtt.md for detailed checklist
```
## Architecture (V2)
### Module Structure
The v2 codebase follows a clean modular architecture in [pilot-v2/src/](pilot-v2/src/):
- **[config/](pilot-v2/src/config/)**: YAML configuration loading and validation
- **[mqtt/](pilot-v2/src/mqtt/)**: MQTT client, connection handling, pub/sub logic
- **[ha/](pilot-v2/src/ha/)**: Home Assistant discovery payload generation
- **[telemetry/](pilot-v2/src/telemetry/)**: System metrics collection (CPU, memory, temperature, IP)
- **[commands/](pilot-v2/src/commands/)**: Command parsing, allowlist validation, cooldown logic
- **[platform/](pilot-v2/src/platform/)**: OS-specific backends for power and screen control
- [platform/linux/](pilot-v2/src/platform/linux/): logind/polkit, sudoers, GNOME busctl, X11 xset
- [platform/windows/](pilot-v2/src/platform/windows/): Windows service, WinAPI session
- **[runtime/](pilot-v2/src/runtime/)**: Main event loop orchestration (telemetry ticks, heartbeat, command handling)
- **[security/](pilot-v2/src/security/)**: Security utilities (future: auth/TLS validation)
### MQTT Contract (V2)
Base topic: `pilot/<device>/...`
**Topics:**
- `pilot/<device>/availability`: online/offline (LWT support)
- `pilot/<device>/status`: JSON with version, OS, uptime, backends
- `pilot/<device>/capabilities`: JSON listing enabled features
- `pilot/<device>/state/<name>`: Sensor states (cpu_usage, memory, power_state, etc.)
- `pilot/<device>/cmd/<action>/set`: Command topics (shutdown, reboot, sleep, screen)
**Home Assistant Discovery:**
- Prefix: `homeassistant`
- Conforms to HA discovery spec with device_info, unique_id, state_topic, command_topic
### Runtime Flow
The [runtime/mod.rs:31-127](pilot-v2/src/runtime/mod.rs#L31-L127) orchestrates:
1. **Startup**: Connect to MQTT, publish availability/status/capabilities, send HA discovery, subscribe to commands
2. **Event Loop** (tokio::select):
- Telemetry tick: Read metrics from providers, publish to `state/<name>` topics
- Heartbeat tick: Publish status and power_state
- MQTT events: Handle incoming commands with cooldown and allowlist checks
- Shutdown signal: Publish offline availability, disconnect gracefully
3. **Command Handling**: Parse action/value, check allowlist, enforce cooldown, execute via platform backend, publish state updates
## Configuration (V2)
Config file locations (searched in order):
- Linux: `/etc/pilot/config.yaml` then `./config.yaml`
- Windows: `C:\ProgramData\Pilot\config.yaml` then `./config.yaml`
Example: [config/config.example.yaml](config/config.example.yaml)
Key fields:
- `device.name`: Device identifier (used in MQTT topics)
- `mqtt`: Broker connection details, QoS, retain settings
- `features.telemetry`: Enable/disable, interval
- `features.commands`: Enable/disable, cooldown, dry_run mode, allowlist
- `power_backend.linux/windows`: Backend selection (logind_polkit, sudoers, etc.)
- `screen_backend.linux/windows`: Backend selection (gnome_busctl, x11_xset, etc.)
## Platform Backends
Backends are selected via config and abstracted behind traits:
- **PowerControl**: shutdown, reboot, sleep, hibernate
- **ScreenControl**: screen_on, screen_off
Linux backends require appropriate permissions:
- `linux_sudoers`: Requires sudoers entries for `/sbin/shutdown`, `/sbin/reboot`
- `gnome_busctl`: Requires active GNOME session and user DBus access
See [docs/deploiement.md](docs/deploiement.md) for permission setup details.
## Documentation
Key docs in [docs/](docs/):
- [analyse_v1.md](docs/analyse_v1.md): V1 analysis (hardcoded config, security issues)
- [architecture_v2.md](docs/architecture_v2.md): V2 architecture diagram and MQTT contract
- [deploiement.md](docs/deploiement.md): Deployment guide (systemd service, permissions)
- [tests_mqtt.md](docs/tests_mqtt.md): Manual MQTT testing checklist
- [utilisation.md](docs/utilisation.md): Usage instructions
## Important Notes
- **Active development is on v2 (Rust)**. Only fix critical bugs in v1 Python scripts.
- **Dry-run mode**: Set `features.commands.dry_run: true` in config to test without executing system commands
- **Security**: V1 lacks auth/TLS. V2 architecture supports it but not yet implemented.
- **Testing**: Always test commands in dry-run mode first. Use [scripts/mqtt_send.py](scripts/mqtt_send.py) for manual testing.
- **Systemd service**: V1 uses [mqtt_pilot.service](mqtt_pilot.service), V2 will use `packaging/pilot.service`
- **Backups**: V1 backups are in [backup_v1/](backup_v1/)