The Things Network fordert seit einiger Zeit seine User auf, den neuen Stack V3 zu nutzen und vorhandene Devices umzuziehen.
Beim Umstieg von V2 auf V3 wird von TTN empfohlen, Systeme in V3 komplett neu anzulegen. In Folge muss der beelogger entsprechend den neuen Daten neu programmiert werden.
Obwohl den Nutzern empfohlen wird den neuen Stack zu nutzen, befindet sich V3 immer noch in einem Stadium der Weiterentwicklung. Derzeit kommen regelmäßig neue Funktionen hinzu und Fehler werden behoben.
Bei Schwierigkeiten mit bestehenden beeloggern wird der Abgleich der Einstellungen im TTN mit dieser Seite empfohlen.
Diese Seite wird auf Basis von Informationen aus der community fortwährend aktualisiert.
Für eure Unterstützung vielen Dank.
1-Channel-LoRa-Gateway:
Achtung! Bei Verwendung eines 1 Channel LoRa Gateways zum Tests des beeloggers ist die Unterstützung eines Downlinks zwingend für V3 notwendig.
Beim sehr verbreiteten 1 Channel Gateway auf Github im Repository von things4u gibt es derzeit einen Bug: https://github.com/things4u/ESP-1ch-Gateway/pull/72
Um die Funktion mit V3 sicher zu stellen, ist aktuell der folgende Fork zu verwenden: https://github.com/itsygithub/ESP-1ch-Gateway.
Zudem ist bei Verwendung dieses Gateways zum Test zu beachten, dass der beelogger über die LMIC-Library eine von drei verschiedenen Frequenzen nutzt.
Bei Bedarf kann die Frequenzliste im SketchFunktion setup_LORA() an den vom 1 CH Gateway verwendeten Kanal angepasst werden.
Login und Konfiguraton:
Die Zugangsdaten für V2 und V3 sind identisch, wer allerdings noch keinen Account besitzt, kann diesen auf dieser Seite anlegen: https://www.thethingsnetwork.org.
Der Login zum Stack V3 erfolgt unter https://eu1.cloud.thethings.network. Nach Eingabe der Zugangsdaten kann über die Menüleiste “Application” und danach mit dem Button “+Add application” ein neues Gerät angelegt werden.
Zunächst ist eine Application ID einzugeben, optional kann zusätzlich auch ein Application Name sowie eine Beschreibung eingegeben werden.
Innerhalb der Application ist nun ein Gerät anzulegen, indem auf den Button “+Add end device” geklickt wird.
Zuerst muss ausgewählt werden, dass das neue Gerät “Manually” konfiguriert werden soll. Danach kann als Aktivierungsmethode “ABP” und als LoRaWAN Version “MAC V1.0.2” ausgewählt werden.
Da bei dieser Konfiguration pro Application nur ein Gerät eingerichtet wird, kann für die “End device ID” die gleiche Bezeichung wie für die “Application ID” zuvor in denBasiseinstellungen verwendet werden. Die weiteren Felder können optional ausgefüllt werden.
Die Netzwerkeinstellungen für Europa sind gemäß dem folgenden Screenshot auszufüllen. Vor dem Betrieb des beelogger auf diesem Frequenzband (gilt auch für die folgenden einzustellenden Frequenzen) ist natürlich zu prüfen, ob der Betrieb in der jeweiligen Region erlaubt ist. Um eine “Device address” oder ein “Network session key” zu generieren, ist auf den Doppelpfeil zu klicken.
Um erweitere Einstellungen vornehmen zu können, ist zunächst auf “Advanced settings” zu klicken. Die Nachfolgenden Einstellungen sind ebenfalls gemäß Screenshot einzustellen.
Die Frame Counter witdh ist auf 32 einzustellen.
Durch Klick auf den Button “+ Add Frequency” wird jeweils ein Eingabefeld generiert, in dem Frequenzen einzutragen sind. Der Vorgang ist drei mal durchzuführen und gemäß Screenshot auszufüllen.
Im letzten Abschnitt wird der “Application session key” durch Klick auf den Doppelpfeil erstellt.
Im nächsten Schritt wird das Payload Format eingerichtet. Hiermit können die empfangenen und decodierten Daten in reguläre Messwerte konvertiert werden, die entsprechenden Variablen zugeordnet sind.
Hierzu ist der Reiter “Payload formatters” beim soeben angelegten Gerät auszuwählen. Unter “Uplink” kann dann das “Javascript” kopiert und gespeichert werden, welches wir als Download zur Verfügung stellen.
Der Payload-Formater ist im Download des Sketch anthalten.
Hier für den beelogger-Universal (ATmega) und für die STM32-Systeme.
Als “Base URL” ist der Link zur jeweiligen beelogger_log.php anzugeben.
Beispiele:
System mit einer Waage:
https://community.beelogger.de/UserName/beelogger1/beelogger_log.php?Passwort=deinpasswort&LORA=1
System mit zwei Waagen:
https://community.beelogger.de/UserName/Duo1/beelogger_log.php?Passwort=deinpasswort&LORA=1
Natürlich ist “USERNAME” durch den beeloggerAccountNamen und das entsprechende “Passwort” für den beelogger individuell zu ersetzen.
Test der Verbindung von TTN zum beelogger communityServer
Um die Verbindung von TTN zum communityServer zu testen, kann mit einem Test-Payload ein Uplink simuliert werden.
Hierzu ist in der linken Menüleiste “End devices” anzuklicken, danach kann das soeben angelegte Gerät ausgewählt werden.
Unter “Messaging” -> “Uplink” kann nun unter “Payload” der Test-Payload eingetragen und versendet werden.
Test-Payload:
Single-Systeme: alter Payload-Formatter: 11 02 02 12 48 01 07 EF 02 1A 03 11 07 04 00 08 05 12 34 06 00 11 14 27 89 neuer Payload-Formatter: 09 C5 2B 0F CE 01 15 01 00 28 1C 01 00 03 5C A6 E0 2F
DUO-Systeme: alter Payload-Formatter: 11 02 02 12 1A 01 00 00 02 55 03 24 B5 04 00 08 06 00 00 14 27 89 23 0B B0 13 22 05 12 34 21 02 03 22 33 neuer Payload-Formatter: 09 C5 2B 0F CE 01 15 00 00 00 00 28 1C 00 00 03 5C A6 E1 2F
Nun ist zu prüfen, ob die Test-Daten auf dem eingetragenen Account auf dem communityServer angekommen sind.
Systemtest beelogger
Den Sketch mit den Keys und der Device Address in den beelogger flashen.
Das RFM95-Modul immer mit einer Antenne, ggf. “Klingel-” Draht 86mm lang ab Lötauge, betreiben.
Einen Testsketch haben wir für den LoRa-beelogger nicht erstellt.
Es kann der normale Sketch verwendet werden, nachdem in die Multi_LORA_config.h die Daten für
– Device Adress
– Network Session Key
– App Session Key
eingetragen sind.
Network Session Key und App Session Key aus dem TTN werden im Hexadezimalformat zu je zwei Zeichen in die Multi_LORA_config.h eingetragen.
Beispiel:
// Networks Session Key aus dem TTN: 1234567890ABCDEF2A3B4D5EE2E5196C
static const u1_t PROGMEM NWKSKEY[16] = { 0x12, 0x34, 0x56, 0x78, 0x90, 0xAB, 0xCD, 0xEF, 0x2A, 0x3B, 0x4D, 0x5E, 0xE2, 0xE5, 0x19, 0x6C };
Die Sensoren, soweit vorhanden, konfigurieren und in der beelogger_config.h den Wert von myDEBUG auf 1 setzen.
Den Sketch laden und im Monitor die Ausgabe ansehen. Hier ein Beispiel mit nur einer Waage:
LoRa: Setup: done Payload: 11 834 TempOut: 2100 3 1269 VBatt: 4713 4 11E3 VSol: 4579 6 08D Gewicht: 141 13 0 An-Zeit: 0 16 03DB2 Packet queued, len: 19 320549: EV_TXCOMPLETE Wakeup at: 19:22
Die Daten im Beispiel bedeuten:
Temperatur 21,00°C
Akku: 4,713V
Solar: 4,579V
Gewicht: 0,141kg
Einschaltzeit 0 Sekunden ( =Wert beim ersten Senen nach Reset)
Ist eine der Leitungen NSS, MOSI, MISO, SCK oder 3,3V nicht korrekt angeschlossen wird diese Fehlermeldung angezeigt. Ebenso bei falschem Modul und auch fehlerhafter Einstellung in der LMIC-Bibliothek.
LoRa: Setup: FAILURE C:UserstestDocumentsArduinolibrariesarduino-lmic-mastersrclmicradio.c:689
Wenn die Leitung von DIO-0 bzw. DIO-1 nicht richtig verschaltet ist, wird eine Time-Out Meldung angezeigt.
Packet queued, len: 19 ...timeout Wakeup at: 19:30
Inbetriebnahme
Nach erfolgreichem Test kann das System mit den gewünschten Sensoren ausgestattet werden. Nach erfolgter Konfiguration und Laden auf den beelogger ist das System betriebsfertig.
Je nach Ausbaustufe und Auswahl der Sensoren wird mehr Systemspeicher benötigt als verfügbar ist. Wird der Wert myDEBUG auf 0 gesetzt, steht mehr Speicher zur Verfügung.
Bitte für den Dauerbetrieb immer den Wert myDEBUG auf 0 setzen.
Sobald die Daten vom LoRa-beelogger im TTN ankommen, werden sie automatisch an den beelogger-Webserver übertragen und stehen wie alle anderen Daten für den User im communityAccount zur Verfügung.
Im der TTN V3 Stack können die eingehenden Daten den jeweiligen “End device” unter “Live data” eingesehen werden.
LoRa™, LoRa™ Alliance und LoRaWAN™ sind eingetragene Warenzeichen der Semtech Corporation