Einen verwalteten MQTT-Broker für mobile Apps nutzen

Ein MQTT Broker für mobile Apps ermöglicht es einem Smartphone, Gerätedaten in dem Moment zu sehen, in dem sie sich ändern, und mit sehr wenig Overhead Befehle zurückzusenden. Dieser Leitfaden erklärt, wie sich mobile Apps verbinden sollten, wann MQTT das richtige Werkzeug ist und wann Push-Benachrichtigungen der Plattform, wie Sie den Akkuverbrauch niedrig halten und wie Sie Zugangsdaten sicher handhaben, mit einem funktionierenden Beispiel gegen ConnectMQ.

Warum mobile Apps MQTT nutzen

Mobile IoT-Apps brauchen meist drei Dinge: den Live-Zustand anzeigen (ist die Tür verriegelt, wie voll ist der Tank), Befehle senden (Pumpe einschalten) und schnell auf Änderungen reagieren. Eine REST-API alle paar Sekunden abzufragen, erfüllt alle drei schlecht: Es verschwendet Akku und Datenvolumen, erhöht die Latenz und belastet Ihr Backend. MQTT hält eine langlebige Verbindung offen, solange die App aktiv ist, und überträgt nur, was sich geändert hat.

Im industriellen Umfeld sind es zum Beispiel Apps für die Instandhaltung, die Maschinenstatus, OEE-Kennzahlen und Störmeldungen einer Linie auf dem Tablet anzeigen. Ist der Topic-Baum des Werks als Unified Namespace (UNS) nach der ISA-95-Hierarchie Enterprise → Site → Area → Line → Cell aufgebaut, abonniert die App einfach den passenden Ausschnitt, etwa acme/werk-muenchen/montage/linie-1/#. Befehle aus einer App an Maschinen sollten Sie dabei besonders eng begrenzen und im Backend oder auf der Steuerungsseite prüfen.

Der Broker in der Mitte entkoppelt die App von den Geräten. Das Smartphone braucht nie die IP-Adresse eines Geräts; beide Seiten sprechen mit einem bekannten Endpunkt. Wenn diese Rolle neu für Sie ist, lesen Sie zuerst, was ein MQTT-Broker macht.

Verbindungsoptionen vom Smartphone aus

Beide sind verschlüsselt und funktionieren mit MQTT 3.1.1 und 5.0. WebSocket ist in JavaScript-basierten Apps und in restriktiven WLANs oft der Weg des geringsten Widerstands; natives TLS ist geringfügig effizienter. Verwenden Sie in einer produktiven App niemals die unverschlüsselten Ports 1883 oder 8083. Der Leitfaden zu MQTT über WebSocket erklärt den WebSocket-Transport im Detail.

MQTT vs. Push-Benachrichtigungen

Das ist die wichtigste Designentscheidung, und die Antwort lautet meist „beides“.

Mobile Betriebssysteme suspendieren Hintergrund-Apps und deren Sockets. Insbesondere iOS lässt Sie eine MQTT-Verbindung im Hintergrund nicht unbegrenzt offen halten. Die robuste Architektur sieht daher so aus:

1. Vordergrund: Die App verbindet sich mit dem Broker, abonniert die Geräte, die der Nutzer gerade ansieht, und sendet Befehle über MQTT.
2. Hintergrund: Die App trennt die Verbindung sauber. Ein kleiner Backend-Service abonniert Alarm-Topics auf dem Broker und sendet Push-Benachrichtigungen der Plattform, wenn etwas Wichtiges passiert.
3. Rückkehr in den Vordergrund: Die App verbindet sich neu, Retained Messages liefern sofort den aktuellen Zustand, und die Oberfläche ist binnen Augenblicken auf dem neuesten Stand.

Das Backend-Relay aus Schritt 2 ist einfach ein weiterer MQTT-Client, den Sie betreiben, zum Beispiel ein Node.js- oder Python-Service. ConnectMQ versendet selbst keine Push-Benachrichtigungen, und wenn diese Logik in Ihrem eigenen Service liegt, bestimmen Sie selbst, welche Ereignisse zu Benachrichtigungen werden.

