Phase 1: content source of truth — 40 documents across six areas
Satisfies the Phase 1 Definition of Done: - content/ validates cleanly against the frozen schema. `make validate` reports OK: 40 document(s) validated, 0 violations. - Six areas exist, each with an L1 entry: ai-overview, platform-overview, edge-overview, products-overview, history-overview, about-overview. - All six areas have an L2 entry: ai-systems, platform-estate, edge-fleet, products-business, history-engagements, about-narrative. - 28 L3 artefact stubs under content/<area>/l3/. Every artefacts[].url in every document resolves to one of them; the validator proves there are no dangling references (and a deliberately broken copy exits 1). - Every metric value traces to a source line in the evidence notes or the approved metric set in reference/content-map.md (per-metric citations are recorded in the AUD-131 completion comment). - Every document carries confidence and last_verified=2026-10-26; the validator rejects a missing or non-canonical value. - docs/content-redaction.md records the redaction pass: identifiers, third party personal data, credentials and infrastructure detail excluded, with reasons, plus the two numbers that are reported rather than smoothed. Honesty positions held: 3 businesses active (12 adoptions over time), Where-Woof deployed and pre-market, failures kept in (edge-failures), no promotion of in-progress work to delivered. No site code, no templates, no CSS, no rendering (Phase 2).
This commit is contained in:
Documenter
65
content/edge/edge-fleet.md
Normal file
65
content/edge/edge-fleet.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
id: edge-fleet
|
||||
area: edge
|
||||
level: 2
|
||||
title: "Constrained devices · custom radio · and a record of what broke"
|
||||
claim: "Twenty or more edge nodes across nine zones and twenty automations — solar power · deep sleep · LoRa and hand-built Zigbee — reporting into one automation layer with voice control on top."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, LoRa, Zigbee, MQTT, Home Assistant, Snapcast, Pi, PIR, mmWave]
|
||||
metrics: [{label: "edge nodes", value: 20}, {label: "lighting zones", value: 9}, {label: "automations", value: 20}, {label: "hand-built Zigbee routers", value: 2}]
|
||||
artefacts: [{type: doc, label: "Edge architecture — power · radio · deep sleep", url: "content/edge/l3/edge-architecture.md"}, {type: doc, label: "LoRa irrigation under solar power", url: "content/edge/l3/edge-lora-sprinkler.md"}, {type: doc, label: "Hand-built Zigbee routers and lighting", url: "content/edge/l3/edge-zigbee.md"}, {type: doc, label: "Distributed audio — eight endpoints with ducking", url: "content/edge/l3/edge-snapcast.md"}, {type: doc, label: "Front door — vision · voice · and a rebuild", url: "content/edge/l3/edge-front-door.md"}, {type: doc, label: "Sensors and actuation", url: "content/edge/l3/edge-sensors.md"}, {type: doc, label: "The failures, kept in the record", url: "content/edge/l3/edge-failures.md"}]
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, iot, esp32, lora, zigbee, audio]
|
||||
---
|
||||
|
||||
# Constrained devices · custom radio · and a record of what broke
|
||||
|
||||
**Capability statement.** Devices that must run for months on a small battery, talk over radio that was chosen for range rather than convenience, and fail in ways that are visible. Twenty or more nodes, nine zones, twenty automations, and a voice layer on top of all of it.
|
||||
|
||||
## What is actually run
|
||||
|
||||
**Edge architecture.** Each node is designed around its power budget: a LiFePO battery with a solar controller where there is sun, deep sleep between wakes, and a wake source chosen per job. The sprinkler and the garden lights wake on radio rather than on a timer, so a command can arrive while the device is asleep.
|
||||
|
||||
**Radio.** Three links, each for a reason. LoRa for range and penetration on outdoor nodes — long enough to cover the garden and the shed without a repeater. Zigbee for the indoor lighting mesh, including two routers built by hand where the commercial mesh did not reach. Wi-Fi where a device is mains-powered and needs bandwidth, such as the audio endpoints and the camera path.
|
||||
|
||||
**Sensors and actuation.** PIR for movement, radar and mmWave for presence that a PIR cannot see — including a presence sensor built for a bathroom and a child's bedroom because the off-the-shelf options were wrong for the space. Relays and step-down converters for 240V loads, servos and a 16-channel PWM driver for mechanical jobs, solenoids for water, load cells for weight.
|
||||
|
||||
**Audio distribution.** Eight Snapcast endpoints on Pi hardware, fed by a Snapserver, with Spotify and a music server as sources. Every spoken announcement — automation notices, assistant replies, doorbell messages — plays across all eight endpoints with the music ducked underneath and restored afterwards.
|
||||
|
||||
**The automation layer.** Home Assistant holds the state and the routines; MQTT carries the messages. Nine lighting zones and twenty automations, with voice control on top, so a request spoken in one room is answered through the speakers in whichever room a person is standing.
|
||||
|
||||
**Cameras and vision.** The front door takes an image, logs it, has the image described, and speaks the result into the house before deciding what to do next. RFID tags on boxes and on trees resolve to records — inventory with prices for the boxes, care notes for the trees — written by an automation rather than typed by hand.
|
||||
|
||||
## Evidence
|
||||
|
||||
| Claim | Evidence | Artefact |
|
||||
|---|---|---|
|
||||
| Twenty or more nodes | Ten ESP32 devices · two hand-built Zigbee routers · eight Pi audio endpoints | [Edge architecture](l3/edge-architecture.md) |
|
||||
| Radio chosen per job | LoRa outdoors with radio wake from deep sleep; Zigbee indoors with hand-built routers | [Irrigation](l3/edge-lora-sprinkler.md) · [Zigbee](l3/edge-zigbee.md) |
|
||||
| Nine zones and twenty automations | Lighting zones and routines in the automation layer | [Zigbee and lighting](l3/edge-zigbee.md) |
|
||||
| Eight endpoints with ducking | Snapcast clients on Pi hardware with music lowered under speech | [Distributed audio](l3/edge-snapcast.md) |
|
||||
| Vision and voice at the door | Image capture · description · spoken response · two-way audio | [Front door](l3/edge-front-door.md) |
|
||||
| Failures are stated | Lizard feeder destroyed · garden cameras postponed · doorbell being rebuilt | [Failures](l3/edge-failures.md) |
|
||||
|
||||
## Trade-offs and limits
|
||||
|
||||
- **Power decides the design.** Deep sleep means a device is unreachable for most of its life, so every routine has to tolerate a node that is asleep. That constraint is why radio wake exists at all.
|
||||
- **Range over bandwidth.** LoRa is slow and payload-limited. It is chosen where a hundred bytes a day is enough and the alternative is a Wi-Fi access point in a garden bed.
|
||||
- **Some things are still manual.** The garden automation is partly manual — some watering and lighting is scheduled, some is a person turning something on. The page says which is which instead of implying full coverage.
|
||||
- **The failures cost money and are kept.** A lizard destroyed a feeder built for it. The garden cameras were postponed with the parts already bought. The doorbell is being rebuilt rather than declared finished. Those are the most honest evidence of production experience on this site.
|
||||
|
||||
## Drill-downs
|
||||
|
||||
- [Edge architecture — power · radio · deep sleep](l3/edge-architecture.md) — level 3
|
||||
- [LoRa irrigation under solar power](l3/edge-lora-sprinkler.md) — level 3
|
||||
- [Hand-built Zigbee routers and lighting](l3/edge-zigbee.md) — level 3
|
||||
- [Distributed audio — eight endpoints with ducking](l3/edge-snapcast.md) — level 3
|
||||
- [Front door — vision · voice · and a rebuild](l3/edge-front-door.md) — level 3
|
||||
- [Sensors and actuation](l3/edge-sensors.md) — level 3
|
||||
- [The failures, kept in the record](l3/edge-failures.md) — level 3
|
||||
|
||||
## Period and confidence
|
||||
|
||||
`period: 2020–`, anchored on the homelab year in the evidence notes. Confidence is `running` for the fleet as a whole; individual nodes carry their own label, and the ones being rebuilt or postponed are labelled that way on their pages.
|
||||
25
content/edge/edge-overview.md
Normal file
25
content/edge/edge-overview.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: edge-overview
|
||||
area: edge
|
||||
level: 1
|
||||
title: "Edge & Devices"
|
||||
claim: "Builds and maintains a twenty-node edge fleet — constrained devices · custom radio · solar power · deep sleep · and sensors — reporting into a single automation layer."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, LoRa, Zigbee, MQTT, Home Assistant, Snapcast, Raspberry Pi]
|
||||
metrics: [{label: "edge nodes", value: 20}, {label: "lighting zones", value: 9}, {label: "automations", value: 20}]
|
||||
artefacts: [{type: doc, label: "Edge architecture — power · radio · deep sleep", url: "content/edge/l3/edge-architecture.md"}, {type: doc, label: "The failures, kept in the record", url: "content/edge/l3/edge-failures.md"}, {type: doc, label: "Distributed audio — eight endpoints with ducking", url: "content/edge/l3/edge-snapcast.md"}]
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, iot, esp32, lora, zigbee]
|
||||
---
|
||||
|
||||
# Edge & Devices
|
||||
|
||||
**Claim.** Twenty or more nodes — ten ESP32 devices, two hand-built Zigbee routers and eight Pi audio endpoints — across nine lighting zones and twenty automations, all reporting into one automation layer.
|
||||
|
||||
**Status.** Running. Some of it is finished, some is being rebuilt, and at least one thing was destroyed by the animal it was built for. All three states are shown.
|
||||
|
||||
**Why it is credible.** These devices are outdoors, on solar, in deep sleep, and they must keep working when nobody is looking. The failures on this page cost real time and are documented as failures.
|
||||
|
||||
**Start here.** [The capability page](edge-fleet.md) covers the architecture, the radio, the audio and what broke.
|
||||
31
content/edge/l3/edge-architecture.md
Normal file
31
content/edge/l3/edge-architecture.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: edge-architecture
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — Edge architecture · power · radio · deep sleep"
|
||||
claim: "Each node is designed around its power budget — battery and solar · deep sleep between wakes · and a deliberate choice of wake source per job."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, LoRa, Zigbee, LiFePO, MQTT, Home Assistant]
|
||||
metrics: [{label: "edge nodes", value: 20}, {label: "ESP32 devices", value: 10}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, architecture, power, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Edge architecture · power · radio · deep sleep
|
||||
|
||||
**Status: stub.** One annotated diagram of a representative node and the radio path lands in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The per-node pattern: 240V step-down or solar with a LiFePO battery and charge controller, an ESP32 in deep sleep, a wake source (timer, radio, or a physical input), a relay or driver for the load, and an MQTT message into the automation layer. Around it, the reason each node uses LoRa, Zigbee or Wi-Fi.
|
||||
|
||||
## What it proves
|
||||
|
||||
Power budgeting and remote wake as design decisions, not hobby wiring — and an architecture that survived being repeated across twenty nodes.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: evidence notes section 1.
|
||||
39
content/edge/l3/edge-failures.md
Normal file
39
content/edge/l3/edge-failures.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: edge-failures
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — The failures · kept in the record"
|
||||
claim: "Three things did not go to plan — a feeder the animal destroyed · cameras postponed with the parts already bought · and a doorbell being rebuilt instead of declared finished."
|
||||
confidence: in-progress
|
||||
period: "2020–"
|
||||
tech: [ESP32, Servo, PWM, Camera]
|
||||
metrics: [{label: "crickets released per day by the feeder", value: 10}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, failures, artefact]
|
||||
---
|
||||
|
||||
# Artefact — The failures · kept in the record
|
||||
|
||||
**Status: in progress.** Two items are being rebuilt, one is postponed. The page is not finished because the work is not finished.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
A short, unpolished register of what did not work, in the order it broke.
|
||||
|
||||
**The lizard feeder.** Servo motors on a 16-channel PWM driver, rubber-band spring-loaded boxes, an ESP32 — one box opened per day to release ten crickets for the bearded dragon it was built for. The lizard attacked the boxes and destroyed the mechanism. Version one is abandoned; it is being rebuilt with plastic containers.
|
||||
|
||||
**The garden cameras.** Postponed. The parts have arrived and are sitting in a box. No photographs and no claim until they are installed.
|
||||
|
||||
**The front door.** Built, then found to greet people who were not at the door. It is being rebuilt with a time-of-flight ranging sensor rather than being described as complete.
|
||||
|
||||
**The garden automation.** Partly manual. Some of it runs on schedule and some of it is a person. Both are true and the page says so.
|
||||
|
||||
## What it proves
|
||||
|
||||
That this is a working estate and not a rendering: things break, budgets get spent on parts that are not installed yet, and hardware has to be designed around an animal's behaviour. Production experience is measured in rebuilds as much as in launches.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7, with photographs of the rebuilt feeder and the installed cameras if they exist by then. If they do not, the entry stays as written — labelled rather than deleted.
|
||||
35
content/edge/l3/edge-front-door.md
Normal file
35
content/edge/l3/edge-front-door.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: edge-front-door
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — Front door · vision · voice · and a rebuild"
|
||||
claim: "A doorbell that sees a person · describes the image · speaks to the house and to the visitor · and is currently being rebuilt with a time-of-flight sensor."
|
||||
confidence: in-progress
|
||||
period: "2020–"
|
||||
tech: [ESP32, ESP32-CAM, PIR, mmWave, VL53L0X, MiniMax, Piper, Whisper, Apprise]
|
||||
metrics: [{label: "voice engines in use", value: 2}, {label: "presence sensing inputs", value: "PIR · mmWave · time-of-flight"}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, doorbell, vision, voice, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Front door · vision · voice · and a rebuild
|
||||
|
||||
**Status: in progress.** The device was built and is being rebuilt. The page states this rather than describing it as finished.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
A door unit with microphone, speaker, camera, button, PIR and mmWave presence. It detects a person, captures an image, logs it, has the image described, and announces to the house who is at the door before offering a spoken greeting; the visitor's reply is captured and played over the house speakers, with an alert pushed to a phone. Voice output ran on one provider and now runs on a cloned voice with a fallback to a local synthesiser.
|
||||
|
||||
## What it proves
|
||||
|
||||
Vision, voice and actuation in one device under real constraints — latency that a person at a door will tolerate, and a failure mode that must be polite.
|
||||
|
||||
## Limits stated on the page
|
||||
|
||||
The measurement it is being rebuilt around: presence detection with a time-of-flight ranging sensor, to stop the unit greeting people who are walking past rather than standing at the door. Until the rebuild is finished the honest label is `in-progress`.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7 for photos and the sensor change. Source: evidence notes section 1.
|
||||
35
content/edge/l3/edge-lora-sprinkler.md
Normal file
35
content/edge/l3/edge-lora-sprinkler.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: edge-lora-sprinkler
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — LoRa irrigation under solar power"
|
||||
claim: "A solar-powered controller that sleeps · wakes on radio · and drives a solenoid — with the first version polling over a message queue instead."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, LoRa, LiFePO, Solenoid, Home Assistant, RabbitMQ]
|
||||
metrics: [{label: "major revisions", value: 2}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, lora, solar, irrigation, artefact]
|
||||
---
|
||||
|
||||
# Artefact — LoRa irrigation under solar power
|
||||
|
||||
**Status: stub.** The bill of materials and the wake-on-radio change land in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The build: solar panel, charge controller, LiFePO battery, ESP32, LoRa module, relay and solenoid valve. Version one woke on a schedule and polled through a message queue to learn whether it should run. Version two is better: a LoRa packet can wake the ESP32 from deep sleep and switch the valve directly, so on-time is short and the battery is not spent asking whether there is work.
|
||||
|
||||
## What it proves
|
||||
|
||||
Iteration on a real constraint. The first version worked; the second version was designed around the power cost of asking, which is the kind of decision you only make if you are watching the battery.
|
||||
|
||||
## Limits stated on the page
|
||||
|
||||
Watering is partly scheduled and partly a person. The routine lives in the automation layer and the voice assistant can trigger it, but the garden is not fully automatic and the page does not pretend otherwise.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: evidence notes section 1.
|
||||
31
content/edge/l3/edge-sensors.md
Normal file
31
content/edge/l3/edge-sensors.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: edge-sensors
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — Sensors and actuation"
|
||||
claim: "Movement · presence · weight · temperature · water and mechanical actuation — chosen per job and integrated into one automation layer."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, PIR, Radar, mmWave, Load cell, Servo, Solenoid, MQTT]
|
||||
metrics: [{label: "automations", value: 20}, {label: "PWM channels on the feeder driver", value: 16}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, sensors, actuation, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Sensors and actuation
|
||||
|
||||
**Status: stub.** A sensor and actuator table lands in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The parts list of the fleet in the way an engineer would want it: what is sensed, which device senses it, what is actuated, and how the decision reaches a physical action — a relay, a solenoid, a servo, a step-down converter switching 240V, a wheel that flicks food into a tank, an auger that dispenses it, a load cell that decides when to top up water.
|
||||
|
||||
## What it proves
|
||||
|
||||
Range across the awkward middle of embedded work: not just reading a sensor but choosing an actuator, sizing its driver, and making the whole loop recoverable when the network is absent.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: evidence notes section 1.
|
||||
31
content/edge/l3/edge-snapcast.md
Normal file
31
content/edge/l3/edge-snapcast.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: edge-snapcast
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — Distributed audio · eight endpoints with ducking"
|
||||
claim: "Eight synchronised endpoints with music ducked under every spoken announcement and restored afterwards — driven by Home Assistant and the voice assistant."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [Snapcast, Mopidy, Spotify, Raspberry Pi, Home Assistant]
|
||||
metrics: [{label: "audio endpoints", value: 8}, {label: "client hardware", value: "Pi 2W"}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, audio, snapcast, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Distributed audio · eight endpoints with ducking
|
||||
|
||||
**Status: stub.** The topology diagram and a short recording of ducking land in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
A Snapserver with eight Pi clients, Spotify and a local music server as sources, and one behaviour that matters more than the rest: when the house needs to speak, the music drops and the announcement plays everywhere, then the music returns to its previous level. Requests arrive by voice, so the same system that plays music is also the output for every automation and every answer.
|
||||
|
||||
## What it proves
|
||||
|
||||
Multi-room audio treated as infrastructure with a predictable interruption behaviour — and the difference between "the speakers work" and "the speakers can be interrupted safely". Mains-powered nodes, bandwidth-heavy work, and a state machine for volume: the opposite design constraints to the battery nodes.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: evidence notes section 1.
|
||||
31
content/edge/l3/edge-zigbee.md
Normal file
31
content/edge/l3/edge-zigbee.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: edge-zigbee
|
||||
area: edge
|
||||
level: 3
|
||||
title: "Artefact — Hand-built Zigbee routers and lighting"
|
||||
claim: "Two routers built by hand to extend an indoor mesh · feeding nine lighting zones with presence sensing and voice control."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [ESP32, Zigbee, Relay, PIR, Radar, Home Assistant]
|
||||
metrics: [{label: "hand-built Zigbee routers", value: 2}, {label: "lighting zones", value: 9}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [edge, zigbee, lighting, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Hand-built Zigbee routers and lighting
|
||||
|
||||
**Status: stub.** The router build and a zone map land in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
Two Zigbee routers on ESP32 hardware, built because the commercial mesh did not cover the house and a repeater would have been a black box. Behind them, nine lighting zones: custom presence sensors with PIR and radar for the bathroom and a child's bedroom, a central light controller with a readout and a potentiometer, and a three-button remote with a dial — click on, double click off, dial for level.
|
||||
|
||||
## What it proves
|
||||
|
||||
Mesh networking understood at the level where you can add a node instead of buying one, and lighting built for how a house is used rather than for a product category.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: evidence notes section 1.
|
||||
Reference in New Issue
Block a user