Guide: Opsæt din egen MQTT‑broker på din hjemmeserver

Drømmer du om et hjem, der selv justerer varmen, sender besked om vandforbruget og reagerer øjeblikkeligt, når du trykker på en knap? Så er MQTT – og især en egen MQTT-broker – nøglen til din næste niveau af hjemme-automation.

Mange begynder med cloud-tjenester til deres IoT-enheder, men opdagelsen kommer hurtigt: Hvorfor sende følsomme data over Atlanten, når de kan blive hjemme i din egen kælder? Ved at hoste din egen broker får du ikke kun fuld kontrol over privatlivet – du skærer også dyrebare millisekunder af responstiden, undgår månedlige abonnementer og kan tilpasse alt ned til mindste detalje.

I denne guide viser vi trin for trin, hvordan du på under en eftermiddag kan:

  • Installere en lynhurtig MQTT-broker på din Raspberry Pi eller hjemmeserver
  • Hærdningen med TLS, adgangskontrol og smarte ACL-regler
  • Finpudse topic-strukturen, så dine pumper, temperaturfølere og automationsflows spiller perfekt sammen
  • Teste, overvåge og udvide din opsætning – helt uden at knække budgettet

Uanset om du er ny i IoT-verdenen eller allerede har et dusin ESP32-sensorer i gang, vil du her få praktiske anvisninger og bedste praksis, der gør din bolig både smartere og mere selvstændig. Klar til at tage kontrollen hjem? Så scroll videre – din personlige MQTT-broker venter.

Hvorfor sætte en egen MQTT-broker op?

MQTT (Message Queuing Telemetry Transport) er et letvægts-protokol designet til at sende beskeder på ustabile eller båndbredde­begrænsede netværk. I stedet for at enhederne kommunikerer direkte med hinanden, sender de beskeder til en broker, som distribuerer dem til de klienter, der har subscribe’t til de relevante topics. Denne publish/subscribe-model betyder, at sensorer, styreenheder og dashboards kan være fuldstændigt adskilte, men stadig udveksle data i realtid.

Fordele ved at hoste selv

  • Privatliv og datasuverænitet — Al trafik forbliver på dit lokale netværk, så følsomme målinger som rumtemperatur, vandforbrug eller bevægelsesdata lander ikke i en sky-tjeneste.
  • Fuld kontrol — Du bestemmer brugere, adgangskontrol og opdaterings­frekvens. Ingen pludselige ændringer i abonnement eller service­betingelser.
  • Lav latency — Lokale beskeder tager millisekunder, hvilket gør dine automations mere responsive og giver færre udfald, hvis internet­forbindelsen går ned.
  • Skalerbarhed til hus­behov — En Raspberry Pi eller hjemmeserver kan uden problemer håndtere hundredevis af topics og enheder.

Typiske hjemmebrugsscenarier

  • Varmefølere og termostater
    Rumtemperatur og sætpunkter publiceres til home/livingroom/temperature, mens gulvvarme­pumper lytter på home/heating/command.
  • Vandmåling og lækagealarmer
    En vandmåler sender pulstællinger, mens en lækage­sensor publicerer en Last Will i tilfælde af strømsvigt.
  • Cirkulations- og drænpumper
    MQTT-styrede relæer tænder/slukker baseret på f.eks. udendørs­temperatur eller tidsplaner fra Home Assistant.
  • Automationsflows og scene-styring
    Node-RED abonnerer på home/+/status for at bygge regler som “hvis dør åbnes efter kl. 23, tænd natlys”.
  • Energiovervågning
    Målinger fra solcell­e-inverter, varmepumpe og el-bil oplader kombineres i realtime og sendes til graf- og alarm­systemer.

Ved at køre en egen broker binder du alle disse data­kilder sammen på din platform og lægger fundamentet for stabile, fremtidssikre hjem­automationer.

Forudsætninger: hardware, netværk og forberedelser

Inden du kaster dig ud i selve installationen, er det værd at sikre, at fundamentet er i orden. En MQTT-broker kan godt køre på næsten hvad som helst, men et solidt setup giver færre overraskelser senere.

