Standard LoRa TTN Payload Decoder für sensebox:home Temperatur, Feuchte, Feinstaubsensor

[dasLempf]

Moin,

jetzt habe ich die sensebox:home (WiFi, Feinstaub, Temperatur, Luftfeuchte) in Betrieb genommen und an die OpenSenseMap gehängt… Juhu, fliegt…kein Problem!
Leider steht die Station etwas weit im Garten und die Daten kommen nur gelegentlich über
das WiFi Modul rein (im Abstand zwischen 1h und 8h)…

Also LoRa ausprobieren…
TTN Gateway habe ich erfolgreich in Betrieb genommen…
Die Anleitung unter https://sensebox.github.io/books-v2/home/de/komponenten/bees/lora.html
funktioniert auch soweit…
Registierung, Einstellungen, ID’s alles kein Problem…
Die Daten kommen auf dem TTN Server an…

Jetzt muss der Payload ausgewertet werden, um an die openSenseMap
weitergeleitet zu werden.

“…Wichtig: Wenn du den Feinstaubsensor anschließen willst musst du im
Dekodierungs-Profil JSON auswählen…”
“…Ein Beispiel dafür wurde dir oben gezeigt…”
Äh?
Hüstel, hat für diesen doch eigentlichen Standardfall vielleicht jemand schon einen Payload Decoder gebaut?
Auf dem Weg zwischen dem Sensor via TTN zur oSM sind so viele Fehler möglich, dass ich an
dieser Stelle gerne “Jugend forscht” vermeiden würde…

[Jan]

Moinsen @dasLempf,

ja da ist was dran. die LoRa Anwendung ist wirklich nicht so ganz trivial. Wir haben das aber bereits versucht weiter zu vereinfachen. @david hat dazu einen Artikel auf unserer Projektseite verfasst.

Ganz ohne Konfiguration kommt man bei TTN leider nicht aus. Ich vergesse beispielsweise regelmäßig in der Application die Integration zu definieren und wundere mich dann dass nichts ankommt Aber ich denke mit dem Artikel wirst du es bestimmt zum Laufen bekommen!

Grüß dich, Jan

[wdebbaut]

Shönen Abend beide,

auch hier können Sie die richtige Decoder Javascript finden damit alles decodiert werden soll am Moment die Daten von TTN das OsEM Platform erreichen.

(entschuldiging für mein mangelhaftiges Deutsch - ich bin Belgier).

[Jan]

Besten Dank für die Ergänzung @wdebbaut! Schön zu hören dass die belgische Community auch aktiv ist

[david]

Hallo zusammen,

was Jan meint ist, dass man das Decoding komplett umgehen kann.

Einfach bei der Registrierung der Station auf der openSenseMap das Dekodierungs-Profil „senseBox:home“ auswählen.

Danach bei TTN eine HTTP Integration anlegen mit der URL: „https://ttn.opensensemap.org/v1.1“

Einige Minuten warten und schon sind die Daten auf der openSenseMap

Lg,

David

[dasLempf]

Herzlichen Dank für die schnellen Antworten.
Die Projektbeschreibung von @david ist super. Da bleiben keine Fragen offen…
Neue Box registriert, Sketch hochgeladen, Daten kommen auf dem Gateway an…
Jetzt muss ich wohl ein wenig abwarten… der openSenseMap Server scheint aktuell
sehr beschäftigt zu sein…

Grüße Martin

[dasLempf]

wie vermutet kommen die Daten auch an… leider nicht alle… oSM sagt die Daten sind 50 Jahre alt…
1970? Link
unter TTN sehen die Daten so aus:

Muss ich da noch etwas ändern?

Danke!

Grüße
Martin

[wdebbaut]

Moin Martin,

Erlaube mir in English zum antworten weil meine Deutsche Sprache nicht völlig reicht um etwas technisch zu erklären.

Your data of the Sensebox has well arrived at TTN and has been forwarded to OSeM, no doubt. The reason why it is ‘50 years old’, is because the TTN gateway that is in your vicinity, has timestamped it with its UTC time in his metadata and forwarded that time to the TTN network server.
Meaning your gateway’s receiving time was not updated manually by the owner, nor NTP enabled. Be aware that it is not the TTN servers time that is being used when retrieved in the OsEM.

Problem is, you do not know who the owner is of the TTN gateway to ask him to set it right. Maybe have a look in your TTN community to see what gateways are available in your area.
Also the TTNMapper app is handy to see where all gateways are set up in your region.

Hopefully this enlightens a bit the weird time found in the metadata of a TTN gateway (1970 …).

[dasLempf]

Hi @wdebbaut,
the data items at gateway level seem to be correct :

Gateways\Traffic:
{
“gw_id”: “eui-58a0cbfffe801a88”,
“payload”: “QL8uASaAIgIBwlSECmOq8s2q/JKC”,
“f_cnt”: 546,
“lora”: {
“spreading_factor”: 12,
“bandwidth”: 125,
“air_time”: 1482752000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-11-01T09:49:03.467Z”,
“rssi”: -105,
“snr”: 5,
“dev_addr”: “26012EBF”,
“frequency”: 868300000
}

However, if I take a look at the application data something seems to have changed.
For whatever reason it shows a date stamp of year 1970 …

{
“time”: “2019-11-01T10:23:41.374267249Z”,
“frequency”: 868.1,
“modulation”: “LORA”,
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-58a0cbfffe801a88”,
“timestamp”: 80677236,
“time”: “1970-01-01T00:00:01.572603821Z”,
“channel”: 0,
“rssi”: -101,
“snr”: 4.75
}
]
}

The gateway is my own , but it’s a TTN Indoor Gateway

The Things Indoor Gateway

which does not allow any configuration by myself

Do you have any idea how to solve this ?

[wdebbaut]

Hi Martin,

I am afraid you can not do anything to change the timestamps on the TTIG. It is one of those cheap gateways which can only be configured by browser and not by a serial interface.

Also, that cheap gateway does not send its timestamp (just like the more popular lorix one) to the TTN servers, which explains its 1970 timestamp in the metadata.

On top of it, since it has been released four months ago, there are bugs in the actual firmware 2.0.0, e.g. rebooting all the time after the ESP8622 looses its wifi associations; the location not correctly forwarded; etc…

Anyways, I thing you have to wait for a new firmware release that solves these bugs in the actual firmware. For that, you still have to wait for a Github while they still have not published their code.

In the meantime, you can debug yourself to see what is happening once you have opened the case and attach a UART interface with a FTTI device. All this is well documented, but be aware, you void the warranty!

Succes with all of your endeavors and soon we will be deploying our senseboxes, but with other outdoor TTN gateways