Ett fungerande proof of concept som samlar energidata, sensorer och smarta enheter i en plattform. I drift i två fastigheter, där en AI-agent fattar autonoma värmebeslut var trettionde minut.
Oavo är ett fungerande proof of concept för AI-driven fastighetsdrift. Det började som ett läroprojekt med en enkel fråga: hur mycket av driften kan en AI-agent faktiskt ta över, när den får köra mot riktiga sensorer i riktiga hus i stället för i en demo?
En AI-agent fattar autonoma värmebeslut var trettionde minut i två fastigheter, med 15+ IoT-integrationer, omkring 200 uppkopplade givare, energianalys och en boendeapp. Plattformen är byggd till stor del med AI som kodare, vilket flyttade arbetet från att bygga till att verifiera.
Lärdomarna delas gärna. Är du intresserad av att samarbeta, jämföra erfarenheter eller höra hur agenten fattar sina beslut? [email protected]
Från autonom värmestyrning till boendeapp — det här är vad som faktiskt körs i de två fastigheterna i dag.
Realtidsdata från elmätare och värmepump samlas i samma analys. Effekt just nu, i dag och för månaden ur elmätaren, plus förbrukning per rum, per enhet och mot föregående period.
Energi & klimatElmätaren läses över AMS-gränssnittet och ger effekt just nu, förbrukning i dag och hittills i månaden. Värmepumpen Bosch Climate 6000i pollas var femte minut över tillverkarens API och rapporterar drifttillstånd och börvärden; Compress 7000i tar emot styrkommandon över MQTT.
Mätvärdena landar i en tidsserie i PostgreSQL, så förbrukningen går att bryta ner per rum, per enhet och mot föregående period. Det är samma tidsserie agenten läser ur när den fattar sina värmebeslut — analysen och styrningen delar databas, i stället för att en rapportvy visar en sak och regleringen gör en annan.
Sensordata jämförs mot baslinjer per givare, och avvikelser larmar innan de blir fel. En tystnadsdetektor hittar givare som slutat skicka, och bortfall per MQTT-prenumeration larmar i alla tre instanserna.
Drift & underhållBaslinjer byggs per givare, och avvikelser larmar innan de blir fel. Två detektorer täcker det som är svårast att upptäcka: att en givare slutar höras av.
En tystnadsdetektor larmar när minst tio regelbundna givare ur samma källa varit tysta i 48 timmar. En bortfallsdetektor bevakar varje MQTT-prenumeration i alla tre instanserna. Ute i fastigheten startar en watchdog om bluetooth-bryggan när länken till belysningen tyst försvunnit.
Poängen är att tystnad är en vanligare felmod än fel värden — och den syns inte i en graf.
De boende ser inomhustemperatur, sensorernas tillstånd, avgifter och förbrukning — och felanmäler direkt i appen. Varje lägenhet ser bara sin egen data.
Boende & serviceDe boende ser inomhustemperatur och tillståndet per sensor, sina avgifter och sin förbrukning, och kan felanmäla direkt i appen.
Varje lägenhet ser bara sin egen data. Behörigheten är scopad ner på lägenhetsnivå i samtliga skrivvägar, och kontrollen sker på servern — inte i gränssnittet, där den vore ett förslag snarare än en spärr.
Startsidan visar det som behöver uppmärksamhet just nu i stället för en full instrumentpanel, och vyn går att ställa in i tre nivåer — dölj, enkelt eller avancerat.
KPI-vyer för energi, ekonomi och underhåll ger styrelse och förvaltare samma faktaunderlag. Budget mot utfall per kategori, historisk årsnavigering och en månadsrapport som ställs samman av sig själv.
Analys & rapporterBudget mot utfall per kategori, med historisk årsnavigering: äldre år öppnas skrivskyddade, så att historiken inte går att råka ändra. KPI-vyer för energi, ekonomi och underhåll ger styrelse och förvaltare samma underlag i stället för var sitt kalkylark, och flera fastigheter hanteras i samma gränssnitt.
Månadsrapporten ställs samman av sig själv den första varje månad klockan åtta, för månaden som precis tagit slut: budgetavvikelse i kronor, antal larm under perioden och hur många som fortfarande är aktiva, samt avklarade underhållsarbeten av totalt planerade. Sammanfattningen kan skickas vidare som ett webhook-anrop, och den fullständiga rapporten finns som en egen vy.
Varje fastighet är modellerad efter REC-ontologin. Rumsnivå-data, utrustningsregister och relationer ger ett komplett digitalt fastighetsminne.
Digital tvillingFastigheterna är modellerade efter REC-ontologin: en platshierarki från fastighet ner till rum, ett utrustningsregister och relationerna mellan dem. Registren ligger i samma PostgreSQL som mätvärdena.
Tvillingen är inte en visualisering utan ett register. Den är källan till vilka givare som finns, var de sitter och vad de hör ihop med — och det är just det som gör att en avvikelse kan pekas ut på rumsnivå i stället för på ett anonymt givar-id.
Flera fastigheter i samma gränssnitt, med en startsida som listar dina fastigheter, deras hälsostatus och det som behöver uppmärksamhet just nu.
PortföljvyStartsidan Mina fastigheter listar fastigheterna med hälsostatus och chips för det som behöver uppmärksamhet. En fastighet kan nålas som favorit och blir då den du landar på.
Varje fastighet har en egen detaljsida där korten går att ordna om med drag och släpp och visas i tre nivåer. Appen är byggd som en fristående Vue-applikation bakom inloggningen, skild från den äldre instrumentpanelen — samma data, ny informationsarkitektur.
Var trettionde minut läser en agent sensordata, frågar en språkmodell och fattar ett värmebeslut — och skickar kommandot vidare till värmepumpen. Varje beslut och varje kommando sparas med granskningsrad.
Autonom driftVar trettionde minut kör ett schemalagt flöde: det hämtar aktuell sensordata ur PostgreSQL, bygger en förfrågan och skickar den till en språkmodell. Svaret tolkas till konkreta åtgärder, som går ut som MQTT-kommandon till värmepumpen och som anrop till klimatstyrningen.
Varje beslut och varje utgående kommando loggas — besluten i en agentlogg, kommandona i en kommandologg med granskningsrad — så att det i efterhand går att se vad agenten gjorde och varför.
Styrningen har en växel i appen. Är den påslagen kör agenten utan att någon trycker på en knapp; slås den av fattar agenten inga beslut alls, och det är avsiktligt — en autonom värmestyrning ska gå att stänga av från soffan. Det är den här delen som gör projektet till ett proof of concept och inte en demo.
Egen SSO med Keycloak, och behörighet ända ner på lägenhetsnivå: varje läs- och skrivväg kontrolleras på servern, och styrkommandon loggas med en identitet som inte går att förfalska.
Säkerhet & rollerInloggningen sköts av en egen Keycloak-installation. Behörigheten går ner på enskild lägenhet, och kontrollen ligger på servern i varje läs- och skrivväg.
Styrkommandon skrivs med en identitet som inte går att förfalska från klienten, på samtliga nio styrvägar.
Att den här delen står med bland funktionerna är ett medvetet val. Den är osynlig när den fungerar — och den är samtidigt det som avgör om resten överhuvudtaget går att köra mot riktiga boendes data.
Oavo körs som molntjänst på en egen server: Node-RED i tre instanser, PostgreSQL och en Vue-app bakom SSO. Ingenting är köpt som färdig produkt.
Befintliga sensorer, värmesystem, elmätare och IoT-enheter kopplas in via öppna standarder — MQTT, Z-Wave och leverantörernas egna API:er. 15+ integrationer är i drift.
Mätvärdena landar i en tidsserie i PostgreSQL och baslinjer byggs per givare. Avvikelser, tystnad och bortfall upptäcks automatiskt.
Agenten fattar värmebeslut var trettionde minut och skickar kommandon till värmepumpen. Notiser, avvikelser och åtgärdsförslag når styrelse, förvaltare och boende — var och en scopad till sin egen data.
Plattformen läser och styr system som redan fanns på plats, över öppna standarder och leverantörs-API:er — ingenting behövde bytas ut.
Oavo körs i produktion i två fastigheter med vitt skilda förutsättningar — och levererar realtidsdata dygnet runt.
Oavo är byggt för att ta reda på vad som faktiskt krävs för att låta AI styra en fastighet i skarp drift — och svaret blev både mer och annorlunda än väntat. Lärdomarna delas gärna: vill du samarbeta, jämföra erfarenheter eller titta närmare på arkitekturen och agenten? Hör av dig.
Kontakt: [email protected]