Einfacher als MQTT? MQTT / UDP

Published on November 13, 2018

Einfacher als MQTT? MQTT / UDP

    Ich wollte einen ausführlichen Artikel zu diesem Thema schreiben, aber meine Hände reichen offensichtlich nicht. Deshalb eine kurze Nachricht. Ich habe in mehreren Sprachen eine Prototyp-Codeversion des MQTT-Protokolls unter dem Arbeitsnamen MQTT / UDP entwickelt und implementiert. Für die Ungeduldigen und für diejenigen, die bereits klar und deutlich sind, der Code auf Github

    Warum

    ich in einer Wohnung lebe, die seit mehreren Jahren fast vollständig von meinem eigenen Smart-Home-System gesteuert wird. Kontrolle von Licht, Klima, Sensoren, einfache Automatisierung, das ist alles.

    Während dieser Zeit habe ich herausgefunden (übrigens, ich habe es schon früher verstanden), dass das Hauptmerkmal von UD-Systemen die Zuverlässigkeit ist.

    Alle Systeme mit einem zentralen Standort sind per Definition unzuverlässig. Daher der Wunsch, eine Verbindungssystemkomponente zu erhalten (und es gibt viele davon in einem echten Smart Home), ohne einen zentralen Hub zu verwenden.

    Gleichzeitig gehen wir davon aus, dass der Verkehr in UD-Systemen im Allgemeinen gering ist - die Sensoren müssen selten mehr als einmal pro Minute aktualisiert werden, der Rest der Daten ist endgültig (sie schalten das Licht ein) und der Verkehr ist völlig irrelevant. Selbst jede zweite Aktualisierung aller Daten im System ist nicht nur eine Katastrophe, sondern auch ein erhebliches Problem.

    Die logische Schlussfolgerung - UDP Broadcast ist das perfekte Werkzeug.

    (Ja, ich gehe davon aus, dass das interne Netzwerk der Wohnung durch eine Firewall geschlossen ist.)

    Was die Profis zu bieten haben:

    Eine unglaublich einfache Implementierung. Ein winziger Mikrocontroller mit kleinem Speicher kann ein UDP-Paket senden. Für den Sensor wird kein UDP-Empfang benötigt.

    Extrem niedrige Latenz. Es gibt keine Weiterleitung im zentralen Hub, die UDP-Paketlieferzeit ist praktisch die Mindestzeitmenge im modernen System.

    Es gibt keine zentrale Fehlerquelle im Hub / Broker. Stellen Sie sich eine einfache Schaltung vor: zwei Temperatursensoren, eine Fußbodenheizung und eine Heizung. Bei Verwendung von MQTT / UDP führt der Ausfall eines Teils eines solchen Systems nicht zum Ausfall des gesamten Systems.

    Geringer Netzwerkverkehr. Unten ist nirgendwo. TCP und Bestätigungen erhöhen nur den Datenverkehr, aber nicht die Zuverlässigkeit. Fehlerhafter Sensor funktioniert nicht beim Empfang von TCP-ACK. Und das Scheitern, und so zeigen wir das Fehlen von Updates.

    Die Unzuverlässigkeit des UDP-Protokolls selbst ist unerheblich - Sensoren aktualisieren die Daten weiterhin regelmäßig, und der Verlust der Zählung wird völlig unbemerkt, und das Verschwinden eines Befehls von beispielsweise einem Switch wird durch einen Ausfall des Zielsystems visuell bestätigt. Was macht ein Mann? Klickt erneut. Dies ist jedoch die Hauptgrenze für die Anwendbarkeit des Protokolls. Ideal für wiederholte Umfragen.

    Keine Systemkonfiguration erforderlich. Niemand muss die Adresse eines Brokers, Hubs usw. registrieren. Die Sensorkonfiguration wird jedoch weiterhin benötigt - es ist erforderlich, die Sensorkennung zu registrieren. Wenn Sie jedoch andere Teile des Systems auf andere Server übertragen, ist keine Neukonfiguration der Antwortkomponenten erforderlich.

    Interessant ist auch, dass dieses Datenaustauschmodell gut zu natürlichen Breitbandmedien wie Radiosendern oder RS ​​/ 485 passt. Ich habe nicht damit experimentiert, und das Protokoll in solchen Umgebungen muss kontrolliert werden. Sinnvoll ist es hier übrigens, einen CRC16 aus dem Modbus einzusetzen.

    Die Nachteile liegen auch auf der Hand: Die Zuverlässigkeit der Zustellung wird nur durch die Hardware und den Datenverkehr im Netzwerk bestimmt, und wenn sich ein Feind in das Netzwerk eingeschlichen hat, wird das Protokoll sofort besiegt. Seien wir ehrlich, das Hacken anderer typischer Protokolle des Smart Home ist eine Frage von Sekunden, daher ist dies ein umstrittener Nachteil von MQTT / UDP. Ein weiteres nicht offensichtliches Minus ist maximal ein Empfänger pro IP-Adresse.

    Was wurde getan und befindet sich im Quell-Repository:

    • Client / Server-Implementierungen in mehreren Sprachen. Es gibt C, Python und Java. Ich habe Lua nicht gemeistert (konnte nicht alles, was du brauchst, wie lebst du darin?) Und Codesys (konnte kein Paket erstellen, wer hat diese Sprache erfunden?).
    • Minimales Gate in traditionellem MQTT auf Python
    • Primitives Tool zur Anzeige von MQTT / UDP-Verkehr im Netzwerk

    Was würde ich tun, wenn ich mehr Zeit hätte:

    • Würde ein Modul für openHUB schreiben.
    • Würde eine Protokollvariante auf JSON auf einem anderen Port und einen Konverter in das Hauptformat und den Port machen. Oder Tor in beide Richtungen.
    • Würde ein Verkaufsschwein für die Hauptplattformen machen. Für Arduino habe ich eine Herangehensweise an das Gewicht entwickelt und den Code tatsächlich getestet, aber nicht alles richtig entworfen. Für Raspberry sind Testbeispiele für Python geeignet.
    • Würde eine digitale Signatur und Verschlüsselung machen, aber es ist unklar wie.
    • Multicast.

    Auf diesem Dankeschön, willkommen im Repository

    PS: Ein ähnlicher Ansatz, jedoch mit Multicast, wird in diesem Artikel beschrieben.