Hardware

  • Raspberry Pi 3/4 eller lignende SBC
    • 1 GB RAM er nok til et lille hjemmenetværk, men 2-4 GB giver plads til dashboards og andre services.
    • Brug et pålideligt microSD-kort (Industrial eller A2-rated) eller endnu bedre en lille SSD via USB.
  • Hjemmeserver/NAS
    • x86-maskiner (Intel NUC, Proxmox-klynge, Synology med Docker) klarer nemt +10 000 meddelelser/sek.
    • Vælg minimum 2 CPU-kerner og 2 GB RAM for at have luft til TLS-kryptering og logning.
  • Lager & backup
    • Sørg for daglig backup af /etc/mosquitto, bruger-database, certifikater og evt. vedvarende beskeder (persistence).
    • Gem konfiguration i Git eller på NAS, så rollback er hurtigt.

Operativsystem

  • Debian/Ubuntu Server – langtidssupport, store repos og mange guides.
  • Raspberry Pi OS (Lite) – let, men hold øje med pakkeversioner.
  • Alpine Linux – minimalistisk til Docker-hosts.
  • Uanset distro: opdater regelmæssigt (unattended-upgrades eller tilsvarende).

Netværksopsætning

  • Fast IP
    • Tildel statisk IP eller mindst en DHCP-reservation, så klienter altid kan finde broker-en.
  • Porte
    • 1883/tcp – MQTT u/kryptering (LAN).
    • 8883/tcp – MQTT over TLS (anbefalet).
    • 8083/8084 – WebSocket-varianter (hvis du aktiverer det).
  • NTP
    • Korrekt tid er afgørende for TLS-certifikater og logfejlfinding: aktivér timesyncd eller chrony.
  • Firewall
    • På Debian/Ubuntu: ufw allow 8883/tcp comment "MQTT TLS".
    • Luk ALT andet ned, især hvis maskinen senere skal eksponeres til internettet.
  • Lokal DNS
    • Brug fx pi-hole eller dnsmasq til et nemt alias: mqtt.home.lan → 192.168.1.10.
    • Undgå at konfigurere klienter med rå IP-adresser; det gør fremtidige flytninger smertefrie.
  • Kun LAN eller også ekstern adgang?
    • Kun LAN: hurtigst, færrest angrebspunkter, ingen port-forward.
    • Ekstern adgang: kræver TLS, stærke adgangskoder (eller mTLS) og evt. VPN eller reverse proxy.

Planlægning før du går videre

  1. Lav en kort liste over alle enheder, der skal bruge MQTT (sensorer, pumper, Home Assistant osv.).
  2. Afgør om de kører ren TCP, TLS eller WebSocket.
  3. Sæt backup-rutine og automatisk opdatering op inden produktion.
  4. Test netværkslatency og through­put – især hvis du har batteridrevne sensorer, hvor hver ms tæller.

Når ovenstående punkter er afklaret, er du klar til at vælge selve broker-softwaren og begynde installationen.

Vælg broker og arkitektur

Før du trykker install, er det værd at tage et kort kig på de mest udbredte open-source MQTT-brokere og på, hvordan de passer ind i din hjemme- eller små-erhvervsløsning.

