CAN/MQTT

Aus c3RE.de
Wechseln zu: Navigation, Suche

In der Hütte gibt es ein Sensor- und bald auch Aktorennetzwerk, das per CAN/MQTT ansprechbar ist. Es existieren im Wiki 3 verschiedene Artikel zu dem Thema. Ich werde mit diesem Artikel versuchen, die 3 ein wenig zusammenzufassen und die Zusammenhänge besser verständlich zu machen. Damit möglichst vielen der Einstieg in das Thema gelingt, gehe ich zu Beginn auch grob auf CAN und MQTT im einzelnen ein. Viel tiefer könnte ich auch gar nicht drauf eingehen, ich habe auch nur grob Ahnung davon ;-). Los gehts

MQTT

MQTT (Message Queue Telemetry Transport) ist ein Protokoll, das ursprünglich Ende der 90er Jahre von IBM entwickelt wurde, um Sensordaten von Ölpipelines über Satellitenverbindungen zu übertragen[1]. Anforderungen damals waren: niedriger Akkuverbrauch, zuverlässige Datenübertragung und wenig Bandbreitenbedarf. 2010 oder so wurde es dann der Öffentlichkeit zugänglich gemacht. Seitdem gewinnt es immer mehr an Bedeutung. Man rumort, Facebook Messenger würde auf MQTT basieren [2].

MQTT arbeitet nach dem Client/Server-Prinzip. Der Server nennt sich "MQTT-Broker", in unserer Hütte ist das der Raspberry Pi in der CCU (erreichbar unter mqtt.lan). Die Clients, die mit dem Broker sprechen, sind entweder "Subscriber" (also Empfänger) oder "Publisher" (also Sender). Der vierte wichtige Begriff, den man kennen sollte, ist ein sogenanntes "Topic".

Beispiel: Für das folgende Beispiel wird der mosquitto Client verwendet. Gibts für viele coole und ein uncooles Betriebsystem zum Download[3] Möchte man nun eine Nachricht (Das MQTT-Wort hierzu heißt "Message") von Rechner A nach Rechner B schicken, muss man sich ein Topic für die Message überlegen. In unserem Fall nehmen wir das Topic "test". Der Empfänger muss zuerst das Topic "test" subscriben:

mosquitto_sub -t test -h mqtt.lan

mosquitto_sub heißt das spezielle Programm, mit dem man nur subscriben kann, aber nichts schicken. Der Parameter -t steht für Topic. "test" ist also unser Topic. Der Parameter -h steht für unseren Host. In unserem c3RE–Netzwerk ist das mqtt.lan. Wenn man den subscribeclient so startet, passiert ersteinmal nichts. Solange niemand sendet, kommt auch nichts. Erst wenn nun der Sender, also der Publisher, ausgeführt wird, werden Nachrichten auf dem Terminal ausgegeben.

mosquitto_pub -t test -h mqtt.lan -m "hallo, was geht ab?"

Im ersten Terminalfenster, wo der subscriber geöffnet ist, sollte nun "hallo, was geht ab?" stehen. Wem das mit dem Terminal zu kompliziert und unbequem ist, der kann auch den Webclient [4] benutzen. Wenn man den Abschnitt bis hier gut verstanden hat, dann hat man schon das wichtigste Rüstzeug, um am CAN/MQTT-Netzwerk vom c3RE mitzubasteln.

Topics

Nun zum nextlevelshit: Topics sind ineinander verschachtelt. Klingt schlimm. Isses aber nicht. Alles, was das bedeutet, ist: ich kann ein Topic "test/1" und ein Topic "test/2" definieren. Nun kann ich mit meinem Subscribeclient das Topic "test/#" abonnieren und erhalte alle Nachrichten, die nach "test/1" oder "test/2" gesendet werden. "#" ist also der Wildcard-Character. Wer einfach mal alle Nachrichten "mithören" möchte, kann das Topic "#" abonnieren. Wer gezielt einzelne Nachrichten mithören oder Daten senden möchte, der lese den c3REWiki-Artikel MQTT-Topics [5]. In dem Artikel sind Regeln für die Namen von MQTT-Topics definiert sowie ein Verzeichnis am Ende, was auf welchem Topic gesendet wird.


CAN-Bus

