.png?height=120&name=weiss%20(1).png)
Sie suchen die generische LoRaWAN® Dokumentation?
Hier finden Sie die generische LoRaWAN® Dokumentation.
Grundlagen
📢 Dieses Dokument beschreibt sensorübergreifen die für das Funkprotokoll LoRaWAN® spezifischen Eigenschaften und einstellbaren Parameter.
Join Verhalten der LoRaWAN® Sensoren
Bevor Telemetriedaten via LoRaWAN versendet werden können, muss das Gerät eine Verbindung mit dem Netzwerk herstellen. Dazu versendet das Gerät so lange Join-Requests, bis erfolgreich ein Join-Accept empfangen wurde. Als Kompromiss zwischen Energieverbrauch und zügigem Join, werden die Sendeabstände der Join-Requests immer größer. Außerdem wird auch die Datarate variiert (zunächst große Datarate bzw. kleiner Spreizfaktor, dann kleinere Datarate bzw. größerer Spreizfaktor). Das Join Verhalten hält die Vorgaben und Empfehlungen der LoRa-Alliance Spezifikation strikt ein. Sentinum Sensoren setzen die Vorgaben durch sogenannte Join-Bursts, deren Abstand zueinander wächst, um
Ein Join Burst besteht aus maximal 6 Join-Requests mit abnehmender Datarate (DR5-DR0) bzw. zunehmenden Spreizfaktor (SF7-SF12). Die Abstände zwischen den Requests nehmen quadratisch zu, um die Lora-Alliance spezifischen Duty-Cycle Richtlinien nicht zu verletzen. Die LoRa-Alliance schreibt einen Abnehmenden Duty-Cycle für Join Requests gemäß folgender Tabelle vor Zeit Duty-Cycle <1h 1% <11h 0.1%
11h 0.01%
Das Bedeutet das in der ersten Phase (<1h) genau so viel Sendebudget zur verfügung steht, wie in der zweiten (<11h), obwohl nur ein zehntel der Zeit zur verfügung steht. Um das Budget maximal auszunutzen, sind die Abstände zwischen Join Bursts (bestehend aus max. 6 Join Requests) zunächst klein und werden dann größer. Konkret werden in Phase 1 2 Bursts durchgeführt. In Phase 2 werden 2 weitere Bursts durchgeführt, ab Phase 3 wird 1 Burst pro Tag durchgeführt. Die länge der Bursts wächst von ca. 10 Minuten in Phase 1, über ca. 100 in Phase 2 , auf bis zu 16 Stunden in Phase 3, an.
EUIs und Schlüssel
Alle ausgelieferten Sentinum Sensoren besitzen
- DEVEUI
- APPEUI
- APPKEY
- Produktnummer
Die 8 Byte DEVEUI ist eine aus dem Sentinum OUI-Block FC84A ausgewählte eindeutige Nummer, der den Sensoren zugewiesen wurde. Auch die 8 Byte APPEUI ist aus dem Sentinum eigenen Nummernkreis gewählt. Jeder Sensorreihe besitzt immer die gleiche APPEUI. Dadurch kann die Produktreihe innerhalb der Sentinum Produkte indentifiziert werden. Der 16 Byte APPKEY ist eine von einem Programm zufällig generierter Schlüssel.
Zusätzlich besitzt jedes Produkt eine individuelle Produktnummer. Jede Produktnummer (APOQXXXX, FEBRXXXX, …) ist mit einer DEVEUI und einem APPKEY verknüpft.
Der Lieferumfang beinhaltet für jeden LoRaWAN® Sensor die drei aufgeführten Schlüssel und sind Teil des Paketes. Zusätzlich werden die Schlüssel über die eine sichere Cloud bereitgestellt.
Die APPEUI wird beim Auslesen durch die Sentinum LinQs App angezeigt.
Default Parameter
Die default Parameter und Vorseinstellungen gelten, falls in der produktspezifischen Dokumentation keine anderen Werte angegeben sind.
| Parameter | Default | Optional (einstellbar) |
|---|---|---|
| Aktivierung | OTAA | ABP |
| LoRa MAC Version | 1.0.2 | Update erfolgt falls Eigenschaften der Sensoren positiv beeinfluss werden. |
| Join Loop Datarate Start | SF7 (datarate 5) | |
| Join Loop Datarate End | Interne Temperatur | |
| Regional Parameters | RP001 Regional Parameters 1.0.2 revision B | |
| REV | REV B | |
| Frequency Plan (for EU) | Europe 863-870 MHz (SF12 for RX2 recommended) |
APPEUI Konfigurationsmöglichkeiten
NFC- und Downlinkbefehle
|
Name
|
Beschrei-bung
|
json Schlüssel
|
Modul-schlüssel
|
Gruppe für Down-link
|
Property ID
|
Default Wert
|
Min
|
Max
|
read/
write |
|---|---|---|---|---|---|---|---|---|---|
|
APPEUI
|
Gibt die APPEUI an
|
app_eui
|
0x1112
|
0x00
|
0x00
|
w
|
|||
|
APPKEY
|
Gibt die APPEUI an
|
app_key
|
0x1112
|
0x00
|
0x01
|
w
|
|||
|
DEVEUI
|
Gibt die DEVEUI an
|
dev_eui
|
0x1112
|
0x00
|
0x02
|
r
|
|||
|
Confirmed Strategy
|
Gibt an, ob der Sensor im confirmed Modus arbeitet:
0: confirmed off = unconfirmed 1: confirmed INFO messages (Status uplinks) => derzeit nicht verfügbar 2: Alarm Uplinks confirmed 3: Alles confirmed |
conf
|
0x1112
|
0x01
|
0x00
|
0
|
0
|
3
|
rw
|
|
Confirmed Retries
|
Anzahl der maximalen Retries (Sendeversuche im Confirmed Modus)
|
retry
|
0x1112
|
0x01
|
0x01
|
3
|
1
|
5
|
rw
|
|
ADR
|
ADR on/off 0: ADR off
1: ADR on |
adr
|
0x1112
|
0x01
|
0x02
|
3
|
0
|
1
|
rw
|
|
ADR SF min
|
Minimaler Spreading Factor, auf das die ADR zurückfallen kann
|
dr
|
0x1112
|
0x01
|
0x03
|
5
|
0
|
5
|
rw
|
|
Fixed SF
|
Fester Spreadingfactor, falls ADR ausgeschaltet
|
drmax
|
0x1112
|
0x01
|
0x04
|
0
|
0
|
5
|
rw
|
|
Enable Downlink Response
|
Gibt an, ob ein Downlink ausßerhalb der Confirmation bei downlink confirmed bestätigt wird. Der Downlink löst in diesem Fall einen Uplink aus: 0: off
1: on |
dresp
|
0x1112
|
0x01
|
0x05
|
0
|
0
|
1
|
rw
|
|
APPSKEY
|
Für ABP
|
apps_key
|
w
|
||||||
|
NETWSKEY
|
Für ABP
|
netws_key
|
w
|
||||||
|
DEVADDR
|
Für ABP
|
dev_addr
|
w
|
||||||
|
ACTMTH
|
0: OTAA 1: ABP
|
act_mth
|
0
|
0
|
1
|
rw
|
|||
|
REJSTR
|
Rejoin Stratregy: 0: Nie Rejoinen 1: Alle X Sendungen Link Check 2: Alle X Sendungen Confirmed
|
rejstr
|
0
|
0
|
2
|
rw
|
|||
|
CHKEV
|
Check Every bestimmt die Anzahl (x bei rejstr) nach der ein Check durchgeführt wird, entweder durch confirmed mit ACK oder Link Check, je nachdem wie in rejstr spezifiziert.
|
chkev
|
4
|
1
|
48
|
rw
|
|||
|
REJAFT
|
Rejoin after gibt an, nach wie vielen fehlgeschlagenen Checks der Sensor rejoinen soll.
|
rejaft
|
4
|
0
|
5
|
rw
|
📢 Die Werte der Gruppe für Downlink APPEUI, APPKEY, DEVEUI können nur via NFC gesetzt werden!
Um die Schlüssel wie z.B. app_eui und app_key zu ändern und gleichzeitig einen REBOOT
durchzuführen bitte immer folgendes ausführen:
{
„power“:“REBOOT“,
„senticom“:{
„app_eui“:“8XXXXXXXXXXXXXXX“,
„app_key“:“XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX“
}
}
Da app_eui und app_key write-only Parameter sind, können diese nicht von der App gelesen werden, außer diese wurden zuvor von der App beschrieben. Deshalb empfehlen wir in der Regel, die Keys dauerhaft in der JSON-Konfiguration stehen zu lassen. Falls gefordert ist, dass nutzerspezifische Keys gesetzt werden, diese aber keinesfalls auslesbar sein sollen, kann nach erstmaligem setzen der Keys ein weiteres JSON ohne diese Keys geschrieben werden. In diesem Falle bleiben die Keys im internen Speicher erhalten. Erst bei power=RESET werden diese auf Werkseinstellung zurückgesetzt.
💡 rejstr, chkev und rejaft sind Features um einen Link Check zu aktivieren.
SF vs. DR
|
DR
|
SF
|
|
0
|
SF12
|
|
1
|
SF11
|
|
2
|
SF10
|
|
3
|
SF9
|
|
4
|
SF8
|
|
5
|
SF7
|