En återanvändbar templateplattform för energidata, styrning och visualisering – byggd för att paketeras och säljas. Från referensinstallation till skräddarsydd kundlösning.
Syftet med SOVSystems är att bygga en digital tvilling av ett hem för att optimera och minska elförbrukningen samt kostnaden för köpt el. Produkten kombinerar lokal hårdvara, öppen programvara och en intelligent heuristikmotor i ett sammanhållet system.
MQTT-enheter baserade på ESP32 och tredjepartshårdvara som publicerar telemetri till systemet.
Raspberry Pi som kör MQTT-broker, datalager, API och statisk Digital Twin-webb lokalt på LAN.
Statisk webbapp som visualiserar nuläge, historik och planerade åtgärder i realtid.
AI/heuristikmotor som analyserar priser och telemetri för att ge förslag och styra laster.
Systemet är uppbyggt kring en central hub – RPIHUB – som tar emot data från alla enheter i hemmet via MQTT, lagrar det i en lokal SQLite-databas och gör det tillgängligt för UI och AI-motor. Nedan visas hur dataflödet ser ut från sensorer till dashboard.
Den minsta fungerande produkten (MVP) kräver endast att enheter publicerar till MQTT, att RPIHUB kör Mosquitto och ingest, och att API:t serverar UI:n. Baltazar kan aktiveras i ett senare steg när tillräckliga signaler finns tillgängliga.
RPIHUB är produkten som körs lokalt på LAN. Den samlar alla komponenter i ett enda system: MQTT-broker, datainsamling, API och webbgränssnitt. Allt körs som systemd-services för stabil drift.
RPIHUB konfigureras via en env-fil. De viktigaste nycklarna:
RPIHUB_DB – sökväg till SQLite-databasRPIHUB_STATIC_ROOT – måste innehålla DigitalTwin_WebApp/RPIHUB_MQTT_HOST/PORT – broker-adressRPIHUB_MQTT_TOPICS – vilka topic-filter att ingest:aDatabasen är medvetet enkel – ingen ORM, bara ren SQL. Schemat initieras vid start och definieras i mqtt_ingest.py och api_server.py. För att hålla hemligheter separerade från konfiguration delas DT-data upp i två filer.
Råa MQTT-meddelanden för debug och spårbarhet. Innehåller received_at_utc, topic och payload.
Normaliserade tidsserier med time_local, metric, value, unit och source. Indexerad på datum och metric för snabba uppslag.
Dagliga summeringar per datum: produktion, konsumtion, import, export, charge och discharge.
Planerade och registrerade last-event med load_id, start/slut-tid, power_kw och anteckningar.
Masterdata och topologi – inte hemlig. Kan delas och versionhanteras fritt.
Lagrar enbart bearer_token, refresh_token, client_secret och api_key. Indexeras per site och entity. Sätts till chmod 600 på Pi.
För att slippa att varje UI, ingest och AI-motor måste förstå 20 olika payload-format inför vi ett kanoniskt MQTT-lager. Alla signaler normaliseras till samma topic-struktur och JSON-format innan de når databasen.
Shelly, Tuya, växelriktare eller värmepump med eget protokoll.
Node-RED, Python-service eller ESP32-gateway publicerar kanoniska topics.
iot/energy/tele/han/import_kwh_qh – standardiserat format.
Ingest, Digital Twin och Baltazar konsumerar samma enhetliga signaler.
Firmware-källkoden finns i Arduino-repot och täcker allt från dashboard-enheter med LCD-skärm till HAN-mätare och energiaktuatorer. Enheterna provisioneras via WebBLE-verktyget som skickar konfiguration över Bluetooth.
ESP32-S3 med 4,3" RGB-display. Visar lokal energistatus utan broker-koppling.
Läser HAN-porten på elmätaren och publicerar import/export-data till MQTT.
Styrbara reläer för att koppla laster av och på baserat på Baltazars styrsignaler.
Provisionering sker via WebBLE-verktyget som skickar CFG/CARDS/SET-kommandon över BLE.
Se /DEPLOY_SoV.md för komplett deploy-guide.
Första versionen är en deterministisk kontrollheuristik fokuserad på batteristyrning och lastoptimering. Den tar emot parametrar som batterikapacitet, SoC-gränser, max charge/discharge, import-cap (peak shaving) samt trösklar för "billig" och "dyr" el.
Koden finns i /server/telemetry_api/baltazar.py med konfiguration i baltazar_config.json.
För att gå från heuristik till full prognos och automatiserad reglering krävs:
.../cmd/...SOVSystems är designat för att köras lokalt på LAN men kan utvecklas och testas på valfri plattform. Nedan beskrivs de två huvudsakliga driftmiljöerna: lokal utveckling och produktionsdrift på Raspberry Pi.
Starta API:t med statiska filer via uvicorn. DigitalTwin_WebApp servas från samma origin som API:t för att undvika CORS-problem. Idealiskt för att testa UI och API-logik innan deployment.
Följ guiden i deploy/mosquitto/README.md. Konfigurera lyssnare, authentication och topic-filter enligt din installationsbehov.
Installera rpihub.service (API), rpihub-ingest.service (datainsamling) och valfritt rpihub-weather.service. Se /tools/rpihub/README.md för komplett onboarding-guide.
På Pi checkas repot ut i /opt/sovsystems/sovdevice-rpihub och uppdateras med git pull.
För att hålla systemet hanterbart vid varje ny installation finns fyra grundläggande principer att följa. Dessa minskar komplexiteten och gör det möjligt att paketera lösningen till nya kunder.
Varje signal definieras med MQTT-topic, JSON-schema och enhet (kW, kWh, °C, %). Inga implicita antaganden.
Adapter → kanoniska MQTT-topics → ingest/DB/API/AI/UI. Ju tidigare normalisering sker, desto enklare blir varje efterföljande lager.
Telemetri publiceras under .../tele/..., styrkommandon under .../cmd/... med tydligt ack/state-mönster för säker återkoppling.
Råa meddelanden sparas i raw_messages-tabellen. Det möjliggör felsökning i efterhand utan att förlora data.
dt_secrets.json (chmod 600, endast service-user)MQTT_CATALOG.md – komplett topic- och signalkatalogDT_TODO.md – prioriterad backlog (P0/P1/P2)REPO_STRUCTURE.md – mapp-ägarskap och struktursovdevice/tools/rpihub/README.md – onboarding-guide
SOVSystems -