ChuckandClaude Opus 5 bdb9a94033 refactor(api-v3): split the 10,469-line blueprint into a package (#553)
* refactor(api-v3): split the 10,469-line blueprint into a package

web_interface/blueprints/api_v3.py held 111 routes, 56 helpers and 181
functions in one module -- 9% of the core by line count and three times the
next largest file. It becomes a package of nine route modules grouped by path
segment, plus __init__.py for the shared imports, constants, Blueprint and
helpers.

Every route module decorates the SAME api_v3 Blueprint object, so endpoint
names stay api_v3.<function>, the URL map is unchanged and app.py is untouched.
Verified: 111 routes before, 111 after, byte-identical rules, endpoints and
methods, and every endpoint still on the one blueprint.

  plugins   3,867   config    1,178   starlark  692   system  619
  fonts       452   misc        398   wifi      361   display 326   backup 212
  __init__  1,787 (imports, constants, Blueprint, 56 helpers)

Two things the URL-map check could not catch, both found by running the suite:

1. PROJECT_ROOT = Path(__file__).parent.parent.parent. Moving the code one
   directory deeper made that resolve to web_interface/ instead of the project
   root. Nothing failed at import; it surfaced as ~110 tests failing with 404s
   and "installation script not found", because every path built from it was
   one level too shallow. Now parents[3], and test_api_v3_url_map.py asserts
   PROJECT_ROOT/run.py exists so the next move cannot repeat it.

2. Module-attribute patching. Tests do
   monkeypatch.setattr(api_v3_module, "_BACKUP_EXPORT_DIR", ...) and a route
   module that binds such a name by value never sees the patch. The shared code
   therefore stays in __init__.py rather than moving to a _common submodule --
   it has to live on the module the tests patch -- and the eleven names tests
   patch are read back through the package (_pkg.X) instead of bound by value.
   Those eleven were found by AST-scanning every setattr in the test tree, not
   by guessing; "time" is among them, used to drive a fake clock through the
   second-resolution credential-backup filenames.

Test changes are confined to what genuinely moved: patch targets that now name
the owning route module, imports of helpers, and six tests that scan the api_v3
source as a file and now read the package directory.

Full suite: 4,278 passed, 68 skipped, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014RRtqXDCnvnY6EQwhT5CV9

* fix(api-v3): address CodeRabbit findings from the blueprint-split review

Fixes to the api_v3 package split (PR #553), one per finding verified
against the actual code:

- __init__.py: _redact_credentials only blanked scalar values under a
  credential-named key; a bare list of secrets under such a key (e.g.
  tokens: ["a", "b"]) passed through untouched, since the list branch
  recursed with no memory that its key looked like a credential. Nested
  dicts still walk normally (a documented, tested behaviour -- a container
  like secrets: {api_key: ..., note: ...} is a section name, not a value to
  blank outright), but any value reached under a credential-shaped key is
  now actually blanked.

- __init__.py: the OAuth helper script's raw stderr/stdout went to
  logger.error unredacted (CWE-532) right next to a comment claiming this
  was deliberate; the HTTP response already used the existing redact_text
  helper. Routed the log line through the same helper.

- __init__.py / starlark.py: the standalone Starlark manifest fallback
  (used when the plugin instance isn't loaded) read-modified-wrote
  manifest.json with no lock, unlike StarlarkAppsPlugin._update_manifest_safe
  (plugin-repos/starlark-apps/manager.py), which already holds an flock for
  the same file when the plugin is loaded. Added _starlark_manifest_lock,
  mirroring that pattern, and wrapped every standalone read-modify-write
  call site in it. The app-config update route also wrote config.json and
  the manifest as two separate, non-transactional writes (a second,
  distinct finding at the same call site); config.json is now rolled back
  if the manifest write that follows it fails.

- backup.py: restore options used bare bool() on values from the request,
  so {"restore_secrets": "false"} restored secrets anyway (bool("false") is
  True). Switched to the existing _coerce_to_bool helper already used for
  this exact purpose elsewhere in the package.

- config.py: an automated import-rewrite mangled four user-facing
  validation strings and their neighbouring comments -- "Invalid start
  time" had become "Invalid start _pkg.time" (and likewise for "end time")
  in both the schedule and dim-schedule per-day validation paths.

- display.py: `import _pkg.time as time_module` -- _pkg is a local alias
  for the package, not a real importable module, so this raised
  ModuleNotFoundError whenever a caller restarted an already-running
  display service via /display/on-demand/start, after the on-demand
  request was already written to cache. Fixed to `import time`. Audited
  the rest of the package for the same `_pkg.<module>` import mistake;
  every other `_pkg.` reference is a legitimate attribute read-through
  (`_pkg.time.time()`, `_pkg._get_starlark_plugin()`, ...), not a broken
  import statement.

- fonts.py: validate_file_upload's max_size_mb parameter is silently
  unused by that helper (it only checks filename/extension) -- the font
  upload route saved arbitrarily large files as a result. Added the same
  seek-and-check pattern already used for the sibling .star upload.

- wifi.py: two ad hoc, inconsistent bool coercions. POST
  /wifi/ap/auto-enable used bare bool(), so a JSON string "false" enabled
  it. POST /wifi/radio's enabled/force parsing recognized real bool and
  some strings but not int 1/0 (1 is True is False in Python). Factored one
  small _parse_bool_ish helper local to this file and used it at all three
  sites.

Not changed: the "unknown/misspelled restore option keys default to True"
half of the backup.py finding -- the file's own comment documents that a
missing key deliberately means "restore everything," matching the
already-existing JSON-parse-failure guard a few lines above it; only the
bool-coercion defect was a real bug.

Added or extended regression tests for every fix, following each area's
existing test conventions. Full suite: 4328 passed, 62 skipped, 2 failed
on both this branch and origin/main (missing tzdata package breaks two
timezone-alias tests in test_onboarding_checklist.py, unrelated to this
change) -- no new failures.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S3bPMESe2TfrGvbs1ef9c5

* fix(api-v3): reject unknown restore option keys

CodeRabbit's review of the blueprint split (#553) asked that
POST /backup/restore reject option keys outside RestoreOptions'
known set. The follow-up commit fixed the bool("false")-is-True
bug with _coerce_to_bool but never added the key check: a typo'd
or renamed key (e.g. "restoreSecrets") is silently ignored by
opts_dict.get(key, True), so the flag stays at its True default
and secrets get restored despite the caller's request saying
otherwise -- with no indication anything was wrong.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vmcwf5vMgYqdt8bJTZtiwb

* fix(api-v3): address CodeRabbit findings on the blueprint split

- _redact_credentials: blank scalar descendants of objects reached
  through a credential-owned list (e.g. tokens: [{"value": "secret"}])
  regardless of field name -- the existing name-based walk only
  protected direct dict values under a credential key, not list items.
- wifi.py: reject enabled/force/auto_enable_ap_mode values
  _parse_bool_ish can't recognize (400) instead of silently treating
  them as False, which could disable Wi-Fi or the radio itself.
- Starlark manifest locking: lock a stable manifest.json.lock sidecar
  instead of manifest.json itself, in both the standalone route path
  (_starlark_manifest_lock) and the plugin path
  (StarlarkAppsPlugin._save_manifest / _update_manifest_safe).
  manifest.json is replaced by an atomic rename on every write, which
  swaps in a fresh inode; a lock held on the old inode does not
  exclude a second locker that opens the path afresh right after the
  rename and gets the new inode, so two writers could race despite
  each holding "a lock". A sidecar that no write ever touches always
  resolves to the same inode for every locker.

Skipped as stale: the "serialize the complete manifest
read-modify-write" finding at api_v3/__init__.py -- every standalone
handler that calls _write_starlark_manifest is already wrapped in
_starlark_manifest_lock() on this branch.

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

* fix(api-v3): re-check reconciliation findings by the reconciler's own rules

Both CodeRabbit findings on the merge commit, verified against the code first.

Major, plugins.py: the stale-findings filter derived its own notion of "in
config" and "on disk", and both were looser than the reconciliation module's.
set(load_config()) also contains system keys, the secrets-file keys load_config()
merges in, and non-dict values; and any directory holding a manifest.json
counted as installed even when that manifest does not parse. Either looseness
clears a finding that is still true -- and a secrets key read as a plugin is the
precise bug the filter exists to stop reporting, so reintroducing that asymmetry
while re-checking was the wrong way round.

The two extractions now live in state_reconciliation.py as config_plugin_ids()
and disk_plugin_ids(), with ignored_config_keys() and secrets_top_level_keys()
alongside. _get_config_state() and _get_disk_state() use them too, so there is
one definition rather than two that can drift. _get_disk_state() re-reads each
manifest for version/name after taking membership from the shared extractor;
that costs one extra small read per plugin on a path that runs once per boot.

Minor, the new test: the fixture assigned api_v3.config_manager and
api_v3.plugin_manager directly. Those live on a module-level blueprint
singleton, so the mocks leaked into every later test that imports api_v3 --
pointing at a tmp_path already deleted. Both now go through monkeypatch.setattr,
which restores them. This is the same pollution class that made an earlier test
in this session break seven unrelated ones, so it is worth getting right.

Five cases added for the parity itself: a secrets key, a system key and a
non-dict value must not clear an "installed but missing from config" finding,
and neither an unparseable manifest nor a .standalone-backup- directory may
count as installed. All five fail against the looser version.

Linux CI on the preceding commit: Core unit tests, plugin harness, CodeQL and
CodeRabbit all pass. Codacy reads action_required on every commit of this
branch including the first, so it is pre-existing and not from this work.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-11 10:07:38 -04:00
2025-12-27 14:15:49 -05:00
2025-04-07 16:44:16 -05:00
2025-12-27 14:15:49 -05:00
2026-08-26 09:13:23 -04:00

LEDMatrix

License Discord GitHub Stars Codacy Badge

Welcome to LEDMatrix!

Welcome to the LEDMatrix Project! This open-source project enables you to run an information-rich display on a Raspberry Pi connected to an LED RGB Matrix panel. Whether you want to see your calendar, weather forecasts, sports scores, stock prices, or any other information at a glance, LEDMatrix brings it all together.

About This Project

LEDMatrix is a constantly evolving project that I'm building to create a customizable information display. The project is designed to be modular and extensible, with a plugin-based architecture that makes it easy to add new features and displays.

This project is open source and supports third-party plugin development. I believe that great projects get better when more people are involved, and I'm excited to see what the community can build together. Whether you want to contribute to the core project, develop your own plugins, or just use and enjoy LEDMatrix, you're welcome here!

A Note from the ChuckBuilds

I'm very new to all of this and am heavily relying on AI development tools to create this project. This means I'm learning as I go, and I'm grateful for your patience and feedback as the project continues to evolve and improve.

I'm trying to be open to constructive criticism and support, as long as it's a realistic ask and aligns with my priorities on this project. If you have ideas for improvements, find bugs, or want to add features to the base project, please don't hesitate to reach out on Discord or submit a pull request. Similarly, if you want to develop a plugin of your own, please do so! I'd love to see what you create.

Installing the LEDMatrix project on a pi video:

Installing LEDMatrix on a Pi

Setup video and feature walkthrough on Youtube (Outdated but still useful) :

Outdated Video about the project


Connect with ChuckBuilds


Special Thanks to:

  • Hzeller for his groundwork on controlling an LED Matrix from the Raspberry Pi
  • Cursor for making this project possible
  • CodeRabbit for fixing my PR's
  • Everyone involved in this project for their patience, input, and support

Core Features

Core Features LEDMatrix is a plugin platform: the displays below are plugins installed from the built-in Plugin Store (web interface → Plugins), where each can be individually enabled, ordered, and configured — display durations, teams, stocks, weather, timezones, and more. The core repo ships with just two bundled plugins (`starlark-apps` and `web-ui-info`); the official plugins live in the [ledmatrix-plugins](https://github.com/ChuckBuilds/ledmatrix-plugins) monorepo and install with one click, and third-party plugins can be installed from their own GitHub repositories. Displays available in the store include:

Time and Weather

  • Real-time clock display (2x 64x32 Displays 4mm Pixel Pitch) DSC01361

  • Current Weather, Daily Weather, and Hourly Weather Forecasts (2x 64x32 Displays 4mm Pixel Pitch) DSC01362 DSC01364 DSC01365

  • Google Calendar event display (2x 64x32 Displays 4mm Pixel Pitch) DSC01374-1

Sports Information

The system supports live, recent, and upcoming game information for multiple sports leagues:

  • NHL (Hockey) (2x 64x32 Displays 4mm Pixel Pitch) DSC01356 DSC01339 DSC01337

  • NBA (Basketball)

  • MLB (Baseball) (2x 64x32 Displays 4mm Pixel Pitch) DSC01359

  • NFL (Football) (2x 96x48 Displays 2.5mm Pixel Pitch) image

  • NCAA Football (2x 96x48 Displays 2.5mm Pixel Pitch) image

  • NCAA Men's Basketball

  • NCAA Men's Baseball

  • Soccer (Premier League, La Liga, Bundesliga, Serie A, Ligue 1, Liga Portugal, Champions League, Europa League, MLS)

  • (Note, some of these sports seasons were not active during development and might need fine tuning when games are active)

Financial Information

  • Near real-time stock & crypto price updates
  • Stock news headlines
  • Customizable stock & crypto watchlists (2x 64x32 Displays 4mm Pixel Pitch) DSC01366 DSC01368

Entertainment

  • Music playback information from multiple sources:
    • Spotify integration
    • YouTube Music integration
  • Album art display
  • Now playing information with scrolling text (2x 64x32 Displays 4mm Pixel Pitch) DSC01354 DSC01389

Custom Display Features

  • Custom Text display (2x 64x32 Displays 4mm Pixel Pitch) DSC01379

  • Youtube Subscriber Count Display (2x 64x32 Displays 4mm Pixel Pitch) DSC01376


Hardware

Hardware Requirements

Hardware Requirements

⚠️ IMPORTANT
This project can be finnicky! RGB LED Matrix displays are not built the same or to a high-quality standard. We have seen many displays arrive dead or partially working in our discord. Please purchase from a reputable vendor.

Raspberry Pi

  • Raspberry Pi Zero's don't have enough processing power for this project.
  • Raspberry Pi 3B, 4, or 5 Amazon Affiliate Link – Raspberry Pi 4 4GB RAM Amazon Affiliate Link – Raspberry Pi 4 8GB RAM
    • Pi 5 users: the installer automatically detects Pi 5 and builds the rpi-rgb-led-matrix library with RP1 support. If you previously installed on a Pi 4 and migrated the SD card, or if you see mmap errors in the logs, force a fresh library build:
      sudo RPI_RGB_FORCE_REBUILD=1 ./first_time_install.sh
      
    • Pi 5 config: leave rp1_rio at 0 (PIO mode, default) and set gpio_slowdown to 1 or 2.
    • 1GB models (Pi 3B / 3B+) and other low-memory boards: supported, but the rpi-rgb-led-matrix C++ build needs more memory than the Pi has. The installer detects this automatically, compiles with fewer parallel jobs, and adds a temporary swapfile for the build which it removes afterwards. Expect that step to take 15-25 minutes instead of 2-5, and leave at least 3GB free on the SD card. If you manage swap yourself, opt out with --skip-swap. To pin the compiler down further, use --build-jobs 1.

RGB Matrix Bonnet / HAT

LED Matrix Panels

(2x in a horizontal chain is recommended)

  • Adafruit 64×32 – designed for 128×32 but works with dynamic scaling on many displays (pixel pitch is user preference) **Warning: Lately the Waveshare Panels have had different variations - only some are compatible with this project. I hope to identify what is different to fix it but so far there is a decent chance you get a mis-matched set of panels if you don't buy them all at once! **
  • Waveshare 64×32 - Does not require E addressable pad
  • Waveshare 96×48 – higher resolution, requires soldering the E addressable pad on the Adafruit RGB Bonnet to “8” OR toggling the DIP switch on the Adafruit Triple LED Matrix Bonnet (no soldering required!)
  • There are some Panels on Aliexpress that have worked fine for me, shop around! I think Adafruit is probably the "safest" but they do have some limitation on resolution and layout.

    Amazon Affiliate Links – ChuckBuilds receives a small commission on purchases

Power Supply

  • 5V 4A DC Power Supply (good for 2 -3 displays, depending on brightness and pixel density, you'll need higher amperage for more)
  • 5V 10A DC Power Supply (good for 6-8 displays, depending on brightness and pixel density)
  • By soldering a jumper between pins 4 and 18, you can run a specialized command for polling the matrix display. This provides better brightness, less flicker, and better color.
  • If you do the mod, we will use the default config with led-gpio-mapping=adafruit-hat-pwm, otherwise just adjust your mapping in config.json to adafruit-hat
  • More information available: https://github.com/hzeller/rpi-rgb-led-matrix/tree/master?tab=readme-ov-file DSC00079

Possibly required depending on the display you are using.

  • Some LED Matrix displays require an "E" addressable line to draw the display properly. The 64x32 Adafruit display does NOT require the E addressable line, however the 96x48 Waveshare display DOES require the "E" Addressable line.
  • Various ways to enable this depending on your Bonnet / HAT.

Your display will look like it is "sort of" working but still messed up. image or image or image

How to set addressable E line on various HATs:

  • Adafruit Single Chain HATs IMG_5228 or image

  • Adafruit Triple Chain HAT 6358-06

  • ElectroDragon RGB LED Matrix Panel Drive Board RGB-Matrix-Panel-Drive-Board-For-Raspberry-Pi-02-768x574

2 Matrix display with Rpi connected to Adafruit Single Chain HAT. DSC00073

Mount / Stand options

Mount/Stand

I 3D printed stands to keep the panels upright and snug. STL Files are included in the Repo but are also available at https://www.thingiverse.com/thing:5169867 Thanks to "Randomwire" for making these for the 4mm Pixel Pitch LED Matrix.

Special Thanks for Rmatze for making:

These are not required and you can probably rig up something basic with stuff you have around the house. I used these screws: https://amzn.to/4mFwNJp (Amazon Affiliate Link)


Installation Steps

Preparing the Raspberry Pi

Preparing the Raspberry Pi

⚠️ IMPORTANT
It is required to use the NEW Raspberry Pi Imager tool. If your tool doesn't look like my screenshots, be sure to update it.
  1. Create RPI Image on a Micro-SD card (I use whatever I have laying around, size is not too important but I would use 8gb or more) using Raspberry Pi Imager

  2. Choose your Raspberry Pi (3B+ in my case)

Step 1 rpi
  1. For Operating System (OS), choose "Other"
Step 2 Other
  1. Then choose Raspbian OS (64-bit) Lite (Trixie)
Step 4 Trixie Lite 64
  1. For Storage, choose your micro-sd card
⚠️ IMPORTANT
Make sure it's the correct drive! Data will be erased!
Step 5 Select storage
  1. Choose the hostname of the device. This will be often used to access the web-ui and will be the name of the device on your network. I recommend "ledpi".
Step 6 name storage
  1. Choose your timezone and keyboard layout.
Step 7 Choose Timezone
  1. Set your username and password. This is your "root" password and is important, make sure you remember it! We will use it to access the Raspberry Pi via SSH.
Step 8 set password for root
  1. (Optional) Choose your Wi-fi network and enter wifi password. This can be changed in the future. This is also optional if you are going to connect it via ethermet.
Step 9 choose network
  1. Enable SSH and opt for "Use Password Authentication". You can use public key auth if you know how but for the sake of new folks, let's use the password that we chose in Step 9.
Step 10 enable Ssh and choose password authentication
  1. Disable Raspberry Pi Connect. It's a VPN / Remote Connection tool built into Raspberry Pi, it seems like there might be a subscription? Not sure but I am not using it.
step 11 disable RPI connect
  1. Double check your settings then confirm by clicking "Write".
step 12 write to disk
  1. Final warning to be SURE that you have the correct micro-sd card inserted and selected as all data on the drive will be erased.
Step 13 be very sure you are using the right drive

You're done with preparing the Operating System. Once the Raspberry Pi Imager has finished writing to the micro-sd card it will let you know it is safe to eject. Eject the micro-sd card and plug it into the Raspberry Pi and turn it on.

System Setup & Installation

System Setup & Installation

Once your Raspberry Pi has turned on and connected to your wifi (check your router's dhcp leases) or just give it a few minutes after plugging it in. We will connect via ssh.

Secure Shell (SSH) is a way to connect to the device and execute commands. On Windows, I recommend using Powershell. On MacOS or Linux, I recommend using Terminal.

  1. SSH into your Raspberry Pi:
ssh ledpi@ledpi

The format "username@hostname" is coincidentally the same for this project (which is fine) but if you changed the username, hostname, or your router's DNS doesn't recognize the hostname you would use "username@ipaddress". You can skip the username and just enter "ssh hostname" or "ssh ipaddress" and it will prompt you for a username.

Paste this single command into SSH using Ctrl+Shift+V on Windows or Shift+Command+V on Mac.

Tip

Terminal can be funky about pasting with just Ctrl+V, by right click -> paste or using Ctrl+Shift+V you will be able to paste without additional unwanted characters.

curl -fsSL https://raw.githubusercontent.com/ChuckBuilds/LEDMatrix/main/scripts/install/one-shot-install.sh | bash

This one-shot installer will automatically:

  • Check system prerequisites (network, disk space, memory, sudo access)
  • Install required system packages (git, python3, build tools, etc.)
  • Clone or update the LEDMatrix repository
  • Run the complete first-time installation script

The installation process typically takes 10-30 minutes depending on your internet connection and Pi model. Pi 3B/3B+ and other 1GB boards land at the top of that range, because the C++ library is compiled serially to stay within available memory. All errors are reported explicitly with actionable fixes.

Note: The script is safe to run multiple times and will handle existing installations gracefully.

Manual Installation (Alternative)

If you prefer to install manually or the one-shot installer doesn't work for your setup:

  1. SSH into your Raspberry Pi:
ssh ledpi@ledpi
  1. Update repositories, upgrade Raspberry Pi OS, and install prerequisites:
sudo apt update && sudo apt upgrade -y
sudo apt install -y git python3-pip cython3 build-essential python3-dev python3-pillow scons
  1. Clone this repository:
git clone https://github.com/ChuckBuilds/LEDMatrix.git
cd LEDMatrix
  1. Run the first-time installation script:
chmod +x first_time_install.sh
sudo bash ./first_time_install.sh

This single script installs services, dependencies, configures permissions and sudoers, and validates the setup.

It finishes by asking whether to reboot. If you run it non-interactively — piped, over a script, or with -y — there is no one to ask, so it reboots immediately without prompting. Pass --no-reboot-prompt to install without rebooting:

sudo bash ./first_time_install.sh -y --no-reboot-prompt

Configuration

Configuration

Configuration

Initial Setup

For a complete list of every key in config.json and config_secrets.json, see docs/CONFIG_REFERENCE.md.

For most settings I recommend using the web interface: Edit the project via the web interface at http://[IP ADDRESS or HOSTNAME]:5000 or http://ledpi:5000 .

If you need to manually edit your config file, you can follow the steps below:

Manual Config.json editing
  1. First-time setup: The previous "First_time_install.sh" script should've already copied the template to create your config.json:

  2. Edit your configuration:

sudo nano config/config.json

Automatic Configuration Migration

The system automatically handles configuration updates:

  • New installations: Creates config.json from the template automatically
  • Existing installations: Automatically adds new configuration options with default values when the system starts
  • Backup protection: Creates a backup of your current config before applying updates
  • No conflicts: Your custom settings are preserved while new options are added

Everything is configured via config/config.json and config/config_secrets.json and are not tracked by Git to prevent conflicts during updates.

Running the Display

Recommended: Use Web UI Quick Actions

I recommend using the web-ui "Quick Actions" to control the Display.

image

Plugins

LEDMatrix uses a plugin-based architecture where all display functionality is implemented as plugins. All managers that were previously built into the core system are now available as plugins through the Plugin Store.

Plugin Store

See the Plugin Store documentation for detailed installation instructions.

The easiest way to discover and install plugins is through the Plugin Store in the LEDMatrix web interface:

  1. Open the web interface (http://your-pi-ip:5000)
  2. Navigate to the Plugin Manager tab
  3. Browse available plugins in the Plugin Store
  4. Click Install on any plugin you want
  5. Configure and enable plugins through the web UI

Installing 3rd-Party Plugins

You can also install plugins directly from GitHub repositories:

  • Single Plugin: Install from any GitHub repository URL
  • Registry/Monorepo: Install multiple plugins from a single repository

See the Plugin Store documentation for detailed installation instructions.

For plugin development, check out the Hello World Plugin repository as a starter template.

Visual Skins for Scoreboards

Want a different look for a sports scoreboard without forking the plugin? Skins restyle the live/recent/upcoming screens while the plugin keeps handling data, scheduling, caching, and vegas mode. Install one with git clone <skin repo> skins/<skin-id>, select it in the plugin's config, and you're done — see docs/SKIN_SYSTEM.md (how it works) and docs/CREATING_SKINS.md (build your own, including a ready-made Claude Code prompt).

  1. Built-in Managers Deprecated: The built-in managers (hockey, football, stocks, etc.) are now deprecated and have been moved to the plugin system. You must install replacement plugins from the Plugin Store in the web interface instead. The plugin system provides the same functionality with better maintainability and extensibility.

Detailed Information

Display Settings from RGBLEDMatrix Library

Display Settings

If you are copying my exact setup, you can likely leave the defaults alone. However, if you have different hardware or want to customize the display behavior, these settings allow you to fine-tune the LED matrix configuration.

The display settings are located in config/config.json under the "display" key and are organized into three main sections: hardware, runtime, and display_durations.

Hardware Configuration (display.hardware)

These settings control the physical hardware configuration and how the matrix is driven.

Basic Panel Configuration

  • rows (integer, default: 32)

    • Number of LED rows (vertical pixels) in each panel
    • Common values: 16, 32, 48, 64
    • Must match your physical panel configuration
  • cols (integer, default: 64)

    • Number of LED columns (horizontal pixels) in each panel
    • Common values: 32, 64, 96, 128
    • Must match your physical panel configuration
  • chain_length (integer, default: 2)

    • Number of LED panels chained together horizontally
    • If you have 2 panels side-by-side, set to 2
    • If you have 4 panels in a row, set to 4
    • Total display width = cols × chain_length
  • parallel (integer, default: 1)

    • Number of parallel chains (panels stacked vertically)
    • Use 1 for a single row of panels
    • Use 2 if you have panels stacked in two rows
    • Total display height = rows × parallel

Brightness and Visual Settings

  • brightness (integer, 0-100, default: 90)
    • Display brightness level
    • Lower values (0-50) are dimmer, higher values (50-100) are brighter
    • Recommended: 70-90 for indoor use, 90-100 for bright environments
    • Very high brightness may cause distortion or require more power

Hardware Mapping

  • hardware_mapping (string, default: "adafruit-hat-pwm")
    • Specifies which GPIO pin mapping to use for your hardware
    • "adafruit-hat-pwm": Use this for Adafruit RGB Matrix Bonnet/HAT WITH the jumper mod (PWM enabled). This is the recommended setting for Adafruit hardware with the PWM jumper soldered.
    • "adafruit-hat": Use this for Adafruit RGB Matrix Bonnet/HAT WITHOUT the jumper mod (no PWM). Remove -pwm from the value if you did not solder the jumper.
    • "regular": Standard GPIO pin mapping for direct GPIO connections (Generic)
    • "regular-pi1": Standard GPIO pin mapping for Raspberry Pi 1 (older hardware or non-standard hat mapping)
    • Choose the option that matches your specific hardware setup, if aren't sure try them all.

PWM (Pulse Width Modulation) Settings

These settings affect color fidelity and smoothness of color transitions:

  • pwm_bits (integer, default: 9)

    • Number of bits used for PWM (affects color depth)
    • Higher values (9-11) = more color levels, smoother gradients
    • Lower values (7-8) = fewer color levels, but may improve stability on some hardware
    • Range: 1-11, recommended: 9-10
  • pwm_dither_bits (integer, default: 1)

    • Additional dithering bits for smoother color transitions
    • Helps reduce color banding in gradients
    • Higher values (1-2) = smoother gradients but may impact performance
    • Range: 0-2, recommended: 1
  • pwm_lsb_nanoseconds (integer, default: 130)

    • Least significant bit timing in nanoseconds
    • Controls the base timing for PWM signals
    • Lower values = faster PWM, higher values = slower PWM
    • Typical range: 100-300 nanoseconds
    • May need adjustment if you see flickering or color issues

Advanced Hardware Settings

  • scan_mode (integer, default: 0)

    • Panel scan mode (how rows are addressed)
    • Common values: 0 (progressive), 1 (interlaced)
    • Most panels use 0, but some require 1
    • Check your panel datasheet if colors appear incorrect
  • limit_refresh_rate_hz (integer, default: 100)

    • Maximum refresh rate in Hz (frames per second)
    • Caps the refresh rate for better stability
    • Lower values (60-80) = more stable, less CPU usage
    • Higher values (100-120) = smoother animations, more CPU usage
    • Recommended: 80-100 for most setups
  • disable_hardware_pulsing (boolean, default: false)

    • Disables hardware pulsing (usually leave as false)
    • Set to true only if you experience timing issues
    • Most users should leave this as false
  • inverse_colors (boolean, default: false)

    • Inverts all colors (red becomes cyan, etc.)
    • Useful if your panel has inverted color channels
    • Set to true only if colors appear inverted
  • show_refresh_rate (boolean, default: false)

    • Displays the current refresh rate on the matrix (for debugging)
    • Set to true to see FPS on the display
    • Useful for troubleshooting performance issues

Advanced Panel Configuration (Advanced Users Only)

These settings are typically only needed for non-standard panels or custom configurations:

  • led_rgb_sequence (string, default: "RGB")

    • Color channel order for your LED panel
    • Common values: "RGB", "RBG", "GRB", "GBR", "BRG", "BGR"
    • Most panels use "RGB", but some use "GRB" or other orders
    • Check your panel datasheet if colors appear wrong
  • pixel_mapper_config (string, default: "")

    • Advanced pixel mapping configuration
    • Used for custom panel layouts, rotations, or transformations
    • Examples: "U-mapper", "Rotate:90", "Mirror:H"
    • Leave empty unless you need custom mapping
    • See rpi-rgb-led-matrix documentation for full options
  • orientation (string, default: "normal")

    • Rotates the rendered image to match how the panel is physically mounted
    • Set to "180" (or use the "Upside Down" option in the web UI's Display settings) if the panel is mounted upside down — useful for optimizing where the Raspberry Pi and wiring sit relative to the mounting location
    • Applied independently of pixel_mapper_config (appended as a trailing Rotate:180 mapper), so custom mapper configs keep working alongside it
  • row_address_type (integer, default: 0)

    • How rows are addressed on the panel
    • Most panels use 0 (direct addressing)
    • Some panels require 1 (AB addressing) or 2 (ABC addressing)
    • Check your panel datasheet if display appears corrupted
  • multiplexing (integer, default: 0)

    • Panel multiplexing type
    • 0 = no multiplexing (standard panels)
    • Higher values for panels with different multiplexing schemes
    • Check your panel datasheet for the correct value

Runtime Configuration (display.runtime)

These settings control runtime behavior and GPIO timing:

  • gpio_slowdown (integer, default: 3)
    • GPIO timing slowdown factor
    • Critical setting: Must match your Raspberry Pi model for stability
    • Raspberry Pi 3: Use 3
    • Raspberry Pi 4: Use 4
    • Raspberry Pi 5: Use 1–2 in PIO mode (rp1_rio: 0, the default); start with 1 and increase if you see flickering
    • Raspberry Pi Zero/1: Use 1-2
    • Incorrect values can cause display corruption, flickering, or system instability
    • If you experience issues, try adjusting this value up or down by 1

Display Durations (display.display_durations)

Controls how long each installed plugin stays visible in seconds before switching to the next one, keyed by plugin id.

  • Plugin-specific durations
    • Each plugin can have its own duration setting
    • Format: "<plugin-id>": <seconds>
    • Example: "hockey-scoreboard": 45 shows hockey scores for 45 seconds
    • Example: "weather": 20 shows weather for 20 seconds
    • If a plugin doesn't have a duration here, it uses its default (usually 15 seconds)
    • You can also set display_duration in each plugin's individual configuration

Tips for Display Durations:

  • Longer durations (30-60 seconds) = more time to read content, slower cycling
  • Shorter durations (10-20 seconds) = faster cycling, less time per display
  • Balance based on your preference and how much information each display shows
  • For example, if you want more focus on stocks, increase the stock plugin's duration value

Display Format Settings

  • use_short_date_format (boolean, default: true)
    • Use short date format (e.g., "Jan 15") instead of long format (e.g., "January 15th")
    • Set to false for longer, more readable dates
    • Set to true to save space and show more information

Dynamic Duration Settings (display.dynamic_duration)

  • max_duration_seconds (integer, optional)
    • Maximum duration cap for plugins that use dynamic durations
    • Some plugins can automatically adjust their display time based on content
    • This setting limits how long they can extend (prevents one display from dominating)
    • Example: If set to 60, a plugin can extend up to 60 seconds even if it requests longer
    • Leave unset to use the default cap (typically 90 seconds)

Example Configuration

{
  "display": {
    "hardware": {
      "rows": 32,
      "cols": 64,
      "chain_length": 2,
      "parallel": 1,
      "brightness": 90,
      "hardware_mapping": "adafruit-hat-pwm",
      "scan_mode": 0,
      "pwm_bits": 9,
      "pwm_dither_bits": 1,
      "pwm_lsb_nanoseconds": 130,
      "disable_hardware_pulsing": false,
      "inverse_colors": false,
      "show_refresh_rate": false,
      "limit_refresh_rate_hz": 100
    },
    "runtime": {
      "gpio_slowdown": 4
    },
    "display_durations": {
      "calendar": 30,
      "hockey-scoreboard": 45,
      "weather": 20,
      "stocks": 25
    },
    "use_short_date_format": true,
    "dynamic_duration": {
      "max_duration_seconds": 60
    }
  }
}

Troubleshooting Display Settings

Display is blank or shows garbage:

  • Check rows, cols, chain_length, and parallel match your physical setup
  • Verify hardware_mapping matches your HAT/connection type
  • Try adjusting gpio_slowdown
  • Ensure your display doesn't need the E-Addressable line

Colors are wrong or inverted:

  • Check led_rgb_sequence (try "GRB" if "RGB" doesn't work)
  • Try setting inverse_colors to true
  • Verify hardware_mapping is correct for your hardware

Display flickers or is unstable:

  • Increase gpio_slowdown by 1-2
  • Lower limit_refresh_rate_hz to 60-80
  • Check power supply (LED matrices need adequate power)

Display is too dim or too bright:

  • Adjust brightness (0-100)
  • Very high brightness may require better power supply

Performance issues:

  • Lower limit_refresh_rate_hz
  • Reduce pwm_bits to 8
  • Set pwm_dither_bits to 0
Manual SSH Commands (for reference)

The quick actions essentially just execute the following commands on the Pi.

From the project root directory (ex: /home/ledpi/LEDMatrix):

sudo python3 display_controller.py

This will start the display cycle but only stays active as long as your ssh session is active.

Convenience Scripts

Two convenience scripts are provided for easy service management:

  • start_display.sh - Starts the LED matrix display service
  • stop_display.sh - Stops the LED matrix display service

Make them executable with:

chmod +x start_display.sh stop_display.sh

Then use them to control the service:

sudo ./start_display.sh
sudo ./stop_display.sh
Service Installation Details

The first time install will handle this: The LEDMatrix can be installed as a systemd service to run automatically at boot and be managed easily. The service runs as root to ensure proper hardware timing access for the LED matrix.

Installing the Service (this is included in the first_time_install.sh)

  1. Make the install script executable:
chmod +x scripts/install/install_service.sh
  1. Run the install script with sudo:
sudo ./scripts/install/install_service.sh

The script will:

  • Detect your user account and home directory
  • Install the service file with the correct paths
  • Enable the service to start on boot
  • Start the service immediately

Managing the Service

The following commands are available to manage the service:

# Stop the display
sudo systemctl stop ledmatrix.service

# Start the display
sudo systemctl start ledmatrix.service

# Check service status
sudo systemctl status ledmatrix.service

# View logs
journalctl -u ledmatrix.service

# Disable autostart
sudo systemctl disable ledmatrix.service

# Enable autostart
sudo systemctl enable ledmatrix.service
Web Interface Installation Details

The first time install will handle this: The LEDMatrix system includes Web Interface that runs on port 5000 and provides real-time display preview, configuration management, and on-demand display controls.

Installing the Web Interface Service

The first-time installer (first_time_install.sh) already installs the web service. The steps below only apply if you need to (re)install it manually.

  1. Make the install script executable:
chmod +x scripts/install/install_web_service.sh
  1. Run the install script with sudo:
sudo ./scripts/install/install_web_service.sh

The script will:

  • Copy the web service file to /etc/systemd/system/
  • Enable the service to start on boot
  • Start the service immediately
  • Show the service status

Web Interface Configuration

The web interface can be configured to start automatically with the main display service:

  1. In config/config.json, ensure the web interface autostart is enabled:
{
    "web_display_autostart": true
}
  1. The web interface will now start automatically when:
    • The system boots
    • The web_display_autostart setting is true in your config

Accessing the Web Interface

Once installed, you can access the web interface at:

http://your-pi-ip:5000

Managing the Web Interface Service

# Check service status
sudo systemctl status ledmatrix-web.service

# View logs
journalctl -u ledmatrix-web.service -f

# Stop the service
sudo systemctl stop ledmatrix-web.service

# Start the service
sudo systemctl start ledmatrix-web.service

# Disable autostart
sudo systemctl disable ledmatrix-web.service

# Enable autostart
sudo systemctl enable ledmatrix-web.service

Web Interface Features

  • Real-time Display Preview: See what's currently displayed on the LED matrix
  • Configuration Management: Edit settings through a web interface
  • On-Demand Controls: Start specific displays (weather, stocks, sports) on demand
  • Service Management: Start/stop the main display service
  • System Controls: Restart, update code, and manage the system
  • API Metrics: Monitor API usage and system performance
  • Logs: View system logs in real-time

Troubleshooting Web Interface

Web Interface Not Accessible After Restart:

  1. Check if the web service is running: sudo systemctl status ledmatrix-web.service
  2. Verify the service is enabled: sudo systemctl is-enabled ledmatrix-web.service
  3. Check logs for errors: journalctl -u ledmatrix-web.service -f
  4. Ensure web_display_autostart is set to true in config/config.json

Port 5000 Not Accessible:

  1. Check if the service is running on the correct port
  2. Verify firewall settings allow access to port 5000
  3. Check if another service is using port 5000

Service Fails to Start:

  1. Check Python dependencies are installed
  2. Verify the virtual environment is set up correctly
  3. Check file permissions and ownership

If you've read this far — thanks!


License

LEDMatrix is licensed under the GNU General Public License v3.0 or later.

LEDMatrix builds on rpi-rgb-led-matrix, which is GPL-2.0-or-later. The "or later" clause makes it compatible with GPL-3.0 distribution.

Plugin contributions in ledmatrix-plugins are also GPL-3.0-or-later unless individual plugins specify otherwise.

Contributing

See CONTRIBUTING.md for development setup, the PR flow, and how to add a plugin. Bug reports and feature requests go in the issue tracker. Security issues should be reported privately per SECURITY.md.

S
Description
Raspberry Pi LED Matrix Project
Readme GPL-3.0
218 MiB
Languages
Python 78.2%
JavaScript 12%
HTML 6.2%
Shell 3.2%
CSS 0.4%