Einfacher als MQTT? MQTT / UDP

Ich wollte einen ausführlichen Artikel zu diesem Thema schreiben, aber meine Hände reichen offensichtlich nicht aus. Daher eine kurze Nachricht. Ich habe in mehreren Sprachen als Prototypcode eine Version des MQTT-Protokolls unter dem Arbeitsnamen MQTT / UDP entwickelt und implementiert. Für Ungeduldige und diejenigen, die bereits alles verstehen und natürlich den Code auf Github

Warum

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

Während dieser Zeit fand ich heraus (ja, das habe ich übrigens schon verstanden), dass die Haupteigenschaft von UD-Systemen die Zuverlässigkeit ist.

Alle Systeme mit einem zentralen Knoten sind per Definition unzuverlässig. Daher der Wunsch, die Verbindung der Systemkomponenten herzustellen (und es gibt viele davon in einem echten Smart Home), ohne einen zentralen Hub zu verwenden.

Gleichzeitig gehen wir davon aus, dass der Verkehr von UD-Systemen im Allgemeinen gering ist - Sensoren müssen selten öfter als einmal pro Minute aktualisiert werden, der Rest der Daten ist ereignisbasiert (Licht eingeschaltet) und der Verkehr ist völlig unbedeutend. Selbst jede zweite Aktualisierung aller Daten im System ist nicht nur eine Katastrophe, sondern sogar ein erhebliches Problem.

Die logische Schlussfolgerung ist, dass UDP Broadcast ein ideales Werkzeug ist.

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

Was ist in den Profis:

Unglaublich einfache Implementierung. Ein minimaler Mikrocontroller mit winzigem Speicher kann ein UDP-Paket senden. Für den Sensor ist kein UDP-Empfang erforderlich.

Extrem niedrige Latenz. Im zentralen Hub gibt es keine Weiterleitung. Die UDP-Paketzustellzeit ist praktisch der minimale Zeitschlitz in einem modernen System.

Es gibt keinen zentralen Fehlerpunkt im Hub / Broker. Stellen Sie sich ein einfaches Schema vor: zwei Temperatursensoren, eine Fußbodenheizung und eine Heizungsbatterie. Bei Verwendung von MQTT / UDP führt ein Ausfall eines Teils eines solchen Systems nicht zu einem Ausfall des gesamten Systems.

Geringer Netzwerkverkehr. Unten nirgendwo. TCP und Bestätigungen erhöhen nur den Datenverkehr, erhöhen jedoch nicht die Zuverlässigkeit. Ein ausgefallener Sensor funktioniert beim Empfang einer TCP-Bestätigung nicht. Und wir identifizieren Fehler durch das Fehlen von Updates.

Die Zuverlässigkeit des UDP-Protokolls selbst ist unerheblich - die Sensoren aktualisieren die Daten immer noch regelmäßig, und das Verschwinden der Zählung ist vollständig unsichtbar, und das Verschwinden eines Befehls von beispielsweise einem Switch wird durch den Ausfall des Zielsystems visuell bestätigt. Was macht eine Person? Klickt erneut. Dies ist jedoch eine wesentliche Einschränkung der Anwendbarkeit des Protokolls. Ideal für wiederkehrende Umfragen.

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

Es ist besonders interessant, dass dieses Modell des Datenaustauschs gut zu natürlich ausgestrahlten Medien wie einem Radiosender oder RS ​​/ 485 passt. Ich habe damit nicht experimentiert und das Protokoll in solchen Umgebungen muss kontrolliert werden. Hier ist es übrigens logisch, CRC16 vom Modbus anzuwenden.

Die Minuspunkte liegen ebenfalls auf der Hand: Die Zuverlässigkeit der Zustellung wird nur durch die Hardware und den Datenverkehr im Netzwerk bestimmt. Wenn der Feind in das Netzwerk gelangt ist, wird das Protokoll sofort besiegt. Wir werden ehrlich sein, das Hacken anderer typischer Smart-Home-Protokolle ist nur eine Frage von Sekunden. Dies ist also ein umstrittener Nachteil von MQTT / UDP. Ein weiteres nicht offensichtliches Minus ist maximal ein Empfänger pro IP-Adresse.

Was wurde getan und liegt im Quellcode-Repository:

• Client / Server-Implementierungen in mehreren Sprachen. Es gibt C, Python und Java. Ich habe Lua nicht gemeistert (konnte nicht alles sagen, was du brauchst, wie lebst du darin?) Und Codesys (konnte das Paket nicht kompilieren, wer hat diese Sprache erfunden?).
• Minimales Tor zum traditionellen MQTT in Python
• Ein primitives Tool zum Anzeigen des MQTT / UDP-Verkehrs in einem Netzwerk

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

• Ich würde ein Modul für openHUB schreiben.
• Würde eine Protokollvariante für JSON an einem anderen Port und einen Konverter für das Hauptformat und den Port erstellen. Oder ein Tor in beide Richtungen.
• Ich würde Implementierungslücken für die Hauptplattformen machen. Für Arduino habe ich mich dem Gewicht zugewandt und den Code wirklich getestet, aber nicht alles richtig entworfen. Für Raspberry sind Testfälle in Python geeignet.
• Würde digital signieren und verschlüsseln, aber es ist nicht klar wie.
• Multicast.

Vielen Dank dafür, willkommen im Repository

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