kami
5fe8f228c1
Add a read-only /ecosystem page that consumes the sibling services' JSON APIs (Nexus entities, Praxis attention, Hexis capabilities), fetched concurrently with honest per-panel error states. Siblings stay headless — mavweb is their human surface (arch §16). Wired via mavweb -nexus/-praxis/-hexis flags; mavweb joins the ecosystem compose network. Fix mobile horizontal overflow across all pages: .content is a flex child with default min-width:auto, so it refused to shrink below the tables' intrinsic width. min-width:0 lets wide tables pan inside .scroll instead of dragging the page sideways. Verified via CDP geometry check (scrollWidth === clientWidth at 430px). Also includes in-progress Ethos UI redesign, ecosystem deploy compose, and planning docs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
29 lines
2.6 KiB
Markdown
29 lines
2.6 KiB
Markdown
# Plan: SmartHome Ecosystem Integration
|
|
|
|
**Goal:** Maven connects to the SmartHome ecosystem — Home Assistant, MQTT, Zigbee2MQTT, or direct HTTP APIs — to read sensor states, control devices, and trigger automations based on facts and presence.
|
|
|
|
**Done when:**
|
|
- MQTT client in `internal/smarthome/mqtt.go` — connects to broker, subscribes to topic patterns, publishes control messages
|
|
- Home Assistant API client in `internal/smarthome/ha.go` — REST API + WebSocket for state reads and service calls
|
|
- SmartHome entities are writable as facts (sensor → fact write for loop predicates)
|
|
- Tool verbs for device control: `turn_on`, `turn_off`, `set_temp`, `set_brightness` — mapped to existing `tool.Executor` or the SmartHome API directly
|
|
- Presence integration: motion sensors, door sensors, WiFi presence feed into the existing `store.PresenceProbes` pipeline
|
|
- Voice control: "maven, выключи свет в гостиной" routes through `IntentAct` → SmartHome tool
|
|
|
|
**Scope:**
|
|
- New `internal/smarthome/` package — MQTT client, Home Assistant client, entity registry
|
|
- New `cmd/mavpoll/` extension — existing polling infrastructure extended with SmartHome sensors
|
|
- Config: `smarthome` block in `config.Config` — `{provider: "homeassistant|mqtt", url, token, mqtt_broker}`
|
|
- Reuses `internal/tool.Executor` for device control tools
|
|
- Reuses `internal/store.PresenceProbes` for presence input
|
|
|
|
**Steps:**
|
|
1. Create `internal/smarthome/ha.go` — Home Assistant REST client: `GetStates()`, `CallService(domain, service, target, data)`, subscribe to WebSocket events
|
|
2. Create `internal/smarthome/mqtt.go` — MQTT client via `github.com/eclipse/paho.mqtt.golang`: subscribe to `zigbee2mqtt/#`, `homeassistant/#`, publish to `cmnd/#`
|
|
3. Create `internal/smarthome/entity.go` — entity registry: maps entity_id → fact key, device_class → fact kind
|
|
4. Create programmatic tool registration — on startup, enumerate SmartHome entities and call `ProposeTool` for each controllable device (light, switch, climate, cover)
|
|
5. Wire MQTT sensor updates into `store.WriteFact` — e.g., `zigbee2mqtt/temperature` → `WriteFact(kind="env", key="temp:living_room", value="22.5")`
|
|
6. Wire SmartHome presence signals into `store.PresenceProbes` — e.g., WiFi presence or motion sensor → `presence_wifi` / `presence_motion` probes
|
|
7. Add `smarthome` block to `config.Config` and wire into `cmd/mavend/main.go` — starts separate goroutine for MQTT/WebSocket event loop
|
|
8. Test with a local MQTT broker and simulated sensor messages — verify facts are written and loop predicates can read them
|