Användningsfall för MQTT-baserad närvaroautomation

De flesta fastighetsautomationsprojekt misslyckas inte på sensorsidan – de misslyckas i integrationslagret. Ett BMS som pollar en REST-API var femte minut för att hämta beläggningsdata reagerar för långsamt för att styra ventilation, belysning eller access i realtid. Det är precis här MQTT occupancy automation gör skillnad: ett publish/subscribe-mönster där räknesensorer pushar händelser i samma sekund de inträffar, till vilket system som helst som prenumererar på rätt topic. Skillnaden mellan polling och push låter akademisk tills du står i ett konferensrum där ventilationen fortfarande går för fullt tjugo minuter efter att alla lämnat.

Varför MQTT och inte bara ännu ett API

MQTT är designat för exakt det scenario en fastighet befinner sig i: många enheter, opålitliga nätverk, låg bandbredd och behov av leveransgarantier. En räknesensor som publicerar in/ut-händelser till en broker behöver inte veta något om vilka system som konsumerar datan. Ni kan koppla på BMS:et idag, städplaneringssystemet nästa kvartal och en energidashboard året därpå – utan att röra sensorkonfigurationen. QoS-nivåerna (0, 1, 2) låter er dessutom välja mellan hastighet och garanterad leverans per användningsfall: belysningsstyrning tål en tappad händelse, medan beläggningsräknare som ligger till grund för brandskyddsgränser inte gör det.

En praktisk detalj som ofta glöms: retained messages. Konfigurera sensorerna att publicera aktuell zonbeläggning som retained, så får varje nytt system som ansluter – eller ett BMS som startar om efter strömavbrott – omedelbart senaste kända värde istället för att vänta på nästa händelse. Det låter trivialt men är skillnaden mellan ett system som återhämtar sig på sekunder och ett som visar nollor i en timme efter varje omstart.

Användningsfall 1: HVAC-styrning på faktisk beläggning

Behovsstyrd ventilation baserad på CO2-givare är standard, men CO2 är en eftersläpande indikator – halten stiger först när rummet redan varit fullt en stund. Räknedata via MQTT ger en ledande signal: ventilationen kan trappas upp när trettio personer passerar in i en föreläsningssal, inte femton minuter senare när luften redan är dålig. Kombinationen är starkast: låt beläggningsräkningen sätta grundflödet och CO2-givaren finjustera. Integratörer som byggt detta rapporterar att den verkliga vinsten inte är komforten utan nedtrappningen – rum som tömts identifieras direkt, och aggregat går ner i viloläge timmar tidigare än med schemabaserad drift.

Användningsfall 2: Städning och service på behov, inte schema

Toaletter, mötesrum och gemensamma ytor städas idag oftast enligt fast schema – vilket betyder att lågtrafikerade ytor överstädas och högtrafikerade ytor understädas samma dag. Med ackumulerade passageräkningar per zon publicerade över MQTT kan ett FM-system trigga arbetsordrar när tröskelvärden nås: "toalettgrupp plan 3 har passerat 120 besök sedan senaste städning". Facility managers som infört detta brukar börja med en enda byggnadsdel som pilot, eftersom städleverantörens avtal ofta är skrivna kring frekvens snarare än behov – kontraktsomskrivningen tar längre tid än den tekniska integrationen.

Användningsfall 3: Beläggningsgränser och evakueringsunderlag

I lokaler med kapacitetsgränser – eventytor, gym, kantiner – ger realtidsräkning över MQTT ett levande underlag: skyltar som visar aktuell beläggning, automatiska notiser till personal när 90 procent av kapaciteten nås, och loggad historik som underlag vid tillsyn. Här spelar räknenoggrannheten en avgörande roll, och den bör hanteras ärligt i kravställningen. Vemco Group arbetar med ett kontraktuellt minimum på 96 procents noggrannhet, med 98–99 procent som typiskt utfall när ljusförhållanden, entréutformning och besöksbeteende tillåter. Skriv in minimigränsen i avtalet och verifiera med manuell kontrollräkning vid driftsättning – lova aldrig en fast siffra i era egna kundavtal som er leverantör inte garanterar er.

