bonamin
1ed5012a95
melody.uid is never actually populated anywhere in MelodyForm.jsx, so keying local .bsm storage on it (as the previous commit did) would silently break for every existing melody. pid is the correct key anyway: it identifies the underlying archetype binary, and multiple melodies legitimately share one pid (each remaps the same note sequence to different bells/speed/duration via its own settings). Deletion is now share-aware — a melody's binary is only removed from disk once no other melody still references its pid. Also adds backend/scripts/migrate_melody_binaries_to_local.py to backfill existing melodies from their old Firebase URLs to local storage, with --dry-run support and a warning list for pids whose melodies point at different source files (a pre-existing data issue, flagged for manual review via each melody's playback button rather than silently resolved). 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.