LoRaWAN

Referenz zum Treiber LoRaWAN: der eingebettete Netzwerkserver Basics Station, Zertifikate der Gateways, die Anmeldungen von Sensor und Konzentrator und die Adressierung in der Nutzlast.

Der Treiber LoRaWAN macht Ganter Lab zu einem kleinen LoRaWAN-Netzwerkserver. Die Richtung der Beziehung ist gegenüber den meisten Treibern umgekehrt: Die Station greift nicht nach einem Sensor, sondern das Gateway verbindet sich mit Ganter Lab, und die Sensoren liefern ihre Messwerte als Uplinks durch dieses Gateway. Ganter Lab bringt einen Netzwerkserver mit, der das Protokoll LoRa Basics Station von Semtech spricht, jedes Gateway mit der Firmware Basics Station kann diese Station also als seinen LNS verwenden.

Der eingebettete Server startet, sobald das erste aktivierte LoRaWAN-Gerät in den laufenden Connector geladen wird, nicht beim Start der Anwendung, und hört auf, sobald das letzte entfernt oder deaktiviert wird: Sind weder Sensor noch Konzentrator eingerichtet, lauscht überhaupt nichts auf dem Port. Eines hinzuzufügen holt es zurück, ohne die Anwendung neu zu starten.

Jedes Gerät unter diesem Treiber ist eine von zwei Anmeldungen, in seinem Bereich gewählt:

• Ein Sensor, erkannt an seiner DevEUI und mit seinem Anwendungsschlüssel zugelassen. Seine Tags entschlüsseln die Nutzlast des Uplinks.
• Ein Funkkonzentrator (das Gateway), erkannt an seiner Station EUI und in einer Funkregion aus einer Liste angemeldet. Er trägt keine eigenen Tags: Auf seiner Seite bleibt Tag hinzufügen ausgegraut und nennt den Grund, bis das Gerät als Funksensor registriert ist.

Melden Sie den Konzentrator ebenso an wie die Sensoren. Ein Konzentrator mit Basics Station fragt gleich nach dem Verbinden nach seiner Funkkonfiguration und leitet überhaupt nichts weiter, bevor sie beantwortet ist, eine Station, die seine Station EUI nie gesehen hat, lässt also jeden Sensor dahinter ohne Wert, während die Verbindung selbst gesund aussieht. Die Antwort wird hier aus der Region gebaut, die Sie gewählt haben; es gibt keinen Konfigurationstext zum Einfügen.

Gateway vorbereiten

Das Gateway wählt sich über LoRa Basics Station bei dieser Station ein und weiß ab Werk nicht, wo die Station ist. Die Seite jedes Geräts, das als Funkkonzentrator registriert ist, trägt die Karte Gateway vorbereiten mit dem, was in den Basics-Station-Einstellungen des Gateways einzutragen ist, für diese Station geschrieben:

Die Karte ist aufgeklappt, solange sich das Gateway seit dem Öffnen der Station nicht verbunden hat, und klappt ein, sobald es sich verbunden hat: Sie bleibt auf der Seite für das nächste Mal, dass das Gateway eingerichtet wird. Ein Gateway, für dessen Zertifikat keine in Windows installierte Stammzertifizierungsstelle bürgt, wird bei der ersten Verbindung abgewiesen und wartet unter Anlagenzugriff. Ein Gateway, das nur das Protokoll Semtech UDP packet forwarder spricht, kann sich nicht verbinden: Es braucht eine Basics-Station-Firmware.

Die Datei ist für alle Gateways dieser Station dieselbe, und sie ändert sich nicht, wenn sich Name oder Adressen der Station ändern. Ein Gateway mit den Standardeinstellungen von Basics Station akzeptiert die Station: In seiner Konfiguration muss nichts ausgeschaltet werden.

Jedes Gateway, das von einer früheren Version eine Datei erhalten hat, braucht diese, einmal als tc.trust installiert. Beim ersten Start dieser Version zeigt eine Station, deren Gateways eine frühere Datei haben können, auf der Karte einen Hinweis, Die Datei dieser Station hat sich geändert, nur in diesem Lauf. Der Hinweis ist eine Erinnerung, nicht die Anweisung: Installieren Sie die neue Datei einmal auf jedem Gateway einer Station, die schon Gateways hatte, ob die Karte den Hinweis zeigt oder nicht.

Netzwerkserver und Ports

