nth.io

mattertimectl

2026-07-29T00:00:00+00:00

TL;DR — mattertimectl</a> is a tiny, single-binary Matter controller that keeps device clocks correct. It joins an existing Matter fabric as an extra administrator and pushes the time through the standard Time Synchronization cluster, on any ecosystem, with no Home Assistant or extra hub required. </blockquote>
The problem: complex inconsistency</h2>
The IKEA ALPSTUGA air-quality monitor is actually mainly a little desk clock. But, it has no battery-backed clock inside so every power cycle resets it. Its as smart as a microwave clock. Matter luckily allows for Matter-based time sync so long as the controllers (Apple, Google, Amazon, etc.) support it.
Unfortunately not all of the major Matter controllers fully support time sync, and some not at all. It's a recurring complaint: who is responsible for restoring the time</a>, whether the device re-requests it after a reboot</a>, how to get ALPSTUGA time sync working over Thread</a>, and syncing Matter device clocks</a> in general.
It depends entirely on the hub</h3>
Whether a device ever gets the time back is decided by which hub it happens to be paired to:

IKEA's own DIRIGERA hub does it (and Homey Pro), re-pushing the time after every power-off. The common advice in those threads is, more or less, "buy a IKEA Dirigera hub."</li>
SmartThings is unreliable with some never get the clock back and there's no button to trigger a sync. Others say it eventually syncs but takes a long time.</li>
Apple Home apparently doesn't set the time at all.</li>
Home Assistant's built-in Matter integration can't write the time cluster in the first place, which is exactly why the cottage industry of fixes below exists.</li> </ul> The software fix is a pile of Home Assistant</h3>
When the hub doesn't do it, the answer today is Home Assistant plus glue. It started as a Python script that opens a WebSocket to HA's Matter Server and sends SetUTCTime</code>; that grew into acustom component</a> and a stack of automations people trade around, including gnarly ones that special-case the daylight-saving "duplicate hour" and rate-limit the flood of devices all reconnecting at once after an outage.
It works, and it's clever. But it's a lot of house to keep one clock correct. Running Home Assistant, its Matter Server add-on, a custom integration, an exposed WebSocket port, and a timezone-aware automation, all so a little display shows the right time.
And the time itself is genuinely fiddly</h3> The reason this keeps tripping people up is that the devices are picky about the write. The ALPSTUGA rejects SetUTCTime</code> unless it is handed Matter-epoch microseconds, the right granularity, and a time source. Time zone and DST are their own minefield: in those threads people hit ConstraintError (0x87)</code> the moment they use a non-European zone (Australia/Sydney, Asia/Tokyo, America/Toronto), and found that if the DST offset isn't set just right, the time zone is silently ignored. The solution: mattertimectl</h2> mattertimectl</a> is a single Rust binary that does this one job, correctly, on any Matter setup, without adopting a home-automation platform. It structured as a secondary controller which joins the devices' existing fabric as an additional Matter administrator (Matter "multi-admin") on its own fabric, and pushes the time through the standard cluster. The primary ecosystem (Apple Home, SmartThings, Google, etc.) keeps working untouched. mattertimectl is just one more admin on the fabric so it's ecosystem-agnostic by construction. Any time zone, not just European ones. DST offsets come straight from the IANA time-zone database, so they're correct for Sydney or Toronto the same as for Paris, and the DST list is bounded to what the device can actually store.</li> It speaks the device's language. Matter-epoch microseconds only at the wire, with the right granularity and time source, so the write is accepted, then it reads the clock back to confirm the device took it.</li> One binary, one job. No daemon, no database, no runtime. A ~3 MB binary and a small JSON config.</li> Runs from a timer. Each run connects, sets the clock, verifies, and exits; a systemd timer fires it hourly, and staleness is bounded by the interval.</li> Safe by default. It won't push time unless the host's own clock is NTP-trusted.</li> Thread without the baggage. No Thread radio, no border router of its own, and no BLE; it reaches Thread devices over IPv6 through the border routers already on the network (ex: HomePods, an Apple TV, etc.).</li> </ul> Since it's a simple binary, it can be run from MacOS as a one off as well. It builds and runs on Linux and macOS today. Because it's already a small, single-purpose binary with a tiny state footprint, a natural next step is a port to the ESP32, so the whole job could fit on a cheap microcontroller instead of a Raspberry Pi. Using it</h2> Commission each device once, inside a pairing window opened in the primary app, then let a timer drive it: sudo -u mattertimectl mattertimectl commission <pairing-code> sudo systemctl enable --now mattertimectl.timer</code></pre> That's the whole setup. The ALPSTUGA gets the right time a couple of minutes after boot and every hour after, with nothing left to think about. It's built on rs-matter</a>, the official CSA Rust Matter stack. Source is at src.nth.io/luke/mattertimectl</a> (with a GitHub mirror</a>), and prebuilt aarch64 Linux and macOS binaries are on the releases page.



ESP32 Ethernet Display
2026-07-18T00:00:00+00:00
</a></p>
src code</a> - README</a></p>
Intro</h2>
The problem</h3>
My front door has no window or peephole so when the doorbell rings I have to pull out my phone and open the Unifi
Protect app. Unifi sells a wall display for this, the Unifi Access Intercom
Viewer</a> at $199, but it's built
for the Unifi Access</em> ecosystem and won't display generic Protect cameras or doorbells like the Doorbell Lite I have.</p>
A partial fix: Apple TV</h3>
The Apple TV actually pops up a live camera feed when a doorbell rings or motion is detected but the Apple TV has to be
on for this and it's specific to Apple. The Unifi Protect accessories are bridged into Apple Home through Scrypted. I
want that same glanceable doorbell view in other parts of the house whether or not the TV is on.</p>
The prototype</h3>
I built the first version as a Raspberry Pi Unifi Protect doorbell
viewport</a> but it was a prototype running on a full Linux
computer, running mpv</code>, a Python daemon speaking Unifi Protect's WebSocket protocol, and a stack of Raspberry Pi
display quirks (fkms</code> connector names, fbcon</code> holding the DRM device, hardware decode segfaults) held together with
Ansible.</p>
ESP32 Solution</h2>
I set out to build a more robust solution on an ESP32 devboard with the same screen I used with the RPI.</p>
The display knows nothing</h3>
The RPI version handled a lot of logic on the display device. It authenticated against Unifi Protect, had to know the
doorbell's camera ID, and how to parse a proprietary WebSocket event stream, pull an RTSP feed, decode H.264, and rotate
video to portrait.</p>
When I rebuilt it as the esp32-poe-scrypted-viewport</code></a> appliance,
I moved as many of those concerns off the device and into Scrypted</a> as practical. Scrypted
handles authentication, camera selection, video decoding, scaling, rotation, overlays, and layout. It renders finished
pixels and pushes them to the display. The display just paints them and reports when the touchscreen is tapped.</p>
The whole design follows from one rule:</p>

If it changes what</strong> should be shown, it belongs in the controller (Scrypted). If it changes how</strong> pixels reach
the screen, it belongs in the display (ESP32).</p>
</blockquote>
The hardware</h3>
The hardware appliance is a Waveshare ESP32-P4-ETH</a> driving a Hosyond 5"
800×480 IPS touchscreen</a> over MIPI-DSI.</p>
</a></p>
The ESP32-P4 is an awesome fit, and unusually for an ESP32 it has no Wi-Fi at all</strong>. For a permanently mounted
appliance I see that as a feature:</p>

Ethernet, with optional PoE.</strong> A single cable, and with PoE it carries power too. No batteries, no Wi-Fi
credentials, no wireless coverage worries. Plug it into a trusted VLAN and it works.</li>
Hardware JPEG decode.</strong> The P4 has a dedicated JPEG engine, so the controller can push compressed frames and the
display decodes them without touching the CPU.</li>
MIPI-DSI + PSRAM.</strong> Enough memory bandwidth to triple-buffer a real display and paint full-motion video tear-free.</li>
</ul>
The device boots, pulls a DHCP lease, advertises itself over mDNS (_scrypted-viewport._tcp</code>), and waits. It has no
configuration UI, no authentication, and no business logic. All configuration is pushed to it by the controller after
discovery.</p>
Plug and play</h3>
A key design goal is that this is built for a plain trusted residential network. Onboarding a display is simply plugging
in one Ethernet cable:</p>

Plug in.</strong> PoE is optional, the architecture only needs Ethernet, but with a cable already run to the wall, one drop
carrying power and data beats a separate USB adapter.</li>
Get an address.</strong> The display pulls a DHCP lease the moment the link comes up.</li>
Announce itself.</strong> It publishes an mDNS service (_scrypted-viewport._tcp</code>) advertising its name, address, and
capabilities.</li>
Get discovered.</strong> Controllers browse for that service, pick the display up automatically, and push it its
configuration. Nothing is typed into the device.</li>
</ul>
That's the whole setup. There's no companion app, no BLE pairing, no QR code scanning, no handing over Wi-Fi
credentials, and no Thread commissioning. To be clear, NFC or BLE provisioning is genuinely great for devices that mesh
wirelessly. But a wired display just doesn't need to be that complex on a trusted wired network.</p>
Enclosure</h3>
I designed a flush-mounted, single cable, roughly the footprint of the standard light switch wallplates. The enclosure
is a two-piece 3D-printed design built around a standard electrical single-gang rough-in.</p>
</a></p>

