En temperaturgivare i ett fläktrum, en vattenmätare i en fastighet och en nivåsensor i en pumpstation har sällan nytta av sina värden var för sig. Värdet uppstår när informationen når rätt system, rätt person eller rätt automatisering i rätt tid. Det är här MQTT-brokerns funktion blir central: den tar emot, organiserar och förmedlar meddelanden mellan uppkopplade enheter och de system som ska använda data.
För verksamheter med många platser, sensorer och tekniska system är MQTT ofta ett praktiskt sätt att skapa ordning i datakommunikationen. Protokollet är byggt för små meddelanden och nätverk där anslutningen ibland kan vara begränsad. Med rätt utformning får driftorganisationen aktuell information utan att varje sensor behöver känna till varje dashboard, styrsystem eller rapportlösning som använder den.
Vad gör en MQTT-broker?
En MQTT-broker är en server som fungerar som meddelandecentral i ett IoT-system. Sensorer, dataloggers, gateways, PLC:er och andra enheter skickar meddelanden till brokern. Andra system hämtar sedan de meddelanden de behöver från samma broker.
Det sker genom principen publicera och prenumerera. En givare kan till exempel publicera ett temperaturvärde till ämnet `fastighet/uppsala/ventilation/temperatur`. Ett övervakningssystem prenumererar på ämnet för att visa värdet i en dashboard. Samtidigt kan en larmfunktion prenumerera på samma data och bedöma om temperaturen avviker från satta gränser. Givaren skickar alltså informationen en gång, medan flera mottagare kan använda den på olika sätt.
Brokern avgör vem som får vilket meddelande. Den jämför ämnet som avsändaren använder med de ämnen som mottagare prenumererar på. Därmed slipper enheterna direkta kopplingar till varandra. Det förenklar både installation, förändringar och framtida utbyggnad.
Ämnen ger struktur i stora installationer
Ämnen, ofta kallade topics, är MQTT:s sätt att sortera information. En bra ämnesstruktur speglar normalt verksamheten och gör data lättare att hitta. Den kan utgå från kund, geografisk plats, byggnad, anläggning, system och mätpunkt.
Ett kommunalt VA-bolag kan exempelvis skilja på data från reservoarer, pumpstationer och reningsverk. En industriverksamhet kan i stället gruppera data per produktionslinje, maskin eller energislag. Det viktiga är inte ett visst namnsystem, utan att strukturen är konsekvent, förståelig och fungerar när antalet mätpunkter växer.
En genomtänkt struktur underlättar även behörighetsstyrning. En entreprenör som ansvarar för en byggnad ska inte automatiskt kunna läsa information från samtliga fastigheter. Med tydliga ämnen kan åtkomst avgränsas på ett kontrollerat sätt.
MQTT-brokerns funktion från sensor till åtgärd
I praktiken är MQTT-brokern en del av en kedja. En sensor mäter ett fysiskt förhållande, till exempel temperatur, luftfuktighet, elförbrukning, flöde eller markfukt. Informationen skickas via en gateway, direkt över mobil uppkoppling eller från ett lokalt styrsystem. Brokern tar emot meddelandet och gör det tillgängligt för de funktioner som behöver det.
Nästa steg beror på användningsområdet. I en fastighet kan värdet visas i en dashboard tillsammans med historik och energinyckeltal. I en pumpstation kan samma typ av data användas för larm vid låg nivå eller onormala drifttider. I en industri kan data gå vidare till SCADA, underhållssystem eller analys för att upptäcka förändringar innan ett driftstopp uppstår.
Detta är en viktig skillnad mot att bara samla in data i en databas. En broker kan förmedla informationen direkt när något händer. Det passar när larm, styrning eller snabba beslut kräver färska värden. Historik och rapportering är fortfarande viktiga, men de ersätter inte behovet av kommunikation i realtid.
Exempel: vattenläckage i en kommersiell fastighet
Anta att en flödesmätare registrerar kontinuerlig vattenförbrukning under en tid då fastigheten normalt är tom. Mätaren eller den lokala gatewayen publicerar värdet via MQTT. Brokern levererar informationen till övervakningsplattformen, där regler jämför flödet med normal drift och fastställda gränsvärden.
Om avvikelsen kvarstår kan systemet skapa ett larm till jouransvarig och samtidigt registrera händelsen för uppföljning. Om anläggningen har en styrbar avstängningsventil kan en separat, behörighetsstyrd styrsignal skickas tillbaka via MQTT. Resultatet är kortare tid från upptäckt till åtgärd, vilket kan begränsa både vattenskador och kostnader.
Leveranssäkerhet när data inte får försvinna
Alla mätvärden har inte samma betydelse. Ett temperaturvärde som uppdateras varje minut kan ofta tåla att ett enskilt meddelande missas. Ett larm från en frysanläggning, ett tryckvärde i ett vattennät eller en statusförändring från en kritisk pump kan däremot kräva högre leveranssäkerhet.
MQTT har därför olika kvalitetsnivåer för leverans, vanligen QoS. Vid QoS 0 skickas meddelandet utan bekräftelse. Det ger låg belastning och passar täta, mindre kritiska mätvärden. QoS 1 innebär att meddelandet bekräftas och kan skickas igen vid behov. QoS 2 ger ytterligare kontroll men kräver mer kommunikation och används mer selektivt.
Det finns ingen inställning som är bäst överallt. Högsta möjliga leveransnivå kan verka trygg, men den ökar trafik och komplexitet. En välprojekterad lösning väljer nivå utifrån datans betydelse, uppdateringsfrekvens, nätverkets kvalitet och vad som händer om ett värde kommer sent eller två gånger.
En broker kan också behålla det senast publicerade värdet för ett ämne. När en ny mottagare ansluter kan den då få aktuell status direkt, i stället för att vänta på nästa mätning. För driftbilder är det ofta värdefullt. Det kräver samtidigt tydliga regler så att gamla värden inte misstolkas som nya observationer.
Säker MQTT-kommunikation kräver rätt grundarbete
En MQTT-broker samlar många informationsflöden på en plats. Därför måste säkerheten planeras från början, särskilt när systemet omfattar fastigheter, kritisk infrastruktur eller industriella processer.
Krypterad kommunikation skyddar data under överföring. Identitet och behörighet avgör sedan vilka enheter som får ansluta, publicera eller läsa från specifika ämnen. En fuktgivare i en källare ska exempelvis inte kunna skicka styrkommandon till ventilationen, och en extern part ska bara se den information uppdraget kräver.
Driftansvariga behöver också kunna följa upp anslutningar, felaktiga inloggningsförsök och enheter som slutat rapportera. En broker är inte ett engångsprojekt som sätts upp och lämnas utan tillsyn. Certifikat, lösenord, behörigheter och programvaruversioner behöver hanteras som en del av den löpande förvaltningen.
Var brokern ska köras är också en avvägning. En molnbaserad lösning kan förenkla central hantering av många geografiskt spridda anläggningar. En lokal installation kan vara lämplig när nätverkskrav, interna säkerhetsregler eller mycket korta svarstider styr valet. I vissa miljöer fungerar en kombination bäst: lokal kommunikation för kritiska funktioner och vidarebefordran av utvald data till en central plattform.
När MQTT passar – och när annat behövs
MQTT är särskilt lämpligt när många enheter ska skicka små mängder data ofta, eller när flera system behöver använda samma händelser. Det fungerar väl med fjärrövervakning av byggnader, energiuppföljning, miljömätning, vatteninfrastruktur och industriella tillämpningar.
Men MQTT ersätter inte automatiskt alla andra gränssnitt. Modbus kan vara rätt nära mätare och styrutrustning. OPC kan vara relevant i industriella system. LoRaWAN och NB-IoT kan vara transportvägar från fältet, medan MQTT används från gatewayen och vidare in i övervakningsplattformen. API:er kan behövas för affärssystem, fakturering eller externa rapporter.
Styrkan ligger därför ofta i att låta varje teknik göra det den är bäst på. MQTT-brokern blir då en tydlig kommunikationspunkt mellan fältutrustning, analys, dashboards, larm och överordnade system – utan att låsa verksamheten till en enda typ av sensor eller nätverk.
Så planerar ni en fungerande MQTT-lösning
Börja med verksamhetsfrågan, inte med protokollet. Vilka värden behöver ni se? Vilka avvikelser ska skapa larm? Vem ska kunna agera, och hur snabbt? Först därefter går det att avgöra vilka sensorer, kommunikationsvägar och kvalitetsnivåer som behövs.
Planera sedan ämnesstruktur, identiteter och behörigheter innan antalet enheter blir stort. Dokumentera dessutom hur enheter namnges, hur de tas i drift och vem som ansvarar när kommunikationen uteblir. Det sparar mycket tid när en ny byggnad, produktionslinje eller pumpstation ska anslutas.
Sensor-Online hjälper verksamheter att koppla samman sensorer, dataloggers, gateways och befintliga system i en gemensam lösning för data, larm och uppföljning. Som Sveriges största leverantör med erfarenhet från många branscher kan vi hjälpa er att reda ut tekniska val utan att göra projektet onödigt komplicerat. Kontakta oss på info@nodeledge.se eller ring +46(0)500 6000 22 – vi hjälper gärna till att hitta en lösning som ger er kontroll över det som händer ute i verksamheten.
