LORAWAN / The Things Network TTN

Falls jemand Interesse hat:

Grüße
richimaint

Gesendet von iPhone XS mit Tapatalk

Das TTN-Device war meine erste Instanz. Die kann tatsächlich die Rohdaten verwalten wenn die Daten als solche gesendet werden, ist jedoch in den meinsten fällen nicht der Fall (Habe ich auch dazu gelernt :rolleyes:)
Daher habe ich auch in der Doku geschrieben, dass ich diese Instanz auch nicht mehr weiterentwickle. Falls sie doch noch jemand verwendet wollte ich sie aber nicht ersatzlos raus werfen. Durch die Struktur von TTN werden die Daten ja im Decoder bereits zerteilt und werden dann als Objekte über die API raus gegeben. Daher macht es wenig Sinn mit den Rohdaten zu arbeiten sondern mit dem Objekten und das dann im „TTN Object Device“.

Danke da verliert man beim Programmieren gerne den Überblick :slight_smile:
Beim nächsten Update passt das wieder :slight_smile:

Da Bist du schon auf dem richtigen Weg die Daten werden im Decoder zerlegt und werden dann in das „TTN Object Device“ weiter gegeben. Hierbei muss „RAW-Payload“ deaktiviert sein, da das bedeuten würde, dass die Daten als JSON im Payload des LoRa Gerätes stehen (macht aus Sicht des Overheads keinen Sinn)

Wenn du „Variablen automatisch erstellen“ aktiviert hast sollten sich diese beim Empfang der ersten Nachricht selbst erstellen.

Wenn RSSI-Werte vorhanden sind aber keine Daten erstellt werden stimmt vermutlich etwas mit deinem Decoder nicht.

Beispieldecoder:


function Decoder(bytes, port) {
    var decoded = {};

    decoded.value = parseFloat(String.fromCharCode.apply(null, bytes).substring(0, 4))/10

    return decoded;
}

die Variablen müssen unter decoded stehen. Wie z.B. decodet.value. Dann wird die Variable „value“ erstellt.
Tiefere Verschachtelungen sind hier nicht möglich.

Viel einfacher geht das wenn der Node das Cayenn LPP-Format unterstützt. Dann geht das alles automatisch :wink:

Der Enviroment Sensor ist im Grunde ein „TTN Object Device“ mit festen Keys für die Parameter:

[ul]
[li]Temperatur
[/li][li]Luftfeuchtigkeit
[/li][li]Luftdruck
[/li][li]Batteriespannung
[/li][li]Solarzellen-Spannung
[/li][li]Fehler
[/li][/ul]
Diese Variablen werden dann auch geloggt wenn man das aktiviert hat.

Eigentlich sollte das noch nicht online gehen weil die Doku noch nicht fertig ist aber beim Update für Symcon 5.5 war es heimlich dabei :slight_smile:

Moin,

ich nutze folgenden Decoder:

https://github.com/Alpha-Omega-Technology/ttn-klax

Bei mir wird nichts automatisch angelegt, dafür bekomme ich, aber folgenden Fehler:

21.09.2020, 06:02:03 | FlowHandler          | Kann Daten nicht zur Instanz #38498 weiterleiten: <br />
<b>Fatal error</b>:  Uncaught Error: Object of class stdClass could not be converted to string in C:\ProgramData\Symcon\modules\.store\firebuster.thethingsnetwork\TtnObjectDevice\module.php:113
Stack trace:
#0 C:\Windows\System32\-(3): TtnObjectDevice->ReceiveData('{"DataID":"{474...')
#1 {main}
  thrown in <b>C:\ProgramData\Symcon\modules\.store\firebuster.thethingsnetwork\TtnObjectDevice\module.php</b> on line <b>113</b><br />

Die Instanz #38498 ist das „TTN Object Device“

Habe noch ein zweites Gerät angelegt, ein Tabs Door Sensor, da funktionierte das automatische Anlegen einwandfrei.

Eine weitere Frage habe ich aber auch noch, muss ich für jedes Gerät ein extra „TTN HTTP Integration Gateway“ anlegen?

Hein09

Also auf die Schnelle würde ich sagen der Decoder gibt keine Objekte aus sondern direkt die Variablen.

Ich schick dir mal meine Mail-Adresse.
Würde gerne mal sehen wie das in der Console aussieht und im Debug vom Symcon.

Eine HTTP Integration muss genau einmal angelegt werden.

Beim anschauen der Debug-Dateien sieht man, dass die Daten in mehreren Ebenen verschachtelt sind.
Das wird von der Instanz so zur Zeit nicht abgedeckt. Dies ist auch der erste Fall wo dieses Problem Auftritt.

Es gibt zwei Lösungsmöglichkeiten um damit umzugehen.

  1. Den Decoder so umbauen, dass es nur noch eine Ebene ist

