mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-10-04 06:15:09 +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>
980 lines
22 KiB
Markdown
980 lines
22 KiB
Markdown
# Troubleshooting Guide
|
|
|
|
## Quick Diagnosis Steps
|
|
|
|
Run these checks first to quickly identify common issues:
|
|
|
|
### 1. Check Service Status
|
|
|
|
```bash
|
|
# Check all LEDMatrix services
|
|
sudo systemctl status ledmatrix
|
|
sudo systemctl status ledmatrix-web
|
|
sudo systemctl status ledmatrix-wifi-monitor
|
|
|
|
# Check AP mode services (if using WiFi)
|
|
sudo systemctl status hostapd
|
|
sudo systemctl status dnsmasq
|
|
```
|
|
|
|
**Note:** Look for `active (running)` status and check for error messages in the output.
|
|
|
|
### 2. View Service Logs
|
|
|
|
**IMPORTANT:** The web service logs to **syslog**, NOT stdout. Use `journalctl` to view logs:
|
|
|
|
```bash
|
|
# View all recent logs
|
|
sudo journalctl -u ledmatrix -n 50
|
|
sudo journalctl -u ledmatrix-web -n 50
|
|
|
|
# Follow logs in real-time
|
|
sudo journalctl -u ledmatrix -f
|
|
|
|
# View logs from last hour
|
|
sudo journalctl -u ledmatrix-web --since "1 hour ago"
|
|
|
|
# Filter for errors only
|
|
sudo journalctl -u ledmatrix -p err
|
|
```
|
|
|
|
### 3. Run Diagnostic Scripts
|
|
|
|
```bash
|
|
# Web interface diagnostics
|
|
bash scripts/diagnose_web_interface.sh
|
|
|
|
# WiFi setup verification
|
|
./scripts/verify_wifi_setup.sh
|
|
|
|
# Captive portal troubleshooting
|
|
./scripts/troubleshoot_captive_portal.sh
|
|
```
|
|
|
|
> Weather is provided by the `ledmatrix-weather` plugin (installed via the
|
|
> Plugin Store). To troubleshoot weather, check that plugin's tab in the
|
|
> web UI for its API key and recent error messages, then watch the
|
|
> **Logs** tab.
|
|
|
|
### 4. Check Configuration
|
|
|
|
```bash
|
|
# Verify web interface autostart
|
|
cat config/config.json | grep web_display_autostart
|
|
|
|
# Check plugin enabled status
|
|
cat config/config.json | grep -A 2 "plugin-id"
|
|
|
|
# Verify API keys present
|
|
ls -l config/config_secrets.json
|
|
```
|
|
|
|
### 5. Test Manual Startup
|
|
|
|
```bash
|
|
# Test web interface manually
|
|
python3 web_interface/start.py
|
|
|
|
# If it works manually but not as a service, check systemd service file
|
|
```
|
|
|
|
---
|
|
|
|
## Common Issues by Category
|
|
|
|
### Installation & Build Issues
|
|
|
|
#### Step 6 fails: "Failed building wheel for rgbmatrix"
|
|
|
|
**Symptoms:**
|
|
|
|
```
|
|
note: This error originates from a subprocess, and is likely not a problem with pip.
|
|
ERROR: Failed building wheel for rgbmatrix
|
|
Failed to build rgbmatrix
|
|
✗ Failed to install rpi-rgb-led-matrix Python package
|
|
```
|
|
|
|
**Cause:**
|
|
|
|
Almost always the kernel's out-of-memory killer, not missing build tools. The
|
|
`rpi-rgb-led-matrix` library compiles roughly 45 C++ translation units, two of
|
|
them Cython-generated — a single `cc1plus` on those can peak near 800MB. The
|
|
build system defaults to running several of those at once, which exceeds RAM on
|
|
512MB and 1GB boards. Because the OOM killer writes nothing to pip's output, the
|
|
failure looks like a toolchain problem, and `sudo apt install -y
|
|
python-dev-is-python3 cmake build-essential` will report everything is already
|
|
up to date.
|
|
|
|
**How to confirm:**
|
|
|
|
```bash
|
|
dmesg -T | grep -i "out of memory" # look for "Killed process ... (cc1plus)"
|
|
free -h # total RAM and swap
|
|
```
|
|
|
|
**Fix:**
|
|
|
|
Current versions of the installer handle this automatically: they cap build
|
|
parallelism based on available RAM and add a temporary swapfile for the build,
|
|
removing it when the build finishes. If you are on an older checkout, or the
|
|
temporary swapfile could not be created, either force a serial compile:
|
|
|
|
```bash
|
|
sudo ./first_time_install.sh --build-jobs 1
|
|
```
|
|
|
|
or add permanent swap and re-run the installer, which resumes at Step 6:
|
|
|
|
```bash
|
|
sudo apt install -y dphys-swapfile
|
|
sudo sed -i 's/^#\?CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile
|
|
sudo sed -i 's/^#\?CONF_MAXSWAP=.*/CONF_MAXSWAP=2048/' /etc/dphys-swapfile
|
|
sudo dphys-swapfile swapoff && sudo dphys-swapfile setup && sudo dphys-swapfile swapon
|
|
sudo ./first_time_install.sh
|
|
```
|
|
|
|
`CONF_MAXSWAP` matters: it defaults to 2048 and silently clamps `CONF_SWAPSIZE`,
|
|
so setting only `CONF_SWAPSIZE` to a larger value has no effect.
|
|
|
|
**Related:**
|
|
|
|
- The installer needs roughly 3GB free on the card to place the swapfile. If
|
|
disk is tight it will say so and skip the swapfile: `sudo apt clean` first.
|
|
- `sudo bash scripts/check_system_compatibility.sh` reports RAM and disk.
|
|
- `sudo bash scripts/diagnose_dependencies.sh` dumps build-dependency state.
|
|
|
|
---
|
|
|
|
### Web Interface & Service Issues
|
|
|
|
#### Service Not Running/Starting
|
|
|
|
**Symptoms:**
|
|
- Cannot access web interface at http://your-pi-ip:5000
|
|
- `systemctl status ledmatrix-web` shows `inactive (dead)`
|
|
|
|
**Solutions:**
|
|
|
|
1. **Start the service:**
|
|
```bash
|
|
sudo systemctl start ledmatrix-web
|
|
```
|
|
|
|
2. **Enable on boot:**
|
|
```bash
|
|
sudo systemctl enable ledmatrix-web
|
|
```
|
|
|
|
3. **Check why it failed:**
|
|
```bash
|
|
sudo journalctl -u ledmatrix-web -n 50
|
|
```
|
|
|
|
#### web_display_autostart is False
|
|
|
|
**Symptoms:**
|
|
- Service exists but web interface doesn't start automatically
|
|
- Logs show service starting but nothing happens
|
|
|
|
**Solution:**
|
|
|
|
```bash
|
|
# Edit config.json
|
|
nano config/config.json
|
|
|
|
# Set web_display_autostart to true
|
|
{
|
|
"web_display_autostart": true,
|
|
...
|
|
}
|
|
|
|
# Restart service
|
|
sudo systemctl restart ledmatrix-web
|
|
```
|
|
|
|
#### Import or Dependency Errors
|
|
|
|
**Symptoms:**
|
|
- Logs show `ModuleNotFoundError` or `ImportError`
|
|
- Service fails to start with Python errors
|
|
|
|
**Solutions:**
|
|
|
|
1. **Install dependencies** as root, so the root display service can import
|
|
them:
|
|
```bash
|
|
sudo python3 -m pip install --break-system-packages --no-cache-dir -r requirements.txt
|
|
sudo python3 -m pip install --break-system-packages --no-cache-dir -r web_interface/requirements.txt
|
|
```
|
|
|
|
2. **Test imports step-by-step:**
|
|
```bash
|
|
python3 -c "from src.config_manager import ConfigManager; print('OK')"
|
|
python3 -c "from src.plugin_system.plugin_manager import PluginManager; print('OK')"
|
|
python3 -c "from web_interface.app import app; print('OK')"
|
|
```
|
|
|
|
3. **Check Python path:**
|
|
```bash
|
|
python3 -c "import sys; print(sys.path)"
|
|
```
|
|
|
|
#### Port Already in Use
|
|
|
|
**Symptoms:**
|
|
- Error: `Address already in use`
|
|
- Service fails to bind to port 5000
|
|
|
|
**Solutions:**
|
|
|
|
1. **Check what's using the port:**
|
|
```bash
|
|
sudo lsof -i :5000
|
|
```
|
|
|
|
2. **Kill the conflicting process:**
|
|
```bash
|
|
sudo kill -9 <PID>
|
|
```
|
|
|
|
3. **Or change the port in start.py:**
|
|
```python
|
|
app.run(host='0.0.0.0', port=5051)
|
|
```
|
|
|
|
#### Permission Issues
|
|
|
|
**Symptoms:**
|
|
- `Permission denied` errors in logs
|
|
- Cannot read/write configuration files
|
|
|
|
**Solutions:**
|
|
|
|
[PERMISSIONS.md](PERMISSIONS.md) lists the expected owner and mode of every
|
|
file and directory, and which `scripts/fix_perms/` script to run as which
|
|
user. Don't `chown -R` the whole project: the two sudo helper scripts in
|
|
`scripts/fix_perms/` must stay owned by root.
|
|
|
|
```bash
|
|
# Config files: web user owns both; secrets must stay 640
|
|
stat -c '%U:%G %a %n' config/config.json config/config_secrets.json
|
|
sudo chmod 644 config/config.json
|
|
sudo chmod 640 config/config_secrets.json
|
|
|
|
# Which user the web interface runs as
|
|
sudo systemctl cat ledmatrix-web | grep User
|
|
```
|
|
|
|
#### Flask/Blueprint Import Errors
|
|
|
|
**Symptoms:**
|
|
- `ImportError: cannot import name 'app'`
|
|
- `ModuleNotFoundError: No module named 'blueprints'`
|
|
|
|
**Solutions:**
|
|
|
|
1. **Verify file structure:**
|
|
```bash
|
|
ls -l web_interface/app.py
|
|
ls -ld web_interface/blueprints/api_v3/
|
|
ls -l web_interface/blueprints/pages_v3.py
|
|
```
|
|
|
|
2. **Check for __init__.py files:**
|
|
```bash
|
|
ls -l web_interface/__init__.py
|
|
ls -l web_interface/blueprints/__init__.py
|
|
```
|
|
|
|
3. **Test import manually:**
|
|
```bash
|
|
cd /home/ledpi/LEDMatrix
|
|
python3 -c "from web_interface.app import app"
|
|
```
|
|
|
|
---
|
|
|
|
### WiFi & AP Mode Issues
|
|
|
|
#### AP Mode Not Activating
|
|
|
|
**Symptoms:**
|
|
- WiFi disconnected but AP mode doesn't start
|
|
- Cannot find "LEDMatrix-Setup" network
|
|
|
|
**Solutions:**
|
|
|
|
1. **Check auto-enable setting:**
|
|
```bash
|
|
cat config/wifi_config.json | grep auto_enable_ap_mode
|
|
# Should show: "auto_enable_ap_mode": true
|
|
```
|
|
|
|
2. **Verify WiFi monitor service is running:**
|
|
```bash
|
|
sudo systemctl status ledmatrix-wifi-monitor
|
|
```
|
|
|
|
3. **Wait for grace period (90 seconds):**
|
|
- AP mode requires 3 consecutive disconnected checks at 30-second intervals
|
|
- Total wait time: 90 seconds after WiFi disconnects
|
|
|
|
4. **Check if Ethernet is connected:**
|
|
```bash
|
|
nmcli device status
|
|
# If Ethernet is connected, AP mode won't activate
|
|
```
|
|
|
|
5. **Check required services:**
|
|
```bash
|
|
sudo systemctl status hostapd
|
|
sudo systemctl status dnsmasq
|
|
```
|
|
|
|
6. **Manually enable AP mode:**
|
|
```bash
|
|
# Via API (the WiFi blueprint is mounted under /api/v3)
|
|
curl -X POST http://localhost:5000/api/v3/wifi/ap/enable
|
|
|
|
# Via Python
|
|
python3 -c "
|
|
from src.wifi_manager import WiFiManager
|
|
wm = WiFiManager()
|
|
wm.enable_ap_mode()
|
|
"
|
|
```
|
|
|
|
#### Cannot Connect to AP Mode / Connection Refused
|
|
|
|
**Symptoms:**
|
|
- Can see "LEDMatrix-Setup" network but can't connect to web interface
|
|
- Browser shows "Connection Refused" or "Can't connect to server"
|
|
- AP mode active but web interface not accessible
|
|
|
|
**Solutions:**
|
|
|
|
1. **Verify web server is running:**
|
|
```bash
|
|
sudo systemctl status ledmatrix-web
|
|
# Should be active (running)
|
|
```
|
|
|
|
2. **Use correct IP address and port:**
|
|
- Correct: `http://192.168.4.1:5000`
|
|
- NOT: `http://192.168.4.1` (port 80 — nothing listens there)
|
|
|
|
3. **Check wlan0 has correct IP:**
|
|
```bash
|
|
ip addr show wlan0
|
|
# Should show: inet 192.168.4.1/24
|
|
```
|
|
|
|
4. **Verify hostapd and dnsmasq are running:**
|
|
```bash
|
|
sudo systemctl status hostapd
|
|
sudo systemctl status dnsmasq
|
|
```
|
|
|
|
5. **Test from the Pi itself:**
|
|
```bash
|
|
curl http://192.168.4.1:5000
|
|
# Should return HTML
|
|
```
|
|
|
|
#### DNS Resolution Failures
|
|
|
|
**Symptoms:**
|
|
- Captive portal doesn't redirect automatically
|
|
- DNS lookups fail when connected to AP mode
|
|
|
|
**Solutions:**
|
|
|
|
1. **Check dnsmasq status:**
|
|
```bash
|
|
sudo systemctl status dnsmasq
|
|
sudo journalctl -u dnsmasq -n 20
|
|
```
|
|
|
|
2. **Verify DNS configuration:**
|
|
```bash
|
|
cat /etc/dnsmasq.conf | grep -v "^#" | grep -v "^$"
|
|
```
|
|
|
|
3. **Test DNS resolution:**
|
|
```bash
|
|
nslookup captive.apple.com
|
|
# Should resolve to 192.168.4.1 when in AP mode
|
|
```
|
|
|
|
4. **Manual captive portal testing:**
|
|
- Try these URLs manually:
|
|
- `http://192.168.4.1:5000`
|
|
- `http://captive.apple.com`
|
|
- `http://connectivitycheck.gstatic.com/generate_204`
|
|
|
|
#### Firewall Blocking Port 5000
|
|
|
|
**Symptoms:**
|
|
- Services running but cannot connect
|
|
- Works from Pi but not from other devices
|
|
|
|
**Solutions:**
|
|
|
|
1. **Check UFW status:**
|
|
```bash
|
|
sudo ufw status
|
|
```
|
|
|
|
2. **Allow port 5000:**
|
|
```bash
|
|
sudo ufw allow 5000/tcp
|
|
```
|
|
|
|
3. **Check iptables:**
|
|
```bash
|
|
sudo iptables -L -n
|
|
```
|
|
|
|
4. **Temporarily disable firewall to test:**
|
|
```bash
|
|
sudo ufw disable
|
|
# Test if it works, then re-enable and add rule
|
|
sudo ufw enable
|
|
sudo ufw allow 5000/tcp
|
|
```
|
|
|
|
---
|
|
|
|
### Plugin Issues
|
|
|
|
#### Plugin Not Enabled
|
|
|
|
**Symptoms:**
|
|
- Plugin installed but doesn't appear in rotation
|
|
- Plugin shows in web interface but is greyed out
|
|
|
|
**Solutions:**
|
|
|
|
1. **Enable in configuration:**
|
|
```json
|
|
{
|
|
"plugin-id": {
|
|
"enabled": true,
|
|
...
|
|
}
|
|
}
|
|
```
|
|
|
|
Or toggle the plugin on in the **Plugin Manager** tab, which writes the
|
|
same flag.
|
|
|
|
2. **Wait a few seconds.** The display service watches `config.json` and
|
|
loads a newly enabled plugin without a restart
|
|
(`DisplayController._reconcile_enabled_plugins()` in
|
|
[`src/display_controller.py`](../src/display_controller.py)). This
|
|
needs hot reload, which is on unless `LEDMATRIX_HOT_RELOAD=false` is set.
|
|
|
|
3. **If it still does not appear**, check the logs for a config validation
|
|
error, then restart: `sudo systemctl restart ledmatrix`
|
|
|
|
#### Plugin Not Loading
|
|
|
|
**Symptoms:**
|
|
- Plugin enabled but not showing
|
|
- Errors in logs about plugin
|
|
|
|
**Solutions:**
|
|
|
|
1. **Check plugin directory exists:**
|
|
```bash
|
|
ls -ld plugin-repos/plugin-id/
|
|
```
|
|
|
|
2. **Verify manifest.json:**
|
|
```bash
|
|
cat plugin-repos/plugin-id/manifest.json
|
|
# Verify all required fields present
|
|
```
|
|
|
|
3. **Check dependencies installed.** Install them with `sudo`: the display
|
|
service runs as root and does not see packages pip put in your user's
|
|
`~/.local` (see [PLUGIN_DEPENDENCY_GUIDE.md](PLUGIN_DEPENDENCY_GUIDE.md)):
|
|
```bash
|
|
if [ -f plugin-repos/plugin-id/requirements.txt ]; then
|
|
sudo python3 -m pip install --break-system-packages --no-cache-dir -r plugin-repos/plugin-id/requirements.txt
|
|
fi
|
|
```
|
|
|
|
4. **Check logs for plugin errors:**
|
|
```bash
|
|
sudo journalctl -u ledmatrix -f | grep plugin-id
|
|
```
|
|
|
|
5. **Load and render the plugin headlessly:**
|
|
```bash
|
|
python3 scripts/check_plugin.py --plugin plugin-id
|
|
```
|
|
|
|
#### Stale Cache Data
|
|
|
|
**Symptoms:**
|
|
- Plugin shows old data
|
|
- Data doesn't update even after restarting
|
|
- Clearing cache in web interface doesn't help
|
|
|
|
**Solutions:**
|
|
|
|
1. **Manual cache clearing:**
|
|
|
|
The cache 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 easiest option is the helper script:
|
|
|
|
```bash
|
|
# Clear the cache with the helper script
|
|
sudo python3 scripts/utils/clear_cache.py --clear-all
|
|
|
|
# Or remove files manually from the cache dir in use, e.g.:
|
|
sudo rm -rf /var/cache/ledmatrix/*
|
|
|
|
# Restart display
|
|
sudo systemctl restart ledmatrix
|
|
```
|
|
|
|
2. **Check cache permissions.** Expected: `root:ledmatrix`, `drwxrwsr-x`.
|
|
`setup_cache.sh` restores that layout (see
|
|
[PERMISSIONS.md](PERMISSIONS.md#repair-scripts)):
|
|
```bash
|
|
ls -ld /var/cache/ledmatrix
|
|
sudo bash scripts/install/setup_cache.sh
|
|
```
|
|
|
|
---
|
|
|
|
### Weather Plugin Specific Issues
|
|
|
|
#### Missing or Invalid API Key
|
|
|
|
**Symptoms:**
|
|
- "No Weather Data" message on display
|
|
- Logs show API authentication errors
|
|
|
|
**Solutions:**
|
|
|
|
1. **Get OpenWeatherMap API key:**
|
|
- Sign up at https://openweathermap.org/api
|
|
- Free tier: 1,000 calls/day, 60 calls/minute
|
|
- Copy your API key
|
|
|
|
2. **Add to config_secrets.json (recommended):**
|
|
```json
|
|
{
|
|
"openweathermap_api_key": "your-api-key-here"
|
|
}
|
|
```
|
|
|
|
3. **Or add to config.json:**
|
|
```json
|
|
{
|
|
"ledmatrix-weather": {
|
|
"enabled": true,
|
|
"openweathermap_api_key": "your-api-key-here",
|
|
...
|
|
}
|
|
}
|
|
```
|
|
|
|
4. **Secure the API key file:**
|
|
```bash
|
|
chmod 640 config/config_secrets.json
|
|
```
|
|
|
|
5. **Restart display:**
|
|
```bash
|
|
sudo systemctl restart ledmatrix
|
|
```
|
|
|
|
#### API Rate Limits Exceeded
|
|
|
|
**Symptoms:**
|
|
- Weather works initially then stops
|
|
- Logs show HTTP 429 errors (Too Many Requests)
|
|
- Error message: "Rate limit exceeded"
|
|
|
|
**Solutions:**
|
|
|
|
1. **Increase update interval:**
|
|
```json
|
|
{
|
|
"ledmatrix-weather": {
|
|
"update_interval": 300,
|
|
...
|
|
}
|
|
}
|
|
```
|
|
**Note:** Minimum recommended: 300 seconds (5 minutes)
|
|
|
|
2. **Check current rate limit usage:**
|
|
- OpenWeatherMap free tier: 1,000 calls/day, 60 calls/minute
|
|
- With 300s interval: 288 calls/day (well within limits)
|
|
|
|
3. **Monitor API calls:**
|
|
```bash
|
|
sudo journalctl -u ledmatrix -f | grep "openweathermap"
|
|
```
|
|
|
|
#### Invalid Location Configuration
|
|
|
|
**Symptoms:**
|
|
- "No Weather Data" message
|
|
- Logs show location not found errors
|
|
|
|
**Solutions:**
|
|
|
|
1. **Use correct location format:**
|
|
```json
|
|
{
|
|
"ledmatrix-weather": {
|
|
"city": "Tampa",
|
|
"state": "FL",
|
|
"country": "US"
|
|
}
|
|
}
|
|
```
|
|
|
|
2. **Use ISO country codes:**
|
|
- US = United States
|
|
- GB = United Kingdom
|
|
- CA = Canada
|
|
- etc.
|
|
|
|
3. **Test API call manually:**
|
|
```bash
|
|
API_KEY="your-key-here"
|
|
curl "http://api.openweathermap.org/data/2.5/weather?q=Tampa,FL,US&appid=${API_KEY}"
|
|
```
|
|
|
|
#### Network Connectivity to OpenWeatherMap
|
|
|
|
**Symptoms:**
|
|
- Other internet features work
|
|
- Weather specifically fails
|
|
- Connection timeout errors
|
|
|
|
**Solutions:**
|
|
|
|
1. **Test connectivity:**
|
|
```bash
|
|
ping api.openweathermap.org
|
|
```
|
|
|
|
2. **Test DNS resolution:**
|
|
```bash
|
|
nslookup api.openweathermap.org
|
|
```
|
|
|
|
3. **Test API endpoint:**
|
|
```bash
|
|
curl -I https://api.openweathermap.org
|
|
# Should return HTTP 200 or 301
|
|
```
|
|
|
|
4. **Check firewall:**
|
|
```bash
|
|
# Ensure HTTPS (443) is allowed for outbound connections
|
|
sudo ufw status
|
|
```
|
|
|
|
---
|
|
|
|
## Diagnostic Commands Reference
|
|
|
|
### Service Commands
|
|
|
|
```bash
|
|
# Check status
|
|
sudo systemctl status ledmatrix
|
|
sudo systemctl status ledmatrix-web
|
|
sudo systemctl status ledmatrix-wifi-monitor
|
|
|
|
# Start service
|
|
sudo systemctl start <service-name>
|
|
|
|
# Stop service
|
|
sudo systemctl stop <service-name>
|
|
|
|
# Restart service
|
|
sudo systemctl restart <service-name>
|
|
|
|
# Enable on boot
|
|
sudo systemctl enable <service-name>
|
|
|
|
# Disable on boot
|
|
sudo systemctl disable <service-name>
|
|
|
|
# View service file
|
|
sudo systemctl cat <service-name>
|
|
|
|
# Reload systemd after editing service files
|
|
sudo systemctl daemon-reload
|
|
```
|
|
|
|
### Log Viewing Commands
|
|
|
|
```bash
|
|
# View recent logs (last 50 lines)
|
|
sudo journalctl -u ledmatrix -n 50
|
|
|
|
# Follow logs in real-time
|
|
sudo journalctl -u ledmatrix -f
|
|
|
|
# View logs from specific time
|
|
sudo journalctl -u ledmatrix --since "1 hour ago"
|
|
sudo journalctl -u ledmatrix --since "2024-01-01 10:00:00"
|
|
|
|
# View logs until specific time
|
|
sudo journalctl -u ledmatrix --until "2024-01-01 12:00:00"
|
|
|
|
# Filter by priority (errors only)
|
|
sudo journalctl -u ledmatrix -p err
|
|
|
|
# Filter by priority (warnings and errors)
|
|
sudo journalctl -u ledmatrix -p warning
|
|
|
|
# Search logs for specific text
|
|
sudo journalctl -u ledmatrix | grep "error"
|
|
sudo journalctl -u ledmatrix | grep -i "plugin"
|
|
|
|
# View logs for multiple services
|
|
sudo journalctl -u ledmatrix -u ledmatrix-web -n 50
|
|
|
|
# Export logs to file
|
|
sudo journalctl -u ledmatrix > ledmatrix.log
|
|
```
|
|
|
|
### Network Testing Commands
|
|
|
|
```bash
|
|
# Test connectivity
|
|
ping -c 4 8.8.8.8
|
|
ping -c 4 api.openweathermap.org
|
|
|
|
# Test DNS resolution
|
|
nslookup api.openweathermap.org
|
|
dig api.openweathermap.org
|
|
|
|
# Test HTTP endpoint
|
|
curl -I http://your-pi-ip:5000
|
|
curl http://192.168.4.1:5000
|
|
|
|
# Check listening ports
|
|
sudo lsof -i :5000
|
|
sudo netstat -tuln | grep 5000
|
|
|
|
# Check network interfaces
|
|
ip addr show
|
|
nmcli device status
|
|
```
|
|
|
|
### File/Directory Verification
|
|
|
|
```bash
|
|
# Check file exists
|
|
ls -l config/config.json
|
|
ls -l plugin-repos/plugin-id/manifest.json
|
|
|
|
# Check directory structure
|
|
ls -la web_interface/
|
|
ls -la plugin-repos/
|
|
|
|
# Check file permissions
|
|
ls -l config/config_secrets.json
|
|
|
|
# Check file contents
|
|
cat config/config.json | jq .
|
|
cat config/wifi_config.json | grep auto_enable
|
|
```
|
|
|
|
### Python Import Testing
|
|
|
|
```bash
|
|
# Test core imports
|
|
python3 -c "from src.config_manager import ConfigManager; print('OK')"
|
|
python3 -c "from src.plugin_system.plugin_manager import PluginManager; print('OK')"
|
|
python3 -c "from src.display_manager import DisplayManager; print('OK')"
|
|
|
|
# Test web interface imports
|
|
python3 -c "from web_interface.app import app; print('OK')"
|
|
python3 -c "from web_interface.blueprints.api_v3 import api_v3; print('OK')"
|
|
|
|
# Test WiFi manager
|
|
python3 -c "from src.wifi_manager import WiFiManager; print('OK')"
|
|
|
|
# Test plugin import
|
|
python3 -c "
|
|
import sys
|
|
sys.path.insert(0, 'plugin-repos/plugin-id')
|
|
from manager import PluginClass
|
|
print('Plugin imports OK')
|
|
"
|
|
```
|
|
|
|
---
|
|
|
|
## Reinstalling Service Files
|
|
|
|
If a systemd service file is corrupted or missing, do NOT hand-write
|
|
one. The real unit files live in the repo's `systemd/` directory
|
|
(`ledmatrix.service`, `ledmatrix-web.service`,
|
|
`ledmatrix-wifi-monitor.service`) and contain a
|
|
`__PROJECT_ROOT_DIR__` placeholder that the install scripts substitute
|
|
with your actual checkout path:
|
|
|
|
```bash
|
|
# Reinstall the display service unit
|
|
sudo ./scripts/install/install_service.sh
|
|
|
|
# Reinstall the web interface service unit
|
|
sudo ./scripts/install/install_web_service.sh
|
|
```
|
|
|
|
Note that `ledmatrix-web.service` runs as root via
|
|
`scripts/utils/start_web_conditionally.py` — root is needed for
|
|
system operations (service control, WiFi management), and the wrapper
|
|
honors the `web_display_autostart` config flag before actually
|
|
starting the web server.
|
|
|
|
---
|
|
|
|
## Complete Diagnostic Script
|
|
|
|
Run this script for comprehensive diagnostics:
|
|
|
|
```bash
|
|
#!/bin/bash
|
|
|
|
echo "=== LEDMatrix Diagnostic Report ==="
|
|
echo ""
|
|
|
|
echo "1. Service Status:"
|
|
systemctl status ledmatrix --no-pager -n 5
|
|
systemctl status ledmatrix-web --no-pager -n 5
|
|
echo ""
|
|
|
|
echo "2. Recent Logs:"
|
|
journalctl -u ledmatrix -n 20 --no-pager
|
|
echo ""
|
|
|
|
echo "3. Configuration:"
|
|
cat config/config.json | grep -E "(web_display_autostart|enabled)"
|
|
echo ""
|
|
|
|
echo "4. Network Status:"
|
|
ip addr show | grep -E "(wlan|eth|inet )"
|
|
curl -s http://localhost:5000 > /dev/null && echo "Web interface: OK" || echo "Web interface: FAILED"
|
|
echo ""
|
|
|
|
echo "5. File Structure:"
|
|
ls -la web_interface/ | head -10
|
|
ls -la plugin-repos/ | head -10
|
|
echo ""
|
|
|
|
echo "6. Python Imports:"
|
|
python3 -c "from src.config_manager import ConfigManager" && echo "ConfigManager: OK" || echo "ConfigManager: FAILED"
|
|
python3 -c "from web_interface.app import app" && echo "Web app: OK" || echo "Web app: FAILED"
|
|
echo ""
|
|
|
|
echo "=== End Diagnostic Report ==="
|
|
```
|
|
|
|
---
|
|
|
|
## Success Indicators
|
|
|
|
A properly functioning system should show:
|
|
|
|
1. **Services Running:**
|
|
```
|
|
● ledmatrix.service - active (running)
|
|
● ledmatrix-web.service - active (running)
|
|
```
|
|
|
|
2. **Web Interface Accessible:**
|
|
- Navigate to http://your-pi-ip:5000
|
|
- Page loads successfully
|
|
- Display preview visible
|
|
|
|
3. **Logs Show Normal Operation:**
|
|
```
|
|
INFO: Web interface started on port 5000
|
|
INFO: Loaded X plugins
|
|
INFO: Display rotation active
|
|
```
|
|
|
|
4. **Process Listening on Port:**
|
|
```bash
|
|
$ sudo lsof -i :5000
|
|
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
|
|
python3 1234 ledpi 3u IPv4 12345 0t0 TCP *:5000 (LISTEN)
|
|
```
|
|
|
|
5. **Plugins Loading:**
|
|
- Logs show plugin initialization
|
|
- Plugins appear in web interface
|
|
- Display cycles through enabled plugins
|
|
|
|
---
|
|
|
|
## Emergency Recovery
|
|
|
|
If the system is completely broken:
|
|
|
|
### 1. Git Rollback
|
|
|
|
```bash
|
|
# View recent commits
|
|
git log --oneline -10
|
|
|
|
# Rollback to previous commit
|
|
git reset --hard HEAD~1
|
|
|
|
# Or rollback to specific commit
|
|
git reset --hard <commit-hash>
|
|
|
|
# Restart all services
|
|
sudo systemctl restart ledmatrix
|
|
sudo systemctl restart ledmatrix-web
|
|
```
|
|
|
|
### 2. Fresh Service Installation
|
|
|
|
```bash
|
|
# Reinstall WiFi monitor
|
|
sudo ./scripts/install/install_wifi_monitor.sh
|
|
|
|
# Recreate service files (substitutes __PROJECT_ROOT_DIR__ in systemd/ units)
|
|
sudo ./scripts/install/install_service.sh
|
|
sudo ./scripts/install/install_web_service.sh
|
|
|
|
# Restart
|
|
sudo systemctl restart ledmatrix ledmatrix-web
|
|
```
|
|
|
|
### 3. Full System Reboot
|
|
|
|
```bash
|
|
# As a last resort
|
|
sudo reboot
|
|
```
|
|
|
|
---
|
|
|
|
## Related Documentation
|
|
|
|
- [WEB_INTERFACE_GUIDE.md](WEB_INTERFACE_GUIDE.md) - Web interface usage
|
|
- [WIFI_NETWORK_SETUP.md](WIFI_NETWORK_SETUP.md) - WiFi configuration
|
|
- [PLUGIN_STORE_GUIDE.md](PLUGIN_STORE_GUIDE.md) - Plugin installation
|
|
- [REST_API_REFERENCE.md](REST_API_REFERENCE.md) - API documentation
|