ChuckandClaude Opus 5.5 7b90759252 fix: /errors stack traces, Wi-Fi disconnect and save, plugin fonts, API cache TTL (#636)
* fix(errors): record the exception's own stack trace

record_error() called traceback.format_exc(), which only sees an
exception while its except block is running. plugin_executor records
exceptions caught on a worker thread after that block has ended, so
every trace on /errors read "NoneType: None". The trace is now built
from the exception's __traceback__. The executor's log call had the
same problem with exc_info=True and now passes the exception.

record_error() also merged LEDMatrixError context into the caller's
dict in place; it now works on a copy.

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

* docs(wifi): point at configure_wifi_permissions.sh instead of a sudoers list

The module docstring told users to grant NOPASSWD sudo on iptables and
ip. configure_wifi_permissions.sh refuses those grants on purpose: a
wildcard rule for either runs an arbitrary program as root. Point at
the script and say why it leaves them out.

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

* fix(wifi): disconnect finds the saved profile by SSID

disconnect_from_network() asked `nmcli -f NAME,802-11-wireless.ssid
connection show` for the profile to take down, but nmcli rejects that
column for `connection show`, so the lookup always failed and only the
device was disconnected. The per-profile lookup _connect_nmcli() already
used is now _find_profile_for_ssid(), and both callers share it. It
also splits terse output on the last colon and unescapes "\:", so a
profile name containing a colon is found.

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

* fix(wifi): write wifi_config.json atomically and report a failed save

_save_config() opened the file for writing in place and swallowed any
error, so a wifi_config.json left owned by root made the web toggle for
auto-enabling AP mode report success while nothing was saved, and a
crash mid-write could truncate the file. It now uses atomic_write_json,
which also keeps the file's owner and shared group when root saves it,
and returns False on failure. POST /wifi/ap/auto-enable answers 500 in
that case.

The file is now written with indent=4, like the other config files.

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

* fix(fonts): resolve plugin:// fonts in the plugin's own directory

FontManager looked for a plugin's bundled fonts under Path("plugins") /
plugin_id: relative to the process cwd, and not the default install
directory (plugin-repos/), so a manifest's plugin:// fonts never loaded.

register_plugin_fonts() takes an optional plugin_dir, and PluginManager
passes the directory it loaded the plugin from. Callers that omit it get
a lookup in the configured plugin_system.plugins_directory, then plugins/,
resolved against the install root.

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

* fix(api-helper): cache responses for the requested cache_ttl

APIHelper.get(cache_ttl=...) and set_cache(ttl=...) dropped the ttl on
the claim that CacheManager does not support one, but CacheManager.set()
takes a ttl, stores it with the entry, and both cache tiers honour it
over a reader's max_age. Without it every response expired after the
300-second default read age, whatever the plugin asked for. The ttl is
now passed through, and the cache read passes cache_ttl as max_age for
entries written without one. The class docstring describes what the
helper actually does.

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

* fix(style): one scale range for the schema, element_scale and LogoHelper

The generated Scale field allowed 0.1 to 10, element_style's reader
capped at 10 with no floor, and LogoHelper accepted 0.05 to 8 and reset
anything else to 1.0. A logo scale of 9, which the form accepts, drew at
the shipped size.

MIN_ELEMENT_SCALE / MAX_ELEMENT_SCALE (0.1, 10.0) in src.element_style
are now the schema bounds and the clamp every reader applies through
coerce_scale(): a positive number outside the range is clamped, and
anything that is not a finite positive number means the default. That
also stops element_scale() passing NaN through, since min(nan, 10.0)
is nan.

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

* fix(logos): placeholder lands at the requested path; empty logos list

download_missing_logo() wrote its fallback placeholder to
<normalize_abbreviation(abbr)>.png in the logo directory rather than to
the logo_path the caller passed, so it could return True while nothing
existed where the plugin looks (e.g. "TA&M.png" vs "TAANDM.png").
create_placeholder_logo() takes an optional filepath, and
download_missing_logo passes the requested one.

download_missing_logo_for_team() only caught KeyError, so a team whose
"logos" list is empty raised IndexError; it now treats KeyError,
IndexError and TypeError as "no logo URL".

The placeholder is drawn with PLACEHOLDER_SIZE / PLACEHOLDER_BG, the
constants is_placeholder_logo() recognises it by, instead of repeated
literals.

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

* fix(fonts): resolve bundled font paths against the install root

TextHelper's default font_dir, the logo placeholder's font and
FontManager's font_overrides.json were all relative to the process cwd,
so a process started anywhere but the install root (the plugin safety
harness, a manual run, a unit without WorkingDirectory) drew with PIL's
default face and read no overrides. They now go through
font_layout.resolve_asset_path; the overrides file sits in the install
root's config/.

The resolver docstrings described an order the code does not follow:
resolve_asset_path never consults the cwd, and sports_shared's
_resolve_font_path tries the cwd first. Both docstrings now say what
the code does, and _resolve_font_path calls resolve_asset_path instead
of probing FontManager for it.

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

* fix(sync): the web UI reads the sync status file the display writes

sync_manager writes its status to tempfile.gettempdir(), but
GET /api/v3/sync/status read a hardcoded /tmp/led_matrix_sync_status.json
and defaulted the port to a literal 5765. Wherever TMPDIR is set (or on
any non-/tmp host) the page only ever showed "starting". The endpoint now
uses sync_manager.STATUS_FILE and SYNC_PORT.

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

* fix(http): the rankings resolver sends the project's User-Agent

DynamicTeamResolver fetched ESPN rankings with a bare requests.get, so
it sent python-requests' default User-Agent, which ESPN rejects; the
AP_TOP_N favourites then resolved to nothing. It now sends
DEFAULT_HTTP_HEADERS. BaseOddsManager carried its own copy of the
User-Agent string and now uses the same shared headers (which also adds
Accept-Language).

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

* fix(backup): record the core release and read the configured plugin dir

The manifest's ledmatrix_version came from a VERSION file that does not
exist, then from .git/HEAD: a 12-character sha, or "ref: refs/he" when
the branch's ref was packed. It is now src.__version__.

list_installed_plugins() scanned a hardcoded plugin-repos/, so on an
install whose plugin_system.plugins_directory points elsewhere, plugins
missing from plugin_state.json were left out of the backup. It now reads
the configured directory from config/config.json, defaulting to
plugin-repos.

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

* fix(startup): report a missing display section once

A config without a display section produced three errors for the one
problem ("Missing required configuration key: display", "Display
configuration is missing or empty" and "Display configuration is
missing"), and an empty one produced two. _validate_config now reports
it once, as a missing key or an empty section, and
_validate_display_config leaves it to that.

The module docstring said the validator fails fast; nothing in the
display service calls raise_on_errors(), so it now says the errors are
reported and startup continues.

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

* refactor(wifi): share the copied blocks and name the AP constants

- _parse_nmcli_wifi_list() is the one parser behind _scan_nmcli and
  _scan_nmcli_cached.
- _verify_connected(), _wait_for_device_idle(), _failsafe_ap() and
  _mark_forced() replace blocks that were pasted two or three times in
  the connect and enable-AP paths. The device-idle wait now checks
  before its first one-second sleep instead of after it.
- _check_command() calls _find_command_path() instead of repeating it.
- AP_IP, PORTAL_PORT, AP_PROFILE_NAME and AP_PROFILE_NAMES name values
  that were spelled out 14, 12, 8 and 2 times; the two deletion loops
  now walk the same tuple. The iwconfig status path compares the AP
  address exactly: startswith() also skipped 192.168.4.10-19.
- Dropped a second WIFI.SIGNAL query that repeated the first, a no-op
  "if ssid: continue", the try/except around _connect_wpa_supplicant's
  constant return, and a second save of a scan scan_networks already
  saves.
- _ensure_wifi_radio_enabled's docstring says it returns True when the
  radio state cannot be read at all.

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

* refactor(config): drop dead branches and history comments in ConfigManager

- The module docstring pointed plugin authors at update_plugin_config(),
  which does not exist; it now names save_config_atomic() and
  save_raw_file_content().
- load_config's FileNotFoundError handler tested the message for
  "config_secrets.json", but a missing secrets file is handled where it
  is read, so only config.json reaches it; the check is gone.
- save_raw_file_content's `file_type == "main" or "secrets"` guard was
  always true (anything else raised earlier).
- get_raw_file_content('secrets') already returns {} for a missing file,
  so the os.path.exists() in front of two calls to it is gone.
- Comments that narrated earlier behaviour are rewritten as what the
  code does now.

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

* refactor(background-data): present-tense comments, drop unused API

- Comments that told the history of each fix (what "used to" happen,
  "the old per-delivery release") now state the invariant the code keeps.
- get_statistics() no longer reports a constant 'queue_size': 0, and the
  uncalled clear_completed_requests() is gone (_cleanup_completed_requests
  does that job on every completion). Neither is referenced in core, the
  web UI or the plugin monorepo.

shutdown_background_service() has no production caller either, but it
is the only way to tear down the get_background_service() singleton,
which the tests rely on, so it stays.

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

* refactor(odds): drop the unread cache_ttl and merge the odds_data branches

BaseOddsManager loaded base_odds_manager.cache_ttl from config and never
used it: cached odds live for the update interval (get_odds' ttl=interval).
No core or monorepo code reads the attribute, so it is gone along with
its log line. The two consecutive `if odds_data:` blocks are one.

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

* refactor(backup): one table for the single-file sections

config, secrets, wifi and ytm_auth were each spelled out in create,
preview, validate and restore. _SINGLE_FILE_SECTIONS lists them once,
with the RestoreOptions flag that restores each, and all four walk it.
Restore error messages keep their wording ("Failed to restore
<file name>").

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

* refactor(fonts): drop FontManager's write-only state and duplicate logs

- fonts_config, font_metadata and font_dependencies were written and
  never read; the performance_stats keys font_load_times, render_times,
  total_renders and the per-call "resolve" timings
  (_record_performance_metric) likewise. get_performance_stats() reads
  only the counters that remain. Nothing in core or the plugin monorepo
  references any of them.
- A failed BDF load was logged twice, by _load_bdf_font and again by
  get_font; get_font's line is the one kept.
- Removed "NEW:" and commented-out cozette entries, the "Copy font to
  assets/fonts" comment on code that copies nothing, and local imports
  of names the module already imports. The deprecated add_font() now
  resolves assets/fonts against the install root.

The @deprecated methods stay.

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

* refactor(text-helper): cache loaded fonts; drop the pre-textlength fallback

TextHelper declared _font_cache, cleared it and reported its size, but
never stored anything in it. load_fonts() now keeps each (file, size)
it loads there, so clear_font_cache() and get_font_cache_stats() mean
what they say and repeated load_fonts() calls reuse the fonts.

get_text_width() no longer catches AttributeError for Pillow releases
without ImageDraw.textlength; requirements.txt pins Pillow>=12.2.
The class docstring describes what the helper does.

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

* docs(common): fix wrong docstrings in api_helper, permission_utils, snapshot_policy

- permission_utils called 0o2775 "sticky bit"; the 2 is setgid, which is
  what makes new files take the directory's group.
- snapshot_policy pointed at web_interface/blueprints/api_v3.py, which
  is a package now; the health check is in api_v3/misc.py.
- APIHelper.clear_cache() lost a history note and a fallback to a
  clear() method that neither CacheManager nor the testing
  MockCacheManager has. The session headers are built from
  DEFAULT_HTTP_HEADERS instead of a copy of them, and the module
  docstring says what the module offers.

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

* docs(sports): present-tense comments in the shared scoreboard renderers

- sports_scroll and sports_game_renderer comments that referred to "this
  PR", "the old flat 128px card" or what the renderer "previously" did
  now describe the current behaviour and its reason.
- The block explaining why non-finite settings are rejected sat above
  _score_reserve_width; it describes _center_gap_width and now lives in
  it.
- unshare_element_fonts wrapped its import of font_layout.load_truetype
  in an `except ImportError` that cannot fire inside core; the import
  stays at call time so tests can spy on the pinned loader.
- sports_card docstrings that told the history of a fix say what the
  code does.

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

* refactor(sports-shared): drop dead code, name the ESPN limit

- _get_weeks_data asked for limit=1000, which fetch_espn_scoreboard
  clamps to ESPN_MAX_LIMIT anyway; it now names that constant. Its
  unused `immediate_events = []` is gone.
- _get_season_schedule_dates() returned ("", "") and has no caller in
  core or the plugin monorepo.
- _should_log keeps its warning_type parameter (part of the inherited
  signature, though nothing in core or the monorepo calls it) and its
  docstring says the cooldown is shared across types.
- An unused ImageFont import is gone.

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

* refactor(sync): one follower-mode switch, shared panel defaults

- The class docstring said the leader sends PNG frames. Frames go over
  UDP as raw RGB; PNG is only the Vegas scroll image sent over TCP. It
  now describes both paths.
- _enter_follower_mode() replaces the two copies of "note the leader,
  switch from standalone to follower, log, write status" in the frame
  and scroll-position handlers.
- The rows/cols fallbacks use DEFAULT_ROWS / DEFAULT_COLS from
  src.display_geometry, as chain_length already did.

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

* refactor(style): drop _layout_axis, name the layout group title

- ElementStyleResolver._layout_axis() had no caller in core or the
  plugin monorepo.
- _element_block_from_spec checked spec['size'] was a dict again after
  size_spec already had; it reads size_spec.
- The "Layout Offsets" title written into three generated schema blocks
  is _LAYOUT_TITLE.

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

* docs(logo-helper): say what the placeholder draws; name the 1.5 box factor

- _create_placeholder_logo's docstring said it draws the team
  abbreviation; it draws an outlined grey box and nothing else. The
  docstring says so, and the "in a real implementation you'd want text"
  comments are gone.
- The 1.5 x panel default logo box, written out six times, is
  DEFAULT_LOGO_BOX_FACTOR.
- ImageDraw is imported with Image at the top of the module.

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

* refactor(logos): drop dead code and a duplicate regex in logo_downloader

- _SAFE_LEAGUE_CODE_RE was the same pattern as _SAFE_LEAGUE_RE; both
  checks use the one.
- get_logo_filename_variations reassigned the TA&M case to the list it
  already had; the function returns the two names directly.
- _get_team_name_variations() had no caller in core or the plugin
  monorepo.
- fetch_single_team's docstring was copied from fetch_teams_data; a log
  message read "for{team_id}".

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

* refactor: drop the Pillow<9.1 resample shim and a catch-and-reraise

- adaptive_images fell back to Image.LANCZOS/NEAREST for Pillow < 9.1;
  requirements.txt pins Pillow>=12.2. RESAMPLE_LANCZOS and
  RESAMPLE_NEAREST keep their names (src.common re-exports them).
- CacheManager.save_cache caught CacheError only to re-raise it; the
  disk write is now called directly, with the same result.

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

* test(api-helper): stop the real CacheManager's cleanup thread

The cache-lifetime tests built a CacheManager and left its cleanup
thread's class-wide claim on the directory in place, which broke
test_cache_cleanup_thread_ownership when it ran later in the session.
The fixture now stops the thread on teardown.

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

* docs(changelog): core-common

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 17:32:29 -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

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 3B, 4, or 5 (a Pi Zero 2 W also works, with the limits described under the 1GB/low-memory bullet below; the original Pi Zero / Zero W doesn't have enough processing power for this project) 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 start gpio_slowdown at 1, raising it a step at a time if the image flickers or shows garbage (see gpio_slowdown under Display Settings).
    • 1GB models (Pi 3B / 3B+), the 512MB Pi Zero 2 W 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. Once running, keep an eye on memory: see docs/LOW_MEMORY_BOARDS.md.

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.
  • The default config uses hardware_mapping adafruit-hat. If you do the mod, change it to adafruit-hat-pwm (Display settings in the web interface, or config.json)
  • 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
  • Print the web interface address, then reboot the Pi automatically (your SSH session will disconnect; give it a few minutes to come back)

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 git (first_time_install.sh installs the build dependencies itself: python3-pip, python-dev-is-python3, build-essential, cmake, ninja-build and the rest):
sudo apt update && sudo apt upgrade -y
sudo apt install -y git
  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, the plugins/hello-world/ plugin in the ledmatrix-plugins repository is a starter template.

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.

The defaults below are the values in config/config.template.json. They are what applies when you haven't set a key: on every load, LEDMatrix adds any key your config.json lacks from the template, so DisplayManager's own fallbacks are never reached on a normal install.

The web UI and the config API refuse values the rgbmatrix library can't start with. If one is written into config.json by hand anyway, the display logs which setting it is (Failed to initialize RGB Matrix in sudo journalctl -u ledmatrix), runs in fallback mode, and the Display tab shows the message.

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
    • An even number from 8 to 64, the most the rgbmatrix library drives per panel
    • 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
    • At least 16, with no upper limit
    • Must match your physical panel configuration
  • chain_length (integer, default: 2)

    • Number of LED panels chained together horizontally
    • 1 to 255 (the library's Python binding stores it in one byte); longer chains lower the refresh rate
    • 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
    • 1–3, and no more than your hardware_mapping has outputs: regular and classic have 3 (e.g. the Adafruit Triple LED Matrix Bonnet); adafruit-hat, adafruit-hat-pwm, regular-pi1 and classic-pi1 have 1. The library stops the display service outright on a mismatch, so it is refused
    • Total display height = rows × parallel

Brightness and Visual Settings

  • brightness (integer, 1-100, default: 90)
    • Display brightness level
    • Lower values (1-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")
    • 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). Also the right choice for the Adafruit Triple LED Matrix Bonnet
    • "regular-pi1": Standard GPIO pin mapping for Raspberry Pi 1 (older hardware or non-standard hat mapping)
    • "classic" / "classic-pi1": the library's original pin-outs, for old adapter boards wired to them. Not used by current HATs
    • Any other name is refused. compute-module is only compiled in when the library is built with ENABLE_WIDE_GPIO_COMPUTE_MODULE, which the installer doesn't do. On a Raspberry Pi 5, classic-pi1 isn't supported
    • Choose the option that matches your specific hardware setup, if aren't sure try them all.
    • Hardware pulsing (see disable_hardware_pulsing) needs the panel's OE line on GPIO 18, which adafruit-hat-pwm and regular provide and adafruit-hat does not

PWM (Pulse Width Modulation) Settings

These settings affect color fidelity and smoothness of color transitions:

  • pwm_bits (integer, 1-11, default: 9)

    • Color depth per channel: how many brightness levels each LED gets
    • Higher values (9-11) = more color levels, smoother gradients, lower refresh rate
    • Lower values (7-8) = the subtlest shades are dropped for a higher refresh rate; 1 gives 8 colors
    • Recommended: 9-10
  • pwm_dither_bits (integer, 0-2, default: 1)

    • Time-dithers the lowest color bits: their brightness comes from showing them on only some frames
    • Raises the refresh rate; the cost is that dark shades can shimmer slightly
    • 0 = steadiest dim colors, 2 = fastest
    • The rgbmatrix library accepts only 0-2; a higher value stops the display starting
  • pwm_lsb_nanoseconds (integer, 50-3000, default: 130)

    • On-time of the least significant color bit; each higher bit doubles it
    • Lower values = higher refresh rate, but can cost color accuracy or add ghosting on some panels
    • Higher values = less ghosting (faint trails behind bright text on black), lower refresh rate
    • Typical range: 100-300 nanoseconds

Advanced Hardware Settings

  • scan_mode (integer, 0-1, default: 0)

    • Order the rows are refreshed in: 0 = progressive, 1 = interlaced
    • Interlaced can look a little smoother when the refresh rate is very low, but usually shows a comb effect on anything moving
    • Leave at 0 unless you are tuning a slow setup
  • limit_refresh_rate_hz (integer, default: 100)

    • Caps the panel refresh rate in Hz; 0 = no cap
    • A steady cap reduces flicker caused by other activity on the Pi, and in camera recordings
    • Scroll speeds are worked out against this value (against 100 Hz when it is 0), so a cap the panel can actually hold keeps scrolling even
    • Recommended: 80-120. sudo python3 scripts/scroll_speeds.py --measure reports the rate your panel really achieves
  • disable_hardware_pulsing (boolean, default: false)

    • false = the Pi's hardware PWM times each brightness pulse; true = software timing
    • Leave false where possible. Software timing is less exact, so a row, or the whole panel, can briefly flash brighter
    • Hardware pulsing needs the panel's OE line on GPIO 18 (adafruit-hat-pwm, regular, the Adafruit Triple LED Matrix Bonnet). With adafruit-hat the library uses software timing anyway
    • It also needs the Pi's onboard sound driver (snd_bcm2835) disabled, which first_time_install.sh does. Set true only if you need the Pi's own audio
  • 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)

    • Prints the live refresh rate to the console; nothing is drawn on the panel
    • Readable when you stop the service and run sudo python3 run.py in a terminal; under the service the output is buffered
    • sudo python3 scripts/scroll_speeds.py --measure is an easier way to see the real refresh rate

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
    • If red shows as blue, try "BGR" (the Waveshare 96x48 V2 needs it)
    • 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
    • "90" and "270" are for a panel mounted on its side; they swap the display's width and height
    • Applied independently of pixel_mapper_config (appended as a trailing Rotate:<degrees> 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)
    • 1 = AB-addressed, 2 = direct row select, 3 = ABC-addressed, 4 = ABC shift + DE direct (SM5266), 5 = SM5368 / B707 row shift register
    • ABC panels (no E line, e.g. many 128x64 FM6124 panels) use 3
    • Panels with SM5368 row drivers use 5 with led_rgb_sequence "BGR" — e.g. the Waveshare 96x48 V2 (back silkscreen 24S-A1; the V1, 24S-A2.1, uses the defaults). This is what Waveshare's 96X48_1_24_SM5368 panel type sets in their library fork.
    • SM5368 row drivers are timing-sensitive: if rows jump up and down or the bottom row shows a copy of other rows, raise gpio_slowdown. On a Pi 4 with an Adafruit Triple LED Matrix Bonnet, 4 left rows jumping; 6–8 gave a stable image.
    • On a Raspberry Pi 5 the rgbmatrix library currently supports only 0 and 2 (and parallel 1-3). Anything else would crash the display service, so on a Pi 5 the web UI offers only 0 and 2, the config API refuses the others, and if one is set in config.json anyway the display logs why and runs in fallback mode
    • Check your panel datasheet if display appears corrupted
  • multiplexing (integer, 0-22, default: 0)

    • How pixels are wired on outdoor/specialty panels (P10, P8, P4 and P3 outdoor modules and similar) whose LEDs aren't laid out in straight rows
    • 0 = direct (standard indoor panels)
    • 1 Stripe, 2 Checkered, 3 Spiral, 4 ZStripe, 5 ZnMirrorZStripe, 6 Coreman, 7 Kaler2Scan, 8 ZStripeUneven, 9 P10-128x4-Z, 10 QiangLiQ8, 11 InversedZStripe, 12–14 P10Outdoor1R1G1B v1–v3, 15 P10CoremanMapper, 16 P8Outdoor1R1G1B, 17 FlippedStripe, 18 P10-32x16-HalfScan, 19 P10-32x16-QuarterScan, 20 P3Outdoor-64x64, 21 DoubleZMultiplex, 22 P4Outdoor-80x40
    • If the image is scrambled in a repeating pattern, try the value named after your panel first
  • panel_type (string, default: "")

    • Sends a start-up initialization sequence to driver chips that need one
    • "" = Standard (no initialization) — right for most panels, including FM6124 / FM6124D / FM6124DJ
    • "FM6126A" or "FM6127" for panels with those chips; try "FM6126A" if the panel stays dark or lights only the first pixel on Standard

Runtime Configuration (display.runtime)

These settings control runtime behavior and GPIO timing:

  • gpio_slowdown (integer, default: 3)

    • GPIO timing slowdown factor (0-10): slows GPIO writes so the panel electronics keep up. Higher is more reliable but lowers the refresh rate
    • Critical setting: depends on your Raspberry Pi model and your panel
    • Raspberry Pi Zero/1: 0-1
    • Raspberry Pi 2/3: 1-3
    • Raspberry Pi 4: 2-4 (the config template ships 3)
    • Raspberry Pi 5: 1–3 in PIO mode (rp1_rio: 0, the default). Start at 1 (the library treats 0 as 1 there) and raise it a step at a time if the image flickers or shows garbage — chained panels are the likeliest to need it
    • Panels on row_address_type 5 (SM5368 row drivers) can need 6-8 on a Pi 4
    • Too low: garbage, flicker or rows jumping. Too high: a lower refresh rate
    • If you experience issues, try adjusting this value up or down by 1
  • rp1_rio (integer, 0 or 1, default: 0) — Raspberry Pi 5 only

    • Which driver the Pi 5's RP1 chip uses: 0 = PIO (default, less CPU), 1 = RIO (registered I/O, can reach a higher refresh rate)
    • In RIO mode the effect of gpio_slowdown is inverted: higher values may be faster
    • Ignored on a Pi 0-4, and applied only if the installed rgbmatrix library supports it

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)
    • Currently has no effect. The web UI still saves it, but no core code reads it. Scoreboard plugins that offer a short date format read the setting from their own plugin config instead. See CONFIG_REFERENCE.md.

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 (180 seconds; the web UI accepts 30-1800)

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
  • If it went blank right after a settings change, the Display tab shows a "simulation mode" banner, and sudo journalctl -u ledmatrix shows Failed to initialize RGB Matrix followed by the reason. When LEDMatrix refused the settings (for example more than 64 rows, parallel 2 on an adafruit-hat mapping, a misspelled hardware_mapping, or on a Raspberry Pi 5 a row_address_type other than 0 or 2), the message names each one: change them, save, and restart the display service. Otherwise the library itself failed, and its own message just before names the problem
  • A repeating scramble points at row_address_type or multiplexing; a panel that stays dark, at panel_type

Rows jump up and down, or the bottom row repeats other rows:

  • Raise gpio_slowdown a step at a time (SM5368 panels on row_address_type 5 can need 6-8 on a Pi 4)

A row or the whole panel briefly flashes brighter:

  • Set disable_hardware_pulsing to false (needs the OE line on GPIO 18; see hardware_mapping)

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 web interface's quick actions (Start/Stop/Restart Display) call sudo systemctl start|stop|restart ledmatrix.service — see execute_system_action() in web_interface/blueprints/api_v3/system.py. The service runs run.py as root.

To run the display in the foreground instead (for debugging), stop the service first, then from the project root (e.g. /home/ledpi/LEDMatrix):

sudo systemctl stop ledmatrix.service
sudo python3 run.py          # add -d for debug logging

This only runs as long as your SSH session stays open.

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 ledmatrix.service (display, runs as root), ledmatrix-web.service (web interface, runs as your user) and the ledmatrix-update-verify units, with the correct paths
  • Enable them to start on boot
  • Start them 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. The installer puts them in the system Python with pip install --break-system-packages (there is no virtual environment), so python3 -c "import flask" should succeed.
  2. 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%