Akku und Datenvolumen

• Nur bei Bedarf verbinden. Öffnen Sie die Verbindung, wenn der relevante Bildschirm erscheint, und schließen Sie sie, wenn die App in den Hintergrund wechselt.
• Eng abonnieren. Abonnieren Sie home/42/devices/+/state, nicht #. Jede empfangene Nachricht kostet Funkzeit.
• Retained Messages für Zustände nutzen. Die App erhält beim Abonnieren sofort den letzten bekannten Wert, sodass Sie nie pollen oder eine Aktualisierung anfordern müssen.
• Ein moderates Keep Alive wählen. 30 bis 60 Sekunden halten die Balance zwischen schneller Erkennung toter Verbindungen und weniger Aufweckvorgängen des Funkmoduls.
• Payloads kompakt halten. Kurze JSON-Schlüssel oder binäre Kodierungen helfen bei Mobilfunkverbindungen.
• Topic Aliases und Message Expiry von MQTT 5 nutzen, wo verfügbar. Aliases verkürzen wiederholte lange Topic-Namen; Message Expiry verhindert, dass veraltete Befehle verspätet zugestellt werden.
• Beim Reconnect Backoff verwenden. Mobilfunknetze wechseln ständig; exponentielles Backoff vermeidet enge Wiederholungsschleifen, die den Akku leeren.

Funktionierendes Beispiel: React Native oder Web mit MQTT.js

MQTT.js läuft im Browser und in React Native über WebSocket. Dieses Modul kapselt Verbinden, Abonnieren und die Behandlung des App-Lebenszyklus.

import mqtt from "mqtt";

const BROKER_URL = "wss://broker.connectmq.com:8084/mqtt";

export function createDeviceConnection({ clientId, username, password, homeId, onState }) {
  const client = mqtt.connect(BROKER_URL, {
    clientId,
    username,
    password,
    protocolVersion: 5,
    keepalive: 45,
    clean: true,
    reconnectPeriod: 3000,
    connectTimeout: 10000,
  });

  const stateTopic = `homes/${homeId}/devices/+/state`;

  client.on("connect", () => {
    client.subscribe(stateTopic, { qos: 1 }, (err) => {
      if (err) console.warn("Subscribe failed", err.message);
    });
  });

  client.on("message", (topic, payload) => {
    const deviceId = topic.split("/")[3];
    try {
      onState(deviceId, JSON.parse(payload.toString()));
    } catch {
      console.warn("Ignoring non-JSON payload on", topic);
    }
  });

  client.on("error", (err) => console.warn("MQTT error", err.message));

  return {
    sendCommand(deviceId, command) {
      client.publish(
        `homes/${homeId}/devices/${deviceId}/cmd`,
        JSON.stringify(command),
        { qos: 1, properties: { messageExpiryInterval: 30 } }
      );
    },
    pause() {
      client.end(false);
    },
    resume() {
      if (!client.connected) client.reconnect();
    },
  };
}

Rufen Sie in React Native pause() und resume() aus einem AppState-Listener auf. Die Message Expiry von 30 Sekunden sorgt dafür, dass ein Befehl, der gepuffert wird, während ein Gerät offline ist, nicht unerwartet Minuten später ausgelöst wird. Manche React-Native-Setups brauchen ein WebSocket- oder Buffer-Polyfill; plattformspezifische Details finden Sie im Leitfaden zu React Native MQTT und, wenn Sie mit Dart entwickeln, unter Flutter MQTT.

Um das ohne Konto auszuprobieren, richten Sie es auf den kostenlosen öffentlichen MQTT-Broker, lassen Benutzername und Passwort weg, verwenden eine beliebige, nicht leere, eindeutige Client ID und stellen den Topics etwas Eindeutiges voran, etwa connectmq/demo/m7d2w/homes/.... Alles auf dem öffentlichen MQTT-Broker ist für jeden lesbar, nutzen Sie ihn also nur für Demos und Tests, nie für Produktionsdaten.

Zugangsdaten sicher handhaben