Bracket.</strong> A base that fits over a standard 1-gang low-voltage mounting box</strong>. The ESP32-P4-ETH board tucks neatly
inside the wall cavity behind it so the only thing outside the wall is the display screen.</li>
Screen carrier.</strong> A separate front bracket that holds the 5" panel and has a dovetail on its back</strong> to mate with
the mounting bracket. The carrier slides down over a matching dovetail on the bracket, locking the screen to the wall
while keeping the board and cabling fully concealed behind it.</li>
</ul>
The protocol</h3>
The display's network API is intentionally tiny. It exposes a handful of HTTP endpoints and one raw TCP socket, and
everything is pushed to</em> it:</p>

POST /frame</code></strong> — paint a single JPEG. This is the whole interaction for still content: a calendar, a weather panel,
a dashboard. Render a picture, POST it, tap-to-view.</li>
A raw TCP stream socket</strong> — for live content, the controller opens a socket and pushes framed MJPEG straight at the
panel with no per-frame HTTP overhead. This is how doorbell video gets to 24 fps.</li>
POST /state</code></strong> — wake or sleep. The backlight is fully off when idle, and the controller wakes it when something's
worth showing.</li>
POST /config</code></strong> — the controller pushes name, orientation, brightness, and its own callback URL after discovery.
Nothing is typed into the device.</li>
</ul>
Note:</strong> As of the time of writing this, no ESP32 chip has hardware H.264 decode (though the P4 does</em> have H.264
encode) which is why I went with MJPEG.</p>
Touch goes the other way: a tap toggles wake/sleep and the device POSTs the resulting state back to the controller as a
peer, not a request/response. The display owns its own state, and the controller and the display are symmetric peers
that each serialize their own writes and trust idempotency to converge. There's no auth and no TLS. It's a LAN-only
appliance on a trusted VLAN, just like the trust model of a networked printer.</p>
The key property: the display performs virtually no translation.</strong> It renders pixels to the framebuffer and reports
taps. Whether those pixels are a live doorbell or a static dashboard is entirely the controller's concern.</p>
The ESP32-P4 firmware: zero-copy and tear-free</h3>
Keeping a 5-inch panel fed at 24 fps on a microcontroller comes down to two rules: never copy a frame, and never block
the network. The firmware meets both with two three-buffer rings and a single pass through memory. Each JPEG is read off
the socket into the network ring</strong>, decoded once by the P4's hardware JPEG engine straight into a framebuffer ring</strong>
that the panel scans out of, and never copied again. The network ring keeps the socket draining on its own core while
the decoder works on the other; the framebuffer ring lets the decoder write directly into display memory, so presenting
a finished frame is a pointer swap rather than a memcpy</code>.</p>
Draining the socket.</strong> The raw TCP stream lands on a dedicated FreeRTOS receive task whose only job is to drain the
socket continuously. It hands each JPEG to a separate decode task through a three-buffer PSRAM ring: the receive task
fills one buffer, the decode task works on a second, and the third is either free or holds the next frame waiting
between them. The receive task never blocks on the decoder, and if decode ever falls behind, the ring keeps only the
newest frame and drops the stale one. Old unrendered frames are just dropped. An earlier single-task version that did
recv</code>, decode, and paint in one loop stalled the socket for a few milliseconds every frame, which throttled the sender
into a stop-and-go crawl against the small default TCP window. Splitting receive from decode was the change that
unlocked the full frame rate.</p>
Painting without a copy.</strong> The hardware JPEG engine decodes straight into one of three DSI framebuffers that the
display controller owns. There is no separate decoder output buffer and no memcpy anywhere: presenting a frame is a
cache writeback plus a pointer swap, on the order of tens of microseconds. That swap is deferred, though. The DSI DMA
only picks up the new buffer at the end of the scan pass it is in the middle of, roughly every 21 ms. With only two
buffers, decoding the next frame immediately would write into the buffer the DMA is still reading out, and the result
tears. So the three framebuffers rotate through three roles, scanning (the DMA is reading it), pending (flipped, shown
at the next boundary), and free, and the decoder is always handed the free one. The firmware tracks which buffer is
scanning from the display driver's end-of-refresh interrupt, so a safe decode target always exists. The result is
tear-free by construction with no waiting on vsync, at the cost of one extra 1.15 MB framebuffer in PSRAM.</p>
Where the time goes.</strong> With both rings in place the per-frame budget is lopsided in the right direction. Receiving the
JPEG off the wire is about 70% of each frame, the hardware decode is about 25%, and the actual paint is under a fifth of
a percent. The decode-and-paint stage sits idle most of the time. The wire, not the display, sets the pace, which is the
right bottleneck for a device whose whole job is to render whatever a controller sends.</p>
The Unifi Protect cameras are natively 24fps, the 100mbps ethernet, the 5" screen size and medium resolution, all kind
of luckily worked out to have no real bottlenecks. The full pipeline works well at full 24fps. I suspect a higher
resolution, a larger screen, etc. would cause lower framerates.</p>
Scrypted and doorbell video</h3>
The first concrete controller is a Scrypted</a> integration
(scrypted/scrypted-viewport.ts</code></a> in the repo). Scrypted already
knows how to talk to Unifi Protect, and dozens of other camera systems, so instead of teaching the display about
cameras, I taught Scrypted about displays.</p>
</a></p>
On a doorbell press or camera motion event, Scrypted wakes the display, spawns one ffmpeg</code> child that pulls the
camera's prebuffered substream, scales and rotates it to the panel's native resolution, and streams framed MJPEG over
the raw TCP socket.  Opening ffmpeg</code> on an already-buffered keyframe is what cuts wake-to-first-frame from ~5–6 seconds
down to about 0.7 seconds. One catch: Scrypted's rebroadcast prebuffer is only enabled on the high-resolution stream by
default, and the display pulls the medium substream, so prebuffering has to be turned on for the medium stream too.
Without it the fast start silently falls back to a cold ~5–6 second open.</strong></p>
On the wire it sustains painted = sent = 24 fps</strong> with sub-50 ms glass-to-glass latency, the source frame rate rather
than the device being the limit.</p>
Compared to the Pi prototype this is dramatically simpler on the display device</em>: no mpv</code>, no RTSP parsing, no Protect
WebSocket handling, no software H.264 decode, no OS. All of that complexity moved to Scrypted, where it belongs and
where it's shared across every display.</p>
A hardwired path</h3>
There's a compounding benefit once the whole chain is wired. My cameras and doorbell are PoE, the Apple TV is on
Ethernet, and the displays are PoE. When an event occurs, a doorbell press or motion at a side gate, there's no wireless
hop anywhere between the sensor and the glass. The stream is already prebuffered on a wired NVR and it lands on a wired
display across a wired switch, so it loads instantly instead of stalling the way a Wi-Fi camera feeding a Wi-Fi tablet
does. Latency and reliability stop being things I think about, because there's no radio in the path to be congested,
roamed off of, or dropped.</p>


