Hate to keep raising problems @johan - guess @Maj will think me a ‘wingeing Pom’ to borrow a cricketing term! - but playing devil’s advocate here and trying to concieve solutions/mitigation strategies… The user may not have control of the GWs or own them, also simply migrating the GW’s to V3 if they do have control simply switches off other V2 users nodes/applications covered by them - not very community spirited
How can we co-ordinate these activities and transitions. Some users - especially many end users - may not even be aware of pending transition and behind the scenes activity and just receive a service or the output from a dashboard integration perhaps on a shared url link… then suddenly one day it stops working/updating…
in @esairq 's case above clearly he didnt get the telegram saying do x before doing y, and likely is only the 1st of many - we need to quickly come up with a very simple (so people like me can do it!) step by step guide and publish it professionally and well signposted or the community is going to get very fragmented & very messy very quickly (and the Forum likely wont be a nice place to be for a while! )
The moderators I’m sure will curate and clean up and guide where they can but this could get overwhelming I fear…
From what I am getting on back channels 3 main issues look to be biggest concern - timing with RO from April even if actual sunset much later - everyone dealing with pandemic and thinking this is too much too quickly. And 2nd is the lack of V2 to V3 dataflow atleast during transition phase…may not be technically possible or a big lift to fix but can something be done before chaos lets loose. Many now getting the transition message and looking far out to sea the Tsunami is already building And that leads to 3rd concern that GW’s that are relied on may switch before users ready/have time/can access nodes to effect change or update…many indeed wont even know if what they have in their hands or have deployed in the field falls into (which) one of the 4 categories of device you called out depending if build or bought of the shelf and if a screwdiver build or s/w compiled themselves etc. They simply may not know where to start!
Whilst we cant cover all the self builds and hacks people have put together & deployed on TTN perhaps we can post a traffic light system for popular off the shelf systems - Green - will transition with no issue, Amber may need a reset (OTA or power cycle) or a minor intervention, some ttnctl cmd line hacking or whatever, Red - oops you’ve got a potential problem/may be stuffed and need to work hard! And apply that to the likes of say (just for examples) Laird RS1xx T&H, Dragino LHT65, ERS-xyz, MCF88-abc, DecentLabs-ghi etc…(Maybe start with labeling the items listed in the TTN/TTI Marketplace?!) That way we can focus efforts and manage by exception/scale of problem…? Perhaps this is something we can recruit the product manufacturers/suppliers into doing?
Instructions appear to be written for migration to thethingsindustries.com.
There is no mentioning of The Things Network or thethings.network URLs.
“Configure V2 CLI
3. Create a file called .ttnctl.yml in your home directory
For Windows users make sure to use the --config flag with the full path to the configuration file: ttnctl.exe --config <fullpath\>/config.yml
The title says “configure V2 CLI” but the config file appears to contain V3 related settings.
Why use a different config file name for Windows? The different name is confusing (only the leading dot should be removed for Windows).
The contents specified for .ttnctl.yml will not work for Windows.
Windows requires backslash (not forward slash) as path separator and the default user folder of a Windows user is C:\Users\<user_name>.
What is folder /home/<user_name>/.ttnctl used for?
Storing data that is internally used by the ttnctl program?
I ran ttnctl on Windows (without first creating a config file due to incomplete instructions). As a result a .ttnctl folder was automatically created in my current folder, which can actually be any folder. This is probably not the preferred way.
One needs to specify <domain_id> in several places.
Nowhere is mentioned what value must be used for <domain_id>.
Can we simply use URL’s like [*.]<domain_id>.thethings.industries and only need to use some <domain_id> specific for The Things Network V3, or do we need completely different URL’s?
This is unclear because the (eu) URL for The Things Network V3 Console is eu1.cloud.thethings.network/console which does not match any of the <domain_id>.thethings.industries URLs specified for the config file.
The config file mentions “handler-id: <domain_id>-handler”.
Is this a V3 handler-id? “Configure V2 CLI” gives the impression it should be a V2 handler and the IDs generated by the command ttnctl discover handler are very different.
Hi @johan, I will be pending when the deployment of nam1 is ready, to start the migration of the devices and gateways here on Colombia, could you explain the effect of RX delay change on the operation of the devices?
The increased RX1 delay will make the downlink path more reliable. If gateways have a high latency backhaul or if you want to have application-layer downlink responses in the RX1 or RX2 window, this will now most likely all work. When devices join The Things Network V3, they will automatically get the new RX1 delay.
Many of our community members are no techies, so they will have many trouble with using a non gui tool like ttnctl. As suggestion, is it possible to make an simple export function in the old V2 console? So the user can click on a few buttons and became as result the json of the choosen devices for importing them in V3.
Ok, that would be easier. The login data is the same when login in V3 as in V2, in that case after the login, the system identifies the user and his applications and devices in V3 and V2 too. With this, it is not possible to list the devices from V2 in the “import” screen in the V3 Console?
Ooops, thats new - and a bit of a show stopper…one of the most used Integrations I suspect and certainly one of my go to’s for a quick demo to potential clients or to show Community users the art of the possible/benefits of LoRaWAN & TTN…
For TTN community connected GW’s default should be status & location public, though I can understand that with e.g EU GDPR owner may now have to be opt-in vs opt out (but not neccessarily in other parts of the world?) - though sure should be there to opt in to as an enabler for community communication and info exchange and also to request help in debugging and checking coverage etc…
Also as a Community Initiator where I see new GW’s pop up in any of the Communities I have set up I often reach out to the owner and invite them to join the local TTN community, if not already a member, as part of the process - if I dont see who the owner is that initiative of Community building breaks!
Gateway location and status is not considered personal data. We may, however, want to add some “circle” and round the exact coordinates, so that it is not exactly clear on which roof the gateway is installed. But I don’t see legal limitations here.
Indeed this is a use case that we should keep supporting. I included this in the issue I linked above.