PLUGIN_STORE_GUIDE.md
- 19 occurrences of port 5050 -> 5000
- All API paths missing /v3 (e.g. /api/plugins/install ->
/api/v3/plugins/install). Bulk fix.
PLUGIN_REGISTRY_SETUP_GUIDE.md
- Same port + /api/v3 fixes (3 occurrences each)
- "Go to Plugin Store tab" -> "Open the Plugin Manager tab and scroll
to the Install from GitHub section" (the real flow for registry
setup is the GitHub install section, not the Plugin Store search)
PLUGIN_CONFIG_QUICK_START.md
- Port 5001 -> 5000 (5001 is the dev_server.py default, not the web UI)
- "Plugin Store tab" install flow -> real Plugin Manager + Plugin Store
section + per-plugin tab in second nav row
- Removed reference to PLUGIN_CONFIG_TABS_SUMMARY.md (archived doc)
PLUGIN_CONFIGURATION_TABS.md
- "Plugin Management vs Configuration" section confusingly described
a "Plugins Tab" that doesn't exist as a single thing. Rewrote to
describe the real two-piece structure: Plugin Manager tab (browse,
install, toggle) vs per-plugin tabs (configure individual plugins).
PLUGIN_DEPENDENCY_GUIDE.md
- Port 5001 -> 5000
PLUGIN_DEPENDENCY_TROUBLESHOOTING.md
- Wrong port (8080) and wrong UI nav ("Plugin Store or Plugin
Management"). Fixed to the real flow.
PLUGIN_QUICK_REFERENCE.md
- "Plugin Location: ./plugins/ directory" -> default is plugin-repos/
(verified in config/config.template.json:130 and
display_controller.py:132). plugins/ is a fallback.
- File structure diagram showed plugins/ -> plugin-repos/.
- Web UI install flow: "Plugin Store tab" -> "Plugin Manager tab ->
Plugin Store section". Also fixed Configure ⚙️ button (doesn't
exist) and "Drag and drop reorder" (not implemented).
- API examples: replaced ad-hoc Python pseudocode with real curl
examples against /api/v3/plugins/* endpoints. Pointed at
REST_API_REFERENCE.md for the full list.
- "Migration Path Phase 1-5" was a roadmap written before the plugin
system shipped. The plugin system is now stable and live. Removed
the migration phases as they're history, not a roadmap.
- "Quick Migration" section called scripts/migrate_to_plugins.py
which doesn't exist anywhere in the repo. Removed.
- "Plugin Registry Structure" referenced
ChuckBuilds/ledmatrix-plugin-registry which doesn't exist. The
real registry is ChuckBuilds/ledmatrix-plugins. Fixed.
- "Next Steps" / "Questions to Resolve" sections were
pre-implementation planning notes. Replaced with a "Known
Limitations" section that documents the actually-real gaps
(sandboxing, resource limits, ratings, auto-updates).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
6.1 KiB
LEDMatrix Plugin Architecture - Quick Reference
Overview
LEDMatrix is a modular, plugin-based system where users create, share, and install custom displays via a GitHub-based store (similar in spirit to HACS for Home Assistant). This page is a quick reference; for the full design see PLUGIN_ARCHITECTURE_SPEC.md and PLUGIN_DEVELOPMENT_GUIDE.md.
Key Decisions
✅ Plugin-First: All display features (calendar excepted) are now plugins
✅ GitHub Store: Discovery from ledmatrix-plugins registry plus
any GitHub URL
✅ Plugin Location: configured by plugin_system.plugins_directory
in config.json (default plugin-repos/; the loader also searches
plugins/ as a fallback)
File Structure
LEDMatrix/
├── src/
│ └── plugin_system/
│ ├── base_plugin.py # Plugin interface
│ ├── plugin_manager.py # Load/unload plugins
│ ├── plugin_loader.py # Discovery + dynamic import
│ └── store_manager.py # Install from GitHub
├── plugin-repos/ # Default plugin install location
│ ├── clock-simple/
│ │ ├── manifest.json # Metadata
│ │ ├── manager.py # Main plugin class
│ │ ├── requirements.txt # Dependencies
│ │ ├── config_schema.json # Validation
│ │ └── README.md
│ └── hockey-scoreboard/
│ └── ... (same structure)
└── config/config.json # Plugin configs
Creating a Plugin
1. Minimal Plugin Structure
manifest.json:
{
"id": "my-plugin",
"name": "My Display",
"version": "1.0.0",
"author": "YourName",
"entry_point": "manager.py",
"class_name": "MyPlugin",
"category": "custom"
}
manager.py:
from src.plugin_system.base_plugin import BasePlugin
class MyPlugin(BasePlugin):
def update(self):
# Fetch data
pass
def display(self, force_clear=False):
# Render to display
self.display_manager.draw_text("Hello!", x=5, y=15)
self.display_manager.update_display()
2. Configuration
config_schema.json:
{
"type": "object",
"properties": {
"enabled": {"type": "boolean", "default": true},
"message": {"type": "string", "default": "Hello"}
}
}
User's config.json:
{
"my-plugin": {
"enabled": true,
"message": "Custom text",
"display_duration": 15
}
}
3. Publishing
# Create repo
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/YourName/ledmatrix-my-plugin
git push -u origin main
# Tag release
git tag v1.0.0
git push origin v1.0.0
# Submit to registry (PR to ChuckBuilds/ledmatrix-plugin-registry)
Using Plugins
Web UI
- Browse Store: Plugin Manager tab → Plugin Store section → Search/filter
- Install: Click Install in the plugin's row
- Configure: open the plugin's tab in the second nav row
- Enable/Disable: toggle switch in the Installed Plugins list
- Reorder: order is set by the position in
display_modes/ plugin order; rearranging via drag-and-drop is not yet supported
REST API
The API is mounted at /api/v3 (web_interface/app.py:144).
# Install plugin from the registry
curl -X POST http://your-pi-ip:5000/api/v3/plugins/install \
-H "Content-Type: application/json" \
-d '{"plugin_id": "hockey-scoreboard"}'
# Install from custom URL
curl -X POST http://your-pi-ip:5000/api/v3/plugins/install-from-url \
-H "Content-Type: application/json" \
-d '{"repo_url": "https://github.com/User/plugin"}'
# List installed
curl http://your-pi-ip:5000/api/v3/plugins/installed
# Toggle
curl -X POST http://your-pi-ip:5000/api/v3/plugins/toggle \
-H "Content-Type: application/json" \
-d '{"plugin_id": "hockey-scoreboard", "enabled": true}'
See REST_API_REFERENCE.md for the full list.
Plugin Registry Structure
The official registry lives at
ChuckBuilds/ledmatrix-plugins.
The Plugin Store reads plugins.json at the root of that repo, which
follows this shape:
{
"plugins": [
{
"id": "clock-simple",
"name": "Simple Clock",
"author": "ChuckBuilds",
"category": "time",
"repo": "https://github.com/ChuckBuilds/ledmatrix-clock-simple",
"versions": [
{
"version": "1.0.0",
"ledmatrix_min_version": "2.0.0",
"download_url": "https://github.com/.../v1.0.0.zip"
}
],
"verified": true
}
]
}
Benefits
For Users
- ✅ Install only what you need
- ✅ Easy discovery of new displays
- ✅ Simple updates
- ✅ Community-created content
For Developers
- ✅ Lower barrier to contribute
- ✅ No need to fork core repo
- ✅ Faster iteration
- ✅ Clear plugin API
For Maintainers
- ✅ Smaller core codebase
- ✅ Less merge conflicts
- ✅ Community handles custom displays
- ✅ Easier to review changes
Known Limitations
The plugin system is shipped and stable, but some things are still intentionally simple:
- Sandboxing: plugins run in the same process as the display loop; there is no isolation. Review code before installing third-party plugins.
- Resource limits: there's a resource monitor that warns about slow plugins, but no hard CPU/memory caps.
- Plugin ratings: not yet — the Plugin Store shows version, author, and category but no community rating system.
- Auto-updates: manual via the Plugin Manager tab; no automatic background updates.
- Dependency conflicts: each plugin's
requirements.txtis installed via pip; conflicting versions across plugins are not resolved automatically. - Plugin testing framework: see HOW_TO_RUN_TESTS.md and DEV_PREVIEW.md — there are tools, but no mandatory test gate.
See PLUGIN_ARCHITECTURE_SPEC.md for the full architectural specification.