@disk91 I might get beaten with the nasty stick here, but I don’t find this V2 > V3 migration really customer friendly. It seems to be written by techies for techies. When it says ‘you might need to reset your node’ I’m thinking: my node is hanging underneath a bridge 200 km’s from here… 
When I look at commercial LoraWan networks, migrations to new versions of the LoraWan stack are fully transparent for existing users.
1 Like
It’s been barely a fortnight so if you can give the techies that speak human some time, we’ll get the documents translated. The TTI team are The Techies in the Underground Bunker, many of us here have been in a bunker but like fresh air & sunshine so we can translate from Bunker to Human. Then a human can have a whiz at it and any issues can be resolved by us or by us translating to pure Techie and passing it on.
Or you can take a cue from Dante and erect a mental “Abandon hope all ye who enter here” over the TTN V3 console.
If you have a reasonably compliant device then there should not be a reason to visit it, if it’s not so bright that it doesn’t notice it’s not on the network, then it will need a visit.
Moving versions from v42.3.5 to v42.4.0 maybe. This is a whole new code & data base with everything they’ve learnt from building V2. There are scripts & procedures to help with the migration already available that are being tuned as people give TTI feedback.
I’m sure if you became a commercial customer they’d ease the way for you.
I am not beating you with the nasty stick, I’m saying if you look at the situation in context of only two weeks active use from a wide range of users & use cases, the progress being made, the fact we get TTN for free & can’t expect old code on old server to be supported forever and your lack of experience with the migration (aka, try it, it may be seamless for you), that forecasting the end of the world is a bit premature.
From my personal perspective as a regular TTN user and contributor I can understand that response.
There is no migration manual that guides TTN users fully through the migration process and documentation and instructions currently available are fragmented and are indeed aimed at techies.
While the migration documentation will be improved it is not yet clear when this will be available.
Commercial networks have paying customers and SLA’s. The TTN community network does not have these which will surely make a difference. Commercial providers will also have strict compliancy rules for end devices on their network (which will make migrations easier).
Last night I managed to successfully migrate. Was having the same issue as mentioned early on in this post. Not sure what changed. I don’t think my V2 gateway received the downlinks during the join initially… Or maybe a latency issue. As of today all successful.
@fullstomp You are a lucky guy, I did not get more success today
@descartes Is that possible to get a feedback like “someone is working on understanding the problem”, There is no emergency to migrate but refreshing post and retrying connection twice on daily basis is a bit disappointing if no one else look at it.
@rharte I’m not really understanding why pinging me… basically I’m trying to migrate to explain the procedure to human
1 Like
I have a vested interest in this so I am working on understanding the challenges of migration - I have all sorts of device formats, both ones I’ve designed and other manufacturers devices that my clients have.
I know, as a moderator that scans the vast majority of posts, that others are working on this.
I know, as a moderator, that TTI are watching but they can’t pull changes out the bag and need to see the scale of the problems to be able to come up with a scheme.
As I keep saying, it’s only been a fortnight, we need to pool resources to work methodically and not come to any conclusions too early.
I have some more tests scheduled for this weekend - when the emails aren’t flowing and the phone doesn’t ring - so I will be re-running my migration tests again then.
1 Like
There were some Packet Broker issues that we resolved yesterday, indeed causing things to delay so badly that the join-accept delays were not being made.
Currently checking offline with @disk91 to see what the issue is. We have tried to replicate but we see consistently successful joins of V3 devices via V2 gateways.
This morning, after upgrading my Laird gateway firmware, the device get connected. I don’t think it is related to the firmware directly (I see no reason as the protocol is the same). But I had to redeclare the gateway in the TTN backend, even in v2. The gateway id changed from laird-disk91-1 to eui-c0ee40… It is possible the ttn servers have also changed (now it is router.eu.thethings.network)
The laird FW version now is Laird Linux gatwick-laird-93.8.5.21 it was 93.7.x previously.
That said ; it means V3 devices could not be able to join V2 infrastructure currently running correctly.
I may have 2 other gateways with same configuration as the one migrated. I’ll make some join try on them to see if we can reproduce. (A bit more complicated to me as these gateways are not at home but deployed)
1 Like
interesting - my first V3 gateway was/is a RAK833 on a Pi3 - it was very variable until I compiled the packet forwarder from the latest version and since then it’s been spot on.
Maybe there is something that V2 could tolerate that’s not acceptable in V3. Another thing to investigate!
1 Like
The other difference is:
- current version uses Semtech UDP (legacy)
- previous version seemed to use the old TTN protocol (before basic station, don’t know how to name it)
Could be the reason why ?!?
Yes, that’s it. We don’t have forwarding to Packet Broker with the long discontinued TTN packet forwarder using the gRPC protocol. We’ll add that to the instructions, thanks, issue found!
1 Like
@johan can you please confirm that my kickstater gateway data is not forwarded from V2 to V3? And as aresult if that, joins will fail?
So basically our kickstarter gateways won’t be able to be connected in V3 anymore ? Is there a firwmare upgrade to support it ?
You are jumping to conclusions. There is a manual on how to connect Kickstarter gateways to V3 so it is extremely unlikely it can’t be connected.
Ok, cool ! thank you for sharing, I’ll upgrade my gateway soon … (… I have a lot to upgrade and all different !! )
Another question to make sure:
Does ttnv3 accepts Semtech Legacy protocol or just Basic Station ?
No, thats not what I said. I have successfully migrated a Kickstarter gateway to V3
Perhaps spend 5 minutes on the documentation site?
The answer is V3 does support the Semtech UDP protocol as well as BasicStation and ttn-gateway-connector protocol. (The last protocol being used by the Kickstarter gateway and by gateways running mp-forwarder.)
1 Like
Can’t confirm, those gateways are also connected to endpoints that are offloading to Packet Broker.
And indeed, you can connect them directly to V3 too.
1 Like
Thank you for your answer
Where did you get the information that mp-forwarder is supported in the documentation ? I was not able to find it and this question is basically the reason of that topic.
https://thethingsindustries.com/docs/gateways/
Found by going to:
Home | The Things Stack for LoRaWAN and typing “packet”
But could have clicked on Gateway icon and, boom, there it is left hand column, second square down.
Maybe worth exploring the micro-site.