![Logo_quer_farbig.png]](https://docs.sentinum.de/hs-fs/hubfs/Logo_quer_farbig.png?width=168&height=40&name=Logo_quer_farbig.png){kind=logo}
Generische LoRaWAN® Dokumentation
Sie suchen die generische LoRaWAN® Dokumentation?
Hier finden Sie die generische LoRaWAN® Dokumentation.
Join-Verhalten der LoRaWAN® Sensoren
Bevor Telemetriedaten via LoRaWAN® übertragen werden können, muss das Gerät zunächst eine Verbindung mit dem Netzwerk herstellen. Dazu sendet das Gerät wiederholt Join-Requests, bis ein Join-Accept erfolgreich empfangen wurde.
Um Energieverbrauch und Join-Geschwindigkeit optimal auszubalancieren, werden die Übertragungsintervalle der Join-Requests mit der Zeit größer. Parallel dazu wird die Datarate variiert — beginnend mit einer höheren Datarate (kleiner Spreizfaktor) und anschließend mit einer niedrigeren Datarate (größerer Spreizfaktor). Dieses Verhalten folgt strikt den Spezifikationen und Empfehlungen der LoRa Alliance®.
Sentinum Sensoren setzen dieses Verhalten durch sogenannte Join-Bursts um, deren zeitlicher Abstand mit der Dauer zunimmt.
Join-Bursts
Ein Join-Burst besteht aus bis zu sechs Join-Requests mit abnehmender Datarate (DR5 → DR0) bzw. zunehmendem Spreizfaktor (SF7 → SF12). Die Intervalle zwischen den einzelnen Requests steigen quadratisch an, um die Duty-Cycle-Beschränkungen der LoRa Alliance® einzuhalten.
Duty-Cycle Grenzwerte für Join-Requests
| Zeitfenster | Duty-Cycle |
|---|---|
| < 1 Stunde | 1 % |
| < 11 Stunden | 0,1 % |
| > 11 Stunden | 0,01 % |
Das bedeutet, dass in der ersten Phase (< 1 Stunde) das gleiche Gesamt-Sendebudget zur Verfügung steht wie in der zweiten Phase (< 11 Stunden), obwohl die erlaubte Sendezeit dort zehnmal geringer ist. Um dieses Budget optimal zu nutzen, beginnen Sentinum Sensoren mit kurzen Abständen zwischen den Join-Bursts, die mit fortschreitender Zeit länger werden.
Phasen des Join-Prozesses
- Phase 1: 2 Bursts mit kurzen Intervallen (Burst-Dauer ca. 10 Minuten)
- Phase 2: 2 zusätzliche Bursts mit längeren Intervallen (Burst-Dauer ca. 100 Minuten)
- Phase 3: 1 Burst pro Tag mit sehr langen Intervallen (Burst-Dauer bis zu 16 Stunden)
EUIs und Schlüssel
Alle Sentinum LoRaWAN® Sensoren werden mit folgenden Kennungen ausgeliefert:
- DEVEUI
- APPEUI
- APPKEY
- Produktnummer
Die 8-Byte DEVEUI ist ein eindeutiger Identifikator aus dem Sentinum OUI-Block FC84A. Die 8-Byte APPEUI stammt ebenfalls aus einem Sentinum-internen Nummernkreis und ist für jede Produktreihe identisch, wodurch diese eindeutig identifizierbar ist.
Der 16-Byte APPKEY ist ein individuell und zufällig generierter kryptografischer Schlüssel, der für Authentifizierung und Verschlüsselung während des LoRaWAN® Join-Prozesses verwendet wird.
Zusätzlich besitzt jedes Produkt eine eindeutige Produktnummer (z. B. APOQXXXX, FEBRXXXX), die dauerhaft mit einer DEVEUI und einem APPKEY verknüpft ist.
Diese drei Schlüssel werden jedem LoRaWAN® Sensor beigelegt und zusätzlich sicher über die Cloud bereitgestellt. Die APPEUI kann beim Auslesen des Geräts mit der Sentinum LinQs App angezeigt werden.
Die Downlinks der LORA Module werden alle auf Port 4 ausgeführt und auszuführende Befehle (EXEC) auf Port 5. Diese sind mit einem „(EXEC)“ hinter der jeweiligen Ressource gekennzeichnet.
LoRa – modulübersicht
| Modul | Modulschlüssel | Gruppe | Gruppen ID | Beschreibung |
|---|---|---|---|---|
| LoRa | 0x2211 | Netzwerkressourcen | 0x00 | DEVEUI des Gerätes (read only) |
| LoRa | 0x2211 | Übertragungseinstellungen | 0x01 | Übertragungseinstellungen, z. B. adaptive Datarate (ADR), Confirmed Uplinks etc. |
| LoRa | 0x2211 | Rejoin Einstellungen | 0x02 | Einstellungen zur Netzprüfung und automatischen Wiederverbindung bei Verbindungsverlust. |
| LoRa | 0x2211 | GNSS Gruppe | 0x03 | Einstellungen und Timings für Lokalisierungsoptionen (für Sensoren mit Tracking-Feature). |
| Supervisor | 0x3211 | System | 0x00 | Gerät zurücksetzen oder neu starten. |
Tabellen für produktübergreifende Module finden Sie in der Generischen NFC und Downlink Dokumentation.
Weitere Informationen zur Konfiguration der Sensor-Kommunikation finden Sie je nach Version in der jeweiligen generischen LoRaWAN® oder Mioty® Dokumentation.
Die aktuellen Einstellungen eines Parameters können abgefragt werden, indem beim Downlink kein Wert zur Konfiguration mitgesendet wird.Beispiel:
Um die aktuelle Einstellung des ADR-Parameters auszulesen, kann folgender Downlink verwendet werden:
11 22 11 01 02
Dieser Downlink fragt den aktuellen ADR-Wert ab, ohne ihn zu verändern.
Der Downlink muss auf Port 6 gesendet werden. Der Sensor antwortet hier auf Port 3.
LoRa – gruppe netzwerkressourcen (0x00)
| Ressource | Ressourcen ID | Schlüssel (NFC/BLE) | Min | Max | Werkseinstellung | Einheit | Modulschlüssel |
|---|---|---|---|---|---|---|---|
| DEVEUI | 0x00 | dev_eui | 16 | 16 | 16 | 22XX | |
| READONLY-Parameter: DEVEUI des Sensors. Dieser Parameter kann per Downlink nicht ausgelesen werden. | |||||||
LoRa – gruppe übertragungseinstellungen (0x01)
| Ressource | Ressourcen ID | Schlüssel (NFC/BLE) | Min | Max | Werkseinstellung | Einheit | Modulschlüssel |
|---|---|---|---|---|---|---|---|
| Bestätigt | 0x00 | conf | 0 | 3 | 0 | 22XX | |
|
Gibt an, ob der Sensor im bestätigten Modus arbeitet: • 0: bestätigt aus = unbestätigt • 1: bestätigte INFO-Nachrichten (Status-Uplinks) – derzeit nicht verfügbar • 2: Alarm-Uplinks bestätigt • 3: Alles bestätigt |
|||||||
| Confirmed retries | 0x01 | retry | 1 | 5 | 3 | 22XX | |
| Anzahl der maximalen erneuten Sendeversuche im „BESTÄTIGT"-Modus. | |||||||
| ADR | 0x02 | adr | 0 | 1 | 1 | dr | 22XX |
|
ADR ein-/ausschalten: • 0: ADR aus • 1: ADR an |
|||||||
| Datarate | 0x04 | drmax | 0 | 5 | 0 | dr | 22XX |
| Feste Datenrate (SF), falls ADR deaktiviert ist. | |||||||
| Aktiviere Downlink Antwort | 0x05 | dresp | 0 | 1 | 0 | 22XX | |
|
Gibt an, ob ein Downlink außerhalb des „BESTÄTIGT"-Bereichs einen Uplink auslöst: • 0: aus • 1: an |
|||||||
LoRa – gruppe rejoin einstellungen (0x02)
| Ressource | Ressourcen ID | Schlüssel (NFC/BLE) | Min | Max | Werkseinstellung | Einheit | Modulschlüssel |
|---|---|---|---|---|---|---|---|
| Rejoin Strategie | 0x00 | rejstr | 0 | 2 | 0 | 22XX | |
|
Wiedereintritt-Strategie: • 0: Nie wieder beitreten • 1: Alle x Übertragungen Link-Check • 2: Alle x Übertragungen bestätigt |
|||||||
| Verbindung Check alle | 0x01 | chkev | 1 | 48 | 4 | 22XX | |
|
Bestimmt die Anzahl x (für rejstr), nach der eine Netzprüfung durchgeführt wird: • ACK-Bestätigung (wenn rejstr = 2) • Link-Check (wenn rejstr = 1) |
|||||||
| Fehler bis Rejoin | 0x02 | rejaft | 0 | 5 | 4 | dr | 22XX |
| Gibt an, nach wie vielen fehlgeschlagenen Prüfungen der Sensor einen Rejoin durchführen soll. | |||||||
LoRa – gnss gruppe (0x03)
| Ressource | Ressourcen ID | Schlüssel (NFC/BLE) | Min | Max | Werkseinstellung | Einheit | Modulschlüssel |
|---|---|---|---|---|---|---|---|
| GNSS Modus | 0x00 | lmode | 0 | 4 | 0 | 22XX | |
|
Gibt die Reihenfolge der Lokalisierungstechnologien an: • 0: Aus • 1: GNSS Scan • 2: WIFI SSIC Scan • 3: GNSS Scan → danach WIFI SSID Scan • 4: WIFI SSID Scan → danach GNSS Scan |
|||||||
| GNSS Update Periode | 0x01 | gper | 1 | 43200 | 1440 | min | 22XX |
| Aktualisierungsintervall der Lokalisierung des Geräts (in Stunden). | |||||||
| Almanac Daten herunterladen | 0x02 | gnssal | 0 | 1 | 0 | 22XX | |
|
ALMANAC Daten werden heruntergeladen (erhöht den Energieverbrauch, ermöglicht jedoch schnellere und präzisere GNSS-Lokalisierung): • 0: keine Daten werden heruntergeladen • 1: Almanac Daten werden heruntergeladen |
|||||||
| GNSS in mobilen Anwendungen | 0x03 | gnssmb | 0 | 1 | 0 | 22XX | |
|
Lokalisierungsverfahren werden für die Anwendung optimiert: • 0: Optimiert für statische Objekte • 1: Optimiert für sich bewegende Objekte |
|||||||
| Scan ausführen (EXEC) | 0x04 | 22XX | |||||
Scan starten. Beispiel-Downlink (Port 5):11 2211 03 04
|
|||||||
Supervisor – gruppe system einstellungen (0x00)
| Ressource | Ressourcen ID | Schlüssel (NFC/BLE) | Min | Max | Einheit | Modulschlüssel |
|---|---|---|---|---|---|---|
| Reboot (EXEC) | 0x00 | reboot | 0 | 43200 | s | 32XX |
|
Reboot des Gerätes – Einstellungen bleiben erhalten. Nach der Ressourcen-ID müssen dem Kommando 2 zusätzliche Bytes hinzugefügt werden. Diese geben die Zeit bis zum Reboot an. • Zeit in Sekunden • Wert darf 0 sein • Immer 2 Bytes angeben (auch bei 0 → 00 00)• Minimal: 0 • Maximal: 43200 |
||||||
| Reset (EXEC) | 0x01 | reset | 0 | 43200 | s | 32XX |
|
Reset des Gerätes – Einstellungen werden auf Werkseinstellung zurückgesetzt. Nach der Ressourcen-ID müssen dem Kommando 2 zusätzliche Bytes hinzugefügt werden. Diese geben die Zeit bis zum Reset an. • Zeit in Sekunden • Wert darf 0 sein • Immer 2 Bytes angeben (auch bei 0 → 00 00)• Minimal: 0 • Maximal: 43200 |
||||||
Beispiel: Reboot des Gerätes nach 0 Sekunden:
Port 5:
11 3211 00 00 00 00
Werden die 2 Bytes nicht angehängt, so scheitert der Downlink!
Beispiel downlinks
| Ressource | Beschreibung | Downlink |
|---|---|---|
| Reboot | Reboot des Gerätes nach 10 Sekunden. Einstellungen bleiben erhalten. | 11 3211 00 00 00 0A |
| Scan ausführen | GNSS Scan ausführen. | 11 2211 03 04 |
| Confirmed | Alle Uplinks sollen als bestätigte (confirmed) Uplinks ausgeführt werden. | 11 2211 01 00 00 00 00 03 |
| ADR | ADR ausschalten. | 11 2211 01 02 00 00 00 00 |
Technische Änderungen behalten wir uns ohne vorherige Ankündigung vor. Alle Angaben ohne Gewähr.
