Files
LEDMatrix/docs
ChuckBuildsandClaude Opus 5 ed2b81a4fb docs(sports): stop a wrapped PR reference reading as a heading
A line wrapped onto "#433), the newest manifest entry ...", which
markdownlint reads as a malformed ATX heading (MD018). Reflowed so the
line starts with "(#431, #433)" instead.

Not the suggested fix: adding a space after the hash would have turned
the PR reference into "# 433". The B5 safety claim raised alongside this
was already corrected in ac44b5a.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
2026-08-11 12:37:18 -04:00
..
2025-12-27 14:15:49 -05:00
2025-12-27 14:15:49 -05:00

LEDMatrix Documentation

This directory contains guides, references, and architectural notes for the LEDMatrix project. If you are setting up a Pi for the first time, start with the project root README — it covers hardware, OS imaging, and the one-shot installer. The pages here go deeper.

I'm a new user

  1. GETTING_STARTED.md — first-time setup walkthrough
  2. WEB_INTERFACE_GUIDE.md — using the web UI
  3. PLUGIN_STORE_GUIDE.md — installing and managing plugins
  4. WIFI_NETWORK_SETUP.md — WiFi and AP-mode setup
  5. TROUBLESHOOTING.md — common issues and fixes
  6. SSH_UNAVAILABLE_AFTER_INSTALL.md — recovering SSH after install
  7. CONFIG_DEBUGGING.md — diagnosing config problems

I want to write a plugin

Start here:

  1. PLUGIN_DEVELOPMENT_GUIDE.md — end-to-end workflow
  2. PLUGIN_QUICK_REFERENCE.md — cheat sheet
  3. PLUGIN_API_REFERENCE.md — display, cache, and plugin-manager APIs
  4. PLUGIN_ERROR_HANDLING.md — error-handling patterns
  5. DEV_PREVIEW.md — preview plugins on your dev machine without a Pi
  6. EMULATOR_SETUP_GUIDE.md — running the matrix emulator

Going deeper:

Configuring plugins

Advanced features

Reference

Contributing to LEDMatrix itself

Archive

docs/archive/ holds older guides that have been superseded or describe features that have been removed. They are kept for historical context and git history but should not be relied on.

Contributing to the docs

  • Markdown only, professional tone, minimal emoji.
  • Prefer adding to an existing page over creating a new one. If you add a new page, link it from this index in the section it belongs to.
  • If a page becomes obsolete, move it to docs/archive/ rather than deleting it, so links don't rot.
  • Keep examples runnable — paths, commands, and config keys here should match what's actually in the repo.