Add LCD Gateway page; wire it into nav
The ESP32-P4 + 10.1" MIPI-DSI touchscreen gateway (repo SplitFlapGatewayLCD)
was undocumented. New LCD-Gateway.md mirrors Matrix-Gateway.md: the shared
virtual-flap emulation and 237-flap reel, the Ethernet/PoE + touchscreen +
no-RTC differences, canvas/effects, and timer/alarm double-tap dismissal.
Wired in: _Sidebar (Build it), Home (branches + page index + release notes),
Choosing-a-Configuration (both no-hardware callouts now name it too).
Restore 22 pages + 23 images deleted by mistake in 3b9277a (2026-07-30)
Commit 3b9277a ("Binary ops: one format, no version framing") was pushed from
an incomplete working copy of the wiki: alongside its intended 11-line edit to
Canvas-Ops-Reference.md it recorded deletions of every page not in that copy --
22 pages (Home, Quick-Start, Provisioning, Calibration, FAQ, Hardware, ...) and
23 screenshots. _Sidebar.md still linked all of them, so 22 of 28 nav links 404'd.
Restored verbatim from 3b9277a's parent. Additions only; the 8 pages that
evolved since 2026-07-30 are left at their current content.
Binary ops: one format, no version framing
Two gateways, two names — plus Provisioning and Calibration get their own pages
SplitFlap Gateway drives real modules; Matrix Gateway draws a simulated
wall on an LED matrix. The Gateway and Matrix-Portal-Gateway pages are
renamed (redirect stubs left at the old names), 21 pages re-worded, and
both diagrams regenerated with the new labels — the configurations
diagram also aligns all seven Modules boxes on one row.
New: Module provisioning (the full process — the SplitFlap Gateway's
Provision tab and bare-metal provision.py in detail, splitflap-os's
built-in equivalent acknowledged without detail) and Module calibration
(the CALIBRATION_GUIDE ported: the three quantities, the golden order,
nudge vs exact offset, per-flap tuning, the wizard and whole-board pass,
the control reference). Linked from the sidebar's Build-it section,
Home, Module-Firmware and the SplitFlap Gateway tab tour.
The companion has its own app library — the csader relationship, stated honestly
The ecosystem graphic claimed the companion 'runs the splitflap-os app
library (csader)'; it ships its OWN library and speaks the splitflap-os
plugin format. Regenerated, and the framing aligned across the wiki:
splitflap-os is an acknowledged alternative content engine (A/B/E/F);
apps written for it drop in and run here — that inbound direction stays
a hard contract; apps written here MAY run there, without the injected
helpers and unoptimized, with no guarantees. Compatibility's goal
paragraph now says exactly that.
Also: Writing-Apps documents the grown get_weather surface (sky tokens,
days=N forecast + hourly, air=True with labels and canonical bands), and
Built-in Apps gains the countdown's per-unit colour-bar panel and the
weather app's forecast/AQI/UV/pollen in their rows.
Drop the Serial Bridge page: splitflap-os speaks MQTT natively now
The virtual-PTY bridge existed so a serial-only splitflap-os could ride the
gateway's MQTT. splitflap-os has since gained native MQTT support, so the
E/F configurations are just a transport setting in splitflap-os itself —
no bridge, no PTY, nothing to install. Using-splitflap-os says so; Home
and the sidebar drop the entry.
Wiki: five reference pages close the repo-doc gaps; provisioning is in splitflap-os now
A census of all four repos found documentation living only in repo READMEs;
the wiki now carries it:
- Bus Protocol — the RS-485 wire reference: frames, addressing, every module
command with reply grammars and result codes, EEPROM layout, boot sequence.
- Gateway API — REST + MQTT for both gateways, /api/capabilities set
arithmetic, the companion registration + settings-blob contract.
- Companion without Home Assistant — Docker, the install script, the full
COMPANION_* configuration reference, settings storage & disaster recovery.
- Languages & Localization — every language surface and how to contribute one.
- Serial Bridge — splitflap-os over the gateway's MQTT via a virtual PTY,
including Mosquitto setup.
Corrections: splitflap-os now provisions from its own UI (provision.py is
optional, three pages updated); Multiple Displays documents the network scan;
Gateway links its API reference; Home lists all 22 pages + release-notes
links; sidebar gains Reference entries; Built-in Apps adds the Binary Clock
and the Matrix-Portal-only seconds options. Every GitHub link curl-verified.
Wiki: multiple displays, the Matrix Portal's real alphabet, and who decides case
Four things the wiki did not know about yet.
**Multiple displays** — a new page, and a line in every interface's page: one companion
drives several walls, each with its own apps, playlists and settings. GATEWAY_URL takes a
comma-separated list; every /api/ route takes ?display=; the Vestaboard API takes
/local-api/<id>/message; MCP takes a `display` argument and gained `list_displays`; Home
Assistant publishes one device per wall, with the default keeping its historic entity ids
so existing automations don't break.
**The Matrix Portal's extra flaps.** The page still described the lowercase/colour
collision as an unsolved limitation — "the lowercase letter `r` is reachable only by
index". That is still true of the one-byte character protocol, and always will be: the
byte for lowercase `r` already means RED. But firmware 1.6 added an index-addressed
endpoint that sidesteps it, and the companion now uses it automatically, so the 60
lowercase flaps and the 14 pictographs the emulated reel was always carrying are finally
reachable. Documented both — the constraint and the way around it.
**Who decides the case.** Apps write their words the way a person writes them; the
companion folds to capitals on the way out, and only for a wall with no lowercase flaps.
Flaps & Character Sets said "the companion never polices characters", which is no longer
true. It also gains the pictograph table and their fallbacks.
**Stop blanks the wall.** The MCP page claimed `stop` "leaves the last frame on the
flaps". It doesn't any more.
Screenshots retaken against a real companion (two stub gateways, made-up data). The two
new ones are the point of the whole release: the same app, the same minute, showing
"IT'S FIVE PAST THREE" on a split-flap and "It's five past three" on a Matrix Portal.
Wiki: correct the splitflap-os feature grid; give Vestaboard + MCP their own pages
Feature grid — I built it from splitflap-os's README, which undersells it. Rebuilt
from the code (csader/splitflap-os main, with feat/app-triggers, feat/schedules and
feature/custom-char-map all merged in):
- Event triggers, schedules and quiet hours: splitflap-os HAS these. Was "—", now ✅
for every splitflap-os configuration.
- Flap sets: splitflap-os reads each module's flap count and character set from the
firmware and encodes against them, so a non-64 reel works — but it can't *write*
one. Split the row into "custom character set" and "flap count other than 64", both
✅ (web UI) only where the Universal Firmware meets the gateway, ⚠️ for sfOS.
- REST API: it has Flask endpoints for its own UI but no documented API. Now ⚠️.
- Localization: verified against upstream main — no language/locale settings there.
Left as "—" with a footnote saying so; i18n exists in forks.
Vestaboard + MCP are companion features, not Home Assistant features. They now have
their own pages, and the HA page links to them instead of owning them:
- Vestaboard-API: enabling it, the endpoints (GET returns {"message": [[…]]}, POST
201, 401 is plain text), the {"text": …} extension, ha-vestaboard and rest_command.
- MCP-Server: the eleven tools, why read-before-write matters, connecting Claude Code
and Desktop, and worked examples of what you can ask for.
Both are linked from the Companion's new "Ways to drive it from outside" section.
Wiki: flaps & character sets page, WiFi/mDNS setup, HA install steps, real screenshots
- New page "Flaps & Character Sets": the N command, the 64-flap budget, and
validated 64-flap starter sets for 12 locales (each exactly 64 unique CP1252
glyphs) — framed as a suggestion, not a prescription. Linked from the sidebar,
the Home TOC, the feature grid, Module Firmware and the Companion's
localization section.
- Gateway: full first-boot WiFi flow via the fallback AP, and a "Finding it on
your network" section — mDNS is best-effort, so document finding the IP from
the router/serial and using that everywhere (incl. GATEWAY_URL). Same for the
Matrix Portal, whose AP is named after its hostname.
- Home Assistant: step-by-step install for both the App (repository URL, the two
channels, gateway_url, sidebar) and the HACS integration (custom repository of
type Integration, restart, config flow against the *companion's* URL), plus a
full options table. Mirrored as a condensed step 6 in the Quick Start.
- Correct the calibration-compatibility claim: the gateway's Calibration tab
issues only original-protocol commands (c o s t g w h d) against
original-layout EEPROM fields, so it works fully on the original firmware. The
only version gate in the gateway UI is the flap-set editor (v31+).
- Swap the mocked-up screenshots for real ones rendered from the actual UIs with
fake data; drop ha-device.png; de-boastify a few lines; fix four dead anchors.
Configurations: splitflap-os-through-the-Gateway becomes first-class (E/F); library-divergence and app-upload fixes
Two combinations were demoted to a footnote and belong in the grid: the Gateway owning the
bus with splitflap-os providing content over MQTT, on either firmware (E: original, F:
Universal). The grid is now seven columns with sections regrouped by driver (A/B direct
sfOS, C/D gateway alone, E/F sfOS-through-gateway, G companion ★), and 'Switching later'
covers the new moves (A/B -> E/F).
Also, per review: the companion's apps are described as a vendored SNAPSHOT of the
splitflap-os library that may diverge over time — not 'the same app library'; softened the
same claim on Home/Companion/Using-splitflap-os. New grid row for uploading your own apps
from the browser (companion). And the click-to-type compose grid is correctly credited to
splitflap-os as well as the companion — it was wrongly annotated as companion-only.
Add 'Choosing a Configuration': every viable firmware × driver mix, with a feature grid
The stack is swappable at two joints — module firmware (Adam's original vs Universal) and
the driver (splitflap-os on a Pi, the Gateway alone, or Gateway + Companion). The new page
describes each viable combination (including splitflap-os through the Gateway over MQTT,
and the Matrix Portal substitution), a ~20-row feature grid across the five main configs,
footnotes for the depends-on-firmware cases, and how to migrate between configs without
redoing work. Universal → Gateway → Companion is called out as the most featureful path.
splitflap-os facts (playlists, calibration tools, both-firmware compatibility, MQTT
gateway mode, no scheduler/triggers per its README) checked against csader/splitflap-os.
Wired into the sidebar, Home TOC, Quick Start and the splitflap-os page; the splitflap-os
page's 'targets its own environment' line corrected to the fuller picture.
Comprehensive combined wiki for the whole SplitFlap ecosystem
Ties together all the projects — hardware (Adam G Makes), Universal Firmware, Gateway,
Matrix Portal Gateway, Companion (+ HA add-on and HACS integration), and splitflap-os — into
one guided flow from parts to a message on the wall, with optional steps clearly marked.
Pages: Home (ecosystem + TOC), Quick Start (end-to-end, two paths), Hardware, Module
Firmware, Gateway, Matrix Portal Gateway, Companion, Home Assistant (five surfaces), Using
splitflap-os, FAQ & Glossary, plus a sidebar. Includes made-up-data UI mockups (ecosystem
diagram, companion Apps tab, gateway Modules tab, HA device).