The 3D floorplan could say which room somebody was in. This makes it able to
say where in the room — from a different sensor, kept deliberately separate
from the one that knows who they are.
Room-level presence comes from BLE, which cannot give coordinates: RSSI-to-
distance is noisy enough that trilateration in a house lands in the wrong
room. Coordinates come from mmWave radar (LD2450-class), which tracks moving
targets and reports x/y — and cannot say who anybody is, because it sees a
moving blob.
So the two are fused, by a rule that refuses far more often than it commits:
exactly one occupant in the room AND exactly one target in the room
-> that target is that person
anything else
-> targets stay anonymous, occupants stay unpositioned
Two people in a room are two blobs that cannot be told apart. Guessing which
is which would put a name on the wrong person, and a display that does that
occasionally is worse than one that never tries — its wrong answers are
indistinguishable from its right ones. position_ambiguous says so out loud.
Which room a target is in is computed from the polygon rather than from which
sensor saw it: a radar in an open-plan kitchen sees into the living room, and
attributing by sensor would put people through walls.
identity
floorplan_levels gains metres_wide; without it positions are not computed
and the API reports that rather than guessing a scale. New floorplan_sensors
table holds where each radar sits on the plan and which way it faces —
drawn by a human, because a wrong rotation mirrors every target it reports
and the result looks plausible rather than broken. Targets at exactly (0,0)
are dropped: that is how these radars say "nothing here", and treating it
as a detection grows a phantom person on top of every sensor.
render/floorplan-3d
A fused person is drawn at their coordinate with a footprint dot, since a
marker floated above the floor otherwise reads as further back in the room.
An unattributed target is a hollow dashed puck with a question mark — no
colour, no initial, because every visual language here for a person is
reserved for people the system can name. A radar target lights the room even
with nobody named: somebody is in there, and that the house cannot say who
is a fact about the house.
Hardware: HLK-LD2450 added to components.md, ~EUR 15-25 per room, with the
advice to buy one and check its facing before buying more.
Position maths and the fusion rule are unit-tested headlessly. No radar has
been bought, mounted or read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FanS1vyE2gLhGkqKq6HtYj
Adds the workshop/office assistant and the plumbing several other features
were waiting on. The through-line: every new capability that could act on
its own proposes instead, and says out loud when it does not know something.
New service — workshop/
Project notebook (workshop.db) plus a never-pruned knowledge store
(workshop-knowledge.db): standing workflow instructions by activity,
keyword facts, durable project learnings, and the household's ONE hardware
inventory. GET /context returns everything applying right now in one call,
so the assistant is told the standing considerations rather than reminded
of them. Two databases because they have different lifetimes: rebuilding
the project store must not take the note about how you solder with it.
Hardware statuses distinguish reserved (still on the shelf) from in_use
(installed and working) — "can I use this right now" has different answers
for the two, and naming a project on an in_use item never silently demotes
it.
Gitea repos with append-only history: commit/push/branch yes, unattended;
force-push/rebase/amend/reset/filter-repo never, enforced server-side by
branch protection rather than only by this code refusing. When history
genuinely must be scrubbed, /scrub-request prints the commands for a human
to run — the manual step is the safety mechanism.
Fleet scripts: one monitoring-agent script per kind of machine, fetched by
each endpoint's fleet-bootstrap timer. Remote code execution by design, so
the constraints are the design — upload is a draft, publishing is separate,
scripts live in SQLite rather than on the writable share, every version is
kept, and the endpoint verifies the checksum and reports pass or fail.
Slots exist for the ESP32s and network appliances that cannot run a script
at all, holding the CheckMK-server-side config instead.
Infrastructure health
opnsense becomes a LIST of firewalls, each named, keyed by name rather than
index. CheckMK joins it. Both are polled by workshop (always-on) and read
by digest-engine, so the digest can say "critical since Tuesday" instead of
quoting a six-hour-old snapshot. Three states, because "I could not ask" is
not "nothing is wrong".
pantry-vision
All four stock movements are camera-driven; stock counts individual units
and folds brand-free via Grocy product groups. Door-sensor-triggered
appliance cameras record sightings as hints with timestamps, never as
stock — a camera at a door cannot tell in from out.
identity
Per-person colour and settable profile picture, assigned to avoid collisions
between people sharing an initial, on the 2-bit-per-channel lattice a colour
Pebble renders natively.
render/ — shared, vendored, dependency-free
media-visualiser: two-tier by necessity, since most endpoints have no local
audio; the synthetic tier says on screen that it is not an analysis.
floorplan-3d: canvas 2D rather than three.js — the scene is prisms on a
plane, which an isometric projection draws in ~200 lines, predictably on
weak panels, with the frontend still at zero dependencies.
Config and fleet plumbing
Rooms are one vocabulary (an HA area_id) from CoreSystemConfig through the
builders to suggested_area. Keycloak and FreeIPA are coupled as one
decision with USR_HA_ group naming, declaration-only for now and validated
as such. Immich alongside the photo share, read-only. Thin clients get the
full media-key set for a wireless remote.
Docs: fridge-item-location, workshop-assistant, rooms-and-endpoints,
endpoint-surfaces, pebble-presence-watchface.
Testing is stubbed suites and headless unit checks only — no real Grocy,
camera, vision model, CheckMK, Gitea, Samba or browser has been involved.
The CheckMK API shape and Gitea's branch-protection payload are written from
documentation and have version-sensitive field names.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FanS1vyE2gLhGkqKq6HtYj
identity/ (Phase 6, rewritten from the original Node-RED sketch): a
person <-> BLE-identifier registry built directly as a Python service.
Solves multi-phone (multiple identifiers per person), anti-spoofing
(only allowlisted IRK-resolved/fixed-tag entities are ever accepted as
registration candidates, never a raw or randomized MAC), device-less
people (a grandmother without a smartphone gets a no_device registration
plus a hand-operated home/away toggle, reported as "unknown" rather than
a false "away"), and anonymous guests (POST /register/guest, no name
needed). Every person gets an automatic profile picture from their most
recent registration photo. /presence also reports a best-effort room per
person as groundwork for an eventual floor-plan view (not built).
Registration is single-utterance voice ("register me as <name>") or a
touchscreen form; ambiguous/conflicting candidates never auto-commit.
hosts/door-panel/ (Phase 18, new host): structurally kitchen-display's
twin - one Sway workspace, one Chromium kiosk window - defaulting to
identity's weather+clothing/who's-home/groceries-running-low dashboard,
with voice registration as its actual purpose (mic on by default, unlike
every other host's opt-in).
hosts/kitchen-display/: adds opt-in voice satellite and a "Show
registration" screen pointed at identity's register.html, reusing the
same camera-equipped-endpoint registration flow.
pantry-vision/: adds GET /shopping-list (Grocy's own volatile/missing
products, reshaped) for the door panel's "running low" section.
setup-container-host.sh: wires ENABLE_IDENTITY (identity + identity-web,
published like pantry-vision since kiosk browsers call it directly, plus
a persistent SQLite/photos volume unlike pantry-vision's stateless
design) and fixes the HA_URL example to the host's real LAN IP (HA runs
network_mode: host, unreachable by container name - the same situation
Node-RED's own config already documents).
docs/: Phase 6 rewritten, Phase 18 added, hardware/software/guardrail/
open-decision entries throughout project-plan.md and README.md.
components.md gains RuView presence nodes (one per room), fixed BLE tags,
and 2 spare webcams, with the price estimate updated to match.
Nothing here has been run against real hardware, a real HA instance, or
real Private BLE Device entities - TRUSTED_ENTITY_PREFIXES above all
needs checking against a live instance before registration finds
anything. See identity/README.md and hosts/door-panel/README.md for the
itemized verification lists.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
Compares innr RB 285 C (this project's own existing project-plan.md pick,
router-capable, confirmed zigbee2mqtt support), IKEA TRADFRI (cheapest but
not reliably on Amazon), and Sengled (cheap but not a Zigbee router, which
matters for whole-house mesh coverage) — picks innr. Count is a rough ~16
placeholder pending an actual per-room fixture count. Adds it to the
Lighting/Summed totals/Need/Price estimate sections; new subtotal
~€1,729-2,045.
5 Sound Systems total now (was 4) - have 1 (Living Room), need 4 more.
Updates the room list, summed totals, by-room tally, Need section, and
price estimate accordingly: ~€1,489-1,725 total.
Resolves the two "?" marks in the room list, summed totals, by-room tally,
and Need/price sections — all 4 Sound Systems are now confirmed, 3 more
kits needed (have 1), total ~€1,259-1,495. Linus Room's separate "???"
line is unrelated and still open.
Rough EUR figures per item (qty x unit price), a confirmed-need subtotal,
and a separate conditional subtotal for the two unconfirmed Sound Systems.
Reuses docs/project-plan.md's own figures where it has them (GPU, ESP32
board, amp, speakers); everything else is a market-price estimate flagged
as such, not a live-checked Amazon price.
hosts/touch-panel/: cheap touch controllers sometimes report as an absolute-
position HID mouse instead of a real digitizer, which makes libinput hand
sway a type:pointer device instead of type:touch. Add a type:pointer
fallback (flat accel profile, no pointer acceleration, cursor hidden on
idle) so taps still work as single-touch clicks in that case, plus a udev
rule template (configs/udev/99-touchscreen-override.rules) to re-tag a
specific known device back to full wl_touch semantics once its USB vendor/
product ID is known. Documented in a new README section and reflected in
project-plan.md's hardware/guardrail/open-decision entries for Phase 16.
docs/components.md: replace the Lenovo ThinkSmart View pick for Loggia (a
locked-down Teams/Zoom appliance, not a general Linux box) with a cheap
all-in-one touchscreen PC, then supersede that with the Lenovo all-in-one
already on hand for that room — moved from Need to Have throughout. Also
adds a Need section: missing components broken into sub-parts (Sound
System, Voice Reciever) with real Amazon listings found via search.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
Tallies servers/endpoints across all rooms and calls out the still-open
items (Linus Room's undecided line, the two unconfirmed Sound System
entries).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
Amir Alexander Abdelbaki