Der Lauscher ist immer mit TLS. Es gibt keine Einstellung, die die Verschlüsselung abschaltet: Ein Lauscher mit einfachem HTTP wird überall abgelehnt außer auf Loopback, das aus dem Anlagennetz nicht erreichbar ist und nur für Tests im selben Prozess existiert.

Zertifikate

Die Zulassung geschieht über beidseitiges TLS: Der Server weist mit seinem eigenen Zertifikat nach, wer er ist, und jedes Gateway muss mit einem Client-Zertifikat nachweisen, wer es ist.

Serverzertifikat. Der Netzwerkserver weist ein Zertifikat vor, das vom eigenen Stammzertifikat dieser Station signiert ist, demselben, auf das sich das OCPP-Zentralsystem stützt. Das Stammzertifikat wird einmal pro Profil angelegt, beim ersten Start eines der beiden Server, und im Datenordner der Anwendung abgelegt:

• GanterLabConnector.pfx, unter ua\pki\own\private: der private Schlüssel, verschlüsselt unter einem zufälligen Passwort, das selbst pro Windows-Benutzer geschützt ist (DPAPI), sodass sich das Dateipaar für niemanden öffnet, wenn es anderswohin kopiert wird.
• GanterLabConnector-<station>.pem, unter ua\pki\station: das öffentliche Stammzertifikat. Das ist die Datei, die Sie als tc.trust auf dem Gateway installieren, damit es dieser Station vertraut.

Das Subject des Stammzertifikats ist Ganter Lab Connector (<station>), wobei <station> der Netzwerkname an dem Tag ist, an dem es angelegt wurde, und es läuft nicht ab. Seine öffentliche Hälfte installieren Sie einmal von Hand auf jedem Konzentrator; ein Stammzertifikat, das ablief, würde deshalb an seinem Jahrestag das ganze Sensornetz lahmlegen, abgewiesen am Konzentrator, wo diese Station nichts sieht, und es würde einen Besuch bei jedem Konzentrator kosten, es wiederherzustellen. Es gibt keine Ablaufwarnung und keinen Erneuerungsbefehl, weil es nichts zu erneuern gibt; die Karte Stammzertifikat der Station auf der Seite des Treibers zeigt das Datum, das es trägt, als Anzeige (Gültig bis), mit dem vollständigen Pfad der öffentlichen Datei und einer Schaltfläche Ordner öffnen, die sie im Datei-Explorer von Windows zeigt (im eigenen Fenster der Station; in einem Browser auf einem anderen Gerät bleibt die Schaltfläche ausgegraut und sagt, warum).

Das Zertifikat, das der Netzwerkserver unter diesem Stammzertifikat vorweist, nennt den Netzwerknamen der Station (der "Netzwerkname" in der Konfiguration des eingebetteten OPC UA-Servers; solange er leer ist der Computername), localhost und jede IPv4-Adresse der Station; deshalb akzeptiert es ein Gateway, das den Namen des Servers prüft. Den Computer umzubenennen, den Netzwerknamen oder die Adressen der Station zu ändern, ersetzt das Stammzertifikat nicht: Nur das Zertifikat darunter wird von selbst neu ausgestellt, ohne dass an den Konzentratoren etwas zu tun ist.

Das Stammzertifikat wird nur dann neu angelegt, wenn sich das gespeicherte nicht mehr öffnen lässt, etwa weil es von einem anderen Windows-Konto geschrieben wurde. In diesem Fall, und beim ersten Start dieser Version auf einer Station, die Konzentratoren schon eine frühere Datei gegeben haben kann, sagt die Seite des Treibers einmal unter Konzentratoren brauchen die neue Zertifikatsdatei, dass jeder Konzentrator die neue GanterLabConnector-<station>.pem als tc.trust bekommen muss. Bis dahin können sie sich nicht verbinden.

Client-Zertifikat des Gateways. Jedes Gateway muss beim TLS-Handschlag ein Client-Zertifikat vorweisen; ein Handschlag ohne eines wird verworfen, bevor Daten fließen. Das Zertifikat muss:

