Since this is such a hot topic, I’ll try to consolidate some information here.
Can I migrate TTIGs to The Things Stack Community Edition
Not yet, but the backend infrastructure necessary for this is being tested at the moment.
Why is this taking so long?
The Things Indoor gateway is designed to be a no touch, simple to configure device where the configuration is managed by the server. This makes it ideal for mass deployment and management but that means that there’s complex backend support necessary for this to work.
Do I need to physically access my TTIGs to migrate it?
Nope. TTIGs can be easily migrated directly from the server side.
When available, how can I migrate my TTIG?
TTIGs will be migrated via a process called Gateway Claiming. You will need the EUI and the secret WiFi Password that’s printed on your gateway to claim ownership of your gateways.
You will be able to do this via the CLI initially and the console soon after.
What if I can’t access my gateway and I haven’t noted down the WiFi Password?
We will get back with a mechanism for that as well.
What is the timeline for this?
We are aiming to have TTIG claiming support within the next couple of releases.
When will I know when this is ready?
I will post here in this thread with links to documentation when it’s ready to go .
I have remotely deployed GW’s (my own GW estate and clients/collaborators/friends & family) - inc in other countries (local travel bad enough but with Covid pandemic international access a nightmare/impossible , Some in great locations for coverage but lousy/no phyisical access without long planning ( mast access, large scaffolding or cherry picker needs)… obviously have eui’s but never expected to need WiFi passcode other than logging in locally to configure before deployment…
I’m sure other users may not have immediate access to WiFi code…What now?
Understandable that you can’t provide any hard dates but what does “within the next couple of releases” mean for mere mortals, expressed in weeks or months?
I understand where you are coming from, however for people that have deployed the gateways ‘off site’ this is actually an issue. First we usually don’t have the password, but also anyone with physical access to the gateway can claim it before the owner is able to do so.
Will get harder for those I have registered under clients or other users names where I gave the GW and manage/support but say on TTN console for my personal GW estate where I ‘own’ it and can change GW device details, show location on opposite side of world or even delete it! I can do all that …but cant move V2 to V3?!
Will RS Components receipts do (doesnt show any deveice details!)?.. I didnt get one but how will users who were given a unit at TTN Conf Ams a couple of years back show proof? (no receipts!)
Ooohh Good catch! - Surely ‘Ownership’ through V2 Console should be enough given the power over the device already inherent in that? (I can delete it never to be used again for goodness sake…let alone ‘just’ migrate it )
Thats a logistic can of worms for someone to handle.
Realistically, will anyone on site be bright enough to unplug the device to read the WiFi password and know the EUI and then go on to claim it in the v3 console.
And if they do, then TTI could provide some arbitration to move it over …
Also some embedded (e.g. in enclosures with external ant adaptations!) where I dont want end users playing! (Or having to remove from power sockets to gain access to back etc.)
Give people some technology and they will use it in ways you probably won’t or couldn’t have imagined before. The TTIG is also subject to this.
TTI will probably have to update their mindset about the TTIG accordingly and rethink the “how can I migrate my TTIG” procedure for cases like mentioned above.
Realistically, will anyone on site be bright enough to unplug the device to read the WiFi password and know the EUI and then go on to claim it in the v3 console.
Indeed. Also, if someone can access your gateway, what’s preventing them from just taking it? How is this different from let’s say a Multitech gateway where you need to press the reset button for 29s and it completely factory resets, at which point, you can just take that gateway?
I’ll get back to the case where your gateways are not physically reachable. In the meantime, let’s please wait for that discussion. Please note that other people will find this thread. I want it to be easier for them to be informed about TTIGs and not more complicated. I’ve edited the description to make this clear.
I have the same issues, most IG are located at un-attended sites that are visited very infrequently…
without an easy solution, this will be another big pain…
Suggest that you have a check box in TTN V2 to force migration, to a user V3 account… or in V3 to accept a V2 GW to my account by supplying correct V2 account information. MAKE IT EASY FOR THE USER!
Thanks
aging, TTN needs to consider making it easy for the user and not to do the minimal coding to make it easy on your staff…
This is wholly unfair on the TTI staff who provide you with a whole enterprise level LoRaWAN stack plus the servers plus sysops to look after it for free.
And there is nothing minimal about any of the coding.
This forum serves to provide a discussion about such matters, which is what is going on here. As much as we’d like the TTI staff to moonlight as a jobbing LoRa deployment consultancy, they can’t think of everything.
Just plug it in and it will forward traffic to your V3 applications right now. For the gateway to be visible in V3 you will need to be patient. Might happen anytime soon but also in two months.
.
, Some in great locations for coverage but lousy/no phyisical access without long planning ( mast access, large scaffolding or cherry picker needs)… obviously have eui’s but never expected to need WiFi passcode other than logging in locally to configure before deployment…
)