c8ac0b78c597cc0702857b8d93edc2f5c3c28803
req_id (added 2026-09-21 in the v2 topic rebuild, F-062):
- New Extras tab documents it fully: envelope-level (sibling of cmd,
not inside contents), always optional, exact echo/reply behavior,
parse-failure edge case, and an MQTT-only gap — WebSocket and HTTP
transports don't actually read or echo it despite CommandBus
supporting it generically at the bus level.
- Every command's Contents section now carries a persistent note
pointing to Extras, instead of duplicating the explanation 40+ times
or only mentioning it in one Transports card.
- Removed the old "req_id Correlation" card from the Transports tab —
superseded by the Extras tab.
Transports tab: dropped the V2/Legacy sub-tab switcher. It only ever
showed a "not documented yet" placeholder for Legacy, and the legacy
topic set belongs with the rest of the migration reference, not
alongside the current transport list.
Legacy Migration tab (renamed from "v1 → v2 Migration"): added a
"Legacy Topic Migration" table ahead of the command migration table,
mapping every MQTT topic from the old pre-rewrite firmware
("Controller - Production FW") to its v2 equivalent — including three
v2 topics (system/alerts, system/info, system/metrics) that have no
legacy predecessor at all. Reconstructed from that firmware's source;
it has been fully replaced, so this is historical reference only.
playback.play: filled in the full contents field set per the current
Player.cpp implementation — segment_duration, pause_duration,
total_duration, and continuous_loop are the legacy (no "mode") path,
while duration is the v2 path read only when mode is present. Added a
warning callout since sending mode alongside the legacy duration
fields doesn't merge behavior — only one path is read, based solely on
whether mode is present. This is intentional: mode is how a v2 caller
opts in, and its absence is how a v1 caller's request still works.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BellSystems Admin Panel
Self-hosted web admin panel for managing BellSystems devices, melodies, users, and MQTT communications.
Tech Stack
- Backend: Python / FastAPI
- Frontend: React + Tailwind CSS (Vite)
- Database: Google Firestore (Firebase Admin SDK)
- MQTT: Mosquitto (paho-mqtt)
- Auth: JWT with role-based access control
- Deployment: Docker Compose + Nginx
Getting Started
# Clone the repo
git clone <your-gitea-url>/bellsystems-admin.git
cd bellsystems-admin
# Copy env template and fill in your values
cp .env.example .env
# Place your Firebase service account key in the project root
# (file is gitignored — never commit it)
# Start everything
docker compose up --build
Project Structure
bellsystems-admin/
├── backend/ # FastAPI API server
├── frontend/ # React SPA
├── nginx/ # Reverse proxy config
├── docker-compose.yml
└── .env
Documentation
See BellSystems_AdminPanel_Strategy.md for the full architecture and build plan.
Description
BellSystems Contol Panel.
Handles everything from Devices to Clients.
Firebase / Mosquitto / Device Control / logging...
33 MiB
Languages
JavaScript
72.3%
Python
12.8%
HTML
12.4%
CSS
2.5%