mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-10-04 22:35:08 +00:00
* docs: add ARCHITECTURE and PERMISSIONS guides ARCHITECTURE.md maps the processes, the state the display and web services share through the cache, the display loop, the plugin system, the web UI and the update path, with links into the code and a where-to-start table. PERMISSIONS.md lists who owns what after install, both sudoers files (and why iptables is not granted), the polkit rule, and which scripts/fix_perms script to run as which user. Both are linked from the docs index, along with the MQTT bridge README and src/common/README.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: correct stale setup, service and troubleshooting claims - README: quick actions run systemctl on ledmatrix.service (run.py), not display_controller.py; use_short_date_format has no effect; the installer uses system pip with --break-system-packages, not a venv. - CONFIG_DEBUGGING: LEDMATRIX_DEBUG must be "true"; logs are in journald. - GETTING_STARTED, WEB_INTERFACE_GUIDE, TROUBLESHOOTING: enabling a plugin, plugin settings, brightness and Vegas settings apply without a restart; matrix hardware settings still need one. - TROUBLESHOOTING: install dependencies with sudo so the root service sees them; point permission problems at PERMISSIONS.md instead of a project-wide chown. - ADVANCED_FEATURES: real BackgroundDataService stats keys; Vegas hooks return VegasDisplayMode and None falls back to capture; cache files are 0660; fix_web_permissions.sh runs as the web user and does not touch sudoers. - STARLARK_APPS_GUIDE: only the linux-arm64 pixlet binary is downloaded. - HOW_TO_RUN_TESTS: test class examples that exist. - CLAUDE.md: PluginStoreManager, plugin_dirs.py, monorepo installs via the Trees API with ZIP fallback, requirements.txt is optional. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: mark deprecated plugin APIs and state manifest fields once Methods @deprecated("3.7.0") (the set pinned in test_deprecation.py) were shown as current API in the quick reference, API reference, advanced guide, development guide and FONT_MANAGER. Each is now marked deprecated with its replacement. FONT_MANAGER is rewritten around the current API; the override editor is gone and override methods are deprecated. Required manifest fields were stated three different ways. The API reference now has one section: the 7 schema-required fields, the 4 the store refuses without, class_name for the loader, and the 8 to set. The other guides link to it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: document every src/common module and every widget - src/common/README.md covered 7 of 17 modules. It now has a table of all of them (purpose, whether plugins import it, release to floor on), a short entry each, and logging advice that matches the code. - SPORTS_UNIFICATION listed two shared modules and called sports_helpers the first; it now lists all six. - The widgets README lists all 28 registered widgets plus the support files, and absorbs the parts that only docs/widget-guide.md had (x-options.labels, x-advanced, x-display hidden, plugin-file-manager). docs/widget-guide.md is now a pointer to it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(security): fix_web_permissions.sh re-hardens the root sudo helpers The script chowns the whole project to the web user. That included scripts/fix_perms/safe_plugin_rm.sh and safe_pip_install.sh -- the two helpers /etc/sudoers.d/ledmatrix_web lets the web user run as root -- so running it turned both into a root shell for whoever can edit them. It also re-grouped config_secrets.json away from ledmatrix. After the chown it now does what first_time_install.sh's Steps 11 and 11.1 do: helpers back to root:root 755, and config_secrets.json back to the web unit's User=:ledmatrix 640. Each step is non-fatal and prints the manual command if it fails. Also fixes what the script and its docs claimed: it never configured sudoers, its closing hint pointed at ./configure_web_sudo.sh (wrong path), and the README and ADVANCED_FEATURES.md said to run it with sudo, which it refuses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(security): validate and harden every sudoers drop-in the scripts write configure_wifi_permissions.sh copied its rules into /etc/sudoers.d/ledmatrix_wifi without `visudo -c`. A malformed drop-in makes sudo refuse every command for every user, which on a headless Pi leaves no way back in. It now checks first and leaves the installed file alone when the rules do not parse, as the other two writers do. (It already used mktemp, so that part of the review did not apply.) It also grants the two literal commands wifi_manager.py runs for NetworkManager's shared-mode dnsmasq drop-in -- `cp /tmp/ledmatrix-nm-dnsmasq.conf .../dnsmasq-shared.d/ledmatrix-captive.conf` and `rm -f` of that file. The directory's mkdir was granted, the file was not. Both are pinned in test_sudo_allowlist_covers_calls.py. configure_web_sudo.sh wrote its rules to /tmp/ledmatrix_web_sudoers_$$, a predictable name in a world-writable directory; it now uses mktemp with an EXIT trap, as first_time_install.sh does. It sets mode 440 on the installed file instead of leaving the temp file's mode, and finds visudo in /usr/sbin when that is not on the user's PATH, which skipped the check silently. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(install): escape the project path in the DNS-fix and MQTT unit renderers install_dns_fix.sh and install_mqtt_bridge.sh substituted __PROJECT_ROOT_DIR__ with the raw path, while the other three renderers go through sed_escape_replacement from lib_systemd_render.sh. A checkout under a path containing `&`, `\` or `|` rendered a corrupted unit from these two only. Both now source the helper and use it, and a test checks that every placeholder substitution in scripts/install uses an escaped value. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(install): stop the installer scripts reporting things that are not true - first_time_install.sh printed "Password: ledmatrix123" for the setup access point. wifi_manager creates it as an open network ("No password" on the panel), so it now says so. - Step 10.1 printed "✓ WiFi management permissions configured" straight after its own failure message; install_wifi_monitor.sh printed "✓ Package installation completed" after a failed apt install. The tick now only follows success. - Step 7 printed "Web dependencies already installed ... in Step 5" in the one branch that runs because Step 5 did not install them, then created .web_deps_installed on that basis. It now warns and leaves the marker off so the next run retries, as the comment below it intends. - check_system_compatibility.sh called Debian 12 Bookworm "full compatibility confirmed" while first_time_install.sh refuses anything but Debian 13. Bookworm, older Debian and non-Debian systems are now errors. Its counters used ((X++)), which under `set -e` exits the script at the first warning or error (the expression is 0), so the check never reached its summary on any system with one. - configure_web_sudo.sh and configure_wifi_permissions.sh finished by testing `sudo -n test -f ...` and `sudo -n nmcli device status`, neither of which is granted, so they always reported a failure. They now ask `sudo -n -l` about commands the new rules do grant, which checks the rule without running anything. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(install): print the completion summary before rebooting With -y -- and so for every one-shot `curl | bash` install, which always passes -y -- first_time_install.sh ran `reboot` about 180 lines before its "Installation Complete / Web UI Access" summary. reboot returns at once, so the summary printed while the Pi was going down and the SSH session usually dropped before the web UI address could be read. The reboot block moves, unchanged, to the very end of the script. The interactive prompt now also follows the summary. Because the summary now runs before the -y reboot, its one command that could fail under `set -Eeuo pipefail` (the SSID lookup, when nmcli reports a connected device but no active network line) gets `|| true`; a missing SSID was already handled as "SSID unknown". one-shot-install.sh prints its "Next steps" after the installer returns, by which time the reboot is under way, so it now says so, and README's Quick Install mentions the automatic reboot. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * chore(scripts): correct wrong comments and messages, drop dead code No behaviour change except the output text noted below. - 2775 is setgid, not the sticky bit (first_time_install.sh Step 3.1, fix_plugin_permissions.sh), and root needs no "PWM hardware access" to plugin files. - The 777 comments in first_time_install.sh Step 3's fallback and fix_assets_permissions.sh said root needs it to write. Root ignores mode bits; the comments now say what 777 actually opens. The 777 itself is unchanged. - apt_remove ends in `|| true`, so Step 12's "Some packages could not be removed" branch could never run; it is gone and the helper stays non-fatal. - detect_web_service_user's comment named Step 8 for the web unit (install_service.sh installs it in Step 7.5) and now says which branch actually runs. - Step 5 described an "already installed" check that does not exist; the ACTUAL_USER comment described the re-exec backwards. - on_error printed a literal "\n" before "Common fixes:". - Dead code: one-shot-install.sh's uncalled fix_tmp_permissions, LEDMATRIX_ELEVATED=1 (never read) on the sudo re-exec, and configure_web_sudo.sh's unused PYTHON_PATH, which also made a missing python3 fatal for rules that never mention it. - start_display.sh / stop_display.sh said "for user: <you>"; the service runs as root. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(fix_perms): fix_cache_permissions.sh uses setup_cache.sh's model There were two models for /var/cache/ledmatrix. setup_cache.sh (the installer's Step 2) and install_web_service.sh share it through the ledmatrix group: root:ledmatrix, 2775, files 660, which is also what DiskCache relies on to give files the directory's group. fix_cache_permissions.sh instead made it 777 and re-grouped it to the invoking user's group, undoing that. It now runs setup_cache.sh for /var/cache/ledmatrix and keeps its own handling of ~/.ledmatrix_cache. Dropped: /var/cache/ledmatrix/ placeholder_logos (nothing reads it) and the checks against the `daemon` user (no service runs as daemon). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci: pin actions/checkout in the Claude workflows, drop template comments claude.yml and claude-code-review.yml used actions/checkout@v4 while test.yml and release-version-check.yml pin the v4.2.2 commit SHA; they now pin the same SHA. The commented-out starter-template settings (prompt, claude_args, paths, author filter) are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(scripts): index every script and list removal candidates New scripts/README.md gives one line per top-level script and scripts directory, marked keep, dev-only or diagnostic, and lists the eight scripts nothing in the repo refers to as candidates for removal (kept for now). The install, utils and dev READMEs now list the files they were missing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: tighten two checks that mutation testing showed were too loose - The wifi sudoers check matched `visudo -c -f "$TEMP_SUDOERS"` in the error report too, so replacing the check with `if false` still passed. It now requires the command as the condition. - The summary test never had the setup access point up, so reinstating the bogus "Password: ledmatrix123" line went unnoticed. A case with hostapd active now checks the AP is described as open. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(permissions): describe the repaired fix_perms scripts and new WiFi grants Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(changelog): docs-scripts Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
365 lines
12 KiB
Markdown
365 lines
12 KiB
Markdown
# Getting Started with LEDMatrix
|
||
|
||
## Welcome
|
||
|
||
This guide will help you set up your LEDMatrix display for the first time and get it running in under 30 minutes.
|
||
|
||
---
|
||
|
||
## Prerequisites
|
||
|
||
**Hardware:**
|
||
- Raspberry Pi (3, 4, or 5 recommended)
|
||
- RGB LED Matrix panel (32x64 or 64x64)
|
||
- Adafruit RGB Matrix HAT or similar
|
||
- Power supply (5V, 4A minimum recommended)
|
||
- MicroSD card (16GB minimum)
|
||
|
||
**Network:**
|
||
- WiFi network (or Ethernet cable)
|
||
- Computer with web browser on same network
|
||
|
||
---
|
||
|
||
## Quick Start
|
||
|
||
### 1. Install LEDMatrix
|
||
|
||
There is no prebuilt SD card image — you install LEDMatrix onto stock
|
||
Raspberry Pi OS Lite yourself:
|
||
|
||
1. Flash Raspberry Pi OS Lite to the MicroSD card (Raspberry Pi Imager)
|
||
2. Connect the LED matrix to your Raspberry Pi, insert the card, and
|
||
power on
|
||
3. SSH into the Pi and run the one-shot installer:
|
||
```bash
|
||
curl -fsSL https://raw.githubusercontent.com/ChuckBuilds/LEDMatrix/main/scripts/install/one-shot-install.sh | bash
|
||
```
|
||
or clone the repo and run `sudo ./first_time_install.sh` — see the
|
||
[README Installation Steps / Quick Install](../README.md#installation-steps)
|
||
for full details
|
||
|
||
**Expected Behavior after install:**
|
||
- LED matrix will light up
|
||
- A fresh install ships only the bundled `starlark-apps` and
|
||
`web-ui-info` plugins — clock, weather, sports, etc. must be
|
||
installed from the Plugin Store (web UI → Plugin Manager) before
|
||
anything else displays
|
||
- Pi creates WiFi network "LEDMatrix-Setup" if not connected
|
||
|
||
### 2. Connect to WiFi
|
||
|
||
**If you see "LEDMatrix-Setup" WiFi network:**
|
||
1. Connect your device to "LEDMatrix-Setup" (open network, no password)
|
||
2. Open browser to: `http://192.168.4.1:5000`
|
||
3. Navigate to the WiFi tab
|
||
4. Click "Scan" to find your WiFi network
|
||
5. Select your network, enter password
|
||
6. Click "Connect"
|
||
7. Wait for connection (LED matrix will show confirmation)
|
||
|
||
**If already connected to WiFi:**
|
||
1. Find your Pi's IP address (check your router, or run `hostname -I` on the Pi)
|
||
2. Open browser to: `http://your-pi-ip:5000`
|
||
|
||
### 3. Access the Web Interface
|
||
|
||
Once connected, access the web interface:
|
||
|
||
```
|
||
http://your-pi-ip:5000
|
||
```
|
||
|
||
You should see:
|
||
- Overview tab with system stats
|
||
- Live display preview
|
||
- Quick action buttons
|
||
|
||
---
|
||
|
||
## Initial Configuration (15 Minutes)
|
||
|
||
### Step 1: Configure Display Hardware
|
||
|
||
1. Open the **Display** tab
|
||
2. Set your matrix configuration:
|
||
- **Rows**: match your panel — commonly 32 or 64; any even number
|
||
from 8 to 64
|
||
- **Columns**: match your panel — commonly 64 or 96; at least 16,
|
||
with no upper limit
|
||
- **Chain Length**: Number of panels chained horizontally
|
||
- **Hardware Mapping**: usually `adafruit-hat-pwm` (with the PWM jumper
|
||
mod) or `adafruit-hat` (without). See the root README for the full list.
|
||
- **Brightness**: 70–90 is fine for indoor use
|
||
3. Click **Save**
|
||
4. From the **Overview** tab, click **Restart Display Service** to apply
|
||
|
||
**Tip:** if the display shows garbage or nothing, the most common culprits
|
||
are an incorrect `hardware_mapping`, a `gpio_slowdown` value that doesn't
|
||
match your Pi model, or panels needing the E-line mod. See
|
||
[TROUBLESHOOTING.md](TROUBLESHOOTING.md).
|
||
|
||
### Step 2: Set Timezone and Location
|
||
|
||
1. Open the **General** tab
|
||
2. Set your timezone (e.g., `America/New_York`) and location
|
||
3. Click **Save**
|
||
|
||
Correct timezone ensures accurate time display, and location is used by
|
||
weather and other location-aware plugins.
|
||
|
||
### Step 3: Install Plugins
|
||
|
||
1. Open the **Plugin Manager** tab
|
||
2. Scroll to the **Plugin Store** section to browse available plugins
|
||
3. Click **Install** on the plugins you want
|
||
4. Wait for installation to finish — installed plugins appear in the
|
||
**Installed Plugins** section above and get their own tab in the second
|
||
nav row
|
||
5. Toggle the plugin to enabled. The running display loads it within a
|
||
few seconds; no restart is needed
|
||
|
||
You can also install community plugins straight from a GitHub URL using the
|
||
**Install from GitHub** section further down the same tab — see
|
||
[PLUGIN_STORE_GUIDE.md](PLUGIN_STORE_GUIDE.md) for details.
|
||
|
||
### Step 4: Configure Plugins
|
||
|
||
1. Each installed plugin gets its own tab in the second navigation row
|
||
2. Open that plugin's tab to edit its settings (favorite teams, API keys,
|
||
update intervals, etc.)
|
||
3. Click **Save**. The display service watches `config.json` and hands the
|
||
new settings to the running plugin, so no restart is needed. If a plugin
|
||
still shows old settings, restart the display service from **Overview**
|
||
|
||
**Note:** how long each plugin stays on screen is not set in the
|
||
plugin's own tab — use the **Rotation** tab's **Screen Durations**
|
||
section instead (saved to `display.display_durations` in
|
||
`config.json`).
|
||
|
||
**Example: Weather Plugin**
|
||
- Set your location (city, state, country)
|
||
- Add an API key from OpenWeatherMap (free signup) to
|
||
`config/config_secrets.json` or directly in the plugin's config screen
|
||
- Set the update interval (300 seconds is reasonable)
|
||
|
||
---
|
||
|
||
## Testing Your Display
|
||
|
||
### Run a single plugin on demand
|
||
|
||
The fastest way to verify a plugin works without waiting for the rotation:
|
||
|
||
1. Open the plugin's tab (second nav row)
|
||
2. Scroll to **On-Demand Controls**
|
||
3. Click **Run On-Demand** — the plugin runs immediately even if disabled
|
||
4. Click **Stop On-Demand** to return to the normal rotation
|
||
|
||
### Check the live preview and logs
|
||
|
||
- The **Overview** tab shows a **Live Display Preview** that mirrors what's
|
||
on the matrix in real time — handy for debugging without looking at the
|
||
panel.
|
||
- The **Logs** tab streams the display and web service logs. Look for
|
||
`ERROR` lines if something isn't working; normal operation just shows
|
||
`INFO` messages about plugin rotation.
|
||
|
||
---
|
||
|
||
## Common First-Time Issues
|
||
|
||
### Display Not Showing Anything
|
||
|
||
**Check:**
|
||
1. Power supply connected and adequate (5V, 4A minimum)
|
||
2. LED matrix connected to the bonnet/HAT correctly
|
||
3. Display service running: `sudo systemctl status ledmatrix`
|
||
4. Hardware configuration matches your matrix (rows/cols/chain length)
|
||
|
||
**Fix:**
|
||
1. Restart from the **Overview** tab → **Restart Display Service**
|
||
2. Or via SSH: `sudo systemctl restart ledmatrix`
|
||
|
||
### Web Interface Won't Load
|
||
|
||
**Check:**
|
||
1. Pi is connected to network: `ping your-pi-ip`
|
||
2. Web service running: `sudo systemctl status ledmatrix-web`
|
||
3. Correct port: the web UI listens on `:5000`
|
||
4. Firewall not blocking port 5000
|
||
|
||
**Fix:**
|
||
1. Restart web service: `sudo systemctl restart ledmatrix-web`
|
||
2. Check logs: `sudo journalctl -u ledmatrix-web -n 50`
|
||
|
||
### Plugins Not Showing
|
||
|
||
**Check:**
|
||
1. Plugin is enabled (toggle on the **Plugin Manager** tab)
|
||
2. Plugin's display duration is non-zero
|
||
3. No errors in the **Logs** tab for that plugin. A plugin whose
|
||
`validate_config()` fails is not loaded until its settings are fixed
|
||
|
||
**Fix:**
|
||
1. Enable the plugin from **Plugin Manager**
|
||
2. Check the **Logs** tab for plugin-specific errors
|
||
3. If it still does not appear, click **Restart Display Service** on
|
||
**Overview**
|
||
|
||
### Weather Plugin Shows "No Data"
|
||
|
||
**Check:**
|
||
1. API key configured (OpenWeatherMap)
|
||
2. Location is correct (city, state, country)
|
||
3. Internet connection working
|
||
|
||
**Fix:**
|
||
1. Sign up at openweathermap.org (free)
|
||
2. Add API key to config_secrets.json or plugin config
|
||
3. Restart display
|
||
|
||
---
|
||
|
||
## Next Steps
|
||
|
||
### Customize Your Display
|
||
|
||
**Adjust display durations:**
|
||
- Open the **Rotation** tab and use the **Screen Durations** section to
|
||
set how long each plugin stays on screen per rotation (saved to
|
||
`display.display_durations`).
|
||
|
||
**Organize plugin order:**
|
||
- The **Rotation** tab also has a drag-and-drop **Rotation Order** list
|
||
(saved to `display.plugin_rotation_order`). Enable/disable plugins
|
||
from the **Plugin Manager** tab.
|
||
|
||
**Add more plugins:**
|
||
- Check the **Plugin Store** section of **Plugin Manager** for new plugins.
|
||
- Install community plugins straight from a GitHub URL via
|
||
**Install from GitHub** on the same tab.
|
||
|
||
### Enable Advanced Features
|
||
|
||
**Vegas Scroll Mode:**
|
||
- Continuous scrolling ticker display
|
||
- See [ADVANCED_FEATURES.md](ADVANCED_FEATURES.md) for details
|
||
|
||
**On-Demand Display:**
|
||
- Manually trigger specific plugins
|
||
- Pin important information
|
||
- See [ADVANCED_FEATURES.md](ADVANCED_FEATURES.md) for details
|
||
|
||
**Background Services:**
|
||
- Non-blocking data fetching
|
||
- Faster plugin rotation
|
||
- See [ADVANCED_FEATURES.md](ADVANCED_FEATURES.md) for details
|
||
|
||
### Explore Documentation
|
||
|
||
- [WEB_INTERFACE_GUIDE.md](WEB_INTERFACE_GUIDE.md) - Complete web interface guide
|
||
- [WIFI_NETWORK_SETUP.md](WIFI_NETWORK_SETUP.md) - WiFi configuration details
|
||
- [PLUGIN_STORE_GUIDE.md](PLUGIN_STORE_GUIDE.md) - Installing and managing plugins
|
||
- [TROUBLESHOOTING.md](TROUBLESHOOTING.md) - Solving common issues
|
||
- [ADVANCED_FEATURES.md](ADVANCED_FEATURES.md) - Advanced functionality
|
||
|
||
### Join the Community
|
||
|
||
- Report issues on GitHub
|
||
- Share your custom plugins
|
||
- Help others in discussions
|
||
- Contribute improvements
|
||
|
||
---
|
||
|
||
## Quick Reference
|
||
|
||
### Service Commands
|
||
|
||
```bash
|
||
# Check status
|
||
sudo systemctl status ledmatrix
|
||
sudo systemctl status ledmatrix-web
|
||
|
||
# Restart services
|
||
sudo systemctl restart ledmatrix
|
||
sudo systemctl restart ledmatrix-web
|
||
|
||
# View logs
|
||
sudo journalctl -u ledmatrix -f
|
||
sudo journalctl -u ledmatrix-web -f
|
||
```
|
||
|
||
### File Locations
|
||
|
||
```
|
||
/home/ledpi/LEDMatrix/
|
||
├── config/
|
||
│ ├── config.json # Main configuration
|
||
│ ├── config_secrets.json # API keys and secrets
|
||
│ └── wifi_config.json # WiFi settings
|
||
├── plugin-repos/ # Installed plugins (default location)
|
||
└── web_interface/ # Web interface files
|
||
```
|
||
|
||
> Cached data does not live in the project directory — the cache manager
|
||
> uses the first writable location among `/var/cache/ledmatrix`,
|
||
> `~/.ledmatrix_cache`, `/opt/ledmatrix/cache`, and
|
||
> `$TMPDIR/ledmatrix_cache`.
|
||
>
|
||
> The plugin install location is configurable via
|
||
> `plugin_system.plugins_directory` in `config.json`. The default is
|
||
> `plugin-repos/`. Plugin discovery (`PluginManager.discover_plugins()`)
|
||
> only scans the configured directory — it does not fall back to
|
||
> `plugins/`. However, the Plugin Store install/update path and the
|
||
> web UI's schema loader do also probe `plugins/` so the dev symlinks
|
||
> created by `scripts/dev/dev_plugin_setup.sh` keep working.
|
||
|
||
### Web Interface
|
||
|
||
```
|
||
Main Interface: http://your-pi-ip:5000
|
||
|
||
System tabs:
|
||
- Overview System stats, live preview, quick actions
|
||
- General Timezone, location, plugin-system settings
|
||
- WiFi Network selection and AP-mode setup
|
||
- Schedule Power and dim schedules
|
||
- Display Matrix hardware configuration
|
||
- Rotation Rotation order (drag-and-drop) and screen durations
|
||
- Config Editor Raw config.json editor
|
||
- Backup & Restore Config backup and restore
|
||
- Fonts Upload and manage fonts
|
||
- Logs Real-time log viewing
|
||
- Cache Cached data inspection and cleanup
|
||
- Operation History Recent service operations
|
||
- Tools System diagnostics, updates, dependencies, maintenance
|
||
|
||
Plugin tabs (second row):
|
||
- Plugin Manager Browse the Plugin Store, install/enable plugins
|
||
- <plugin-id> One tab per installed plugin for its config
|
||
```
|
||
|
||
### WiFi Access Point
|
||
|
||
```
|
||
Network Name: LEDMatrix-Setup
|
||
Password: (none - open network)
|
||
URL when connected: http://192.168.4.1:5000
|
||
```
|
||
|
||
---
|
||
|
||
## Congratulations!
|
||
|
||
Your LEDMatrix display is now set up and running. Explore the web interface, try different plugins, and customize it to your liking.
|
||
|
||
**Need Help?**
|
||
- Check [TROUBLESHOOTING.md](TROUBLESHOOTING.md)
|
||
- Review detailed guides for specific features
|
||
- Report issues on GitHub
|
||
- Ask questions in community discussions
|
||
|
||
Enjoy your LED matrix display!
|