src/assets/diagrams/packet-control-empty.svg Covers the five empty-payload control types: NoMessage (0x00), ClientRequestNewSession (0x01), ClientSessionTerminated (0x05), ControllerSessionTerminated (0x06), ControllerCannotStartNewSession (0x07). Single 4-byte header diagram with the type byte highlighted, '(no payload)' shown as a dashed empty box, and all five type values enumerated below. src/assets/diagrams/packet-controller-ack-new-session.svg Type 0x02. 11 bytes total — 4-byte header + 2-byte protocol version (0x00 0x01) + 5-byte SessionID nonce. SessionID cells in accent colour because they're what feed quirk #1's session key XOR mix. Bottom annotation explains the proto-version is hard-coded. src/assets/diagrams/packet-secure-session.svg Types 0x03 and 0x04 share the same shape both directions. Two-row layout: top shows the plaintext (5-byte SessionID echo + 11 zero-pad cells with 'zero pad to 16 bytes'); bottom shows the wire form (header + 16-byte AES ciphertext block). Highlights the symmetric client-up/controller-down design. src/assets/diagrams/packet-omnilink-message.svg Covers all four conversation packet types in one diagram: 0x10 (v1 encrypted), 0x11 (v1 plaintext), 0x20 (v2 encrypted), 0x21 (v2 plaintext). Top row shows the encrypted variant with N x 16-byte ciphertext blocks; brace down to bottom row showing the inner Message format (start byte + length + opcode + data + CRC u16 LE). Same diagram serves all 4 since the layout is identical except for the type byte and whether AES is applied. src/content/docs/reference/protocol.mdx Added five new sections so every PacketType is now documented: - NoMessage (0x00) folded into the ClientRequestNewSession heading (same empty-payload layout) - ClientSessionTerminated (0x05) / ControllerSessionTerminated (0x06) / ControllerCannotStartNewSession (0x07) get a combined section with a one-paragraph explanation of when each fires - OmniLinkMessage (0x10), OmniLinkUnencryptedMessage (0x11), OmniLink2Message (0x20), OmniLink2UnencryptedMessage (0x21) consolidated into one section with the diagram + a note about which TCP/PC-Access actually uses ClientRequestSecureSession + ControllerAckSecureSession merged into one section since they share the diagram; original prose preserved as #### subsections beneath. Build: 23 pages clean. Protocol page now 118 KB (was 92 KB) — six inline SVG titles confirmed via grep on the rendered HTML. Every packet type defined in omni_pca.opcodes.PacketType (12 values) is now visualized in the docs.
hai-omni-docs
Documentation site for omni-pca — a
reverse-engineered Python library and Home Assistant integration for HAI/Leviton
Omni Pro II home automation panels. Built with Astro + Starlight, organised
around the Diátaxis framework.
Live: https://hai-omni-pro-ii.l.warehack.ing
Local development
make install # one-time
make dev # http://localhost:4321 with hot reload
Production build (smoke test)
make ci # runs `npm run build`, output in ./dist
Deploy via Caddy
The container ships its static dist/ from an inner Caddy on :80; the host's
caddy-docker-proxy terminates TLS and routes the configured DOMAIN to it via
the external caddy network.
cp .env.example .env # adjust COMPOSE_PROJECT / DOMAIN as needed
make build
make up # then tails logs
Layout
src/
content/docs/
index.mdx
start/ # Overview + Quick start
tutorials/ # Diátaxis: learning-oriented
how-to/ # Diátaxis: task-oriented
reference/ # Diátaxis: information-oriented (protocol, file format, API)
explanation/ # Diátaxis: understanding-oriented (quirks, architecture, bugs)
journey.md # Chronological retrospective
changelog.md
styles/theme.css # Slate-blue + amber accent
assets/logo.svg
Source project
- Library + integration: https://github.com/rsp2k/omni-pca
Description
Languages
MDX
93.4%
JavaScript
2.7%
CSS
1.5%
Dockerfile
1.3%
Makefile
0.8%
Other
0.3%