1. Auf eine von zwei Arten vertrauenswürdig sein: Es bildet auf diesem Windows-Rechner eine gültige Kette bis zu einer dort installierten Wurzel; oder Sie haben genau dieses Zertifikat unter Anlagenzugriff auf der Seite dieses Treibers freigegeben (siehe unten). In beiden Fällen muss es innerhalb seiner Gültigkeitsdaten liegen. Eine fehlgeschlagene Prüfung weist die Verbindung ab, und das Journal hält fest, welche Prüfung fehlschlug.
2. Die EUI der Station des Gateways in seinem Common Name im Antragsteller oder in einem alternativen DNS-Namen tragen. Die Kennung wird als Wert gelesen, AABBCCDDEEFF0011, AA-BB-CC-DD-EE-FF-00-11 und AA:BB:CC:DD:EE:FF:00:11 benennen also alle dieselbe Station.
3. Dieselbe Station benennen, für die sich die Datenverbindung ausgibt: Ein Zertifikat, das ein anderes Gateway nennt als die Adresse der Verbindung, wird abgewiesen.

Anlagenzugriff

Ein Gateway, für dessen Zertifikat keine in Windows installierte Wurzel bürgt, weil es selbstsigniert oder von der eigenen Zertifizierungsstelle des Herstellers ausgestellt ist, braucht diese Wurzel auf diesem Rechner nicht. Seine erste Verbindung wird abgewiesen, und sein Zertifikat wartet unter Anlagenzugriff am Ende der Seite des LoRaWAN-Treibers, derselben Karte wie auf der Seite des OPC UA-Treibers, bis Sie entscheiden:

Jedes Zertifikat wird einzeln freigegeben, nie die Zertifizierungsstelle, die es signiert hat; ein zweites Gateway desselben Herstellers wartet also auf seine eigene Freigabe. Vergleichen Sie den Fingerabdruck mit dem, den das Gateway angibt, bevor Sie es freigeben. Die Freigabe ändert nicht, welches Gateway das Zertifikat ist: Es wird weiterhin nur unter der EUI der Station zugelassen, die es trägt, und nur innerhalb seiner Gültigkeitsdaten. Ein Zertifikat, dem Windows bereits vertraut, wird wie bisher zugelassen und erscheint hier nie; nichts wird automatisch freigegeben.

Die Entscheidungen liegen im Datenordner der Station unter ua\pki\lorawan und überstehen einen Neustart. Die Befehle werden nur einer Rolle gezeichnet, die den Connector konfigurieren darf, und sie wirken nur im eigenen Fenster der Station: Ein Browser auf einem anderen Gerät liest die Karte, ohne sie zu ändern, und kein Werkzeug eines Agenten gibt ein Zertifikat frei. Die Liste hält bis zu 100 Zertifikate, die auf Freigabe warten; ist sie voll, wird ein neues weiter abgewiesen, aber nicht aufgeführt, und die Karte sagt das.

Verbindungsfelder

Ein LoRaWAN-Gerät hat keinen eigenen Host und keinen eigenen Port: Ein Sensor wird über den Konzentrator erreicht, der seinen Funkverkehr trägt, und ein Konzentrator erreicht diese Station. Der Bereich zeigt zuerst die Wahl der Anmeldung, dann die Felder, die diese Anmeldung braucht.

Ein Gerät, dessen DevEUI (Sensor) oder EUI der Station (Konzentrator) noch leer ist, etwa eines, das Sie gerade hinzugefügt haben, wartet darauf. Die Station meldet es nicht am Netzwerkserver an, und es wird keine Verbindung versucht; seine Zeile im Baum und der Hinweis oben auf seiner Seite sagen "DevEUI noch nicht eingetragen" oder "EUI der Station noch nicht eingetragen", statt einen Fehler zu zeigen, Neu verbinden hat nichts wieder zu öffnen, und sein Zustand bleibt Noch unbekannt. Tragen Sie die Kennung in der Karte Verbindung ein, dann meldet die Station das Gerät an. Ein Gerät, das mit leerer Kennung gespeichert ist und nach seiner EUI benannt wurde (sechzehn hexadezimale Ziffern, keine Trennzeichen), wartet nicht: Es meldet sich unter seinem Namen an, wie es das immer getan hat.