Användningsfall 4: Yteffektivitet och hyresbeslut

MQTT-strömmen är realtid, men samma data ackumulerad över månader blir strategiskt underlag. Smart building-team som matar beläggningshändelser in i en tidsseriedatabas (Timescale, InfluxDB eller motsvarande) kan svara på frågor som fastighetsägare faktiskt betalar för: vilka våningsplan når aldrig 40 procents nyttjande, vilka mötesrum bokas men används inte, och hur förändrades mönstret efter hybridarbetspolicyn. Fördelen med MQTT-arkitekturen är att realtidsstyrningen och analysflödet konsumerar exakt samma händelseström – ingen dubbel sensorinfrastruktur, ingen datadivergens mellan system.

GDPR är inte ett hinder – om arkitekturen är rätt från början

Beläggningsdata i kontorsmiljö väcker omedelbart frågor från fackliga representanter och dataskyddsombud, och de frågorna är berättigade. Nyckeln är att välja räkneteknik som aldrig producerar persondata: aggregerade räkningar utan personidentifiering, med möjlighet att exkludera personal ur besöksstatistiken. Vemco Group, som levererat personräkning sedan 2005 till över 2000 kunder i fler än 95 länder, har byggt sin plattform kring exakt denna princip – GDPR-säker räkning där det som publiceras är siffror, inte individer, med drift i hostad eller privat molnmiljö beroende på organisationens krav. För integratören betyder det att MQTT-payloaden kan vara så enkel som zon-ID, tidsstämpel och delta – ingenting som en DPIA behöver problematisera.

Verifiera dock alltid detaljerna innan upphandling: certifieringar, SSO-stöd och datalagringens geografiska placering skiljer sig mellan leverantörer och avtalsformer, och de svaren ska stå i ert avtal, inte i ett säljblad.

Vad implementerare önskar att de vetat från början

Några punkter som sparar veckor i praktiken:

• Definiera topic-strukturen innan första sensorn monteras. Ett mönster som byggnad/plan/zon/händelsetyp med wildcard-prenumerationer gör att nya konsumenter kan ansluta utan omkonfiguration. Att döpa om topics i efterhand kräver att varje prenumerant uppdateras.
• Hantera driftavbrott med Last Will and Testament. Konfigurera LWT så att brokern publicerar offline-status när en sensor tappar kontakt – annars styr ni ventilation på timmar gamla data utan att veta om det.
• Separera brokern från BMS:et. En fristående broker (Mosquitto, EMQX, HiveMQ) med TLS och klientcertifikat överlever BMS-uppgraderingar och leverantörsbyten.
• Räkna zoner, inte bara entréer. Nettoberäknad zonbeläggning kräver att in- och utpassager balanseras – planera för nollställningsrutiner nattetid, eftersom även små räknefel ackumuleras över tid.

Den sista punkten är den observation som skiljer erfarna implementerare från nybörjare: ingen räknare är hundraprocentig, och i en zonberäkning som aldrig nollställs blir 98 procents noggrannhet till en drift på tiotals personer efter en vecka. Automatisk midnattsnollställning när byggnaden bevisligen är tom löser problemet elegant – men bara om någon tänkt på det i designfasen.

Börja med ett användningsfall, bygg för fem

Det starkaste argumentet för MQTT-baserad närvaroautomation är inte något enskilt användningsfall utan arkitekturens återanvändbarhet. Sensorinvesteringen som motiveras av HVAC-besparingar levererar sedan städoptimering, kapacitetsstyrning och ytanalys utan ytterligare hårdvara. Budgetera därför för brokern, topic-designen och datakvalitetsrutinerna från dag ett – det är där skillnaden mellan ett pilotprojekt och en plattform avgörs.

Planerar ni en MQTT-integration av beläggningsdata i er fastighet eller ert kunderbjudande? Kontakta Vemco Group för en teknisk genomgång av räknenoggrannhet, integrationsmöjligheter mot er befintliga IT-miljö och hur GDPR-säker personräkning implementeras i praktiken.