En fuktgivare i en teknikbyggnad skickar ett värde som passerar larmgränsen. Driftansvarig behöver veta det direkt, systemet ska kunna hantera svag uppkoppling och informationen ska samtidigt bli användbar i ett överordnat system. Valet mellan mqtt eller http protokoll påverkar hur väl hela kedjan fungerar – från sensor och gateway till dashboard, larm och rapportering.
Båda protokollen är etablerade och användbara. HTTP är det välkända språket bakom många webbtjänster och systemintegrationer. MQTT är byggt för att skicka små mängder data effektivt mellan många uppkopplade enheter. Rätt val handlar därför sällan om vilket protokoll som är bäst i allmänhet. Det handlar om datamängd, svarstid, nätverkets kvalitet, säkerhetskrav och hur den befintliga miljön ser ut.
MQTT eller HTTP-protokoll: den viktiga skillnaden
HTTP bygger på en tydlig fråga och ett tydligt svar. En enhet eller applikation skickar en begäran till en server, exempelvis för att rapportera ett mätvärde eller hämta en inställning. Servern svarar sedan. Modellen är enkel att förstå och passar särskilt bra när ett system behöver läsa data vid en viss tidpunkt, koppla mot ett API eller skicka mer omfattande information i enstaka överföringar.
MQTT arbetar i stället med publicering och prenumeration. En temperatursensor publicerar sitt mätvärde till ett angivet ämne, ofta kallat topic. Andra system som behöver informationen prenumererar på samma topic och får uppdateringen direkt. En MQTT-broker fungerar som en central förmedlare och ser till att rätt meddelande når rätt mottagare.
Skillnaden kan liknas vid att ringa ett samtal jämfört med att sätta upp en informationskanal. Med HTTP frågar mottagaren efter information eller tar emot ett direkt meddelande. Med MQTT kan flera mottagare få samma uppdatering när den uppstår, utan att sensorn behöver känna till vilka de är.
För verksamheter med många distribuerade mätpunkter ger detta praktiska konsekvenser. En kommun kan exempelvis låta driftcentral, energiuppföljning och analysfunktion ta emot samma flödesdata från en vattenanläggning. En fastighetsorganisation kan låta larmmotor, dashboard och historik få samma temperaturvärde samtidigt.
När MQTT är det naturliga valet
MQTT är utvecklat för IoT-miljöer där enheter ofta har begränsad bandbredd, batteridrift eller varierande nätanslutning. Protokollets meddelanden är små och anslutningen kan hållas öppen, vilket minskar behovet av upprepade uppkopplingar. Det är värdefullt för sensorer som rapporterar ofta och för anläggningar där mobil uppkoppling, radiolänk eller annan kommunikation inte alltid är helt stabil.
Ett tydligt användningsfall är realtidsövervakning. När trycket i en pumpstation förändras, när temperaturen i ett kylrum stiger eller när energiförbrukningen avviker, kan informationen förmedlas snabbt till de funktioner som behöver agera. MQTT lämpar sig också väl när många enheter skickar data parallellt och när samma data ska användas i flera system.
Protokollet har olika nivåer för leveranssäkerhet, så kallad Quality of Service, QoS. Vid QoS 0 skickas meddelandet en gång utan kvittens. Det kan vara tillräckligt för täta, mindre kritiska mätvärden där nästa värde snart kommer. Vid QoS 1 bekräftas leveransen, men mottagaren behöver kunna hantera att samma meddelande kan komma mer än en gång. QoS 2 ger en mer strikt leveransmodell, men innebär också mer kommunikation och belastning.
Det finns alltså ingen anledning att välja högsta nivå för all data. För en utomhustemperatur som rapporteras var femte minut kan en enklare nivå vara klok. För ett larm som signalerar översvämningsrisk, driftstopp eller ett kritiskt gränsvärde kan bekräftad leverans vara rätt prioritering. En genomtänkt konfiguration ger driftsäkerhet utan onödig datatrafik.
MQTT passar särskilt väl för löpande telemetri, larm, status från utrustning och styrsignaler. Det kan användas bakom en gateway som samlar data från Modbus, PLC, OPC eller andra fältprotokoll och skickar informationen vidare till en central plattform. På så sätt behöver äldre utrustning inte bytas ut enbart för att data ska bli tillgänglig på ett modernt sätt.
När HTTP ger mest nytta
HTTP är ofta det bästa valet när data ska utbytas med affärssystem, kundportaler, ärendehantering eller andra webbaserade tjänster. Många API:er bygger redan på HTTP, och det är välkänt hos både IT-avdelningar och systemintegratörer. Det gör det enkelt att hämta rapportunderlag, skicka mätvärden till ett externt system eller skapa integrationer med tydliga anrop och svar.
HTTP fungerar även bra för konfiguration och större dataöverföringar. En gateway kanske behöver hämta nya regler, överföra en loggfil eller rapportera samlad statistik en gång per dygn. I sådana situationer är den direkta begäran och svaret ofta lätt att följa upp, testa och felsöka.
För enskilda enheter som rapporterar sällan kan HTTP vara fullt tillräckligt. En vattenmätare som skickar ett dygnsvärde, eller en datalogger som laddar upp samlade mätserier enligt schema, behöver inte nödvändigtvis en ständig MQTT-anslutning. Valet blir ännu mer naturligt om den mottagande tjänsten enbart erbjuder ett HTTP-baserat API.
Nackdelen visar sig främst vid många frekventa överföringar. Varje HTTP-begäran innehåller mer information än ett typiskt MQTT-meddelande, och modellen ger inte samma naturliga funktion för att distribuera en uppdatering till flera mottagare i realtid. Det går att lösa med kompletterande teknik, men arkitekturen blir ofta mer komplex än nödvändigt för stora sensorflöden.
Säkerhet avgör mer än själva protokollet
Varken MQTT eller HTTP är automatiskt säkert bara för att protokollet valts. Säkerheten formas av hela lösningen: krypterad kommunikation, rätt identiteter, behörigheter, lösenord eller certifikat, nätverksregler och löpande uppdateringar. Kommunikation bör normalt skyddas med TLS, så att data inte kan läsas eller ändras på vägen.
I MQTT-miljöer är det särskilt viktigt att styra vilka topics en enhet får publicera till och prenumerera på. En sensor för ett specifikt objekt ska inte kunna skicka data till eller läsa data från andra delar av verksamheten. I HTTP-lösningar behöver API-nycklar, tokens och behörigheter hanteras med samma omsorg.
Tänk också på driften runt protokollet. Vad händer om internetanslutningen försvinner? Kan gatewayen mellanlagra data lokalt? Hur ser ni att en sensor slutat rapportera? Finns det larm för utebliven kommunikation, för gamla programversioner eller för ovanliga datamönster? Ett säkert system är inte bara skyddat mot obehörig åtkomst, utan också byggt för att upptäcka när något slutar fungera.
MQTT och HTTP fungerar ofta bäst tillsammans
I praktiken behöver ni sällan välja bort det ena protokollet helt. En modern IoT-arkitektur använder ofta MQTT nära enheter och drift, där kontinuerliga dataflöden och larm ska hanteras effektivt. HTTP används sedan för att dela information med externa tjänster, rapportverktyg och verksamhetssystem.
Ett industriföretag kan exempelvis samla maskindata via en lokal gateway, skicka händelser och mätvärden med MQTT till övervakningsplattformen och använda HTTP för att föra över sammanställd data till underhållssystemet. I en fastighet kan MQTT hantera sensorer, ventiler och realtidslarm, medan HTTP används för energiuppföljning, hyresgästportaler eller ekonomisystem.
Det centrala är att informationen får ett tydligt sammanhang. Mätvärden behöver kopplas till rätt byggnad, zon, maskin eller abonnemang. Enheter behöver kunna tas i drift utan omfattande manuellt arbete. Och data ska presenteras så att en drifttekniker kan fatta beslut, inte bara se en lång lista med siffror.
Så väljer ni protokoll för er miljö
Börja med den operativa frågan, inte med tekniken. Behöver ni få larm inom sekunder? Då talar mycket för MQTT. Ska ni integrera med ett befintligt API eller skicka samlade underlag enligt ett schema? Då kan HTTP vara den mest raka vägen. Har ni både kontinuerliga sensordata och externa system att ansluta? Då är en kombination ofta mest hållbar.
Bedöm sedan hur många enheter som ska anslutas, hur ofta de rapporterar och vilken typ av nätverk de använder. Tusentals mätpunkter som rapporterar regelbundet ställer andra krav än tio dataloggrar med en daglig överföring. Titta även på framtiden: ska fler fastigheter, stationer eller produktionslinjer kunna anslutas utan att ni behöver bygga om hela lösningen?
Slutligen bör ni undvika att låsa er till enskild hårdvara eller ett slutet ekosystem. En plattform som kan ta emot data från flera nät, sensortyper och protokoll ger större handlingsfrihet när behoven förändras. Det gör det enklare att behålla befintliga investeringar, välja rätt utrustning för varje plats och samla driften i samma vy.
Sensor-Online hjälper verksamheter att koppla samman fältnära utrustning, dataloggrar och affärsnära system utan att göra teknikvalet onödigt svårt. Som Sveriges största leverantör med dokumenterad erfarenhet från många branscher kan vi hjälpa er att reda ut både protokoll, sensorer, nätverk och krav på framtida utbyggnad. Kontakta oss på info@nodeledge.se eller ring +46(0)500 6000 22 – vi hjälper gärna till att göra nästa steg tydligt och tryggt.
Det bästa protokollet är det som ger er tillförlitliga data när ni behöver dem, passar era befintliga system och fortfarande fungerar när verksamheten växer.