Populære open-source brokere

  1. Mosquitto – den “klassiske” reference-implementation fra Eclipse.
    • Styrker: Lille memory-footprint (< 2 MB), næsten ingen afhængigheder, let at sætte op på alt fra Raspberry Pi til VPS.
    • Begrænsninger: Ikke indbygget web-UI, enkelt-node fokus (clustering kræver ekstern løsning), plugins i C gør udvidelser tungere.
    • Anvendelse: Perfekt til få hundrede enheder og beskeder pr. sekund – typisk nok til et dansk parcelhus med sensorer, pumper og Home Assistant.
  2. EMQX – feature-monsteret fra EMQ.
    • Styrker: Web-UI, integreret dashboard, ACL via SQL-lignende regler, WebSockets/HTTP API, clustering i én linje konfig.
    • Begrænsninger: Større footprint (≈ 150 MB RAM), flere bevægelige dele (Erlang VM), licens-skift ved > 1000 forbindelser.
    • Anvendelse: Når du vil køre flere hjem, små SMV installationer eller holde fremtids-døren åben for million-skala.
  3. HiveMQ Community Edition – Java-baseret, Enterprise-features light.
    • Styrker: Stabilitet, velafprøvet i industri, fuld MQTT 5-understøttelse, ry for lav latenstid trods JVM.
    • Begrænsninger: 1000 klienter maksimum i CE, højere RAM-krav (≥ 512 MB anbefalet), visse plugins bag betal-mur.
    • Anvendelse: God mellemvej hvis du har brug for MQTT 5 og vil lære enterprise-workflow uden at betale – endnu.
  4. NanoMQ – ultralet bro fra EMQ (C-baseret).
    • Styrker: Kilobyte-størrelse, optimeret til embedded boards, kan agere edge-bridge til større broker.
    • Begrænsninger: Færre features (ingen indbygget ACL, clustering i beta), dokumentation mindre moden.
    • Anvendelse: ESP-32, OpenWRT-router eller anden mikro-gateway ved f.eks. solceller i udhuset.

Vigtige evalueringskriterier

  • Performance & skalerbarhed: Hvor mange samtidige klienter/topic-skriv skal den kunne sluge? Kig på brokerens benchmarks – og dit faktiske behov.
  • Adgangskontrol (ACL): Skal du begrænse device-A til kun at skrive varme/stue/#? Undersøg om ACL går på topic-niveau, IP og/eller certifikat-felt.
  • WebSocket & API: Kører du Node-RED i browseren eller vil du lave en React-dashboard? WebSocket gør livet nemt.
  • Clustering & High Availability: Ikke must-have til parcelhus, men fint hvis du senere splitter sensorer over flere VLAN eller vil have zero-downtime.
  • Plugins & eksterne integrationer: LDAP, InfluxDB, Prometheus metrics – jo flere out-of-the-box hooks, jo mindre kludearbejde.

Driftsarkitektur: Bare metal vs. Container

Der er to dominerende måder at køre en MQTT-broker på i et hjemmenetværk:

  1. Bare metal / systemd-service
    • + Mindre overhead, bruger færre ressourcer – ideelt til Raspberry Pi Zero 2 W.
    • + Lettere adgang til hardware (serielle porte, GPIO for UPS-signal osv.).
    • − Sværere at isolere og rulle tilbage; opgraderinger kræver manuel pakke-styring.
  2. Container (Docker/Podman) + evt. docker-compose
    • + Få linjer YAML, hermetisk konfiguration, nem flytning til ny hardware.
    • + Mulighed for multi-arch billeder (arm64/amd64) og CI-baserede auto-opdateringer.
    • − Ekstra abstraktionslag, lidt højere RAM; kræver volumes for vedvarende data.

Log- og datapladsering (persistens)

  • Konfiguration: Gem /etc/mosquitto/conf.d/ eller container-volume i git – versionsstyring er guld, når du tweaker ACL midt om natten.
  • Certifikater: Adskil mappen for TLS-nøgler (eks. /opt/mosquitto/certs) og giv kun mosquitto-brugeren læse-ret.
  • Data: Persisterede sessions og retained beskeder skrives typisk til mosquitto.db. Læg den på SSD eller ramdisk med backup til NAS for hurtig recovery.
  • Logs: Rotér med logrotate eller Docker-driver; hold maksimum 14 dage lokalt og ship ældre logs til syslog-server eller Loki.

Med ovenstående overvejelser i baghovedet kan du nu vælge den broker og det deploy-setup, som bedst matcher dit netværk, dit ambitionsniveau – og ikke mindst den tid, du har lyst til at bruge på vedligehold. Resten af guiden tager udgangspunkt i Mosquitto på Debian, men tip-bokse markerer forskelle for EMQX og Docker-miljøer.

Installation trin for trin

