Files
LEDMatrix/docs
ChuckandClaude Opus 5.5 5a7893b11a feat(web): Schedule and General become ES-module pages (stage 3) (#767)
* feat(web): Schedule and General become ES-module pages (stage 3)

Schedule and General follow stage 2 (#727): no inline scripts or inline
handlers in either partial. Their code moves to static/v3/js/pages/schedule.js
and pages/general.js, started per swap-in by the page registry.

- Schedule: both pickers are drawn from the saved config carried as JSON in
  data-* attributes. The forms' hx-on save handlers become one
  htmx:afterRequest listener on the page; the forms are marked
  data-reports-result, which app.js now treats like an hx-on after-request
  handler, so a save still shows one notification.
- General: the timezone picker reads data-timezone. The Security section's
  forms and buttons are delegated data-actions; requests go through
  core/api.js, so the login redirect is quiet, and a change made just
  before a swap is still reported.
- handleScheduleResponse, handleDimScheduleResponse and webLogin stay as
  deprecated aliases through window.LEDMatrix.
- New DOM suites test_schedule_page.js and test_general_page.js; the web
  login unit suite imports the module; test_es_modules.py pins the pages,
  the aliases, and the schedule config's round trip through its attribute.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* refactor(web): no unused catch bindings or computed writes in the stage 3 modules

Codacy flagged two unused catch variables and dynamic-key writes in
pages/schedule.js and boot.js. The schedule config is read with
getAttribute, and the default days and the webLogin alias object are built
with Object.fromEntries. No behaviour change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 23:18:02 -04: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 (PERMISSIONS.md for "Permission denied")
  6. SSH_UNAVAILABLE_AFTER_INSTALL.md — recovering SSH after install
  7. CONFIG_DEBUGGING.md — diagnosing config problems
  8. LOW_MEMORY_BOARDS.md — Pi Zero 2 W / 3B+ / 1GB Pi 4 memory limits

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

Audits

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, delete it (it stays in the repository history) and fix the links to it; test/test_doc_links.py fails on broken relative links.
  • Keep examples runnable — paths, commands, and config keys here should match what's actually in the repo.