sensebox / openSenseMap-API

API for opensensemap.org
https://docs.opensensemap.org/
MIT License
48 stars 42 forks source link

opensensemap and TTN #207

Closed wdebbaut closed 1 year ago

wdebbaut commented 4 years ago

At this very moment we are able to integrate our sensebox and TheThingsNetwork thanks to https://sensebox.de/projects/de/2020-01-21-ttn-decoding and https://github.com/sensebox/ttn-osem-integration

The issue I would like to raise is the following. TTN is the public network that started in Amsterdam and is an ever growing community worldwide. But, here at my place in Leuven, there is only one public TTN gateway: the one at home that I build myself. The public network server I use is eu.thethings.network, to which I forward all the packets so that the integration on TTN can send the data to https://ttn.opensensemap.org/v1.1. When someone in OSeM chooses the according JSON profile, the right application ID, the correct TTN Device ID (from the public TTN), all goes well.

BUT. Is there a way to make an integration between OSeM and my private loraWAN network based on the V3 loraWAN stack of TTN? The network server we set up for that matter is reachable on dingnet-v3.q.icts.kuleuven.be. I guess that in OSeM, the option TTN is only meant for the public TTN V2 and not for a private TTN V3, like I have.

As a conclusion : Is there a way to have an integration of OSeM and our private TTN ?

ubergesundheit commented 4 years ago

Hi @wdebbaut

is it possible to forward packets in the private TTN v3 to https://ttn.opensensemap.org/v1.1? If so, have http post payloads changed for v3?

If nothing changed, configure your instance to send your data to the integration URL.

wdebbaut commented 4 years ago

Tnx for answering @ubergesundheit. There is still the possibility to forward our packets to OSeM in the TTN console of the new V3. It is called a Webhook now in V3, and the webhook format in which we send it is still JSON. Our payload formatters are the same as in V2 on the public TTN. Whether the http post payloads are changed in the private TTNv3, is another question that I will further investigate with postman or requestbin. Maybe a webhook is not the same as a HTTP integration? The fact is, it does not function at this very moment. We will keep you posted.

ubergesundheit commented 4 years ago

You could send some messages to a webserver you control to print the json payload (or do it with a service like https://requestbin.com/). Then we can see how to help you :)

noerw commented 4 years ago

The webhook interface seems to be the right place. The payload format sent by TTN is documented here, I can't tell though if it is for API v2 or v3.

The docs changed since I last looked, so I presume it's for v3, and all the fields required for ttn-osem-integration are still provided (app_id, dev_id, payload_raw, payload_fields, port).

wdebbaut commented 4 years ago

That is the problem @noerw ! The payload format in v3 has changed completely when I compare it with v2. In https://requestbin.com/ I notice, e.g. : _{ "end_device_ids": { "device_id": "sensebox-dev", "application_ids": { "application_id": "sensebox-app2" }, "dev_eui": "0010DAA0D2093A67", "join_eui": "70B3D57ED0025685", "dev_addr": "0041D70C" }, "correlation_ids": [ "as:up:01E02WW07T90C3X3SQ58B84T74", "gs:conn:01DZXBPJV1N1ED90SBB6K1WN8X", "gs:uplink:01E02WW00W0PD423A59KZ5WAKP", "ns:uplink:01E02WW00W3AQ87TGSNQYBPHDR", "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01E02WW00WBNKHXEJHCNZANGNJ" ], "received_at": "2020-02-02T12:09:11.674340628Z", "uplink_message": { "session_key_id": "AXABBO/7m9y+41OpexkOUg==", "f_port": 1, "f_cnt": 483, "frm_payload": "d2CuIGGL/P//AAAAGwAJAA==", "decoded_payload": { "5e32e0d4aa1220001dda93b7": 0.9, "5e32e0d4aa1220001dda93b8": 2.7, "5e32e0d4aa1220001dda93b9": 0, "5e32e0d4aa1220001dda93ba": 16777212, "5e32e0d4aa1220001dda93bb": 735.57, "5e32e0d4aa1220001dda93bc": 83.66, "5e32e0d4aa1220001dda93bd": 14.03 }, "rx_metadata": [ { "gateway_ids": { "gateway_id": "dingnet-gw-cbib-n06g-1", "eui": "1DEE05017BEEFB5C" }, "timestamp": 3503806172, "rssi": -115, "channel_rssi": -115, "snr": 7.8, "uplink_token": "CiQKIgoWZGluZ25ldC1ndy1jYmliLW4wNmctMRIIHe4FAXvu+1wQ3K3fhg0=", "channel_index": 3 } ], "settings": { "data_rate": { "lora": { "bandwidth": 125000, "spreading_factor": 9 } }, "data_rate_index": 3, "coding_rate": "4/5", "frequency": "867100000", "timestamp": 3503806172 }, "receivedat": "2020-02-02T12:09:11.452929118Z" } }

It is clear that _app_id, dev_id, payloadraw, payload_fields in the former V2 stack have been changed by new ones (in bold in the example above).

By the way, who is the developper or the one in charge of the OSeM - TTN integration, so I can ask? Thank you for the comment.

mpfeil commented 1 year ago

TTN v3 should work already. Going to close this issue. If there are still problems please open this issue again.