Der findes mange måder at få en MQTT-broker i luften på, men for de fleste hjemmeinstallationer lander man på enten en “native” pakke­installation eller et container-setup. Nedenfor gennemgår vi begge metoder trin for trin.

1. Pakke­installation på debian/ubuntu

  1. Opdater systemet

    sudo apt update && sudo apt -y upgrade

  2. Installer Mosquitto og klient­værktøjer

    sudo apt -y install mosquitto mosquitto-clients

    Mosquitto opretter automatisk en systemd-service (mosquitto.service) og kører som bruger mosquitto.

  3. Tjek service­status

    systemctl status mosquitto

    Du bør se active (running). Hvis ikke, kig i /var/log/mosquitto/mosquitto.log.

  4. Standard­stier (kan være nyttige at kende)

    Formål Sti
    Konfiguration /etc/mosquitto/*.conf
    Data / persistens /var/lib/mosquitto/
    Logfiler /var/log/mosquitto/
    Systemd-service /lib/systemd/system/mosquitto.service

  5. Opret din egen konfigurationsfil

    Opret en ny fil, fx /etc/mosquitto/conf.d/local.conf, så du ikke piller ved mosquitto.conf.

    listener 1883allow_anonymous true # Midlertidigt - slå fra senere!persistence truepersistence_location /var/lib/mosquitto/

    Genindlæs konfig:

    sudo systemctl restart mosquitto

  6. Første test

    # Terminal 1mosquitto_sub -h localhost -t "test/hej"# Terminal 2mosquitto_pub -h localhost -t "test/hej" -m "Velkommen til MQTT"

    Dukker beskeden op i Terminal 1, er din broker live.

2. Kørsel i docker/podman (compose)

  1. Forbered mapper og bruger

    sudo useradd -r -s /usr/sbin/nologin mqttsudo mkdir -p /opt/mqtt/{config,certs,data,log}sudo chown -R mqtt:mqtt /opt/mqtt

  2. Minimal mosquitto.conf

    persistence truepersistence_location /mosquitto/data/log_dest file /mosquitto/log/mosquitto.loglistener 1883allow_anonymous true

    Gem den som /opt/mqtt/config/mosquitto.conf.

  3. docker-compose.yml

    version: "3.9"services: mosquitto: image: eclipse-mosquitto:2 container_name: mosquitto restart: unless-stopped user: "1883:1883" # Mosquitto kører som UID/GID 1883 i containeren volumes: - /opt/mqtt/config:/mosquitto/config - /opt/mqtt/data:/mosquitto/data - /opt/mqtt/log:/mosquitto/log ports: - "1883:1883" - "9001:9001" # WebSocket (hvis aktiveret senere)

  4. Start broker

    cd /opt/mqttdocker compose up -d # eller: podman compose up -d

    Tjek status:

    docker compose logs -f mosquitto

  5. Verificér som før med mosquitto_pub/sub

3. Hærd grund­strukturen fra starten

  • Skift allow_anonymous true til false, og opret brugere vha. mosquitto_passwd.
  • Planlæg placering af certifikater (/opt/mqtt/certs) – det gør migrering til TLS meget lettere.
  • Overvej at mappe ekstra logvolumen til syslog, hvis du allerede samler logs centralt.
  • Tag en backup af konfig og data (retained + persistent sessions) – fx med rsync eller et snapshot i din backup-løsning.

Når installationen er testet og kører stabilt, er du klar til næste skridt: at lukke af for anonym adgang, aktivere TLS og definere rettigheder per topic – alt sammen i de kommende afsnit.

Sikkerhed: kryptering og adgangskontrol

En MQTT-broker er kun så sikker som den konfiguration du giver den. Heldigvis er det relativt ligetil at hæve barren kraftigt – også hjemme i teknikskabet.

1. Kryptering med tls

Uanset om du kun kører på LAN, bør trafikken krypteres. Så er du beskyttet mod både nysgerrige brugere på Wi-Fi og fremtidige planer om ekstern adgang.

  • Let’s Encrypt: Gratis, automatiseret og ideelt hvis brokerens hostname er offentligt routet (f.eks. mqtt.mitdomæne.dk). Brug certbot eller acme.sh til at hente/fornye certifikaterne automatisk.
  • Egen CA: Hvis brokeren kun skal tilgås internt, kan du køre din egen Certificate Authority med fx easy-rsa. Fordelene er fuld kontrol og ingen afhængighed af eksterne tjenester.
# mosquitto.conf (uddrag)listener 8883cafile /etc/mosquitto/certs/ca.crtcertfile /etc/mosquitto/certs/server.crtkeyfile /etc/mosquitto/certs/server.keyrequire_certificate false # Sæt 'true' ved mTLStls_version tlsv1.2

2. Slå anonym adgang fra

Standard-installationen af Mosquitto lader anonyme klienter forbinde på port 1883. Det bør deaktiveres:

# mosquitto.confallow_anonymous falsepassword_file /etc/mosquitto/passwd

3. Brugere og adgangskoder

  1. Opret en dedikeret systembruger til brokeren: sudo adduser --system mosquitto
  2. Lav selve MQTT-brugerne med hashed kodeord: 
    sudo mosquitto_passwd -c /etc/mosquitto/passwd ha_coresudo mosquitto_passwd /etc/mosquitto/passwd tasmota01

4. Finmaskede acl-regler

Lad aldrig enheder frit læse/skriv alt. Med en Access Control List kan du give præcise rettigheder:

# /etc/mosquitto/acluser ha_coretopic readwrite #user tasmota01topic read tasmota01/#topic write cmnd/tasmota01/#user esp_watertopic write tele/watermeter/#

Indsæt ACL-filen i mosquitto.conf:

acl_file /etc/mosquitto/acl

5. Mtls til kritiske noder

Har du temperaturfølere i fyrrummet eller vandmåleren i brønden? Brug mutual TLS. Her skal klienten præsentere et certifikat, som din CA har signeret, før brokeren accepterer forbindelsen.

# mosquitto.conf (tillæg)require_certificate true

6. Netværkshygiejne

  • Firewall: Åbn kun de nødvendige porte (1883/8883). På Linux: sudo ufw allow 8883/tcp.
  • DMZ eller VLAN: Placer IoT-enheder på et adskilt netværk og tillad kun MQTT-trafik ind til brokeren.
  • fail2ban: Overvåg Mosquitto-loggen for brute-force-forsøg og bann IP’er automatisk.
  • Minimal eksponering: Skal brokerens TCP-port virkelig være videre­videres fra routeren? Ofte er svaret nej. Brug i stedet VPN (WireGuard/OpenVPN) hvis du vil tilgå den udefra.

7. Regelmæssig vedligehold

Opdater pakkerne, roter logfiler, og revider ACL’en når nye enheder kommer til. Sæt en kalender­påmindelse hver 3. måned – dine fremtidige nattesøvne vil takke dig.

Med disse tiltag er din hjemme-MQTT-broker enkel at administrere, men solidt sikret mod både tilfældige og målrettede angreb.

Konfiguration og bedste praksis

Et konsistent topic-hierarki gør det lettere at subscribe selektivt, versionere dine integrationer og undgå misforståelser.

  • Brug et fast top-niveau — f.eks. hus eller vt (VarmeTeknik). Det giver mulighed for senere at brid­ge til andre brokere uden navnekollisioner.
  • Hierarki: <sted>/<zone>/<enhed>/<måling>
    Eksempel: hus/kælder/varmefyr/temperatur.
  • Undgå mellemrum og specialtegn; brug små bogstaver og - eller _ som separatorer.
  • Skil kommando og status ad:
    hus/stue/lampe/cmd ← kommandoer
    hus/stue/lampe/state ← feedback
  • Versionér ved behov med et ekstra niveau: v1/, v2/.
  • Brug Wildcards bevidst (hus/+/temperatur) og undgå dem i publicerende enheder.

Qos: Balance mellem latency og robusthed

QoS Garantier Typiske brugsscenarier
0 (at most once) Ingen bekræftelse, lavest latency Hyppige sensordata, hvor et tabt målepunkt er OK
1 (at least once) Broker kvitterer, kan give dubletter Kommandoer (pumpe on/off), kritiske statussignaler
2 (exactly once) Handshake i to trin, tungest Betalings-/faktureringsdata; sjældent i hjemmet

Start med QoS 0 og hæv kun niveauet hvor det giver reel værdi. Husk at blandede QoS-niveauer øger RAM-forbrug og disk-I/O på brokeren.

Retained beskeder

  • Benyttes til sidst kendte værdi, så en ny klient straks modtager data.
  • Velegnet til konfiguration (homeassistant/<device>/config) og langsomme datapunkter som firmware_version.
  • Slet en retained besked ved at publicere en tom payload med flaget retain sat.
  • Undgå retained på hurtigt-skiftende topics (f.eks. motion) — det fylder og forvirrer.

Lwt – Last will and testament

Med LWT kan du automatisk indikere at en enhed er offline hvis MQTT-forbindelsen dør uventet.

mosquitto_pub -h broker -t hus/garage/sensor/status \ -m "online" -r \ --will-topic hus/garage/sensor/status \ --will-message "offline" --will-retain \ --will-qos 1
  • Sæt beskeden "online" som retained ved hver (re)connect.
  • Anvend QoS 1, så status når sikkert frem.
  • I Home Assistant kan en availability_topic kobles direkte til sensoren.

Persistente sessions

Hvis en enhed sover eller har ustabil Wi-Fi, kan du sætte clean_session false (eller clean_start 0 i MQTT v5). Broker gemmer så uafleverede QoS 1/2-beskeder, til klienten vågner igen. Vær opmærksom på:

  • Højere server-load og diskforbrug.
  • Brug specifikke client-ids pr. enhed; dubletter overskriver hinanden.

Websocket-endpoint

Et WebSocket-interface gør det nemt at debugge i browseren og integrere med web-apps.

  1. Aktivér i mosquitto.conf:
listener 9001protocol websockets
  • Brug wss:// (TLS) hvis du blotter porten uden for LAN.
  • MQTT Explorer, Grafana og Tasmota-console kan alle tale WebSocket.

Bridging til andre brokere / skyen

  • En bridge videresender valgte topics til f.eks. en ekstern cloud-service eller en sekundær broker i sommerhuset.
  • Vælg outbound- og/eller inbound-topics og tilføj et præfix for at undgå loops.
connection klit_feriehusaddress 10.42.0.5:1883topic hus/# out 0 vt/remote/topic vt/remote/# in 0start_type automatictry_private true

Hold øje med loop detection i loggen, og sikre forbindelsen med TLS-certifikater.

Basale performance-tweaks

  • Disk-I/O: Placer persistence_location på SSD og tag backup af mosquitto.db.
  • Memory: Begræns max_inflight_messages og max_queued_messages til det realistiske behov.
  • Network tuning: Sæt tcp_nodelay true for lavere latency på LAN.
  • Logniveau: Kør med log_type error warning til daglig og hæv kun til debug midlertidigt.
  • TLS-handshake: Genbrug certifikatkæden i både broker og reverse-proxy, så du kun har ét sted at forny.
  • Opgrader rettidigt: Nye versioner bringer ofte markante ydelsesforbedringer og sikkerheds-patches.

Med disse retningslinjer står din MQTT-broker stærkt, både hvad angår struktur, driftsikkerhed og fremtidig udvidelse.

Test, integration og drift

1. Hurtigfunktionstest

Når brokeren kører, er første skridt at sikre, at publish og subscribe virker lokalt.

# Åben to terminaler på serveren eller en klient-PC# Terminal 1 - lytmosquitto_sub -h broker.lan -p 1883 -t 'vat/test' -v# Terminal 2 - sendmosquitto_pub -h broker.lan -p 1883 -t 'vat/test' -m 'Hello MQTT'

Modtager du straks beskeden i terminal 1, er grundfunktionaliteten på plads. Kører du TLS på port 8883, tilføjes flagen -p 8883 --capath /etc/ssl/certs -u USER -P PASSWORD.

2. Grafisk inspektion med mqtt explorer

  1. Download klienten (Win/macOS/Linux).
  2. Opret forbindelse til mqtt://broker.lan:1883 eller mqtts://broker.lan:8883.
  3. Se hierarkiet “live”, send testpayloads og valider retained flag, QoS osv.

MQTT Explorer er guld værd, når du vil tjekke om LWT-beskeder, persistente sessions eller ACL’er opfører sig korrekt.

3. Integrationer

Platform Opsætning Tip
Home Assistant Tilføj mqtt: i configuration.yaml eller brug “MQTT Integration” i UI. Angiv host, port og bruger. Slå “Enable discovery” til – ESPHome/Tasmota enheder dukker automatisk op.
Node-RED Installer node-red-contrib-mqtt-broker eller peg noder mod ekstern broker-URL. Brug separate input/output-noder for tydeligere flows.
ESPHome I esphome.yaml: mqtt: sektion med broker-IP, port, bruger & password. Sæt birth_message og will_message fra starten for stabil tilstedeværelses-tracking.
Tasmota Web-UI → Configuration → MQTT. Indtast host, port, topic-prefix, user/pass. Skift SetOption19 0 hvis du ikke vil bruge Home-Assistant discovery.

4. Fejlfinding

  • Logniveauer: I /etc/mosquitto/mosquitto.conf kan du sætte log_type til error, warning, notice eller debug. Brug midlertidigt debug og kør journalctl -u mosquitto -f.
  • ACL-hits: Tilføj log_type acl for at se afviste forbindelser.
  • QoS-problemer: Test med forskellige QoS-værdier (0/1/2) og bekræft i MQTT Explorer, at beskeder leveres som forventet.
  • Netværkskontrol: Kør nmap -p 1883,8883 broker.lan for at sikre, at portene er åbne internt men ikke på WAN-interfacet.

5. Overvågning & metrics

Mange brokere, fx Mosquitto fra v2.0+, eksponerer $SYS-topics:

mosquitto_sub -t '$SYS/#' -v

Her kan du aflæse uptime, antal forbindelser, bag-queue osv. Eksporter dem til:

  • Prometheus via mqtt_exporter og visualisér i Grafana.
  • Telegraf → InfluxDB → Chronograf/Grafana.

6. Backupstrategi

  1. Konfiguration: /etc/mosquitto/*.conf
  2. Certifikater: /etc/letsencrypt/live/ eller din egen CA-sti.
  3. Data: Hvis du bruger persistence, tag kopi af /var/lib/mosquitto/

Kør daglige rsync eller inkluder stierne i din eksisterende borgbackup/Veeam/Time Machine-strategi.

7. Opdateringsrutiner

  • Sæt automatiske sikkerhedsopdateringer (unattended-upgrades) men pin broker-pakken hvis du vil teste manuelt før major releases.
  • Ved Docker: kør watchtower eller CI-workflow, men test altid i et staging-tag først.
  • Gem ændringer i config i Git – så kan du hurtigt rulle tilbage.

8. Skalering & høj tilgængelighed

Til et almindeligt hjemmenet er single-node nok, men planlæg for vækst:

  • Clustering: EMQX og HiveMQ understøtter indbygget klynge; Mosquitto kan bridge mellem noder.
  • Keep-alives: Sænk keepalive fra 60 s til fx 20 s, hvis du vil opdage nedetid hurtigere.
  • Failover-DNS: Lad en sekundær broker lytte på samme CNAME og brug client-side “broker-list” i kritiske enheder.
  • Persistens & replicering: Brug delt NFS/GlusterFS eller database-backends, hvis du skal sikre, at events ikke tabes ved node-skifte.

Med ovenstående test, integrationer og driftsprocedurer er din egen MQTT-broker klar til at køre stabilt – året rundt – som hjertet i dit Varme, Afløb & Teknik-smarthome.