Hallo.
Wie ich kürzlich schrieb (
erster kurzer Artikel über MQTT / UDP ), ist MQTT / UDP ein Protokoll, das auf MQTT basiert, aber:
- Geht über UDP-Broadcast hinaus (kein Broker erforderlich, fast keine Konfiguration erforderlich)
- Die Implementierung ist relativ einfach (10 Zeilen auf dem C + UDP / IP-Stapel - und Sie senden Daten vom Sensor).
- Jeder hört jeden
In gewisser Weise ist dies CAN, aber zusätzlich zu Ethernet.
Warum.
Meine Wohnung lebt tatsächlich seit mehreren Jahren unter der Kontrolle eines Systems wie "Das Haus ist nicht vollständig oligophren". Es wäre überflüssig, es Intelligenz zu nennen, aber das Licht und das Klima sind automatisiert. Um sich das Ausmaß der Katastrophe vorzustellen - das System belegt ein volles, überfülltes Rack mit einer Breite von etwa 19 Zoll und einer Höhe von zwei Metern. Zwei Wände des Racks sind fast bis zum Boden besetzt.
Als ich das alles entwarf, stand das Problem der Fehlertoleranz an erster Stelle. Mehrere Jahre Betrieb haben gezeigt: Es ist wahr. Verweigert alles. Früher oder später. Elektromechanische Relais sind jedoch noch nicht ausgefallen, und es ist die letzte Stufe des Schutzes vor Ausfällen.
Das nächste Problem nach der Fehlertoleranz ist der Zoo. Aufgrund des natürlichen Lebensverlaufs, meiner Neugier und meiner dringenden Bedürfnisse lebt das übliche Unix auf einem normalen PC, Aries PLC, Raspberr + Orange PI, Atmega-Module, NodeMCU-basierte Module (ESP8266) im System und all dies geht über Modbus miteinander 485, Modbus TCP, http und an der Seite hängt ein unruhiger MQTT-Broker, als Erbe eines erfolglosen Versuchs, mit einem ganzen Lager dorthin zu wechseln.
Warum der Versuch, zu MQTT zu wechseln, nicht erfolgreich ist. Erstens ist ein Teil des Eisens schwer oder kompliziert. Auf dem Fragment von Pascal, das sich in der CodeSys-SPS versteckt, kann nur ein Masochist MQTT schreiben. Aber dann müssen Sie debuggen. Ähnlich bei atmega: man kann stopfen, aber eng. Aber das ist nicht das ganze Problem.
MQTT, wie es ist (und überall akzeptabel ist 3.1.1), besteht darauf, ein PUBLISH-Paket (dh unsere Nachricht an den Broker) an alle Empfänger, einschließlich des Absenders, zu senden. Der Effekt dieses Wahnsinns ist bezaubernd - dasselbe OpenHAB kann keine Daten in MQTT unter demselben Namen senden und empfangen. Dies bedeutet, dass es unmöglich ist, einen Bus basierend auf MQTT zu organisieren (mehrere Module, die den Wert desselben Objekts aktualisieren und verwenden). Und genau so sollte die SPS-Kommunikation organisiert sein, in der die Hauptlichtsteuerung lebt, OpenHAB, die das Licht von der Weboberfläche und der mobilen Anwendung steuert, und intelligente Schalter, die ich hier und hier hinzufügen möchte. Das heißt, dieses Problem kann natürlich umgangen werden, aber tatsächlich bedeutet es, ein eigenes Protokoll SURFACE MQTT zu erstellen, und dies scheint bereits zu viel zu sein.
Was brauche ich gleichzeitig? Senden Sie eine Aktualisierung des Parameterwerts und holen Sie ihn an allen interessierten Stellen ab. Für was in der Tat haben Großväter UDP an der Rundfunkadresse gemacht.
Nach dem letzten Beitrag über Habré warf mir einer der Leser lange Zeit die Unzuverlässigkeit des UDP-Protokolls vor. Ich antwortete ihm spekulativ, dass UDP für IoT zuverlässiger ist als TCP: Bei einem Paketverlust von 50% in einem Netzwerk legt sich TCP nicht nur hin, sondern im Allgemeinen, und der Temperatursensor, der Messungen über UDP sendet, verliert einfach die Hälfte der Anzahl, was sich auswirkt den Betrieb des Systems in irgendeiner Weise. Im Allgemeinen.
Aber es war spekulativ. Die Neujahrsfeiertage wurden jedoch auch einer Person gegeben, um das Trinken von Champagner zu beenden und sich zu fragen: Werden wir heute unser Heim-LAN auf Schaufeln stellen? Und egal was.
Ich nahm MQTT / UDP und schrieb einen primitiven Test. Eine Seite sendet so oft wie möglich aufeinanderfolgende Pakete ohne Pause zwischen den Paketen. Die zweite berücksichtigt Geschwindigkeit und Paketverlust. Das Experiment war einfach: Wir starten diesen Spott und parallel zeigen zwei HD-Fernseher Filme aus dem Internet, und der Desktop-Computer schreibt eine riesige Datei auf den NAS.
Bewerten Sie das Ergebnis. Ich habe auf alles gewartet, aber ... der maximale Verlust für UDP erreichte ein halbes Prozent, und beide Fernseher hörten auf zu zeigen. Ich war also immer noch ein Pessimist. In einem echten Heimnetzwerk ist die Zuverlässigkeit der UDP-Bereitstellung nahezu absolut. Trotzdem werde ich wahrscheinlich eine Version mit Bestätigungen erstellen und Pakete erneut senden. Es gibt nur wenige Schwierigkeiten, aber die Frage ist vollständig beseitigt.
Die zweite Frage ist die Sicherheit, aber richtig, wenn sie in mein Heimnetzwerk eindringen, ist der Datenverlust von Temperatursensoren das Letzte, worüber ich mich Sorgen machen werde. Wiederum ist die Aufgabe des digitalen Signierens von Paketen im Issue-Tracker vorhanden, und ich verstehe bereits, wie MQTT-Pakete für die Implementierung erweitert werden können.
Im Allgemeinen plane ich, dass das erste Gerätepaar im Heimnetzwerk erst neulich zu MQTT / UDP wechselt.
Und ich schlage vor, Sie versuchen es in Ihren Programmen und Geräten:
Repository und
Dokumentation in Englisch .
Was ist verfügbar:
Ziemlich vollständige Implementierungen in Java, Python und C. Grundlegende Implementierung auf Lua. Bisher nur für Arduino und CodeSys PLC senden (getestet und funktioniert auf Aries, aber es sollte alles tun).
GUI-Tool, um zu sehen, was passiert und einzugreifen:
Programme zum Senden und Empfangen von Daten in Python, Lua und Java.
Python-Konnektoren zur Integration in reguläres MQTT und direkt in OpenHAB. Sie erarbeiten einen Schutz gegen Zyklen und verbieten die Rückübertragung der Nachricht für 5 Sekunden, nachdem sie in Vorwärtsrichtung weitergeleitet wurden. Darüber hinaus gibt es eine Bibliothek, um den Fluss wiederholter Daten zu begrenzen. Sie prüft, ob dieses Thema für die angegebene Zeit bereits aktualisiert wurde, und überspringt das neue Update nur, wenn sich die Daten geändert haben.
Ich habe vor, schrittweise vollständig auf dieses Protokoll umzusteigen, und hier ist ein Beispiel dafür, was ich mit Sensoren erreichen möchte:
In einem Raum befinden sich drei Sensoren (oder auf der Straße spielt das keine Rolle). Sie senden Proben über MQTT / UDP. Diese Messwerte werden gleichzeitig vom Haupt-Smart-Home-System (OpenHAB), einer historischen Datenbank und einem Wandmonitor empfangen, der die Temperatur für die Bewohner anzeigt.
Der ganze Reiz von MQTT / UDP besteht darin, dass in einem solchen Schema der Ausfall eines Blocks keine Probleme für alle anderen verursacht. Und das mit der bezaubernden Einfachheit des Protokolls.
Darüber hinaus können redundante Steuerschemata mit Duplizierung leicht in demselben Schema implementiert werden. Der Datenbankserver kann problemlos dupliziert werden. Es wird schwieriger sein, die Module zu duplizieren, die sich mit der Verwaltung befassen. Wenn Sie beispielsweise auf die Temperatur hören, werden die Heizkörper gesteuert. Aber wahrscheinlich ist dies die nächste Geschichte. Heute möchte ich mich darauf konzentrieren, Signale von Sensoren zu sammeln und zwischen den Modulen eines Smart Homes auszutauschen.