Der Anwendungsschlüssel ist ein Geheimnis, und die Station behandelt ihn als solches. Das Panel verbirgt ihn hinter Punkten, mit einem Kästchen Passwort anzeigen, das ihn zeigt, während Sie das Getippte prüfen; die Konfigurationsdatenbank bewahrt ihn geschützt unter dem Windows-Konto auf, das ihn eingegeben hat; und er erscheint weder im Journal noch in der Adresse, die der Treiber liest und die allein die DevEUI trägt. Öffnen Sie dieselbe Konfiguration unter einem anderen Windows-Konto, dann öffnet sich der Schlüssel nicht mit: Das Feld kommt leer zurück und sagt "Unter diesem Windows-Konto nicht lesbar: Es öffnet sich nur auf dem Rechner und unter dem Windows-Konto, das es eingegeben hat. Geben Sie es hier erneut ein.", und der Sensor tritt dem Netz nicht mehr bei, bis Sie den Schlüssel erneut eingeben. Eine Konfiguration, die in einer Sicherung mitgenommen wird, behält ihn, weil die Sicherung mit dem Passwort versiegelt ist, das Sie ihr geben.

Der Join ist nur OTAA: Der Sensor führt einen Join über die Luft durch den Konzentrator aus, und der Netzwerkserver beantwortet ihn mit dem eingestellten AppKey. Eine Join-Anfrage von einer DevEUI, die kein eingerichtetes Gerät trägt, wird abgewiesen und protokolliert. Die Aktivierung durch Personalisierung (ABP, vorab hinterlegte Sitzungsschlüssel) wird nicht unterstützt. Die Sitzung eines Sensors gehört dieser Station, nicht dem Konzentrator, der seinen Join weitergereicht hat: Mit mehr als einem Konzentrator in Reichweite kommen seine Uplinks über den an, der sie hört, und ein Konzentrator, der ausfällt oder entfernt wird, nimmt keinen Sensor mit.

Ein Gerät zu deaktivieren oder zu löschen nimmt es sofort vom Netzwerkserver, ohne auf einen Neustart zu warten: Sein Schlüssel verlässt das Verzeichnis, die Sitzung, die es auf dieser Station hielt, wird freigegeben, und sein nächster Join wird abgewiesen. Einen Konzentrator zu deaktivieren oder zu löschen schließt außerdem sofort seine Verbindung, und die Sensoren, die er weitergereicht hat, behalten ihre Sitzungen.

Eine Anmeldung, die der Server nicht annimmt, kommt gar nicht erst zustande: eine DevEUI oder Station EUI, die eingetragen ist und nicht aus 16 hexadezimalen Ziffern besteht, ein Anwendungsschlüssel, der fehlt oder nicht aus 32 hexadezimalen Ziffern besteht, oder eine Region, die diese Station nicht konfigurieren kann. Das Gerät liest sich als nicht verbunden, seine Zeile im Baum und der rote Text unter der Kopfzeile seiner Seite nennen das abgelehnte Feld und was es enthalten muss, und das Journal hält dieselbe Zeile fest. Der Netzwerkserver wird dafür nicht gestartet, und die Station versucht dieselbe Anmeldung nicht noch einmal: Erst das korrigierte Feld bringt das Gerät zurück, und Neu verbinden antwortet mit derselben Ablehnung.

Der Zustand des Konzentrators

Ein Konzentrator trägt keine Tags, also kann kein Messwert sagen, ob er da ist. Sein Zustand, der Punkt auf seiner Zeile im Baum und die Spalte Zustand auf der Seite des Treibers, ist, ob sein Gateway mit dieser Station verbunden ist:

Bis zu zehn Sekunden, nachdem eine Änderung am Konzentrator gespeichert wurde oder der Connector startet, liest er sich Noch unbekannt: Die neue Anmeldung schließt die Verbindung des Gateways, und das Gateway braucht einen Moment, um sich wieder zu verbinden. Die Sensoren behalten ihren eigenen Zustand, aus ihren Messwerten, was immer der Konzentrator zeigt: Mit mehr als einem Konzentrator in Reichweite liefern die anderen weiter, wenn einer abfällt.

Was der Konzentrator gesendet bekommt

Wenn ein angemeldeter Konzentrator seinen Handschlag zur Version beendet hat, antwortet diese Station mit der Funkkonfiguration für seine Region: dem Frequenzbereich, den Datenraten und der Angabe, welche davon nur für den Downlink sind, sowie dem Standardkanalplan der Region. Ist die Station EUI hier nicht angemeldet, wird nichts gesendet, und das Journal sagt, welche Station gefragt hat und dass sie nicht angemeldet ist. Das ist der Eintrag, nach dem Sie suchen, wenn ein Konzentrator sich verbindet und kein Sensor dahinter je einen Wert meldet.

