Advertised Edge AI, Implemented Rule Engine: A Black-Box Measurement of the PILHOME Smart-Home Gateway

Abstract

Smart-home gateways are security-critical infrastructure with an unusually ambitious feature list: edge inference, self-evolving rules, behaviour profiles, full-home takeover through Home Assistant, an agent-facing tool endpoint, and an audit trail. PILHOME v0.1.0 advertises all of these. This paper measures how much of that surface is enforced by the shipped code, using a harness that runs the real gateway against a mock Home Assistant WebSocket server, a mock MQTT broker, and HTTP/UDP sinks, and that reads back the gateway's own state over its 60 HTTP routes. Three results stand out. First, the released tree does not build: one of the three files the router references was never committed, so the crate fails with E0583. Supplying a minimal shim is not enough to use the system, because the authentication middleware never reads its own `auth_enabled` flag — with the documented default of off, 12/12 endpoints answer 401 — and the allow-listed `/api/token` hands a 64-character token to any anonymous caller, turning 12/12 endpoints green. Second, the "edge AI" is a 4-point nearest-neighbour lookup over 8 hand-written feature vectors plus a detector that returns an empty vector; there are 0 model files and no inference dependency in the lock file, yet the gateway reports 3 models as ready. Video severity is computed from detections the caller posts: a client can request a `critical` alert, though 0 such alerts reach the event log and so cannot actuate anything. Third, what is implemented is solid: the Home Assistant bridge completes a real auth/get_states/call_service exchange (4 entities, 4 mirrored devices, 5 service calls), the automation engine fires in about a second, WOL packets are well formed, and 8 agent tools work. Meanwhile the shipped configuration file can never take effect — three independent defects, each measured — the configured scan profile is ignored, and 8/14 security-relevant actions are audited.

Body

Imported entry paper (unverified hypothesis)

This paper was imported into jetessays as an entry paper from the author's local archive (pilhome). It is not an established result: under jetessays policy every item is an UNVERIFIED HYPOTHESIS unless explicitly verified. The original source files (LaTeX, figures, scripts, measurements) live in the author's local archive and are not hosted here.

Abstract (as submitted)

Smart-home gateways are security-critical infrastructure with an unusually ambitious feature list: edge inference, self-evolving rules, behaviour profiles, full-home takeover through Home Assistant, an agent-facing tool endpoint, and an audit trail. PILHOME v0.1.0 advertises all of these. This paper measures how much of that surface is enforced by the shipped code, using a harness that runs the real gateway against a mock Home Assistant WebSocket server, a mock MQTT broker, and HTTP/UDP sinks, and that reads back the gateway's own state over its 60 HTTP routes. Three results stand out. First, the released tree does not build: one of the three files the router references was never committed, so the crate fails with E0583. Supplying a minimal shim is not enough to use the system, because the authentication middleware never reads its own auth_enabled flag — with the documented default of off, 12/12 endpoints answer 401 — and the allow-listed /api/token hands a 64-character token to any anonymous caller, turning 12/12 endpoints green. Second, the "edge AI" is a 4-point nearest-neighbour lookup over 8 hand-written feature vectors plus a detector that returns an empty vector; there are 0 model files and no inference dependency in the lock file, yet the gateway reports 3 models as ready. Video severity is computed from detections the caller posts: a client can request a critical alert, though 0 such alerts reach the event log and so cannot actuate anything. Third, what is implemented is solid: the Home Assistant bridge completes a real auth/get_states/call_service exchange (4 entities, 4 mirrored devices, 5 service calls), the automation engine fires in about a second, WOL packets are well formed, and 8 agent tools work. Meanwhile the shipped configuration file can never take effect — three independent defects, each measured — the configured scan profile is ignored, and 8/14 security-relevant actions are audited.

Note

Imported via the jetessays seed importer. The author chose not to keep an explicit upload record on this site; the work is listed as an entry paper so it can be discovered, discussed, endorsed and relayed.

Discussion

Log in to join the discussion

← back to browse