Der CAN-Bus wurde von Bosch für Autos entwickelt [6]. Dort hat er sich auch durchgesetzt und ist heute in nahezu jedem Auto verbaut. In der Industrie wird der CAN-Bus wegen seiner Zuverlässigkeit auch gerne zur Anlagensteuerung verwendet. Auf dem CAN-Bus gibt es, fast wie bei MQTT, keine "Empfänger" oder "Sender" von Nachrichten. Jeder Nachricht (im folgendenden: "CAN-Frame") wird eine ID zugeordnet (die sogenannte "CAN-ID"). Typischerweise enthalten CAN-Frames mit derselben ID Daten desselben Typs. Beispiel Auto: ID:117 enthält immer den Radiosender. Also wird bei dem einen auf der 117 "1Live" gesendet und beim nächsten "WDR4", aber die ID 117 steht immer für den Radiosender. Die "Payload", also die Nutzdaten eines CAN-Frames, sind 1-8 Byte lang. Ehrlich gesagt würde ich gerne noch mehr zum CAN-Bus erklären, aber mehr Ahnung habe ich leider nicht ;-) Das Wissen bis hier soll uns aber genügen, die Parallele zu MQTT zu erkennen. Also dass ein Topic immer einer ID entspricht. Deshalb nun zum nächsten Kapitel:

CAN2MQTT

Oben wurden die beiden Welten CAN und MQTT beschrieben. Nun geht es darum diese beiden zu verbinden. Warum? Wir wollen möglichst viele Daten sammeln (Datensammelei omnomnom, pööhse) und möglichst vielen den Zugang zum Netzwerk ermöglichen. Der CAN-Bus bietet seine Vorteile (unfassbar lange Leitungen, low level) und IP aber auch (auf vielen Geräten verfügbar). Dein Gerät spricht weder CAN noch MQTT? Oh, Pech gehabt. Du darfst nicht mitspielen.

Nein Scherz, vielleicht kann dein Device ja seriell sprechen? Dann ist das Projekt hier [7] ja etwas für dich. Dort geht es darum, mittels eines ESP8266 einem seriellsprechenden Gerät die Kommunikation über MQTT beizubringen.

Und weiter?

Nachdem die Kommunikation mit CAN und MQTT funktioniert, können wir uns auf die Couch fletzen uns ne Mate aufmachen und nichts mehr tun.

Oder die Daten in eine Datenbank hauen und coole Graphen draus basteln! Ich habe dazu eine InfluxDB [8] aufgesetzt. Es gibt einen Client für MQTT, der sich Telegraf [9] nennt und gewünschte Daten in die InfluxDB schreibt. Dieser Schritt ist optional. Es wird ersteinmal nichts gespeichert, was nicht gespeichert werden soll (wobei natürlich jeder alles mitlesen kann und ne Datenbank selbst anlegen kann). Für Daten, die dann in der Datenbank landen, kann man mit Grafana [10] hübsche Graphen basteln. Es sind bereits Graphen für den aktuellen Internettraffic angelegt.

Daten hinzufügen

Du möchtest Daten ins CAN/MQTT Netzwerk einspeisen? Großartig hier die 10 einfachen Schritte zum Glück:

1. Topic aussuchen Deine Daten werden in ein Topic eingespeist, es gibt ein festes und total unchaotisches Schema an das sich strikt gehalten werden muss, sonst passieren pöhse Dinge. Wie genau das Topic auszusehen hat ist hier [5] beschrieben.

2. Topic "registrieren" Hier gibt es zwei Fälle: im ersten Fall hast du commit-access auf das GitHub-Repo: dann schreib einfach rein. Im zweiten Fall schreib den mamu an der committet das für dich. Beim Topic registrieren wird der CAN-Bus Meister dir eine CAN-Bus-ID zuweisen.

3. Gerät, Datenquelle, Entität konfigurieren Zum Schluss noch das Gerät auf die ID oder das MQTT-Topic konfigurieren. Dann föhlich Daten lossenden/empfangen.

Noch ein Wort zum Inhalt der Datenpakete: Grundsätzlich können die Datenpakete alles enthalten. Man sollte in der CAN-Welt aber bedenken das die Pakete in die MQTT-Welt gespiegelt werden und vice versa. Das bedeutet man sollte möglichst die Daten als simplen uint abschicken. Es hat sich bewährt bei Kommawerten (23,1 Grad Celsius) mit dem Faktor 10 zu multiplizieren und das am Ende wieder rauszurechnen.

Quellenfoo (Markup geht irgendwie nicht, wers hinbekommt: würde mich freuen :-)

[1]: http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt

[2]: https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

[3]: https://mosquitto.org/download/

[4]: http://mqtt.lan

[5]: MQTT-Topics

[6]: https://en.wikipedia.org/wiki/CAN_bus

[7]: https://github.com/c3re/zechenuhr/tree/master/ESP8266

[8]: https://www.influxdata.com/time-series-platform/influxdb/

[9]: https://www.influxdata.com/time-series-platform/telegraf/

[10]: http://grafana.org/