Emacs claude-code-context.el
2026-04-26T00:00:00+00:00
I like to use Claude Code in my terminal Ghostty</a> alongside Emacs. Claude can already read and
edit files directly, and Emacs auto-reverts when it does. But Claude doesn't know my buffer state like which file I have
open, which line im at, and what I have highlighted.</p>
claude-code-context</a>
(github</a>) does just that.</p>
How It Works</h2>
The package runs an idle timer that writes your current buffer state to a JSON file every 2 seconds:</p>
{</span></span>
  "</span>buffer</span>"</span>:</span> "</span>/Users/luke/project/src/main.py</span>"</span>,</span></span>
  "</span>line</span>"</span>:</span> 42</span>,</span></span>
  "</span>column</span>"</span>:</span> 8</span>,</span></span>
  "</span>modified</span>"</span>:</span> false</span>,</span></span>
  "</span>selection</span>"</span>:</span> "</span>def process_data(items):</span>\n</span>    return [x * 2 for x in items]</span>"</span></span>
}</span></span></code></pre>
A UserPromptSubmit</code> hook in Claude Code's ~/.claude/settings.json</code> injects that file into every prompt automatically.
Claude sees your cursor position and active selection without you having to copy-paste anything.</p>
It works in both file buffers and transient buffers like *Messages*</code> and *compilation*</code>.</p>
The timer only fires when Emacs is idle so there's no performance impact during active editing. Use C-c C-l d</code> to
optionally append flymake diagnostics so Claude can see specific errors. All commands are also available manually for
full control without the timer.</p>
Setup</h2>
(</span>add-to-list</span> '</span>load-path</span> "</span>/path/to/claude-code-context</span>"</span>)</span></span>
(</span>require</span> '</span>claude-code-context</span>)</span></span>
(</span>claude-code-context-mode </span>1</span>)</span></span></code></pre>
Add to ~/.claude/settings.json</code>:</p>
{</span></span>
  "</span>hooks</span>"</span>:</span> {</span></span>
    "</span>UserPromptSubmit</span>"</span>:</span> [</span>{</span></span>
      "</span>hooks</span>"</span>:</span> [</span>{</span></span>
        "</span>type</span>"</span>:</span> "</span>command</span>"</span>,</span></span>
        "</span>command</span>"</span>:</span> "</span>CONTEXT_FILE=</span>\"</span>${XDG_CONFIG_HOME:-$HOME/.config}/emacs/claude-code-context.json</span>\"</span>; [ -f </span>\"</span>$CONTEXT_FILE</span>\"</span> ] || CONTEXT_FILE=</span>\"</span>$HOME/.emacs.d/claude-code-context.json</span>\"</span>; if [ -f </span>\"</span>$CONTEXT_FILE</span>\"</span> ]; then echo </span>\"</span>\\</span>n---</span>\\</span>n## Emacs Context</span>\\</span>n</span>\"</span>; cat </span>\"</span>$CONTEXT_FILE</span>\"</span>; echo </span>\"</span>\\</span>n---</span>\"</span>; fi</span>"</span></span>
      }</span>]</span></span>
    }</span>]</span></span>
  }</span></span>
}</span></span></code></pre>
The hook detects both ~/.config/emacs</code> (XDG) and traditional ~/.emacs.d</code> automatically.</p>
Keybindings</h2>
Key</th> Action</th></tr></thead>

C-c C-l u</code></td> Manually update context</td></tr>
C-c C-l d</code></td> Include flymake diagnostics</td></tr>
C-c C-l c</code></td> Clear context</td></tr>
C-c C-l m</code></td> Toggle auto-update mode</td></tr>
</tbody></table>
The package is submitted to MELPA</a>.</p>


Raspberry Pi Unifi Protect Viewport
2026-04-18T00:00:00+00:00
</a></p>
The Problem</h2>
My front door doesn't have a peephole so when someone rings the doorbell, you can't see who it is without pulling out
your phone and looking at the doorbell app. Unifi makes a doorbell viewer device, the Unifi Access Intercom
Viewer</a> for $199. It's a PoE wall
display for viewing Protect cameras and intercoms but it's designed for the Unifi Access ecosystem and don't work with
their doorbells. For a home with a standard Protect doorbell, like mine, it's not really an option as it requires
something like the G6 Entry</a> for $249 to work natively. Standard
Protect doorbells like the Doorbell Lite aren't compatible. If you're not running a full Unifi Access deployment,
there's no path to a dedicated viewer leaving me to build one.</p>
</th> Unifi stack</th> This build</th></tr></thead>

Doorbell</strong></td> G6 Entry ($249)</td> Doorbell Lite ($99)</td></tr>
Display</strong></td> Intercom Viewer ($199)</td> DIY screen ($125)</td></tr>
Total</strong></td> $448</strong></td> $224</strong></td></tr>
</tbody></table>
Beyond the cost, Unifi Protect sends push notifications to the app when someone rings, but I wanted something more
immediate and passive: a dedicated display near the door that shows live video when someone rings without needing to
pull out a phone. Something closer to a traditional peephole or intercom panel that's always there and requires no
interaction.</p>
My design constraints were:</p>

No Home Assistant or Scrypted, just native Unifi Protect</li>
No browser-based playback</li>
No backlight when idle. The screen must be completely off when not in use.</li>
</ul>
Hardware</h2>
Component</th> Price</th></tr></thead>

Unifi Doorbell Lite</a></td> $99.00</td></tr>
Raspberry Pi 4</a></td> $55.00</td></tr>
Raspberry Pi PoE+ HAT</a></td> $34.99</td></tr>
Hosyond 5" DSI Touchscreen</a></td> $34.99</td></tr>
Total</strong></td> $224</strong></td></tr>
</tbody></table>
I already had the RPI4 and POE hat from another project so prices are likely higher now due to AI-driven RAM demand. The
display connects over DSI for video and USB for touch input. Mounted portrait, the logical resolution is 480×800 with
system-level rotation applied via mpv. The PoE HAT powers the Pi directly from the wall switch, keeping the cable run to
a single Ethernet drop.</p>
</a></p>
</a></p>
Software Stack</h2>
Layer</th> Choice</th> Reason</th></tr></thead>

Rendering</td> DRM/KMS (fkms)</td> No X11; framebuffer direct to DSI display</td></tr>
Player</td> mpv --vo=drm</code></td> Low-latency RTSP, software decode, no display server</td></tr>
Backlight</td> sysfs /sys/class/backlight</code></td> Kills backlight entirely without disrupting DRM</td></tr>
Touch input</td> evdev</td> Direct kernel input, no display server required</td></tr>
Doorbell events</td> Unifi Protect WebSocket</td> Native Protect API, no polling</td></tr>
Daemon</td> Python 3 asyncio</td> Clean state machine, concurrent event handling</td></tr>
Supervision</td> systemd</td> Start on boot, auto-restart, journald logging</td></tr>
Config</td> Ansible</td> Auto-deployable with no compiling or binaries</td></tr>
</tbody></table>
State Machine</h2>
The daemon has two states: IDLE</strong> and ACTIVE</strong>.</p>
IDLE:   screen backlight OFF, no playback, waiting for triggers</span></span>
ACTIVE: screen ON, live RTSP stream playing, 45s sliding timeout</span></span></code></pre>
State transitions:</p>

Doorbell press</strong> → IDLE becomes ACTIVE (or resets the 45s timer if already ACTIVE)</li>
Touch while IDLE</strong> → becomes ACTIVE</li>
Touch while ACTIVE</strong> → immediately stops playback and turns screen off</li>
45s timeout</strong> → stops playback, turns screen off, returns to IDLE</li>
</ul>
Backlight Control</h2>
The hardest constraint was "completely dark when idle." A black framebuffer isn't sufficient because the backlight is
still on. The daemon controls brightness exclusively through sysfs:</p>
/sys/class/backlight/rpi_backlight/brightness</span></span></code></pre>
Writing 0</code> kills the backlight entirely. Writing max_brightness</code> restores it. This approach has two key properties: it
doesn't interfere with the DRM/KMS rendering pipeline (unlike vcgencmd display_power</code>, which resets DRM planes and
breaks video output), and it works without root because the Ansible role adds a udev rule granting the video</code> group
write access to the brightness file.</p>
The fkms</code> driver exposes the DSI panel as the DSI-1</code> connector. mpv</code> is configured with --drm-connector=DSI-1</code> so it
targets the correct display without needing to guess device indices.</p>
Unifi Protect Integration</h2>
The daemon authenticates directly against Unifi Protect's local API (no cloud) and holds a persistent WebSocket
connection to the event stream. It filters for ring</code> events on the configured camera ID and ignores motion events
entirely.</p>
One nuance is Protect's WebSocket can deliver multiple binary-framed packets concatenated in a single message. A naive
implementation that reads only the first packet per message will silently drop events. The daemon loops through the full
payload, extracting each packet until the buffer is exhausted.</p>
Each packet has an 8-byte header:</p>
[packet_type: 1B][payload_format: 1B][compression: 1B][unused: 1B][payload_size: 4B]</span></span></code></pre>
Payload format 1</code> is JSON (action/data frames). Compression flag 1</code> means zlib-deflate. Ring events appear in action
frames with action: "add"</code> and modelKey: "event"</code>, and in the corresponding data frame with type: "ring"</code>.</p>
Connection handling is automatic reconnect with exponential backoff, no manual intervention required after a network
disruption.</p>
Video Playback</h2>
mpv</code> plays the RTSP stream from Unifi Protect in fullscreen DRM/KMS mode with no window chrome. On the RPi4 with the
fkms driver, hardware decode via V4L2M2M causes segfaults, so the daemon uses --hwdec=no</code> and software H.264 decode
which is fast enough for a 480p stream on a Pi 4.</p>
The stream starts fresh on each ACTIVE transition as a cold start. mpv</code> is launched as a subprocess and the daemon
waits for it to exit before returning to IDLE, whether from timeout, touch dismiss, or signal.</p>
A few mpv</code> flags that matter:</p>
--vo=drm --drm-connector=DSI-1</span></span>
--video-rotate=270          # portrait orientation</span></span>
--hwdec=no                  # software decode required on fkms</span></span>
--cache=yes --demuxer-max-bytes=1M</span></span>
--loop=no                   # never replay cached content</span></span>
--fullscreen --no-border --no-osc</span></span></code></pre>Touch Input</h2>
Touch events are read via evdev</code>. The daemon discovers the touch device dynamically by scanning all input devices and
matching on multitouch capability (ABS_MT_POSITION_X</code>) and BTN_TOUCH</code> but not on /dev/input/event*</code> index, which can
shift after reboot. An optional name-match pattern (unifi_protect_viewport_touch_match</code>) lets you pin to a specific
device if multiple touch devices are present.</p>
Ansible Role</h2>
The entire deployment is
ansible-roles/unifi-protect-viewport</code></a>. A single
ansible-playbook</code> run on a fresh Ubuntu Server image:</p>

Creates a unifi-protect-viewport</code> system user with video</code>, input</code>, render</code>, and tty</code> groups</li>
Installs mpv</code>, python3-evdev</code>, python3-requests</code>, python3-websockets</code></li>
Writes the daemon binary, systemd service, and environment file from templates</li>
Adds a udev</code> rule granting the service user write access to the sysfs backlight</li>
Configures fbcon=map:99</code> in cmdline.txt</code> to free the DRM device from the framebuffer console</li>
Enables dtoverlay=vc4-fkms-v3d</code> for the DSI connector</li>
Optionally configures PoE HAT fan temperature thresholds</li>
Enables and starts the service</li>
</ol>
Debug Tool</h2>
The deployed system includes unifi-protect-viewport-debug</code> for testing without ringing the actual doorbell:</p>
unifi-protect-viewport-debug</span> show</span>          #</span> turn display on</span></span>
unifi-protect-viewport-debug</span> hide</span>          #</span> turn display off</span></span>
unifi-protect-viewport-debug</span> test-display</span>  #</span> cycle backlight off -> 3s -> on</span></span>
unifi-protect-viewport-debug</span> test-touch</span>    #</span> list evdev touch devices and capabilities</span></span>
unifi-protect-viewport-debug</span> test-stream</span>   #</span> fetch RTSP URL and play via mpv</span></span>
unifi-protect-viewport-debug</span> test-protect</span>  #</span> verify Protect API auth and camera info</span></span></code></pre>Bringup Notes</h2>
A few things that weren't obvious during hardware bring-up:</p>


fbcon holds the DRM device.</strong> Without fbcon=map:99</code> in cmdline.txt</code>, the framebuffer console claims the DRM device
and mpv exits with rc=2 (device busy). The kernel parameter redirects fbcon to a nonexistent VT, freeing card0 for mpv.</p>
</li>

fkms uses DSI-1, not HDMI-A-1.</strong> The firmware KMS driver uses different connector names than full KMS. Getting this
wrong means mpv opens /dev/dri/card0</code> but outputs to nothing.</p>
</li>

vcgencmd display_power resets DRM planes.</strong> Using it to blank the display tears down the rendering pipeline,
breaking subsequent mpv output. Sysfs brightness control avoids this entirely.</p>
</li>

Hardware decode segfaults on fkms.</strong> V4L2M2M hardware decode crashes mpv on the Pi 4 with the firmware KMS
driver. --hwdec=no</code> is required. Software decode handles 480p without issue.</p>
</li>

Protect WebSocket is multi-packet.</strong> A single WebSocket message may contain multiple concatenated binary
packets. Reading only the first will silently drop ring events that arrive bundled with other packets.</p>
</li>
</ul>
Conclusion</h2>
The system boots to idle with the screen fully dark within a few seconds of the Pi coming up. A doorbell press to live
video with one to two seconds for the RTSP stream to begin rendering. The display stays dark under normal conditions.</p>
Compared to the ESP32 HomeKit intercom</a> (which handles the legacy building buzzer and lock),
this system handles the newer Unifi PoE doorbell. The two projects complement each other with the ESP32 handles the
1970s wired intercom hardware and the Pi viewport handles the modern networked camera.</p>
Next up is designing a custom one-gang low voltage bracket mount to make the device look like a proper wall panel that's
flush-mounted and a similar footprint to the Unifi Intercom Viewer it replaces in spirit.</p>


HomeLab Mini Rack v2: Full 2.5G with 10G Backhaul
2026-01-05T00:00:00+00:00
</a></p>
My original mini rack build</a> had most devices on 2.5Gbps but had a few gaps like the gateway, the cluster
switch, and the access points were still gigabit. My mini rack v2 fills those gaps.</p>
Network</h2>
The UCG-Fiber</a> anchors the rack with a
10G WAN port (my modem and WAN are only 2.5Gb), a built-in 4-port 2.5GbE switch, and 1TB NVMe for Protect camera
recording.</p>
Both switches are
USW-Flex-2.5G-8-PoE</a> with all 8
ports at 2.5Gbps. Uplink to the gateway via 10G SFP+.</p>
Each of the three indoor floors has a U7 Pro Wall</a> connected at
2.5Gbps over the existing cat6 runs. The two half-U patch panels give 24 home runs covering APs, cameras, Apple TVs, and
bedroom drops.</p>
Components</h2>

Rack</strong> - NavePoint 9U 10"</a></li>
Shelves</strong> - DIGITUS Shelf 1U 10"</a></li>
Keystones</strong> - VCE Cat6 Keystone Jacks</a></li>
</ul>
U</th> Component</th> Model</th> Notes</th></tr></thead>

9</td> Modem</strong></td> Hitron CODA56</a></td> DOCSIS 3.1 + 2.5Gbps</td></tr>
8</td> Gateway</strong></td> UCG-Fiber</a></td> 10G + integrated 4-port 2.5GbE switch + 1TB NVMe</td></tr>
7</td> AP Switch</strong></td> USW-Flex-2.5G-8-PoE</a></td> PoE APs and cameras, 2.5G cat6 drops. 10G SFP+ backhaul.</td></tr>
6</td> Patch Panel</strong></td> GeeekPi 0.5U 12 Port</a> ×2</td> Two half-U panels for 24 home runs total.</td></tr>
5</td> Cluster Switch</strong></td> USW-Flex-2.5G-8-PoE</a></td> PoE powered from AP switch. 10G SFP+ backhaul.</td></tr>
3/4</td> RPi 4 Cluster</strong></td> russross 2U mount</a></td> Modified OpenSCAD model for PoE and M.2 hat sizes. See the RPi homelab post</a>.</td></tr>
2</td> M4 Mac mini</strong></td> M4 Mac mini</a></td> On a DIGITUS shelf. Custom 3D printed mount planned.</td></tr>
1</td> PDU</strong></td> Tupavco TP1713</a></td> </td></tr>
</tbody></table>


HomeLab Mini Rack: Unifi 2.5G 9U
2025-06-01T00:00:00+00:00
</a></p>
Motivation</h2>
With the emergence of the 10 inch network rack, Jeff Geerling organized a community around the concept of mini-racks</a>. I moved my homelab to a mini rack in early 2024 and the new community was a great
excuse for me to document and publish my latest homelab/mini rack setup. The following is a re-post of my
mini-rack.jeffgeerling.com mini-rack submission</a>.</p>
This mini rack serves two main purposes:</p>

running PoE APs and cameras</li>
running the 4x Rpi4 cluster with PoE and M.2 hats.</li>
</ol>
This has been a long term and ongoing project starting in 2019. This mini rack grew out of my earlier
Raspberry Pi HomeLab</a>, whose writeup explains more of the
motivation and specifics of the Pi cluster. Cluster Ansible roles and provisioning can be browsed here:
https://src.nth.io/luke/ansible-roles/file</p>
Components</h2>
The entire rack is fed from one power cable and one coax cable, excluding the ethernet drops, of course.</p>

Rack</strong> - NavePoint 9U 10”</a></li>
Shelves</strong> - DIGITUS Shelf 1U 10"</a></li>
Keystones</strong> - ZOERAX Keystone Couplers</a></li>
</ul>
U</th> Component</th> Model</th> Notes</th></tr></thead>

9</td> Modem</strong></td> Hitron CODA56</a></td> DOCSIS 3.1 + 2.5Gbps</td></tr>
8</td> Gateway</strong></td> UCG-Max</a></td> 2.5Gbps + 512 GB NVMe</td></tr>
7</td> AP Switch</strong></td> USW-Flex-2.5G-8-PoE</a></td> Runs PoE access points and cameras, as well as cat6 drops.</td></tr>
6</td> Patch Panel</strong></td> Enmane 12 Port</a></td> I prefer this specific panel because of its ratchet-based cable support/strain relief.</td></tr>
5</td> Cluster Switch</strong></td> USW-Ultra</a></td> PoE powered from the AP Switch given the PDU limits.</td></tr>
3-4</td> RPI 4 Cluster</strong></td> russross 2U mount</a></td> I modified the OpenSCAD model to fit my specific PoE and M.2 hat sizes.</td></tr>
2</td> M4 Mac mini</strong></td> M4 Mac mini</a></td> I plan to make a custom M4 Mac mini 3d printed rack mount.</td></tr>
1</td> PDU</strong></td> Tupavco TP1713</a></td> </td></tr>
</tbody></table>
Note: None of these are affiliate links and only provided for ease of reference.</em></p>


3D Printed Metal Vintage Door Latch Parts
2023-02-11T00:00:00+00:00
My family and I moved into a home built in 1895 and thankfully a lot of the original hardware and woodwork had been retained. Unfortunately, one of the bedroom door latches was missing its internals.</p>
</a></p>
After disassembling, cleaning up, and investigating the mortise latch, including another that had all its parts, "B.L.W." branding on the mortise casing lead to Branford Lock Works, a lock company from the mid 1800s in Branford, Connecticut.</p>
</a></p>
A number of vintage hardware resellers carried B.L.W. but it seemed doubtful that exact replacement parts would be locatable, let alone for a reasonable price.</p>
Instead, hoping to have the parts machined locally here in Chicago, I model the missing parts</a> in Fusion 360 and 3D printed a plastic prototype. To my surprise, the prototype worked extremely well even when made with plastic.</p>
</a></p>
Machine shops need technical drawings so I used a Clough42 YouTube</a> video to learn how to make them from my Fusion 360 model. Unfortunately my job was just too small to be worth it for a machine shop and never received a quote.</p>
</a></p>
Given the plastic prototype functioned so well, I finally had the idea to get the model printed in steel by Shapeways</a>. I received an instant quote for steel sintering for about $60, much cheaper than buying vintage replacement parts if they could even be found, and had the finished steel part in hand within a week! The part works perfectly and will hopefully last another 120 years.</p>
</a></p>
</a></p>


Raspberry Pi Unifi Controller on Arm64
2022-11-05T00:00:00+00:00
Ubiquiti wireless access points are configured via a web app called Unifi Controller which can be self hosted. Unfortunately, Unifi Controller relies on some pretty outdated packages, making them hard to find and maintain alongside modern Linux distributions versions. Adding to the complexity, the packages required are old enough that Arm64 packaging was not yet commonplace. The official Unifi docs</a> do not cover installation in such a scenario.</p>
After quite a bit of digging around in public apt repos, I found the right combination of packages to backport with Ubuntu 22.04.1 LTS (Jammy). Specifically, Unifi relies on the outdated packages MongoDB 3.6 and libssl1.1. Again, these packages are so outdated that Arm64 packaging was not readily available. I've developed an Unifi Ansible role</a> to codify and automate my findings</strong> which are covered below.</p>
Mongo DB</h2>
With the first dependency of Unifi, MongoDB, the latest version Unifi seems to support is 3.6 while 6.0 is the latest at the time of publishing. The official MongoDB docs</a> recommend using their apt repo instead of what comes packaged with Ubuntu or Debian. Also, "starting in MongoDB 5.0, mongod, mongos, and the legacy mongo shell no longer support arm64 platforms which do not meet this minimum microarchitecture requirement." By specifying arm64</code> as the architecture in the Xenial Mongo 3.6 apt repo, a compatible MongoDB 3.6 is available for Arm64 Ubuntu.</p>
Lib SSL 1.1</h2>
This old version of MongoDB relies on libssl1, while Ubuntu now uses libssl3. Ubuntu actually maintains a backport of libssl1.1 to which I was only able to find a direct deb package link. The usual Ubuntu package index</a> links do not seem populated anymore.</p>
Unifi</h2>
Finally, Unifi can be installed on a Raspberry Pi with Ubuntu Arm64 by specifying armhf</code> as the architecture. Unfortunately arm64</code> is not available as a specified architecture but, because the application is Java, it's a universal package.</p>
Conclusion</h2>
There was a lot of material online with discussion of people solving this same problem for different distros and architectures but were unfortunately out of date for Ubuntu Jammy Arm64. Specifically, a blog post by Leif Lindholm</a> discussed a lot of the issues as well as a Gist by Dave Coutts</a> and subsequent discussion section.</p>


ESP32 HomeKit Intercom
2022-09-07T00:00:00+00:00
</a></p>
From Raspberry Pi to ESP32</h2>
In 2018 I wired a Raspberry Pi Zero W into my 1970s apartment intercom</a> to make it Siri-controllable. The Pi ran HAP-NodeJS, which worked, but always felt like overkill: a full Linux computer, an npm dependency tree, and Node.js runtime just to toggle a relay and sample an ADC pin. When Espressif released their ESP32 HAP SDK</a> — a native C implementation of the HomeKit Accessory Protocol running on FreeRTOS — it was an obvious upgrade path. The full project source is available on src.nth.io</a>.</p>
Why ESP32</h2>
The original Pi-based implementation had a few pain points:</p>

Boot time.</strong> Linux takes 30+ seconds to come up. A doorbell event during that window is silently dropped.</li>
Fragility.</strong> HAP-NodeJS was difficult to install correctly and the Node/npm stack introduced a lot of surface area for things to break after an apt upgrade</code>.</li>
Power.</strong> A Pi Zero W consumes around 400mA at 5V. An ESP32 at idle is under 10mA.</li>
</ul>
The ESP32 runs FreeRTOS, boots in under a second, and the entire firmware is a single compiled binary. No package manager, no interpreter, no OS updates.</p>
Components</h2>
Both boards use Adafruit's Feather form factor, so the Relay FeatherWing stacks directly on top of the HUZZAH32 with no additional wiring between them.</p>
Component</th> Price</th></tr></thead>

Adafruit HUZZAH32 – ESP32 Feather Board w/ Stacking Headers</a></td> $21.95</td></tr>
Adafruit Non-Latching Mini Relay FeatherWing</a></td> $7.95</td></tr>
Total</strong></td> $29.90</strong></td></tr>
</tbody></table>
</a></p>
The Intercom Circuit</h2>
The building intercom runs at 52V AC (60Hz) with a 23V DC bias component shared across all units on a tier. The same two wires carry both signals simultaneously. This makes voltage sensing non-trivial.</p>
For the doorbell detection</strong> circuit, I built a resistive voltage divider to bring the signal into the ESP32's ADC range:</p>

R1: 100kΩ</li>
R2: 10kΩ + 2.2kΩ</li>
</ul>
The AC component is filtered with a 4.7µF capacitor, leaving only the DC component for the ADC to sample. When the lobby buzzer is triggered, the DC voltage drops approximately 20% — from a nominal ~23V down to roughly 18V, which maps to a 12-bit ADC reading shifting from ~3000 down into the 2300–2400 range.</p>
For the door lock</strong>, a relay on GPIO 21 controls the existing solenoid circuit. The intercom panel's lock switch still works in parallel.</p>
GPIO Architecture</h2>
GPIO pin cannot simultaneously be used for hardware interrupts and ADC sampling. I solved this by bridging two GPIO pins to the same voltage node:</p>

GPIO 27</strong> — interrupt input (GPIO_INTR_NEGEDGE</code>), used for fast doorbell detection</li>
GPIO 33</strong> — ADC1 channel 5, used for voltage verification sampling</li>
</ul>
When the interrupt fires on GPIO 27, a FreeRTOS task wakes up and samples GPIO 33 fifteen times at 20-tick intervals to confirm the doorbell voltage is in range before triggering the HAP event. This eliminates false positives from noise spikes on the intercom line.</p>
void</span> bell_read_task</span>(</span>void</span> *</span>p</span>)</span></span>
{</span></span>
    for</span> (</span>;</span>;</span>)</span></span>
    {</span></span>
        ulTaskNotifyTake</span>(</span>pdTRUE</span>,</span> portMAX_DELAY</span>)</span>;</span> //</span> block until ISR</span></span>
        sample_bell_adc</span>(</span>)</span>;</span>                       //</span> confirm with ADC</span></span>
    }</span></span>
}</span></span></code></pre>HomeKit Services</h2>
The firmware exposes two HomeKit services on a single accessory:</p>

Doorbell service</strong> — uses hap_serv_doorbell_create()</code> with HAP_CHAR_UUID_PROGRAMMABLE_SWITCH_EVENT</code>. When the bell rings, it fires a single-press event to iOS, which generates a notification.</li>
Lock mechanism service</strong> — uses hap_serv_lock_mechanism_create()</code>. A write callback handles lock/unlock commands and triggers an auto-relock timer matching the physical spring-back behavior of the original switch.</li>
</ol>
hap_acc_add_serv</span>(</span>intercom_accessory</span>,</span> bell_service_init</span>(</span>)</span>)</span>;</span></span>
hap_acc_add_serv</span>(</span>intercom_accessory</span>,</span> lock_service_init</span>(</span>)</span>)</span>;</span></span></code></pre>
The accessory presents itself with HAP_CID_DOOR</code> so iOS correctly categorizes it in the Home app.</p>
Debouncing</h2>
The building intercom generates a messy signal — adjacent units ring simultaneously and the AC component causes voltage flutter. After the bell fires a HAP event, a FreeRTOS timer blocks further bell events for a configurable timeout period. This prevents a single lobby press from generating a burst of notifications.</p>
void</span> bell_rang</span>(</span>)</span></span>
{</span></span>
    hap_char_update_val</span>(</span>bell_current_state</span>,</span> &</span>HAP_PROGRAMMABLE_SWITCH_EVENT_SINGLE_PRESS</span>)</span>;</span></span>
    is_bell_blocked </span>=</span> true</span>;</span></span>
    xTimerReset</span>(</span>bell_block_timer_handle</span>,</span> pdFALSE</span>)</span>;</span></span>
}</span></span>
</span>
void</span> bell_block_timer_cb</span>(</span>TimerHandle_t</span> timer</span>)</span></span>
{</span></span>
    is_bell_blocked </span>=</span> false</span>;</span></span>
}</span></span></code></pre>Partition Sizing</h2>
The HAP SDK binary is large enough that the default ESP-IDF single-app partition table doesn't fit it. The factory partition needs to be bumped from 1MB to 1.5MB in partitions_hap.csv</code>:</p>
nvs,</span>      data,</span> nvs,</span>     ,</span> 0x6000,</span></span>
phy_init,</span> data,</span> phy,</span>     ,</span> 0x1000,</span></span>
factory,</span>  app,</span>  factory,</span> ,</span> 0x180000,</span></span></code></pre>
</a></p>
Result</h2>
The ESP32 intercom boots in under a second, uses a fraction of the power of the Pi, and has been running without intervention since installation. iOS doorbell notifications arrive within a second of the lobby button being pressed. The lock control works reliably via Siri, the Home app, and automations.</p>
The main trade-off versus the Pi version is the development workflow — cross-compiling C with the ESP-IDF toolchain is more involved than editing a Python file and restarting a systemd service. But for a device that runs 24/7 and should never need touching, the embedded approach is clearly the right one.</p>
</a></p>
Future Work</h2>
The "talk" and "listen" functions of the intercom panel remain unwired. Two-way audio over HomeKit is a possible next step, though the HAP audio spec is considerably more complex than doorbell events.</p>


Haskell.Social Fediverse
2021-07-25T00:00:00+00:00
Communities need associative hosting</strong>. Following Freenode's well documented collapse</a>, we were motivated to set up haskell.social</a>, an experimental web, matrix, and pleroma set of services to give the haskell-adjacent community an alternative to centralized services like Meetup, Slack/IRC/Discord, and Twitter, etc.</p>
Federation enables people to bring their own identities and connect with other communities online. A recent blog post</a> highlights the importance of self and associative hosting.</p>
Matrix and pleroma certainly have their downsides and IRC and Twitter are pretty hard to beat, but they have their upsides as well. Indeed, much of the haskell community is already supported by the new Libera Chat IRC</a>. haskell.social</a> is an alternative, enabling experimentation with newer federated approaches to online communities.</p>


Raspberry Pi HomeLab
2020-08-01T00:00:00+00:00
</a></p>
This was my first homelab. I later rebuilt it into a Mini Rack</a>, then upgraded it in Mini Rack v2</a>.</em></p>
Motivation</h2>
I became more interested in personal privacy after my Roku started spying on what we were watching outside the Roku itself, our mesh WiFi router switched to a subscription model for "AI" and "cloud" features, and our smart home switches required access to "the cloud" just to turn on lights. TVs, WiFi routers, and smart home devices are all driving prices down by supplementing hardware sales revenue with personal data sales.</p>
On top of that, after creating a custom smart lock</a>, I saw first hand how Google and Amazon's smart home infrastructures are built around selling cloud services and capturing my personal data, while Apple HomeKit is designed to work without any internet access at all.</p>
Given these consideration, I wanted a more robust router and firewall between my home network and the internet. I wanted to be able to completely block smart home devices from accessing the internet. And I wanted to do everything as cheaply as possible while maintaining compute resource (CPU, RAM, disk) separation between self-hosted services.</p>
Setup</h2>

1x $59 Ubiquiti EdgeRouter X</a></li>
1x $70 TP-Link 8 Port PoE Switch</a></li>
4x $55 Raspberry Pi 4 Model B 4GB</a></li>
4x $20 Raspberry Pi PoE HAT</a></li>
3x $48 Seagate 1TB USB HDD</a></li>
Total: $573</strong></li>
</ul>
The Ubiquiti EdgerRouter X is the router and firewall while the mesh WiFi is in "bridge" mode, effectively operating as a switch. IP addresses are assigned in ranges and firewall settings are used to block all devices from the internet except those that need it (Apple TV, Laptops, Phones, etc.).</p>
Four Raspberry Pis host all self-hosted services. Public services</a> like code hosting, federated social networks, and a bitcoin node. And private services like DNS-based ad and tracker blocking. (After using Pi-Hole for a while, I switched to AdGuard Home, which is just simpler and easier to maintain.)</p>
Finally, power over Ethernet (PoE) with a PoE switch is used to reduce the cords to the Raspberry Pis.</p>
Custom Racking</h2>
A downside of not using a standard rack-mounted host is the non-standard form factors of the Raspberry Pis and hard drives etc.</p>
</a></p>
To handle this, I 3D printed a Raspberry Pi 2U rack mount</a>. It's not used in a rack configuration but it's actually just a great way to have easy, uniform, and modular access to the Pis.</p>
Hardware was purchased from McMaster-Carr.</p>

1x $3.33 Super-Corrosion-Resistant 316 Stainless Steel Socket Head Screw, M2.5 x 0.45 mm Thread, 12 mm Long</a></li>
2x $5.66 18-8 Stainless Steel Threaded Rod, M5 x 0.8 mm Thread Size, 300 mm Long</a></li>
1x $3.79 Super-Corrosion-Resistant 316 Stainless Steel Thin Hex Nut, M5 x 0.8 mm Thread, 2.7 mm High</a></li>
Total: $18.44</strong></li>
</ul>
For the hard drives, I designed and 3D printed a custom stand.</p>
Configuration Management</h2>
Host configuration is managed with Ansible</a>. The roles are written to be minimally invasive and optimized for low maintenance.</p>
The Ansible roles are open source</a>.</p>
Layout</h2>
For clarity, my specific Raspberry Pi Ansible playbook in provided below:</p>
-</span> h</span>osts</span>:</span> r</span>pis</span></span>
  r</span>oles</span>:</span></span>
    -</span> r</span>pi-base</span></span>
    -</span> a</span>pt-cacher/client</span></span>
    -</span> p</span>rometheus/rpi-client</span></span>
</span>
-</span> h</span>osts</span>:</span> a</span>dmin.local</span></span>
  r</span>oles</span>:</span></span>
    -</span> a</span>dguard-home</span></span>
    -</span> a</span>pt-cacher/server</span></span>
    -</span> p</span>rometheus/server</span></span>
</span>
-</span> h</span>osts</span>:</span> b</span>tc.local</span></span>
  r</span>oles</span>:</span></span>
    -</span> b</span>lock-device</span></span>
    -</span> b</span>itcoind</span></span>
    -</span> l</span>nd</span></span>
    -</span> b</span>itcoind-prometheus-exporter</span></span>
</span>
-</span> h</span>osts</span>:</span> m</span>edia.local</span></span>
  r</span>oles</span>:</span></span>
    -</span> b</span>lock-device</span></span>
    -</span> p</span>lex</span></span>
    -</span> t</span>ransmission</span></span>
    -</span> h</span>omebridge</span></span>
    -</span> m</span>inecraft</span></span>
    -</span> n</span>ginx</span></span>
</span>
-</span> h</span>osts</span>:</span> w</span>eb.local</span></span>
  r</span>oles</span>:</span></span>
    -</span> b</span>lock-device</span></span>
    -</span> p</span>ostgresql</span></span>
    -</span> p</span>leroma/aws-s3-backup</span></span>
    -</span> p</span>leroma/otp</span></span>
    -</span> w</span>ritefreely</span></span>
    -</span> m</span>ercurial/aws-s3-backup</span></span>
    -</span> m</span>ercurial/web</span></span>
    -</span> o</span>ragono</span></span>
    -</span> p</span>rosody</span></span>
    -</span> n</span>ginx</span></span></code></pre>Conclusion</h2>
Using a hardwired router as the articulation point between the internet and the rest of a home network is a great way to get privacy, security, and self-hosting without really investing much.</p>


Mercurial + WSGI + Nginx
2020-07-02T00:00:00+00:00
I wanted to host my code without a lot of extra infrastructure, apps, and metadata to operate and maintain. I just wanted a simple way to share my repos. Contributors can easily send patches via email without a whole new login and user system. I saw hg.prosody.im</code></a> and was inspired by it's simplicity.</p>
Given the overwhelming popularity of Git and full-service solutions like GitLab, there are only a couple</a> helpful</a>, but slightly outdated, guides for Mercurial + Nginx. It was enough to get me up and running, though, and I wanted to document how I got things working.</p>
Mercurial can run a fork of cgit via WSGI and hosted by Nginx.  Check the repo</a> for the most up-to-date version of these configs in an Ansible role. The setup is as follows for my code hosted at the subdomain src.nth.io</code></a>:</p>
Nginx -> UNIX domain socket -> WSGI -> Mercurial repos</span></span></code></pre>Dependencies</h2>
This particular setup is running Ubuntu 20.04.</p>

mercurial</code></li>
nginx</code></li>
uwsgi</code></li>
uwsgi-plugin-python3</code></li>
python3-pygments</code></li>
</ul>
Nginx Config</h2>
Path: /etc/nginx/sites-enabled/src.nth.io.conf</code></p>
server {</span></span>
    listen 80;</span></span>
    listen [::]:80;</span></span>
    server_name src.nth.io;</span></span>
    return 301 https://$host$request_uri;</span></span>
}</span></span>
</span>
server {</span></span>
    listen 443 ssl http2;</span></span>
    listen [::]:443 ssl ipv6only=on;</span></span>
    server_name src.nth.io;</span></span>
</span>
    ssl_certificate /etc/letsencrypt/live/src.nth.io/fullchain.pem;</span></span>
    ssl_certificate_key /etc/letsencrypt/live/src.nth.io/privkey.pem;</span></span>
    include /etc/letsencrypt/options-ssl-nginx.conf;</span></span>
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;</span></span>
</span>
    ssl_ecdh_curve X25519:prime256v1:secp384r1:secp521r1;</span></span>
    ssl_stapling on;</span></span>
    ssl_stapling_verify on;</span></span>
</span>
    location / {</span></span>
        include     uwsgi_params;</span></span>
        uwsgi_param REMOTE_PORT     $remote_port;</span></span>
        uwsgi_param SERVER_PORT     $server_port;</span></span>
        uwsgi_param SERVER_PROTOCOL $server_protocol;</span></span>
        uwsgi_param UWSGI_SCHEME    $scheme;</span></span>
        uwsgi_param SCRIPT_NAME     /;</span></span>
        uwsgi_param AUTH_USER       $remote_user;</span></span>
        uwsgi_param REMOTE_USER     $remote_user;</span></span>
        uwsgi_pass  unix:/run/uwsgi/app/hgweb/socket;</span></span>
    }</span></span>
}</span></span></code></pre>UWSGI Config</h2>
Path: /etc/uwsgi/apps-enabled/hgweb.ini</code></p>
Note the socket</code> key matches the uwsgi_pass</code> parameter from the Nginx config above.</p>
[uwsgi]</span></span>
processes = 2</span></span>
max-requests = 10240</span></span>
max-requests-delta = 1024</span></span>
max-worker-lifetime = 604800</span></span>
socket = unix:/run/uwsgi/app/hgweb/socket</span></span>
chdir = /var/www/src.nth.io</span></span>
wsgi-file = hgweb.wsgi</span></span>
uid = www-data</span></span>
gid = www-data</span></span>
plugins = python3</span></span></code></pre>
The max request lines allow the uwsgi server to restart the workers and mitigate memory leaks in the HG Web script without incurring downtime.</p>
HgWeb Script</h2>
Path: /var/www/src.nth.io/hgweb.wsgi</code></p>
config = "/var/www/src.nth.io/hgweb.config"</span></span>
from mercurial import demandimport; demandimport.enable()</span></span>
from mercurial.hgweb import hgweb</span></span>
application = hgweb(config.encode())</span></span></code></pre>HgWeb Config</h2>
Path: /var/www/src.nth.io/hgweb.config</code></p>
Note the actual Mercurial repo path at /var/hg/repos</code>.</p>
[paths]</span></span>
/ = /var/hg/repos</span></span>
</span>
[web]</span></span>
deny_push = *</span></span>
allow_archive = gz bz2 zip</span></span>
encoding = UTF-8</span></span>
style = gitweb</span></span>
</span>
[extensions]</span></span>
hgext.highlight =</span></span></code></pre>Running</h2>
With this all set up, sudo systemctl start uwsgi</code> and sudo systemctl start nginx</code>. If something doesn't work, check the logs. Ensure the UWSGI user and group allows for read access to the repo directory.</p>
Both the Nginx and uWSGI Ubuntu packages are set to actually have the configs at {sites|apps}-available</code> and then symlinked to the respective {sites|apps}-enabled</code> directories, as documented on their websites.</p>
Theming</h2>
Check out the Mercurial docs</a> for instructions on theming the website.</p>


3D Printed Intercom Panel
2019-05-01T00:00:00+00:00
After wiring a Raspberry Pi Zero W into my 1970s apartment
intercom</a> to make it Siri-controllable, I needed a way to mount
the Pi inside the panel. My first solution was a small piece of wood screwed into some unused screw terminals. It was
nonconductive, quick, and easy enough to start with. But cutting a precise piece to fit in a few millimeters of
clearance, inside an apartment with no workshop, was difficult. The wood grain made clean cuts even harder. It worked,
but it always felt like a prototype. That got me thinking about 3D printing, a process I had zero experience with.</p>
</a>
</a>
</a></p>
Getting Started with 3D Printing</h2>
I bought the cheapest and smallest printer I could find, a Monoprice, specifically to remake that wood mount in
plastic. I was never able to get it working properly and eventually upgraded to a Prusa i3
MK3</a> kit. My first task was learning to model. Blender was too
freeform for precise measurements. Fusion 360 turned out to be the right tool: parametric, measurement-driven, and
well-covered on YouTube.</p>
The mount itself was a good first project. A 3D printer making its own replacement parts sounds janky, but it's actually
one of its best features: you can iterate and improve your own setup as you go. The opposite of planned obsolescence.</p>
With that success I started thinking: why not remake the whole nasty-looking injection-molded panel? I started by
printing and modeling other simpler things around the house. The full panel became my most challenging 3D model yet.</p>
Remaking the Panel</h2>
The hardest part was the inner wall cutout. The original panel was mortised into the wall, and the recess dimensions
were practically impossible to measure accurately. Calipers couldn't fit into the corners. I made many prototypes until
I found the right shape. 3D printing's fast iteration cycle was exactly what this required.</p>
</a>
</a></p>
Installation</h2>
With a solid prototype shape, I mounted the Raspberry Pi and all the hardware into the panel and started the install.</p>
</a></p>
The three stages of the design, from rough mount to panel prototype to final panel, made the progression clear.</p>
</a></p>
One problem I hadn't anticipated: whoever originally installed the panel had crudely chiseled the wall recess by hand
and it wasn't remotely square. Getting the fully assembled Pi to fit required chiseling out even more material to make
room.</p>
</a></p>
Final Design</h2>
The final panel hides the front screw holes (my wife's idea) and echoes the original vertical slat pattern so it
doesn't look out of place on the wall. I reprinted it in grey and added switch caps for a cleaner finish.</p>
The print files are available on Printables</a>.</p>


Raspberry Pi HomeKit Door Lock
2018-01-19T00:00:00+00:00
Apple HomeKit with Raspberry Pi</h2>
I made my 1970s (?) apartment intercom system Siri controlled and internet accessible with a Raspberry Pi</a> and Pimoroni Automation pHAT</a>. The full project code is available on a src repo</a>.</p>
</a></p>
The Problem</h2>
My apartment building lobby door lock is controlled by an intercom panel in my unit. To unlock the door, the switch completes a circuit to an electromagnet in the lobby. And for someone to ring my unit's doorbell, a switch in the lobby completes a circuit to power a really annoying buzzer in my unit. I can also talk and listen to a speaker in the lobby.</p>
</a></p>
If I'm at work I can't get a package delivered or receive guests. Also, I'd been looking for a fun Raspberry Pi project for a few years and finally it struck me: use the Raspberry Pi to control these switches.</p>
Intercom Layout</h2>
To start, I took the panel off the wall to see how it worked and used a voltmeter to test what all the wires mapped to and at what voltages. I only cared about two functions: unlocking the lobby door and receiving a doorbell signal. There are five wires and four functions, leaving the fifth wire as ground, all at 52V:</p>

Unlock door</li>
Listen for doorbell</li>
Talk to lobby speaker</li>
Listen to lobby speaker</li>
Ground</li>
</ol>
</a></p>
Raspberry Pi</h2>
When selecting a Raspberry Pi or Arduino to control these circuits, I went with the Raspberry Pi because it's a full linux computer and seemed the most flexible. I picked the Raspberry Pi Zero W</a> for the smaller form factor and builtin WIFI. SSH access is provided via ethernet emulation over one of it's USB ports.</p>
I bought the following for one day shipping from Amazon:</p>

CanaKit Raspberry Pi Zero W (Wireless) with Official Case and Power Supply</a></li>
SanDisk Mobile Class4 MicroSDHC Flash Memory Card- SDSDQM-B35A Without Adapter 16GB</a></li>
DIKAVS Break-away 0.1" 2x20-pin Strip Dual Male Header for Raspberry Pi Zero GPIO (Pack of 10)</a></li>
</ul>
Raspberry Pi Add-On Board</h3>
Now I needed a way to switch and read the intercom circuits. "HAT" is the name of a full-sized add-on board and "pHAT" is the name of the Pi Zero form factor add-on board. Pinout</a> is a great resource with a fairly comprehensive list of pHAT boards. I figured I needed a "relay" to unlock the door and a "analog to digital converter" to read the doorbell signal. One board fit the requirements perfectly:</p>

Pimoroni Automation pHAT</a></li>
</ul>
</a></p>
Raspbian Setup</h3>
With the hypothesis of how all this would fit together, I bought the components and started on the software.</p>
I followed two guides to set up a headless Raspian with WIFI enabled and SSH over USB emulated ethernet:</p>

Use Your Raspberry Pi As A Headless System Without A Monitor</a></li>
Connect To A Raspberry Pi Zero With A USB Cable And SSH</a></li>
</ol>
Writing the Software</h2>
With the hardware and OS sorted, I started experimenting with controlling the Automation pHAT using their online docs</a> and Python function reference</a>. I used LEDs and resistors to experiment with the functionality in isolation from the intercom.</p>
pHAT Python Server</h2>
The pHAT Python API access must be single threaded but because I need to poll for the doorbell and for commands to unlock the door in parallel, I made a multithreaded Python server</a> with a message queue for commands using stdio</code>.</p>
Doorbell</h3>
The doorbell goes into the Analog-Digital-Converter (ADC) and a resistive divider is used to bring the 52V into the requisite 24V range.  The ADC digital reading of 6.0--6.3 is when the doorbell is ringing for whatever reason. Everything else is noise. Here's some example output from a one second polling Python test:</p>
7.65</span></span>
7.65</span></span>
7.62</span></span>
7.62</span></span>
6.08  <-- doorbell starts ringing</span></span>
6.18</span></span>
6.19</span></span>
6.18</span></span>
6.19</span></span>
7.62  <-- doorbell stops ringing</span></span>
7.62</span></span>
7.62</span></span>
7.63</span></span>
7.63</span></span></code></pre>Door Lock</h3>
The door lock is controlled by the single relay available on the pHAT which doesn't require bringing the voltage down with a resistor.</p>
Apple HomeKit Integration</h2>
I then created a HAP-NodeJS</a> accessory to expose the Door Python server to Apple HomeKit Protocol (HAP) for Siri and Home App control. I use systemd</code> to keep the HAP server running.  I also use the HAP accessory to timeout the door being unlocked and relock it. This is to mimic the behavior of the physical switches which spring back to neutral (locked) when not being held.</p>
Representing a door lock with HAP-NodeJS in HomeKit</a> was easy but getting the doorbell event to work was very fragile. Now I get iOS notifications when the doorbell rings!</p>
</a></p>
It was also extremely difficult getting NodeJS and all the dependencies installed correctly. Once I got everything installed and working, I wrote Ansible roles</a> to codify exactly what is required.</p>
See the src repo</a> for the full install layout.</strong></p>
</a></p>
Final Build</h2>
I was able to attach the final buildout to the preexisting circuit board screw terminals so the intercom panel still works as before but with the addition of Siri integration! Siri and Apple HomeKit turned out to be a huge win. It meant I didn't need to run any external servers to expose my services to the internet, write any mobile apps, or do anything special to integrate with Siri. Alexa was much more complex and I ended up removing that support.</p>
I was able to use my Apple TV to bridge all of my HomeKit devices, including my custom Lobby Door, to my iOS devices through the internet.  No more missed packages and a fun project over the holidays.</p>
</a></p>
</a></p>
Future Tasks</h2>
Right now the Automation pHAT must poll for doorbell events. I believe there is a way to use the Raspberry Pi GPIO pins to create an event-driven approach.</p>
Perhaps I'd also like to attempt to get the "talk" and "listen" functionality working with an additional audio-focused pHAT.</p>
HomeKit supports BTLE and I believe the Raspberry Pi Zero W does as well. It would be nice to use the lighter-weight protocol instead of WiFi.</p>

Raspberry Pi Unifi Protect Viewport

HomeLab Mini Rack v2: Full 2.5G with 10G Backhaul

HomeLab Mini Rack: Unifi 2.5G 9U

3D Printed Metal Vintage Door Latch Parts

Raspberry Pi Unifi Controller on Arm64

ESP32 HomeKit Intercom

Haskell.Social Fediverse

Raspberry Pi HomeLab

Configuration Management</h2>
Host configuration is managed with Ansible</a>. The roles are written to be minimally invasive and optimized for low maintenance.</p>
The Ansible roles are open source</a>.</p>

Conclusion</h2>
Using a hardwired router as the articulation point between the internet and the rest of a home network is a great way to get privacy, security, and self-hosting without really investing much.</p>

Mercurial + WSGI + Nginx

`Theming</h2> Check out the Mercurial docs</a> for instructions on theming the website.</p>`

3D Printed Intercom Panel

Final Design</h2>
The final panel hides the front screw holes (my wife's idea) and echoes the original vertical slat pattern so it doesn't look out of place on the wall. I reprinted it in grey and added switch caps for a cleaner finish.</p>
The print files are available on Printables</a>.</p>

Raspberry Pi HomeKit Door Lock

Apple HomeKit with Raspberry Pi</h2>
I made my 1970s (?) apartment intercom system Siri controlled and internet accessible with a Raspberry Pi</a> and Pimoroni Automation pHAT</a>. The full project code is available on a src repo</a>.</p>
</a></p>

Writing the Software</h2>
With the hardware and OS sorted, I started experimenting with controlling the Automation pHAT using their online docs</a> and Python function reference</a>. I used LEDs and resistors to experiment with the functionality in isolation from the intercom.</p>

pHAT Python Server</h2>
The pHAT Python API access must be single threaded but because I need to poll for the doorbell and for commands to unlock the door in parallel, I made a multithreaded Python server</a> with a message queue for commands using `stdio</code>.</p>`

Door Lock</h3>
The door lock is controlled by the single relay available on the pHAT which doesn't require bringing the voltage down with a resistor.</p>

nth.io

mattertimectl

ESP32 Ethernet Display

Emacs claude-code-context.el

nth.io

mattertimectl

Using it</h2> Commission each device once, inside a pairing window opened in the primary app, then let a timer drive it:</p>

ESP32 Ethernet Display

The display knows nothing</h3> The RPI version handled a lot of logic on the display device. It authenticated against Unifi Protect, had to know the doorbell's camera ID, and how to parse a proprietary WebSocket event stream, pull an RTSP feed, decode H.264, and rotate video to portrait.</p>

Enclosure</h3> I designed a flush-mounted, single cable, roughly the footprint of the standard light switch wallplates. The enclosure is a two-piece 3D-printed design built around a standard electrical single-gang rough-in.</p>

The protocol</h3> The display's network API is intentionally tiny. It exposes a handful of HTTP endpoints and one raw TCP socket, and everything is pushed to</em> it:</p>

Emacs claude-code-context.el

Raspberry Pi Unifi Protect Viewport

HomeLab Mini Rack v2: Full 2.5G with 10G Backhaul

HomeLab Mini Rack: Unifi 2.5G 9U

3D Printed Metal Vintage Door Latch Parts

Raspberry Pi Unifi Controller on Arm64

ESP32 HomeKit Intercom

Haskell.Social Fediverse

Raspberry Pi HomeLab

Conclusion</h2> Using a hardwired router as the articulation point between the internet and the rest of a home network is a great way to get privacy, security, and self-hosting without really investing much.</p>

Mercurial + WSGI + Nginx

Dependencies</h2> This particular setup is running Ubuntu 20.04.</p>

Nginx Config</h2> Path: /etc/nginx/sites-enabled/src.nth.io.conf</code></p>

UWSGI Config</h2> Path: /etc/uwsgi/apps-enabled/hgweb.ini</code></p> Note the socket</code> key matches the uwsgi_pass</code> parameter from the Nginx config above.</p>

Theming</h2> Check out the Mercurial docs</a> for instructions on theming the website.</p>

3D Printed Intercom Panel

Raspberry Pi HomeKit Door Lock

Door Lock</h3> The door lock is controlled by the single relay available on the pHAT which doesn't require bringing the voltage down with a resistor.</p>

Conclusion</h2>
Using a hardwired router as the articulation point between the internet and the rest of a home network is a great way to get privacy, security, and self-hosting without really investing much.</p>

`Theming</h2> Check out the Mercurial docs</a> for instructions on theming the website.</p>`

Door Lock</h3>
The door lock is controlled by the single relay available on the pHAT which doesn't require bringing the voltage down with a resistor.</p>