search

PiSupply / IoTLoRaRange

Repository for all of the IoT LoRa Range of Products
65 stars 11 forks source link

Support for The Things Network v3 clusters #30

Open AndrewJSchofield opened 3 years ago

AndrewJSchofield commented 3 years ago

I've been using the Raspberry Pi IoT Gateway HAT with LoRa successfully with The Things Network. I've recently noticed a banner on the TTN web page that says my existing v2 cluster will be shut down in the future and I should migrate to v3. I don't know when that will happen but seemed sensible to investigate.

I've spent a few hours trying to get the configuration for the packet forwarder to work with v3. Once I'd created a v3 gateway on TTN, there was a button to download a global_conf.json file. This looked very similar to the supplied global_conf.json file already on my Pi, with the server information changed. Replacing the global_conf.json file didn't work directly because it's regenerated automatically so my changes were overwritten. A bit of fiddling stopped that from happening, but still the new v3 global_conf.json that I downloaded from TTN didn't do the trick.

Will there be an update to the IoT LoRa gateway SD card image to make it work with TTN v3? With better documentation, I think there's a good chance I could make it work, but I'm confused by the difference between a gateway ID, a gateway EUI, whether I need a TTN v3 gateway API key, and how I would supply it in the config.

Any help would be gratefully received.

ryanteck commented 3 years ago

Hi Andrew,

This is something I'm going to try and look into this week, unfortunately I wasn't given any advance notice this change was going to happen and only found out on Thursday.

I believe that as an initial stop gap measure with just new documentation the current image should work fine with settings changes. I'm going to try and give this a go very shortly as I have a gateway setup on TTN myself that I need to migrate.

Currently however I have seen mixed reports as to when to start migrating gateways, while TTN say ASAP some of the community members are recommending leaving it slightly.

From what I've read Nodes which are upgraded to V3 still work with V2 gateways so these are recommended to be first transitioned which should be an easier process I believe, I'll also try to get our guides upgraded soon.

Then at a slightly later date the Gateway migration is better, as once a gateway is migrated to V3 I believe V2 sensors won't be processed by it.

AndrewJSchofield commented 3 years ago

Hi, I have successfully configured my Arduino nano using the LoRa Shield with v3 and that works fine. I'll keep an eye on this issue for news about the gateway. Thanks, Andrew

HaccasDave commented 3 years ago

Just wondering if there is any more news on this. I want to add a second gateway and a handful more nodes, but don't want to set it all up on TTN v2 only to have to redo it all.

Andrew - Is there anything specific that you did to move over to TTN v3?

Thanks.

bucklevision commented 3 years ago

I'm keen on this too. On top of all of that though I'd love it if you could update the image to being based on Raspian 64 bit, as my pi is not only used as a gateway, but also needs other kit to run too and they all require a 64bit OS.

TheNetStriker commented 3 years ago

I've just managed to connect my gateway to ttn v3. I did the following steps:

After all those steps my gateway connected successfully to the ttn v3 network.

Update: I reverted my gateway back to v2 because my LoRa devices could not join the network anymore. (Messages arrived in the console, but my device did not receive a response for some reason)

ryanbateman commented 3 years ago

I had tried the same as @TheNetStriker with much the same result and am also keen in understanding whether an update is feasible. (Though I have also seen the same wariness and vagueness regarding the updating of gateways, so am not rushed at all.)

bucklevision commented 3 years ago

I ended up building from scratch using the RAK common gateway from git on a 64 bit raspios installation, updating the EUI and packet forwarding server. Seems to be working but I get the odd unexpected dropout, which I can't identify just yet.

There's clearly some care being taken around updating (because deleting a gateway from the V2 console apparently leaves you completely scuppered). TBH it's borderline impossible to navigate the documentation without risk, and for those with existing large networks it looks like a task I'm not sure I'd want to take on, but that's why I wanted to move early while I have no significant risk.

On Mon, 10 May 2021 at 09:11, Ryan Bateman @.***> wrote:

I had tried the same as @TheNetStriker https://github.com/TheNetStriker with much the same result and am also keen in understanding whether an update is feasible. (Though I have also seen the same wariness and vagueness regarding the updating of gateways, so am not rushed at all.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PiSupply/IoTLoRaRange/issues/30#issuecomment-836342139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG56DAHXTHROWWY2A3IURL3TM6IL7ANCNFSM4W3SUSOQ .

jakobfriis commented 3 years ago

I built the software manually, and i cannot get it to connect. The built gateway works fine on TTN v2, but changing the config json files to point to TTN v3, with the API key and new server address does not work

16:37:18 INFO: Downstream data is enabled 16:37:18 INFO: Ghoststream data is disabled 16:37:18 INFO: Radiostream data is enabled 16:37:18 INFO: Statusstream data is enabled 16:37:18 INFO: Beacon is disabled 16:37:18 INFO: Packet logger is disabled 16:37:18 INFO: Flush output after statistic is disabled 16:37:18 INFO: Flush after each line of output is disabled 16:37:18 INFO: Watchdog is disabled 16:37:18 INFO: Contact email configured to "jf@jakobf.dk" 16:37:18 INFO: Description configured to "test" 16:37:18 INFO: [Transports] Initializing protocol for 1 servers 16:37:18 ERROR: [TTN] Connection to server "eu1.cloud.thethings.network" failed, retry in 30 seconds src/ttn_transport.c:371:ttn_connect(): ttn_connect: sleeping() at 0, total 30

{ "gateway_conf": { "gateway_ID": "tinesvej", "contact_email" : "jf@jakobf.dk", "description": "test", "servers": [ { "serv_type": "ttn", "server_address": "eu1.cloud.thethings.network", "serv_gw_id": "3245531135677363", "serv_gw_key": "XXXXXXXXXXXXXXXXXXXX2UEWWWHI3WM2HADII6YWV3S2Q.IIHBS5NUMEE7S3YLWZA7ESQ26O7ZW3YRFHS6RGKJLUASKCEMKZVA", "serv_enabled": true } ], "gps": false, "fake_gps": true, "ref_latitude": 0, "ref_longitude": 0, "ref_altitude": 0, "gps_tty_path":"/dev/serial1" } }

jakobfriis commented 3 years ago

I have it connected now. I downloaded the global_conf.json from TTN v3, and added the serv_gw_key with the generated key. I deleted the local_config.json, to keep the configuration from global_conf.json as used.

ryanbateman commented 3 years ago

Any official update on this?

ptbw commented 3 years ago

Even some guidance on how to manually configure the global_config.json would be useful. I think I followed @jakobfriis method and I have a connection in the std out on the pi but not seeing that status change in the v3 console.

(@jakobfriis could you post your global_config.json without your api key pls.)

Thanks

michal-lusiak commented 3 years ago

@ryanteck Can we please get any update on the migration to The Things Stack Community Edition (v3)?

ptbw commented 3 years ago

It may help some but I have switched to using this method for updating my Gateway to V3. https://github.com/kersing/ttn-resin-gateway-rpi-1

It seems to be working fine with the new ThingsNetwork community edition.

ryanbateman commented 2 years ago

@ptbw Did you need to do any additional configuration/adjustment or did you just follow the instructions on the repo as-is, with Balena Cloud set and all?

ryanbateman commented 2 years ago

FWIW, I managed to get it working using the RAKWireless repo here, following the instructions there regarding standard setup, then downloading the global_conf.json from the v3 console and using that to update the packet forward config.