# 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 {#prepare-the-gateway} 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: | Was am Gateway einzustellen ist | Was die Karte angibt | |---|---| | LNS-Adresse (`tc.uri` von Basics Station) | `wss://:5001`, zuerst mit der Adresse über den Namen dieser Station (der "Netzwerkname" in der Konfiguration des eingebetteten OPC UA-Servers, solange er leer ist der Computername), dann einmal für jede IPv4-Adresse, die diese Station in einem Netz hat, jede mit einer Kopierschaltfläche. Ein Gateway, das den Namen des Servers prüft, wie es Basics Station standardmäßig tut (`TLS_SNI`), braucht die Adresse über den Namen; eines, das ihn nicht prüft, nimmt jede dieser Adressen an, und dann genügt die aus seinem eigenen Netz. | | EUI der Station | Die EUI der Station des Konzentrators, mit einer Kopierschaltfläche: die Kennung, unter der dieses Gerät das Gateway registriert. Jedes Gateway ist ein eigenes Konzentrator-Gerät. Solange sie leer ist, sagt die Karte, dass sie in der Karte Verbindung einzutragen ist. | | Client-Zertifikat (`tc.crt`, mit seinem Schlüssel in `tc.key`) | Gegenseitiges TLS: Das Gateway legt ein Client-Zertifikat vor, das seine EUI der Station im Common Name oder in einem alternativen DNS-Namen trägt (siehe [Zertifikate](#certificates)). | | Serverzertifikat, dem zu vertrauen ist (`tc.trust`) | Der vollständige Pfad von `GanterLabConnector-.pem`, dem Stammzertifikat dieser Station, mit der Schaltfläche **Ordner öffnen**, die die Datei im Datei-Explorer von Windows zeigt. Die Schaltfläche wirkt im eigenen Fenster der Station; in einem Browser auf einem anderen Gerät bleibt sie ausgegraut und sagt, warum. Die Datei wird beim ersten Start des Netzwerkservers geschrieben, und bis dahin sagt die Karte das. | 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](#equipment-access). 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 {#network-server-and-ports} | Was | Wert | |---|---| | Protokoll | LoRa Basics Station (WebSocket, JSON) | | Lauscher | Alle Schnittstellen, TCP-Port **5001**, nur TLS | | Adresse des Gateways | `wss://:5001` | | Endpunkt der Suche | Die Anfrage `router-info` von Basics Station wird auf demselben Lauscher bedient | | Datenverbindung | Adressiert über die Station EUI des Gateways als letzten Teil des WebSocket-Pfades | 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 {#certificates} 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-.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 ()`, wobei `` 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-.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 {#equipment-access} 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: | Gruppe | Was sie zeigt | Was Sie tun können | |---|---|---| | Wartet auf Freigabe | Jedes abgewiesene Zertifikat unter der EUI der Station, die es trägt: sein SHA-256-Fingerabdruck, wann das Gateway es zuletzt versucht hat und wie oft, und seine Details (Antragsteller, Aussteller, Domänennamen, Gültigkeitsdaten). | **Freigeben** lässt das Zertifikat ab der nächsten Verbindung des Gateways zu. **Sperren** weist es weiter ab, ohne es hier erneut aufzuführen. **Alle ausstehenden Zertifikate verwerfen** leert die Liste, ohne etwas freizugeben oder zu sperren. | | Freigegebene Anlagen | Die Zertifikate, die Sie freigegeben oder importiert haben, mit der Angabe, wer wann entschieden hat. | **Freigabe zurücknehmen** schließt die Verbindung des Gateways und bringt sein Zertifikat in die Liste zurück. **Zertifikat importieren** gibt das öffentliche Zertifikat eines Gateways vor seiner ersten Verbindung frei. | | Gesperrte Anlagen | Die Zertifikate, die Sie gesperrt haben. Ein gesperrtes Zertifikat wird abgewiesen, auch wenn Windows ihm vertraut. | **Entsperren** bringt das Zertifikat in die Liste zurück, ohne es freizugeben. | 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 {#connection-fields} 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. | Feld | Was es ist | Format | Standard | |---|---|---|---| | Angemeldet als | Welche der beiden Anmeldungen dieses Gerät ist: **Funksensor** oder **Funkkonzentrator**. Umzuschalten leert das Feld darunter, weil ein Anwendungsschlüssel und eine Region nicht dasselbe sind. | Sensor / Funkkonzentrator | Sensor | | DevEUI (Sensor) | Die DevEUI des Sensors, die Identität, die er in seiner Join-Anfrage vorweist. | 16 hexadezimale Ziffern, schlicht (`8899AABBCCDDEEFF`), mit Bindestrichen (`88-99-AA-BB-CC-DD-EE-FF`) oder mit Doppelpunkten. | leer | | Anwendungsschlüssel (Sensor) | Der OTAA-Anwendungsschlüssel (AppKey) des Sensors. Er weist den Join aus und leitet die Sitzungsschlüssel ab. | Genau 32 hexadezimale Ziffern, ohne Trennzeichen. | leer | | Station EUI (Konzentrator) | Die Station EUI des Konzentrators, dieselbe Kennung, die sein Client-Zertifikat tragen muss und die er in seine Verbindungsadresse setzt. | 16 hexadezimale Ziffern, in jeder der Schreibweisen oben. | leer | | Funkregion (Konzentrator) | Wo der Konzentrator steht. Sie entscheidet über die Kanäle, die Datenraten und die Empfangsfenster, die diese Station ihm beim Verbinden übergibt. Aus der Liste gewählt; es gibt keinen Freitext. | Europa 868 MHz, Vereinigte Staaten 915 MHz, Australien 915 MHz, Asien 923 MHz, China 470 MHz (Revision 1), China 470 MHz (Revision 2) | Europa 868 MHz | | Höchste Zeit ohne Übertragung (Sensor) | Sekunden, die dieser Sensor still bleiben darf, bevor seine gespeicherten Werte nicht mehr als Messwerte zählen. 0 schaltet das Verfallen ab. Siehe unten. | 0 oder größer | 3600 | 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 {#the-concentrators-health} 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: | Situation | Zustand | |---|---| | EUI der Station noch leer | **Noch unbekannt**: nichts ist angemeldet | | Angemeldet, das Gateway noch nicht verbunden (etwa weil sein Zertifikat noch auf Freigabe wartet) | **Getrennt** | | Das Gateway verbunden | **Verbunden** | | Das Gateway abgefallen: angehalten, ausgesteckt oder vom Netz abgeschnitten | **Getrennt**, bis es sich wieder verbindet | | Deaktiviert | **Deaktiviert** | 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 {#what-the-concentrator-is-sent} 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 {#when-a-sensor-goes-quiet} 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 {#tag-addressing} 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**: | Feld | Wirkung | Werte | Standard | |---|---|---|---| | Über Kanal und Typ von Cayenne LPP adressieren | Aus: Das Feld für den Kanal ist ein einfacher Byte-Versatz. Ein: Die Nutzlast wird nach einem Paar aus Kanal und Typ nach Cayenne LPP durchsucht. | ein / aus | aus | | Kanal oder Versatz in der Nutzlast | Im Versatzbetrieb: der ab 0 gezählte Byte-Versatz, an dem der Wert beginnt. Im LPP-Betrieb: die Nummer des LPP-Kanals, nach dem gesucht wird. | 0 oder größer | 0 | | LPP-Typcode | Nur im LPP-Betrieb: das Byte des Datentyps nach Cayenne LPP, das auf das Byte des Kanals folgt (zum Beispiel 103 für Temperatur). Die Bytes des Werts werden gleich hinter dem passenden Paar aus Kanal und Typ gelesen, und passen mehrere Nutzlasten, gewinnt die neueste. | 0 oder größer | 0 | | Leselänge (Bytes, leer = automatisch) | Wie viele Bytes der Nutzlast den Wert bilden. Leer leitet sie aus dem Datentyp ab: 1 bei Boolean und Byte, 2 bei Int16, 4 bei Int32 und Float, 16 bei String. | 1 oder größer, oder leer | leer | | Bitmaske (hex, leer = keine) | Eine hexadezimale Maske, die vor allem anderen mit UND auf die rohen Bytes gelegt wird (zum Beispiel `0x0FFF`, um Statusbits wegzunehmen). Das Präfix `0x` ist wahlweise, und eine Maske ungerader Länge wird links aufgefüllt. Die Maske muss genau so viele Bytes abdecken wie die Leselänge, sonst schlägt der Lesevorgang fehl. | Hextext oder leer | leer | | Höchstwertiges Byte zuerst (MSB first, Big-Endian) | Erklärt, dass die Nutzlast den Wert als Big-Endian trägt; die gelesenen Bytes werden vor der Wandlung umgedreht. Ein Feld für die Wortreihenfolge gibt es hier nicht: Eine Nutzlast beliebiger Länge hat keine 16-Bit-Wörter zum Tauschen. | ein / aus | aus | | Multiplikator (leer = keiner) | Ein Faktor auf der Busseite, den der Netzwerkserver gleich nach dem Entschlüsseln anwendet, bevor der Wert in die eigene Wertkette des Tags eintritt. Gilt nur für numerische Typen. Eine 0 wird dort abgelehnt, wo sie eingetippt wird ("Ein Multiplikator von 0 würde jeden Messwert auf null setzen."), weil sie jeden Messwert des Tags als 0 mit guter Qualität melden würde. | jede Zahl außer 0, oder leer | leer | 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 {#supported-data-types} | Typ | Gelesene Bytes (automatisch) | Wie die Bytes gedeutet werden | |---|---|---| | Boolean | 1 | Null ist falsch, alles andere wahr | | Byte | 1 | Vorzeichenloses Byte | | Int16 | 2 | Vorzeichenbehaftete 16-Bit-Ganzzahl | | Int32 | 4 | Vorzeichenbehaftete 32-Bit-Ganzzahl | | Float | 4 | IEEE 754 mit einfacher Genauigkeit | | String | 16 | UTF-8-Text in der Leselänge | ## Schreiben und Gerätesuche {#writes-and-discovery} 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](connector).