Ein App-Binary lässt sich dekompilieren, behandeln Sie also alles, was darin eingebettet ist, als öffentlich.

1. Liefern Sie kein gemeinsames Broker-Passwort in der App aus. Gelangt es nach außen, ist der Datenverkehr aller Nutzer offengelegt, und Sie können es nicht sperren, ohne jede Installation lahmzulegen.
2. Stellen Sie Zugangsdaten pro Nutzer oder pro Session über Ihr Backend aus. Nachdem sich der Nutzer in Ihrer App angemeldet hat, liefert Ihre API die MQTT-Zugangsdaten und die Client ID, die dieser Nutzer verwenden soll.
3. Topics nach Nutzer oder Haushalt abgrenzen. Gestalten Sie Topics so, dass die Daten jedes Nutzers unter einem eigenen Präfix liegen, und setzen Sie auf Geräte- und Backend-Seite durch, welche Befehle von wem akzeptiert werden.
4. Rotieren und sperren. Wenn sich ein Nutzer abmeldet oder ein Telefon verloren geht, sperren Sie dessen Zugangsdaten.
5. Befehle auf dem Gerät oder im Backend validieren. Vertrauen Sie nie darauf, dass ein Befehl von einem legitimen Bildschirm stammt.

ConnectMQ bindet Client IDs an die ausgegebenen Zugangsdaten und sperrt IPs nach wiederholten fehlgeschlagenen Anmeldungen, was gegen Credential Stuffing hilft. Die vollständige Liste finden Sie unter Best Practices für MQTT-Sicherheit.

Kapazitätsplanung für Apps

Jede geöffnete App ist eine Verbindung. Zehn Geräte und fünfzig aktive App-Nutzer ergeben in der Spitze sechzig gleichzeitige Verbindungen, nicht zehn. ConnectMQ Serverless (Free) erlaubt bis zu 25 Verbindungen, was für die Entwicklung und eine kleine Beta passt; Serverless (Paid) reicht bis zu 1.000 Verbindungen mit QoS 2 und Shared Subscriptions; dedizierte Cluster bewältigen größere Nutzerzahlen. Da Apps im Hintergrund die Verbindung trennen, sind die gleichzeitigen Verbindungen meist weit weniger als die Installationen, messen Sie aber Ihr tatsächliches Muster, statt zu raten.

Die Hosting-Optionen hinter diesen Plänen beschreibt der Leitfaden zum Cloud-MQTT-Broker.

Verbinden Sie Ihre App mit ConnectMQ

Erstellen Sie unter app.connectmq.com ohne Kreditkarte einen kostenlosen Serverless-Broker, testen Sie Ihre Topics im Browser-Client und richten Sie das MQTT.js-Beispiel auf Ihren neuen Endpunkt. ConnectMQ ist ein verwalteter MQTT-Broker mit TLS- und Secure-WebSocket-Endpunkten, die ab der ersten Minute für mobile Clients bereitstehen.

Häufig gestellte Fragen

Kann eine mobile App eine MQTT-Verbindung im Hintergrund offen halten?

Nicht zuverlässig. Mobile Betriebssysteme suspendieren Sockets im Hintergrund, nutzen Sie MQTT also, während die App im Vordergrund ist, und Push-Benachrichtigungen der Plattform für Alarme im Hintergrund.

Sollte eine mobile App für MQTT WebSocket oder TCP verwenden?

JavaScript-basierte Apps nutzen meist Secure WebSocket auf Port 8084 mit dem Pfad /mqtt. Native Apps können TLS auf 8883 verwenden; beides ist verschlüsselt.

Wie erhalte ich beim Öffnen der App den aktuellen Gerätezustand?

Lassen Sie Geräte ihren Zustand als Retained Messages publizieren. Der Broker liefert den neuesten Wert sofort, wenn die App abonniert.

Ist es sicher, Broker-Zugangsdaten in eine mobile App einzubetten?

Nein. Stellen Sie nach der Anmeldung über Ihr Backend Zugangsdaten pro Nutzer aus, damit sich kompromittierte Zugangsdaten einzeln sperren lassen.