One possible problem is V2 Application support will stagnate/wither on the vine as new V3 GW’s deploy they wont help coverage for V2 applications, and existing V2 GWs that get migrate to V3 will stop servicing V2 devices/applications - even if they historically did so. Coverage for V2 devices/apps will therefore decline and already deployed devices will in many cases stop working!.
Message appears therefore to be deploy no new V2 devices or apps… the network has just been Osborned!
I understand the potential coverage issue that may occur when migrating gateways now from V2 to V3.
What is highly advised is to migrate devices as soon as possible to V3. Gateway coverage is already there. We support all application level integrations as we do in V2, including storage API, MQTT and webhooks.
Then, if your device has a mechanism to detect link loss (missed acks, missed ADR acks, link check misses etc), it will revert to join mode and join automatically on V3.
So the order would be:
Create applications now on V3 and adapt your application to the new payload formats etc. Few changes, but all minor
Activation by personalization (ABP) devices, i.e. devices that have a fixed DevAddr and session keys, are personalized for a specific network, in this case, The Things Network V2. You should consider V3 as a new network. So if you want to keep using ABP and you cannot use over-the-air activation (OTAA), it is highly recommended to create a new ABP device in V3 and reconfigure the device with the new session. Note that the (default) RX1 delay has changed from 1 to 5 seconds.
Ok so during the conf a user opens his/her TTN Console page (the current ‘public’ face & most used start point for users?), goes to Applications - add new application - will that automatically be in V3 now or will it still be V2?
We need this to be V3 ASAP if we are not to then orphan devices & apps starting now (that also create a big workload revisiting apps and devices to migrate). Going OTAA ok - but if devices dont restart (for a long time - given one feature called out for devices on LoRa is long battery life ) then they will likely be abandoned if not economic to make field visits to ‘fix’…
V3 is available now, but the default Console is still V2 indeed. We need to put a banner there. Also we need to show the cluster overview on thethingsnetwork.org so that it is clear what the host names are and where to go. There’s still quite some work to do on our side.
As said in the keynote, V2 will become readonly from April. So from then, it will not be possible anymore to add new applications and gateways. By then, we should have the right navigation and user experience in place to make sure that people go to the right place. That also means that by then, we need to have nam1 and au1 deployed, and potentially one is Asia Pacific too.
Thanks for clarifying/confirming Johan. Looks like its the apps/devices that is the killer for now given existing V2->V3 routing for GW’s already seem sorted (with packetbroker ) I will hold new device/app deployment for a few days/weeks where I can whilst matters settle and use as excuse to force myself to look deeper into V3 (was hoping that migration would be a ~Q2 task but given April timing that accelerates matters from last Mods heads up!).
Please do amend Console Apps page to forewarn users with a Use V3 Banner ASAP as I can see much nashing of teeth ahead!
Regarding Packer Broker peering:
I understand that TTN gateways (V2 and V3) are already sending traffic to TTI devices.
Are also TTI gateways routing traffic to TTN V3 devices?
Hello, what is the workaround on eu1.cloud.thethings.network for a blank screen after login? I have tried changing my password and used Chrome on Windows and FF on Ubuntu, with standard security settings.
btw: I don’t get a blank screen (on oauth url) with our private instance of V3, login works as expected.
That depends on the customer. Some do, some don’t. The basic rule is that there needs to be some balance; we don’t want leeching. For now, we show them the benefit of TTN coverage, and tell them that it doesn’t cost anything to allow offload (uplink) traffic back to TTN. Now, whether downlink will be supported is another issue. We support downlink prioritization in V3, so private TTI networks may support downlink but only if they have capacity left. We’ll see!
We are working on a fix that will be deployed shortly. cc @bafonins
How should we move “The Things Indoor Gateways” from V2 to V3?
The FAQ from the Gateway say:
Q. I want to delete and re-create (re-register) TTIG. Can I do that?
This is definitely not recommended since you cannot recreate a gateway with the same EUI on the same network. We do this to prevent violation of uniqueness on the EUI.
Do not delete at this time. Looks like no rush to migrate such GW’s yet as the data is being forwarded through to V3 infrastructure back end already Another good thing to do at time of migration is upgrade GW’s to using BasicStation - but the TTIG is already running that so no immediate imperative…
This is fundamental for the migration to be successful.
Does any of the popular stacks support detecting the need for a rejoin automatically? In particular, I assume most LMIC nodes do not do that.
There’s also the mention of migrate while keeping the security session but that breaks the suggested strategy of migrating apps first and gateways later, because keeping the security session only works if gateways are v3.
This is also what I’m unsure of, and I’d love to know what the community thinks. Unfortunately there’s no “LoRaWAN stack” indicator in the join-request message; we have no statistics about this.
Yep. Even if we were routing traffic back from V3 to V2, we wouldn’t make the RX1 delay of 1 second that is used in V2. Gateways would really need to be connected to the cluster where the end device is, to make that short roundtrip.
Also we discussed this internally again today, and what’s also going to be super helpful is a gateway map that shows to which cluster (and version) the gateway is connected.
For now, it’s not necessary to migrate gateways from V2 to V3, so I would suggest waiting with that. New gateways can go to V3 though.
@Johan, thinking further on this today if a device and associated app are migrated to V3 will it break any associated integration(s) done in V2. e.g. if a temp sensor has been running for say 2 years dumping data to something like Cayenne for presentation and showing historic trends/analysis will the same device and application on V3 then continue to show in the dashboard or will there be a whole other set of migrations and restarts/reconfigs needed on associated integrations (poss doubling migration workload?) I know of users where they are not so interested in hour by hour changes but look at long term averaging and month by month or even qtr by qtr or seanally adjusted changes to understand what is happening. A sudden break and start again from no data from historic context would be an issue - think land slip monitoring, water-table or climate change analysis, long term performance of solar panel monitoring, etc.
Is the change of the RX delay also relevant for OTAA devices? I´m having problems with my first device / application in V3 and think it might be because the device gets no downlink.
) then they will likely be abandoned if not economic to make field visits to ‘fix’…
) I will hold new device/app deployment for a few days/weeks where I can whilst matters settle and use as excuse to force myself to look deeper into V3 