{
      "header_batteryPerc":100,
      "header_configured":true,
      "header_connTest":false,
      "header_deviceType":"SML Klax",
      "header_meterType":"SML",
      "header_version":1,
      "msgInfo_msgCnt":1,
      "msgInfo_msgIdx":176,
      "msgInfo_msgNum“:1
.. 
  1. Die Daten selbst aus dem Feld holen.
    Hierfür kannst du in der Instanz ein Script anlegen und auf die Aktualisierung der Frame ID dieses Script ausführen.

Im Script rufst du das Payload-Feld ab und holst dir die Daten selbst raus:


$data = TTN_GetData(TTN_Object_Device_ID);
$header = $data->payload_fields->header;
$msgInfo = $data->payload_fields->msgInfo;
…

$batteryPerc = $header->batteryPerc;
...

Ich habe zum Modul ein eigenes Thema eröffnet.
Hier können spezielle Fragen zum Modul beantwortet werden.

[Modul] TheThingsNetwork

Hallo, ich hoffe, ich sprenge den Rahmen dieses Threads nicht. Ich würde mich gerne mal etwas mit LORAWAN beschäftigen, hab aber dazu typische Einsteigerfragen:

  1. Welches Gateway ist denn gerade „angesagt“? Es gibt so viele von 100 EUR bis 1000 EUR und ich sehe die Unterschiede gar nicht. Selbstbau mit IMST IC880a und Raspberry erscheint zumindest finanziell ja kein Vorteil mehr zu sein. Ich finde derzeit das MikroTik wAP LoRa8 kit ganz okay, da outdoor und mit 150EUR wohl halbwegs im Rahmen.

  2. Ich verstehe die Reichweiten nicht: Angeblich hat das doch so eine enorme Reichweite bis 15km oder so, aber wenn ich auf den ttn-mapper schaue, reicht jeder Kreis höchstens 200m. Ich bin angeblich ca. 2km von einem Gateway entfernt, habe aber Null Empfang.

Vielleicht habt ihr ja den einen oder anderen Tip für mich. Was ich damit genau mache, weiß ich noch nicht - erster Versuch wäre, eine Datenverbindung vom 3.OG in den Keller aufzubauen.

Danke,
Tom

Zu 1
Ich bin auch ein Fan von den MikroTik wAP Lora8. Ein Selbstbau rentiert sich eher weniger. Ggf wenn man was passendes in der Bucht schießt.
Habe mal was zu verschiedenen Gateways und Antennen zusammen gefasst:
Gateway und Antennen

Zu 2.
LoRaWAN bietet trotz der geringen Sendeleistung eine beeindruckende Link-Margin. Das bedeutet ein Signal kann noch sehr schwach empfangen werden.
Die beste Funkverbindung hat man natürlich bei LOS (Line of Sight). Hier gibt es in der Praxis quasi keine Reichweitenbegrenzung. Problem ist, dass durch die Erdkrümmung dies nur bis zu einer bestimmten Entfernung erreicht werden kann.
Daher gilt es beim errichten eines Gateways möglichst hoch zu kommen.
Wenn ein Gateway auf einem Berg steht kann man somit ein ganzes Tal ausleuchten.
Auf einem hohen Gebäude kann man auch problemlos mehrere Kilometer weit kommen.

Im Innerstädtischen Bereich ohne exponierten Standort kommt man jedoch leider nur wenige hundert Meter weit (immer noch ein Vielfaches von dem, was man über WLAN erreicht).

Durch das 868MHz Band kommt man auch problemlos durch Wände oder in den Keller sofern ein Gateway in der Nähe ist.

Hier mal ein Beispiel für einen guten Standort und der Ausleuchtung


TTN-Mapper Ausleuchtung

2 „Gefällt mir“

Danke, Timo. Das erklärt mir einiges! So ein 15€ ESP32-Selbstbaunode ersetzt wohl kein Gateway, aber wofür ist das?

Ein Gateway kann auf allen Kanälen mit unterschiedlichen Spreadingfaktoren gleichzeitig arbeiten. Durch Kombinationen daraus haben die Gateways dadurch typischerweise 49 Demodulatoren :sunglasses:

Ein „Single Channel Gateway“ kann nur einen Kanal bei einem Spreadingfactor. Das will man einfach nicht haben :wink:

Das TTIG ist mit das kleinste vollwertige Gateway. Darin schlummert nur ein ESP8266/ESP32 aber ein vollwertiger LoRaWAN Empfänger.

Ich betreibe auch ein TTIG. Der „Anschluss“ ans TTN war recht einfach, aber…
die Reichweite.
Das Gateway ist natürlich für Indoor gedacht. Ich habe mal Versuche mit dem Lora-GPS-Modul von ELV gemacht. Enttäuschend.
Jetzt suche ich noch ein preiswertes Gateway, das ich auf dem Dach montieren will, habe aber das richtige noch nicht gefunden.

Das TTiG ist nicht schlecht.
Man kann die Antenne im inneren abmachen und via u.FL Pigtail eine externe Antenne anschließen. Diese dann mit einem kurzen und guten Kabel (H155) aufs Dach gelegt.

Als Antenne macht man mit der LoRaWAN Antenne von MikroTik auch nichts falsch.

Das TTiG ist eigentlich echt gut … natürlich nicht mit der internen Antenne und irgendwo im Gebäude …

Alternativ das MikroTik wAP Lora8. Aber hier am besten auch mit der externen Antenne.

1 „Gefällt mir“

Gute Idee. Das werde ich mal versuchen.

Aber hätte ich das Gehäuse schon ohne Beschädigung auf. :hot_face:
Ergänzung Öffnen bei 3:00
:smiley:

1 „Gefällt mir“

TTig jetzt mit externer Antenne. Wird später event. noch ersetzt.

1 „Gefällt mir“