Das Bild in diesem Blogbeitrag basiert auf einem Bild von Gerd Altmann von Pixabay.
Wenn du einen Sensor oder Aktor mit dem Internet verbinden willst und kein WLAN in der Nähe ist, dann ist die nächstbeste Option LPWAN (Low-Power Wide Area Network). In diesem Blogbeitrag beschreibe ich, wie man einen Sensor mit dem AVR-IoT Cellular Mini Board von Microchip mit einer Website verbindet.
Motivation
Vor kurzem habe ich ein Projekt begonnen, bei dem ich einige Bits erfassen und das Ergebnis auf einer Webseite anzeigen möchte. Mit WLAN und einem ESP32 oder ähnlichem sieht das nach einer einfachen Aufgabe aus. In meinem Fall habe ich aber keinen Zugang zu WLAN.
Wie bekommst du also die paar Bits auf die Webseite? Zuerst müssen wir uns entscheiden, welche Art von drahtloser Netzwerktechnologie wir verwenden wollen. Dann müssen wir ein Netzwerkprotokoll wählen, um die Daten zu übermitteln, und einen Weg finden, um die Daten auf einer Webseite anzuzeigen. Schließlich müssen wir die passende Hardware kaufen. Und vielleicht sind diese Entscheidungen alle miteinander verbunden.
Stromsparende Wide-Area-Networks
Es gibt inzwischen eine Reihe von verschiedenen Technologien und Netzwerkbetreiber, die es ermöglichen, einzelne Sensoren mit dem Internet zu verbinden. Diese Arten von Netzwerktechnologien konzentrieren sich auf Verbindungen mit geringem Stromverbrauch und geringer Bandbreite.
LoRaWAN zum Beispiel ist eine Technologie, die Spread-Spectrum-Modulation in lizenzfreien Sub-GHz-Bändern (868 MHz in der EU) nutzt. Das Things Network ist ein gemeinschaftliches, gemeinschaftsbasiertes LoRaWAN-Netzwerk, das jeder kostenlos nutzen kann. Wenn du wissen willst, ob es dort, wo du es nutzen willst, Netzabdeckung gibt, gibt es eine Abdeckungskarte. Wenn die Signalstärke nicht ausreicht, kannst du dein eigenes LoRaWAN-Gateway betreiben.
Ein ähnliches Projekt, das LoRaWAN nutzt, ist Helium. Hier erhältst du eine Vergütung, wenn du ein Gateway betreibst, aber im Gegenzug musst du für die Nutzung des Netzwerks bezahlen.
In beiden Fällen ist man auf die Bereitschaft anderer angewiesen, ein Gateway bereitzustellen, oder man muss ein eigenes Gateway einrichten. Obwohl ich die von einer Gemeinschaft betriebene Vernetzung mag, möchte ich mich nicht darauf verlassen.
Eine andere Technologie ist Ultra-Schmalband, die die gleichen Sub-GHz-Bänder wie die oben genannten nutzt. Sigfox ist ein Netzwerkbetreiber, der drahtlose Verbindungen mit dieser Technologie anbietet. Hier musst du für die Übertragung von Daten bezahlen. Wenn ich es richtig interpretiere, sind es etwa 5 bis 10 € pro Gerät und Jahr, wenn du nur ein paar Bytes pro Tag sendest.
Schließlich bieten die Mobilfunknetzbetreiber, wie die Deutsche Telekom, LPWAN-Technologien wie LTE-M und NB-IoT an. Die Datenraten sind viel höher als in den oben genannten Fällen. Außerdem sind die Servicegebühren sehr wettbewerbsfähig. Bei 1NCE z.B. zahlst du 10 € für 500 MB über 10 (!) Jahre. Der einzige Nachteil ist, dass du nur SIM-Karten kaufen kannst, wenn du nachweisen kannst, dass du ein Unternehmen oder selbstständig bist (z. B. mit deiner Steuererklärung). Ich habe mich dafür entschieden, vor allem weil es das sehr interessante AVR-IoT Cellular Mini Board gibt, das diese Art der Vernetzung unterstützt.
AVR-IoT-Cellular-Mini-Board
Das AVR-IoT-Cellular-Mini-Board ist ein echter Hammer! Es sieht so aus, als ob es mit dem Gedanken entwickelt wurde, dass Maker es benutzen sollten. Das Grunddesign des Boards ist mit Adafruit Feather kompatibel. Die MCU ist ein AVR128DB48, der von Spence Konde’s DxCore unterstützt wird. Zudem stellt Microchip Arduino-Bibliotheken für dieses Board zur Verfügung, die du mit dem Arduino Library Manager installieren kannst.
Was die Hardware angeht, bekommst du die oben erwähnte MCU, einen Temperatursensor (MCP9808), einen Farbsensor (VEML3328), ein CryptoAuthentication™ Device (ATECC608B), ein serielles EEPROM (25CSM04), eine Antenne (824MHz-2170MHz), einen Nano-SIM-Kartenhalter, ein Li-Ion/LiPo-Ladegerät und mehr. Außerdem erhältst du eine SIM-Karte von Truphone (gültig für 90 Tage).
Inklusive Mehrwertsteuer kostet das Board rund 80 €, wenn du es in Deutschland kaufst.
Erste Schritte
Für die ersten Schritte habe ich den Hackster.io-Beitrag von Keenan Johnson verwendet. Fast alles funktionierte auf Anhieb. Aber dann stieß ich auf Probleme. Nachdem ich die Truphone-SIM aktiviert hatte, versuchte ich, eine Verbindung zum Betreiber herzustellen, indem ich das http-Beispiel
aus der AVR-Iot-Cellular-Bibliothek ausführte, Was ich bekam, war Folgendes:
[INFO] Starting HTTP example
[INFO] Connecting to operator....................................................................................................................................................... OK!
[INFO] Did not get time from operator, doing NTP sync. This can take some time...
[WARN] Got disconnected from network whilst doing NTP sync
[ERROR] Failed to connect to the operator
Wie sich herausstellte, ist nicht die NTP-Synchronisierung die Ursache des Problems. Ich habe sie in der LTE-Bibliothek deaktiviert und dann die Fehlermeldung erhalten, dass der Betreibername unbekannt ist. Mit einer SIM-Karte von 1NCE funktionierte jedoch alles. Da die Truphone-SIM-Karte nur 90 Tage gültig ist, bin ich über dieses Problem nicht allzu verärgert. Nach dem Wechsel der SIM-Karten funktionierten alle Beispielsketches einwandfrei. Der Temperatursensor scheint allerdings leicht zu hohe Werten zu messen.
MQTT oder nicht MQTT?
Sobald die grundlegende Vernetzung steht, stellt sich die Frage, wie man die Bits an die Website überträgt, wo sie angezeigt werden sollen. Das bevorzugte Protokoll für IoT-Geräte ist MQTT, und in der AVR-IoT-Celluar-Bibliothek gibt es ein paar Beispielprogramme, die zeigen, wie man damit arbeitet. MQTT ist ein Publish-Subscribe-Protokoll, das für Geräte gedacht ist, die nicht immer online sind. Das klingt zwar nach einer perfekten Lösung, ist aber mit einem hohen Implementierungs- und Verwaltungsaufwand verbunden. Du brauchst einen Server, der den Message Broker bereitstellt und den Status der Geräte verwaltet. Google, Microsoft und Amazon bieten solche Dienste an und es gibt auch andere, die solche Dienste hosten. Außerdem musst du einen Client mit Javascript implementieren, der den Status eines Geräts visualisiert. Das hört sich alles danach an, als würde man sehr hohen Aufwand treiben um ein paar Bits zu visualisieren.
HTTPS, CGI und Javascript verwenden
Ich habe mich entschieden, ein CGI-Bash-Skript auf dem Webserver zu implementieren, auf dem die Webseite angezeigt wird. Dieses CGI-Skript wird über die POST-Anforderungsmethode angesprochen. Das Skript sieht (leicht vereinfacht) wie folgt aus.
#!/bin/bash lese POST_STRING echo "Inhaltstyp: text/html" echo "" IFS="=" set -- $POST_STRING if [ "$1" == "TICKETS" ] then echo "function tickets() { return $2 }" > ../data/newdata.js echo "OK" else echo "FAIL" fi
Die Javascript-Datei newdata.js
muss dann von der Webseite, die die Daten anzeigt, eingebunden und verwendet werden.
Ich habe es mit einem curl-Befehl
getestet und es hat wunderbar funktioniert. Da das HTTPS-Beispiel für das AVR-IoT-Board ebenfalls funktioniert hatte, erwartete ich, dass alles klappt, was nicht der Fall war. Der Aufruf der Website vom AVR-IoT-Board aus führte zu folgender Ausgabe.
[INFO] Starting HTTPS example
[INFO] Connecting to operator.. OK!
[INFO] Connected to operator: Telekom.de
[INFO] Configured to HTTPS
[ERROR] Timed out whilst waiting on delivering the HTTP payload. Is the server online? If you're using HTTPS, you might need to provision with a different CA certificate.
[INFO] POST - HTTP status code: 0, data size: 0
HTTPS und CA-Zertifikate
Heutzutage wird fast der gesamte Datenverkehr zwischen Browsern und Webservern über HTTPS abgewickelt, die sichere Version von HTTP, die Transport Layer Security (TLS) verwendet. Und da das alles funktioniert, fragt man sich nie, wie es funktioniert. Wenn du dich dafür interessierst, hat Robert Heaton einen sehr schönen Blogbeitrag geschrieben, in dem er die Funktionsweise von HTTPS erklärt. Der wichtigste Punkt für meinen Zweck ist, dass es eine Reihe verschiedener Zertifizierungsstellen (CA) gibt, die kryptografische Zertifikate ausstellen, mit denen die Echtheit von Webservern überprüft werden kann. Jeder Browser enthält einen Speicher mit solchen Zertifikaten, die zu diesem Zweck verwendet werden können. Wenn das AVR-IoT-Board eine HTTPS-Verbindung aufbauen will, benötigt es ebenfalls Zugriff auf diese Zertifikate. Und hier kommt die in der obigen Fehlermeldung erwähnte Provisioning ins Spiel. Anstelle eines Speichers von Zertifikaten kann nur ein Zertifikat gespeichert werden.
Du musst das richtige CA-Zertifikat bereitstellen, um mit einem bestimmten Webserver kommunizieren zu können. Aber wie findest du heraus, welches das richtige ist? Ein Klick auf das Schloss-Symbol in der URL-Zeile kann helfen. Das führt dich zu den Zertifikaten, die von dem Webserver verwendet werden. Und hier möchte man das Root-Zertifikat verwenden, das eine Lebensdauer von 10 Jahren oder so hat. In meinem Fall ist es das Zertifikat namens ISRG Root X1. Und natürlich muss man dieses Zertifikat in zehn Jahren ändern!
Nachdem ich das AVR-IoT-Board mit dem richtigen CA-Zertifikat ausgestattet habe, indem ich das Beispielprogramm der AVR-IoT-Cellular-Bibliothek verwendet habe
, funktioniert die HTTPS-Verbindung problemlos und ich kann mich daran machen, die restlichen Teile zu bauen, um das Projekt zu beenden, das ich in einem zukünftigen Blogbeitrag ausführlich beschreiben werde.
Zusammenfassung
Es ist einfach, die ersten Schritte mit dem AVR-IoT-Cellular-Mini-Board von Microchip zu machen. Vielleicht musst du dir aber noch eine LTE-M SIM-Karte von deinem örtlichen Netzbetreiber kaufen. Wenn du Daten über das HTTPS-Protokoll senden willst, musst du herausfinden, welches CA-Zertifikat dein Webserver verwendet, und das Board damit ausstatten. Dann bist du bereit, loszulegen.
Schreibe einen Kommentar