Felder für das Abfrageintervall gibt es nicht. LoRaWAN sendet von sich aus: Der Sensor entscheidet, wann er einen Uplink schickt, der Server behält je Gerät die zuletzt entschlüsselten Nutzlasten, und die Werte der Tags frischen sich aus diesem Zwischenspeicher in einem festen Ein-Sekunden-Takt auf.

Ein Sensor, der noch keinen Uplink geschickt hat, hat daher keinen Messwert, keinen fehlgeschlagenen. Die Tags bleiben leer, das Gerät meldet, dass nichts beobachtet wurde, statt offline zu gehen, und es wird kein Fehlschlag protokolliert: Auf den ersten Uplink zu warten ist das Protokoll bei der Arbeit. Eine Adresse, die in einer Nutzlast, die der Sensor tatsächlich gesendet hat, auf nichts auflöst, ist etwas anderes und wird als der Lesefehler gemeldet, der sie ist.

Wenn ein Sensor still wird

Weil nichts einen Sensor zyklisch abfragt, bleibt die zuletzt gesendete Nutzlast in diesem Zwischenspeicher, bis er eine neue sendet. Sich selbst überlassen, würde ein Sensor mit leerer Batterie dieselbe Zahl weiter als guten Messwert veröffentlichen, solange die Station läuft, und Diagramme, Historie und Alarme mit einem Wert speisen, der nicht mehr stimmt.

Jeder Sensor trägt deshalb in seinem eigenen Bereich eine höchste Zeit ohne Übertragung in Sekunden. Der Standard sind 3600 Sekunden, eine Stunde, was den Takt von zehn bis dreißig Minuten eines üblichen Sensors mit Reserve abdeckt; ein Sensor, der seltener meldet, erhöht seine eigene. Nach dieser Frist:

• Tragen seine Tags keinen Wert mehr und veröffentlichen schlechte Qualität, statt den letzten Uplink zu wiederholen.
• Sagt der Bereich des Geräts, wann der Sensor zuletzt gesendet hat, sodass Sie sehen können, wie lange er schon still ist.

Das Feld auf 0 zu setzen schaltet das Verfallen für diesen Sensor ab: Sein letzter Uplink liest sich unbegrenzt weiter als gut. Sonst ändert sich nichts, und keine gespeicherte Nutzlast wird verworfen.

Adressierung der Tags

Ein LoRaWAN-Tag adressiert Bytes innerhalb der entschlüsselten Nutzlast des Uplinks. Es gibt keine Freitextadresse; die Karte Quelle bietet typisierte Felder in zwei Betriebsarten an, umgeschaltet über das Kontrollkästchen Adressierung über Cayenne LPP-Kanal/-Typ:

Die Reihenfolge der Schritte bei einem Lesevorgang ist: die adressierten Bytes nehmen → die Bitmaske anwenden → umdrehen, wenn das höchstwertige Byte zuerst kommt → in den Datentyp des Tags wandeln → den Multiplikator anwenden (bei numerischen Typen).

Beispiele für einen Sensor, dessen 11 Byte große Nutzlast an Versatz 2 eine Temperatur als Int16 im Big-Endian trägt:

• Versatzbetrieb: Kanal oder Versatz 2, Leselänge 2, höchstwertiges Byte zuerst ein.
• LPP-Betrieb, derselbe Sensor spricht Cayenne LPP auf Kanal 1 mit Typ 103: das LPP-Kontrollkästchen setzen, Kanal 1, Typcode 103, Leselänge 2.

Unterstützte Datentypen

Schreiben und Gerätesuche

LoRaWAN-Tags sind nur lesend: Werte kommen allein aus den Uplinks der Sensoren, das Feld für den Zugriff bietet keine schreibbare Wahl an, und die Laufzeit lehnt einen Schreibvorgang ab, statt Erfolg vorzutäuschen. Downlinks gibt es im Protokoll als Netzverkehr (Join-Accepts, MAC-Befehle), nie als Schreibvorgänge auf Werte von Tags.

Der Treiber hat keinen Suchlauf. Legen Sie den Konzentrator von Hand mit seiner Station EUI und seiner Region an und jeden Sensor von Hand mit seiner DevEUI und seinem AppKey; der allgemeine Ablauf zum Hinzufügen eines Geräts steht auf der Seite Connector.