The floorplan on a wrist, rendering the same GET /floorplan/presence payload as
render/floorplan-3d. If the two ever disagree, one of them is lying.
An app rather than a face, because buttons decide it: watchfaces receive no
button events and Pebble restricts touch to apps, and cycling through rooms was
the point. That costs being the default screen, and it means the JS — therefore
the data — only lives while the app is open, so every launch begins with a
fetch. The last plan is persisted and drawn immediately WITH ITS AGE, then
repainted when the fetch lands: a spinner on a screen that already has something
true to say is worse than slightly stale truth, clearly labelled.
The screens
Plan: occupied rooms light, empty dark, and a dotted edge for rooms HA never
reports on — "nobody is in the study" and "nothing can see the study" are
different sentences. Occupancy reads in lightness, never hue, because colour
already means who. Fused positions are drawn where the person is; an
unattributed radar target is a hollow ring with no colour and no initial,
since every visual language here for a person is reserved for people the
system can name.
Detail: one room per screen, Up/Down wrapping at both ends, each person a
coloured dot plus their name. "Nobody here" is printed rather than left blank,
which reads as a fault. The last entry in the cycle is "Somewhere in the
house" — the people it cannot place are exactly who you picked the watch up
to find.
The wire format is the fragile part
One packed byte array, ~80 bytes for a three-room plan with names, written in
JS and read in C — two implementations of one format, in two languages, that
never run in the same process. Drift between them decodes as plausible-looking
garbage rather than as an error, so test/run-tests.sh builds a payload with the
real writer and decodes it with the real reader compiled against a stub SDK. It
also checks that a truncated payload is refused wholesale (half a plan looks
exactly like a whole one) and that a version mismatch is refused rather than
decoded.
That test earned itself immediately: it caught a disagreement about whether a
radar target in a room HA does not report should read as occupied or unknown.
The code was right — a positive detection outranks no-data — and the test's
expectation was wrong.
Unverified, and both are about the new hardware rather than the code: the Round
2's platform identifier, and its round-screen detection in the JS. Nothing
hardcodes a resolution, so both are one-line changes once the SDK names them.
It has never run on a watch, in an emulator, or against a real identity.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FanS1vyE2gLhGkqKq6HtYj
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
digest-engine grows from a single household digest into four per-person
sections, and gains the memory and inputs to make them worth reading.
Per-person sections. identity owns a digest_sections column per person,
edited in the admin panel and read by digest-engine at the start of every
run (GET /digest-preferences). A run generates the union the household
asked for: a section nobody wants costs no LLM call and no ingestion of
its sources. Each surface then filters to the person HA resolved. The
display half is a filter, not an access control, and says so.
Network is its own section, split out of household so the two can be
wanted separately.
Political section rebuilt around four questions (global class struggle,
organising in Vorarlberg, mid-term consequences, the International and
comrades' reports). ~30 international feeds added, each carrying owner
and bias, with a symmetric ownership analysis rather than a
reliability ranking; Zionist outlets get an explicit zero-trust rule that
is not inversion. RCI social/podcast ingestion (YouTube Atom, podcast RSS,
public Telegram via the existing session) feeds a watch-later window.
Globe markers carry summaries with fold-out sources; counter_run drops
citations whose URLs are not in the context.
Meeting agendas: a Tagesordnung arriving by mail or WhatsApp is matched to
its calendar event, read with pypdf, and its points extracted
mechanically. The political section owns the contents and derives
"Political todos"; the household section is told only that an agenda
exists, enforced structurally.
The archive keeps every ingested item and measured number across runs, so
trends may finally be stated with figures and dates attached.
ntfy push after each run, assembled from existing narrations, gated by the
same per-person sections.
identity gains GET /speaker: automatic recognition for the voice path from
BLE plus recent face sightings. Unresolved means show less, never ask, and
nothing displays a digest because someone walked past a screen.
OPNsense credentials move into CoreSystemConfig.json; thin clients gain a
Display switch (HDMI-CEC, DPMS fallback) so an empty room stops powering a
TV.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NpKsMV1Q2EHJ5cZVoLvK9M
Same tradeoff, weighted toward lamp life: ~4x life for ~30% less light,
with 95% noted as the fallback if it reads too dim in practice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
min_brightness was one line with no procedure. Setting it to 1 is wrong —
triacs stop latching reliably at very low phase angles, so it presents as
flicker rather than a dim glow. Document walking it down to instability
and backing off a step, since the usable floor is fixture-specific.
Also add max_brightness, which matters more: filament life goes roughly
as V^-13 against light as V^3.4, so running at 95% roughly doubles lamp
life for ~15% less output. Worth having on a fixture whose lamp type may
be discontinued.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drives an old ~250 W filament stage fixture from HA via the existing
Zigbee2MQTT backbone: a 400 W-rated dimmer module wired inline into a
Schuko extension lead, ~€25.
Leads with verifying the lamp, because the wattage decides between a €25
module and a €100 dimmer pack, and it's the one step here with real fire
risk. Documents the three stop conditions (discharge lamp, transformer,
cooling fan) and the escape hatch if the lamp turns out over 400 W.
Guidance only, matching the network-integration.md convention — nothing
in this repo touches the fixture or the pairing. The Z2M side needs no
config beyond permit-join, since setup-container-host.sh already sets
homeassistant: true, and pairings live in database.db, which the restic
backups cover.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TLS front door (Caddy) for this repo's own services: one hostname, a permanent
HTTP->HTTPS redirect, and the API on the same origin as the page. Home Assistant,
Grocy, Frigate and the rest keep their own ports — fronting HA brings its own
auth and websocket concerns and none of the problems below need it.
Three concrete reasons, not hygiene:
1. The admin panel's URL carries IDENTITY_TOKEN, which grants administrative
access to the person registry AND to the device grants that decide whether a
smart lock opens. On plain HTTP that is readable by anything on the smart-home
VLAN — a segment deliberately full of cheap IoT hardware.
2. getUserMedia requires a secure context, so register.html's camera cannot work
over http://192.168.x.x at all. It also failed SILENTLY: the call site used
`navigator.mediaDevices?.getUserMedia(...).then().catch()`, and optional
chaining short-circuits the whole chain — so neither handler ran, no "Camera
unavailable" message appeared, and registration proceeded photo-less with no
explanation. Verified in node. register.js now checks explicitly and says
which of the two cases it is; HTTPS is what actually fixes it.
3. Serving the page over HTTPS while ?api= still pointed at http://...:8097 would
have every call blocked as mixed content, so the API has to be proxied too.
tls: internal runs Caddy's own CA (no external dependency, works with no WAN at
all) with tools/export-proxy-ca.sh to fetch the root; tls: custom takes an
existing cert, which is how you'd use a real one from a DNS-01 challenge without
exposing anything. HSTS is deliberately not set — with an internal CA it would
turn a dismissible warning into a hard failure. Kiosks stay on plain HTTP for
now: a full-screen cert interstitial is not dismissible on a device with no
keyboard, so moving them is documented as a follow-up rather than done blind.
Empty service tokens now fill themselves in on the first build and land in
tokens.txt with what each is for. They are written BACK to the config, which is
the part that matters: a token is only useful because two machines agree on it,
so generating fresh randomness per build would produce a door panel that cannot
talk to the service it was built for. Blanks are filled once and never
overwritten. ha_token, mqtt_password, admin_password_hash and ssh_authorized_key
are deliberately not invented — tokens.txt lists them with the reason, so an
empty field is never a mystery.
32 new checks: token generation and stability across runs, disabled services
skipped, tokens.txt contents, config still valid after the rewrite, Caddyfile
routes and redirect, conditional pantry route, both TLS modes, and that the
derived admin URL keeps page and API on one origin. Nothing has been run against
a real Caddy — see proxy/README.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the oldest deferred item in the plan (open decision #22). /presence has
reported a best-effort `room` since Phase 6, but there was nothing to plot it
on: no floor plan, no room list, no coordinate format. The reason it stayed
deferred was sound — nothing here knows the shape of this flat, and inventing a
coordinate format against a guess would have been the wrong kind of work. So the
plan is DRAWN, by hand, in a new Floorplan tab.
Levels hold rooms; rooms are polygons (real rooms aren't rectangles) with an
optional background image to trace over. Click corners to draw, drag handles to
adjust. Each room maps to the HA area string /presence already reported, and the
editor offers a pick-list of the areas HA is actually reporting rather than
asking anyone to retype an area_id from Developer Tools — same anti-typo
reasoning as CoreSystemConfig.json. Tick "Show who's home" and occupied rooms
light up.
Coordinates are normalised 0-1 rather than pixels: the plan has to render on a
laptop now and possibly a wall panel later, and pixels would be right on exactly
one of them. The tradeoff is documented — replacing a background with one of a
different aspect ratio distorts existing rooms.
Two choices about failure worth calling out. A room with no HA area is legal and
labelled as such on the plan, because drawing the flat and wiring up presence are
separate jobs. And anyone who can't be placed — home with no room resolved, or
reporting an area no room claims — is listed under the plan, with unclaimed areas
named so you know what's left to draw. A floor plan that quietly lost people
would be worse than no floor plan.
The whole feature is still gated on AREA_ATTRIBUTE being right, which remains an
unconfirmed guess at what Bermuda publishes; every room can be drawn correctly
and still never light up. The editor makes that diagnosable rather than
mysterious, but can't fix it. Added to identity's verification list.
38 backend checks: level and room CRUD, polygon validation (too few points, out
of range, non-numeric, over the vertex cap), duplicate-area refusal, image
round-trip, the presence join including both unplaceable cases, area suggestions
degrading when HA is down, and cascade on level delete. The editor UI itself has
not been opened in a browser.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
arm64 was the last image in the household whose identity was typed in by hand
after building — Raspberry Pi Imager's OS Customisation dialog set the hostname
per unit at flash time. That's the exact step CoreSystemConfig.json exists to
remove, and it failed quietly when mistyped: spotify-connect-start reads
$(hostname) at service start, so a typo doesn't error, it just puts a Spotify
Connect device with the wrong room name in the picker.
The builder now substitutes the endpoint's hostname from the audio_endpoints
array into a generated copy of config/audio-endpoint.yaml and builds one image
per room, published like every other image as
iso-out/smarthome-<hostname>-<pairid>.img. The substitution is targeted rather
than a YAML round-trip: that template is mostly comments explaining an
unverified schema, and a load/dump would strip every one of them. It fails loudly
if it doesn't match exactly once, rather than shipping an image named after the
wrong room.
The cost is honest and documented: one full rpi-image-gen run per arm64 room,
qemu-emulated on an x86 builder, instead of one for all of them.
build.arm64_prebake: false restores the single generic image for households with
several arm64 rooms and a slow builder. Wi-Fi and SSH keys are still set in
Imager on arm64 either way — only the hostname moved into the build.
Also fixes the image-publishing search, which used `find -newer $BUILD_CONFIG`
and silently found nothing when the build finished within the same filesystem
timestamp granularity as the config write. Newest .img wins instead.
Resolves the per-room-identity asymmetry in project-plan Phase 15.5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renames the image output directory from build-output/ to iso-out/ (config
default, .gitignore, docs).
Also documents the asymmetry that showed up when building a household with
several endpoints: kiosks and amd64 audio endpoints get one image per array
entry, because their hostname is baked in at build time; the arm64 audio image
is generic and built once no matter how many arm64 rooms are listed, because Pi
Imager sets hostname and Wi-Fi per unit at flash time. That is project-plan
Phase 15.5's existing decision, now reflected in what build-all actually does
rather than only in prose.
Verified with a stubbed full run of a six-endpoint household: one build-all
invocation produced nine distinctly-named images with no overwrites.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Follow-up to the tools/ build system: the kiosk and amd64 audio-endpoint
builders left their ISO in the live-build tree under live-build's fixed
filename, and never moved it to build-output/. Configure two thin clients and
build-all would build both into the same path — the second silently overwriting
the first, leaving one ISO carrying the second room's hostname and no sign the
first was ever produced.
core_publish_image() now moves each finished image to
build-output/smarthome-<hostname>-<pairid>.iso, so one array entry produces one
artifact. Verified: two thin clients now yield two distinct ISOs, and the
per-type builders still refuse with the real list when the hostname is omitted
or wrong.
The arm64 audio endpoint is the deliberate exception and is now handled as one:
Pi Imager sets hostname/Wi-Fi per unit at flash time, so a single generic .img
serves every room and build-all builds it once regardless of how many arm64
entries are listed. amd64 has no equivalent for a generic x86 ISO, so it bakes
the hostname in and does need one per room (project-plan Phase 15.5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Installation was six scripts each carrying its own copy of the container host's
IP, three that had to agree on IDENTITY_TOKEN, and every service URL typed by
hand with a port in it. Any one could be wrong, and the symptom was always the
same and always late: an image that boots fine and then can't reach something,
found after a 40-minute build and a reboot.
Two properties fix that class of bug:
- Nothing is written twice. No script in tools/ contains an IP, port or token.
- Anything derivable is derived. You give the subnet prefix once and one last
octet per host; every address and service URL is computed from those.
THE TWINNED PAIR. container_host.ip_last_octet 12 and llm_host 13 mean the
container host's OLLAMA_HOST *is* http://<prefix>.13:11434 — computed in the
same build, not typed into two files and kept in sync. Move the LLM host to .21
and the container host's Ollama URL follows; change the subnet and both halves
move along with every kiosk's URLs. Neither image can be built pointing at an
address the other isn't using. Both carry the same SMARTHOME_PAIR_ID (a hash of
the config's meaning, not its bytes) so two USB sticks can be checked against
each other later.
validate-config.py runs before every build and refuses to start on an error, so
a mistake costs seconds not an hour. It catches duplicate ports (including the
music_assistant/pantry_vision 8095 clash that Compose can't see because MA runs
network_mode:host — open decision #31), both hosts on one address, duplicate
hostnames across kiosks and audio endpoints, placeholder tokens (checked before
the length check, so padding "changeme" to 32 chars doesn't pass), a private key
pasted where the public one goes, and a kiosk pointed at a disabled service.
build-all.sh is the normal entry point — the images are a set that has to agree
with itself, so building one is the exception. It builds the core pair, every
kiosk, and every audio endpoint including both architectures (amd64 live-build
ISO and arm64 rpi-image-gen img are different toolchains, not one image).
The two new host ISOs install unattended with everything burnt in, including
service env files generated from derived values — which permanently removes the
class of bug that had chores.env shipping IDENTITY_URL=http://127.0.0.1:8097.
setup-container-host.sh and setup-llm-host.sh now read every config value as
${VAR:-default} so the images configure them without editing.
That also makes every ISO a credential: Wi-Fi PSK, tokens, MQTT and HA
credentials are readable by anyone holding the stick. .gitignore covers the
filled-in CoreSystemConfig.json and build-output/.
Tested: 43 config validation/derivation checks and 44 builder checks against the
real code paths with only `lb` stubbed — every generated env file, preseed,
network config, first-boot unit and build stamp is verified, including that a
port collision refuses the build before writing anything. No ISO has been built;
`lb build` needs live-build, root and a long fetch. tools/README.md says so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two unchecked items from the README status list that were buildable in-repo
rather than blocked on hardware.
hosts/llm-host/ — Phase 3's LLM machine:
- Auto-detects gpu vs cpu tier (nvidia-smi must both exist AND succeed; a
leftover driver package on a machine whose card was pulled satisfies only
the first and would fail later at container start).
- Runs Ollama as a pinned container rather than curl|sh into a root shell,
matching how everything else here is deployed. Deliberately does NOT install
the GPU driver — the most hardware/kernel-specific step on that box.
- Sets OLLAMA_HOST=0.0.0.0 inside the container. Ollama binds loopback by
default, which in Docker means the published port forwards to nothing and
every caller sees a connection refused indistinguishable from "the host is
off" — and since every consumer here is built to tolerate exactly that, it
degrades silently. Same class of bug as chores' 127.0.0.1 env values.
- Takes a position on Ollama contention (open decision #4's resource half):
MAX_LOADED_MODELS=1 so a 14B text model and a vision model swap predictably
instead of thrashing VRAM or OOM-ing mid-request, NUM_PARALLEL=1 for
predictable Assist latency, KEEP_ALIVE=30m so a household that talks to
Assist a few times an hour isn't paying model-load cost every time.
- Documents that Ollama has NO authentication and its API can delete models,
not just generate — added to network-integration.md's port table, since the
network is the entire boundary.
docs/caldav-integration.md — Phase 8's notes:
- The four independent clients and their directions (digest-engine read-only,
chores' busy-check read-only, trash-calendar create-only under a UID-prefix
ownership invariant, HA's own bridge).
- Why they share one Nextcloud app password, and the two costs: rotation
touches three env files plus HA and fails quietly, and the read-only
invariant is a CODE property, not a permission boundary — an app password
can't be scoped read-only or per-calendar, so the server would not catch a
regression that started writing.
- The two traps worth knowing before debugging them: unexpanded recurrence
reporting a meeting on the day it was created, and CALDAV_VERIFY_TLS=false.
Neither has been run — no Debian machine, no GPU, no live Nextcloud. The script
is syntax-checked and its generated compose validated as YAML for both tiers;
that is the whole of the testing, and both READMEs say so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Records the networking decision behind Phase 6b's arrival notifications so it
doesn't get re-derived later.
ntfy stays LAN-only: identity -> ntfy is a container-to-container call that never
reaches OPNsense, and remote delivery rides a WireGuard split tunnel routing only
the smart-home VLAN. No DMZ, no port forward, no certificates, no inter-VLAN rule.
Both alternatives were weighed and rejected, with reasons recorded:
- DMZ + port forward buys only "notifications without the VPN connected," at the
cost of a public listener, TLS upkeep, and mandatory ntfy auth — an exposed
topic leaks "the house is empty right now".
- DMZ + NAT reflection does avoid a new inter-VLAN rule (the smart-home VLAN's
existing outbound-WAN allow already covers traffic to your own public IP), but
makes a purely internal path depend on the ISP and external DNS being up, so
two devices metres apart stop talking during a WAN outage. CGNAT breaks it
outright, and the rule it avoids was the safe direction anyway.
New §2.1 covers the split tunnel itself, including the trap that motivated it:
AllowedIPs must be the actual VLAN prefix, never 192.168.0.0/16, which collides
with typical café/hotel LANs and breaks the phone's connectivity there. Plus
always-on VPN yes / lockdown no, and no DNS= so queries aren't pulled home.
The household uses no Apple devices, which removes the only forcing function for
exposure (ntfy's iOS app needs APNs and therefore an upstream relay). Open
decision #37 closes as a household decision; the Apple case is kept as a
footnote in case that ever changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rides the same arrival transition the visit log is built from, so "arrived" has
exactly one definition in this service rather than two that could disagree.
- notify_on_arrival (default off) is the "if enabled" half: push me when someone
gets home. announce_arrivals (default ON) is a separate per-person opt-OUT of
being announced, for anyone who doesn't want their comings and goings
broadcast. The asymmetry is deliberate — if both defaulted off, ticking
"notify me" would look broken until everyone else opted in too.
- Per-person notify_topic falling back to NTFY_DEFAULT_TOPIC. Topics are
deduplicated, or a five-person household sharing one topic would get five
identical pushes per arrival. The arriver is never told about themselves;
subscribers who are away still are, since that's most of the point.
- The first sample after startup notifies nobody and establishes a baseline
instead — otherwise a restart after a gap would fire "X just got home" for
everyone already on the sofa. Costs one missed notification in that window.
- Face-recognition arrivals say "was just recognised at home", not "just got
home" — the signals aren't equally reliable and the reader should know which.
- Pushes are sent outside _db_lock and isolated from each other, so a hanging
ntfy can't stall request handling and one bad push can't swallow the rest.
- POST /people/<id>/test-notification, because the alternative way to find a
typo'd topic is to wait for someone to walk in and notice nothing happened.
identity itself never touches the WAN — it POSTs to the ntfy already in this
stack. Whether the push reaches a phone that's AWAY is a network question, and
docs/network-integration.md's existing answer (WireGuard in, never a
port-forward) applies unchanged; iOS can't do this locally at all, since ntfy's
iOS app needs APNs and therefore an upstream relay. Documented as a table.
Also fixes two pre-existing bugs found while wiring this up: chores' template
pointed IDENTITY_URL and NTFY_URL at 127.0.0.1, which inside that container is
the container itself. chores would have reached neither identity nor ntfy, and
done nothing at all — silently, since both paths fail soft by design. Deployed
chores.env files still carry the old values and need editing by hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Extends Phase 6's identity rather than adding a service — all of this is facts
about who someone is, already identity's job.
- admin.html/admin.js: manage people/guests, edit every field, prune, history,
access log. Deliberately not kiosk-shaped and not linked from any wall panel —
a panel anyone can walk up to shouldn't carry a "prune these people" button.
- Nicknames are an input alias only. /resolve accepts them; every payload also
carries speak_name (always the real name) and chores/ uses it for reminders.
A nickname colliding with anyone's name or nickname is refused; a spoken string
matching two people refuses with ambiguous_name rather than picking one.
- Visit history sampled from identity's own /presence. home:null writes nothing,
ever — an HA outage must not record a departure that didn't happen. Departures
need sustained absence (BLE flaps) and are stamped at the last time actually
seen. "With whom" is an interval-overlap query, not a second table.
- Pruning splits selecting from deleting: the filter fills the checkboxes, the
delete goes by explicit id, and the filter is never re-run at delete time.
- Device rights are an answer, never an action — identity stores grants and
answers GET /device-access; HA asks and HA acts. Deny is the default and the
only fallback. Grants can expire; every check is logged, denials included.
- Chore assignment prefers an assignee who's home but doesn't let an absent one
block the chore (CHORE_ASSIGNMENT_STRICT flips that). Litter still ignores
both exemption and assignment.
- Admin-added identifiers still enforce TRUSTED_ENTITY_PREFIXES; only the
"in range right now" check is relaxed, never the allowlist.
Resolves open decision #26; adds #34-37 for the new unknowns (DEPARTURE_GRACE_
SECONDS is untuned, the panel has never been opened in a browser).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 19: trash-calendar (Kennelbach ICS -> CalDAV) and transit (GTFS
departures + OpenTripPlanner-backed voice route planning, slow walking
speed assumed). Phase 20: Tapo camera integration via identity's new
Frigate face-recognition presence signal, and chores, a presence/
calendar-driven household task nudger ("I don't care who does it, as
long as it gets done") with a passive fairness tally, litter culprit
attribution, and per-person chore_exempt/chore_reminder_style settings
on identity.
Also: the HA integrations + hardware-monitoring catalogs, Music
Assistant wiring, docs/network-integration.md (OPNsense VLAN
segmentation, no WAN port-forwards), the ESPHome BLE-proxy firmware,
and RuView CSI-presence integration (github.com/ruvnet/ruview) with
household automations for sleep/distress/concurrent-vitals/bathroom-
occupancy — all flagged with their real unverified assumptions and
open decisions. Fixed two real port collisions surfaced while wiring
this in (OTP vs. zigbee2mqtt on 8080, Music Assistant vs. pantry-vision
on 8095).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
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
hosts/touch-panel/: a touch-driven Sway kiosk with a full Spotify GUI client
(Flathub), a dedicated Home Assistant Chromium kiosk window, a general web
browser, an always-on eww touch dock for app switching, an on-screen keyboard
(wvkbd), and touchpanel-agent giving HA/the LLM the same MQTT-mediated control
the thin client has.
hosts/kitchen-display/ + pantry-vision/: a camera-vision grocery cataloguing
endpoint for the fridge/pantry. The kiosk's browser captures a photo via
getUserMedia and sends it to the new pantry-vision service, which asks an
Ollama vision model to identify the item and estimate shelf life; the
proposal is always human-confirmed before being written into Grocy stock.
The same display shows inventory sorted by soonest-to-expire and Grocy's
recipes.
Wires ENABLE_PANTRY_VISION into setup-container-host.sh and documents both
phases in docs/project-plan.md and README.md, matching this project's
existing per-host hardware/software/guardrail/open-decision conventions.
Nothing here has been run against real hardware, a real camera, or a real
Grocy/vision-model instance — see each new README's verification list.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
Two additions:
- Thin client: an eww weather/clock overlay over the idle-gallery slideshow.
Time/date come from the local clock, weather from a new retained MQTT topic
(smarthome/weather/current) an HA automation has to publish — degrades to
clock-only if that never happens. idle-gallery.sh owns the overlay's
visibility, mirroring how fullscreen-watcher.sh already owns the
now-playing widget's.
- hosts/audio-endpoint/: headless, per-room-independent Spotify Connect
appliances for rooms without a thin client, no shared/synced stream. Two
build pipelines sharing one architecture-independent systemd
unit/wrapper: arm64 (Raspberry Pi + HiFiBerry Amp2) via rpi-image-gen
producing a real flashable .img, and amd64 (mini PC + USB DAC/amp) reusing
the thin client's own live-build toolchain stripped of its graphical/kiosk
stack. Both reuse the thin client's existing apt-first/documented-fallback
Spotify Connect install logic rather than reinventing it. rpi-image-gen's
exact config schema is flagged explicitly as unverified — no ARM build
environment was available to validate it against the real tool.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WgTwMqiho8DT6ue5S49WBP
Three additions to the thin-client/container-host stack:
- admin-canvas + admin-web (Phase 13): an on-demand display surface for the
sys-admin-llm, mirroring digest-engine/digest-web's write/read split but as
a small always-on token-gated write API instead of a scheduled job. New
"4:admin" thin-client workspace, MQTT button, and duplicated canvas-sdk with
stat/image/video/chart window kinds.
- ESPHome firmware for the Waveshare ESP32-S3-Touch-LCD-1.85C-V2 (Phase 14):
a voice satellite + round-display status screen, evaluated as a DIY
alternative to Home Assistant Voice PE. Media/cover-art always takes
priority over an idle weather/time/date cycle, with a voice-state
visualizer overlaid on top. On-device wake word (micro_wake_word) feeding
the existing Assist pipeline, per-room "media_player_entity_id" wiring
documented explicitly to avoid cross-room bleed. Validated with ESPHome's
own config validator; not yet flashed to real hardware.
- Capture-card ("receiver box") video source selection on the thin client: a
new "5:capture" workspace and HA select that dynamically enumerates
USB/PCIe capture cards (re-scanned periodically for hot-plug), launches
mpv against the chosen one, and unconditionally excludes the gesture-
control camera from the list to preserve its existing no-HA-entity
invariant.
Also fixes a pre-existing bug found along the way: digest-browser's pkill
pattern matched any --kiosk mpv/firefox process rather than its own, which
would have let the new admin-browser/capture-view scripts kill each other's
windows.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WgTwMqiho8DT6ue5S49WBP
Every generated document now goes through a second, independent Ollama call
(synth/counter_run.py) before anything is written to output/: it checks quotes,
figures, named theoretical connections, and cross-source correlations against
the exact context the original synthesis pass saw, dropping anything that
doesn't trace back to it. A quote the model claims is grounded also gets a
deterministic substring-search backstop, since that's the one claim type
checkable without trusting the verifying call's own word for it.
The verifier shares the same RCI-derived theoretical basis as the document
it's checking, not a neutral outside standard — its job is confirming the
underlying facts are real and the theory genuinely matches their structure,
not flagging correct Marxist analysis as unverifiable for being theoretical
rather than a bare fact.
Fails safe in one direction only: a document that can't be verified at all
(Ollama unreachable a second time) is kept but marked unverified, never
silently passed through unchecked and never blanked outright. A document that
fails entirely is replaced with an honest "withheld pending verification"
placeholder.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KPD1RhBsjdFKFLpMCLiVT6
Rewrites synth/prompts/political.md's editorial stance: prioritize material
economics (labour disputes, capital concentration, capital export, trade wars)
over horse-race/personality politics, curate and quote rather than summarize
everything, apply Marx's labour theory of value and Lenin's imperialism by
name when an entry's structure genuinely matches (e.g. a merger -> Lenin's
tendency towards monopoly), correlate findings across news/financial/traffic
data explicitly on the globe view, and add a hard anti-speculation rule so
every claim traces to something actually in the context.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KPD1RhBsjdFKFLpMCLiVT6
Implements both new subsystems from the project plan end to end:
- hosts/thin-client/: Debian live-build Sway kiosk image — greetd autologin,
wayvnc (replaces RDP, per open decision #1), thinclient-agent (HA MQTT
discovery + swaymsg control, the sole LLM-reachable surface), mpv/mpv-mpris,
spotifyd/Steam Link, minimal-chrome Firefox with uBlock Origin/SponsorBlock
preinstalled, a fullscreen-aware now-playing widget, persistent audio-output
selection, outbound RDP/VNC via Remmina, HA mobile-app text/pointer remote
control via ydotool, an optional opt-in gesture-control camera (MediaPipe
hand tracking, off by default at two independent gates), a maintenance-shell
keybind, a German default keymap, and an idle-timeout photo slideshow from a
new gallery SMB share on the container host.
- digest-engine/: quarter-daily LLM digest — email/Signal/Telegram/Discord/
WhatsApp ingestion (WhatsApp via a headful-Chromium bridge, opt-in, highest
risk), news (including RCI/marxist.com theoretical sources and a broad
mainstream/state-affiliated outlet list), financial indicators, flight/naval
traffic and an OPNsense Suricata-alerts summary as political-analysis
evidence, Grocy/CalDAV household ingestion, an evening-only recipe and
shopping-list suggestion from soon-to-expire stock, and a vendored
digest-canvas SDK (globe/window/glow) rendering compact and full views. A
digest that goes unviewed (no thin-client canvas display or voice playback)
is merged into the next run instead of being discarded, tracked via a
retained MQTT message on the shared broker.
Both are wired into hosts/container-host/scripts/setup-container-host.sh via
the existing ENABLE_X/X_BLOCK pattern, off by default. docs/project-plan.md and
README.md are updated to match; remaining open decisions and manual-
verification items are tracked in-repo (project-plan.md §4, digest-engine/
README.md, hosts/thin-client/README.md).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KPD1RhBsjdFKFLpMCLiVT6
Extends the container-host script to cover the rest of the Phase 1/9 stack
(README's outstanding checklist item) so a single Debian host setup gets
Home Assistant plus the full companion stack: automation glue, monitoring,
a dashboard, push notifications, container management, and optional
scheduled backups. Also fixes a stale comment referencing a network-attached
SLZB-06 coordinator when the plan and config target a USB CC2652P dongle.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
