Move your TTIG to V3: YES!

A couple of tips for anyone struggling to migrate a TTIG that is remotely deployed or difficult to access short term and where you don’t have immediate record of the claiming code - aka the TTIG’s Wi-Fi password.

The code is needed when configuring & commissioning the device and logging on to the device’s MiniHub-80XXXX style WiFi SSID. On 192.168.4.1 local console.

A problem for many- me included - is that the printing of the details on the label is quite small and can easily be misread/mistyped…B & 8 being a classic that catches many out. To get round that as noted in my post above many will use a magnifying glass to read or if lucky will have taken a photo on a smart phone to zoom in for a closer look.

So Tip 1 is check old photo’s to see if by lucky accident you have made a record of the code you can now use for the migration!

Obviously to configure the device you need to have logged into the TTIG’s local console which means a compute device with a browser will have accessed the WiFi using the code.

If you used a Windows PC or Laptop then you can check the devices local WIFi cache of old connections to see if data is still stored and pull code from there. Sadly until Android 10 it is much harder on a stock smartphone and requires 3rd party tools - sometimes side-loaded and on a rooted device (not recommended from security perspective). Usually you need a way to get to the wifi_supplicant.conf file (under root) to extract details from there. Similarly with Apple iPhone, iPad and MAC devices they make life bloody difficult to get to codes you entered…despite the fact you would be the one to enter them, Dho! Though an internet search will lead you to some options where you can use a combination of tools iCloud, Keychain app and a MAC or other options to get some access in some cases with a following wind, god knows why they can’t just do the same as Windows and make the code accessible.

So Tip 2 is look at the historic WiFi cache of any device(s) used to configure the TTIG. If a Windows PC (7,8,10)… should be easy (e.g. go to network/WiFi icon on task bar, select Open Network and Sharing Center (sic), select Manage wireless networks on the controls panel, and you should then see a list of historic connections…scroll down to your MiniHubxxxxx of choice select it and check properties/ security settings where you you should see stared out version of desired WiFi pass code :slight_smile: )

As above if you used Android or Apple devices you may not be so lucky or may have to take risks (rooting/sideloading) or just have to jump through lots of complicated hoops and over hurdles.

As I noted in post above I found around 60% of my TTIG estate from photo archives, sadly when checking WiFi cache on main Laptop PC to try and find any of the remaining TTIG codes just one MiniHub listing appears… for one one where I already had code/photo :frowning: :scream: as I took decision a couple of years back to ‘travel lite’ when doing such in the field configs and usually use an iPad or old (Android 7 or 8) smartphone - a lot easier if up a mast/tower/working at height, and cheaper/safer if dropped!

From now on I will photo each new device label and log on with a Windows device at least once, so I don’t get caught out again. :rocket:

2 Likes

Yeah, we’ll do something about that.

I really appreciate your help @htdvisser. I was able to claim my gateway successfully in V3.

I am not sure how I revoked my own rights in V3, otherwise I would warn others NOT to do the same. I still “owned” the gateway in V2 and retained all my rights there. FYI…I purchased the TTIG gateway new in 2019.

Hallo everybody,

I have problems Claiming my Gateway.
Every time I try to Claim it I just get the Error “Claim authentication code mismatch”.
I used the EUI and the Claim authentication code (WiFi Password) from the label on the Gateway.
The Gateway is still registered in v2.

Every tip is very appreciated .

I guess the only obvious one is double double double check the code on the label and what you post into the console to claim! Personally, I found writing far too small and I know others who find it too easy to mix up certain characters (e.g. B & 8 or 6 & b etc. depending on print quality and font), so my solution was use my smartphone to take a picture of lable and then expand to be sure…as above that then menat I had a record t enable remote claiming! (Result!).

With v3.14.1, we have now introduced the option to claim a gateway that’s already claimed or registered without needing to delete it. :tada:
Here are the instructions:
https://www.thethingsindustries.com/docs/gateways/thethingsindoorgateway/

cc: @descartes

5 Likes

Is an option for claiming a previously deleted gateway (as mentioned earlier) still in the planning?

I guess you can restore the gateway and then claim it …

Indeed we will have to release previously deleted IDs so that they can be reused. I’ll check internally and get back here.

Hi,

thank you for the instructions. I have two TTIG gateways that worked with V2 and I am trying to migrate to V3. I deleted al gateways and applications in v2.

One of the gateways (lets call it #1) worked right away (although it was displayed as disconnected it was receiving packets) . The other (#2) got stuck with fast blinking green led (establishing connection to LNS/Configuring radio)

I have successfully claimed #1 and that solved the problem. It is now connected in the ttn community edition dashboard and it is receiving packets.

I can not succeed in claiming #2. If I delete the gateway as you suggest I get:
gateway EUI AABBCCFFFEDDEE is not registered (error code 5)

  "code": 5,
  "message": "error:pkg/deviceclaimingserver/gateways:gateway_eui_not_registered (gateway EUI `AABBCCFFFEDDEE` is not registered)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/deviceclaimingserver/gateways",
      "name": "gateway_eui_not_registered",
      "message_format": "gateway EUI `{eui}` is not registered",
      "attributes": {
        "eui": " AABBCCFFFEDDEE "
      },
      "correlation_id": "9537be6d84f94f5e8a5252088b481107",
      "code": 5
    }
  ]
}

if I register wit +Add gateway and then try to claim it I get
gateway with EUI AABBCCFFFEDDEE already exists and is not authorized for claiming

I tried to authorize claiming with ttn-lw-cli.exe but that stuff is a bit over my head at the moment.
I get: error:cmd/ttn-lw-cli/commands:unauthenticated (not authenticated with either API key or OAuth access token)

Can you please point me in the right direction. the real eui is CC50E3FFFED88ED0

In all that jumble it’s not clear if you are just claiming because it looks a bit like you are registering then claiming.

Success report:
Did claim my TTIG yesterday. Worked fine over console, no issues. After power-down it blinked weirdly for two minutes, then it was active in V3.

1 Like

That’s not a valid TTIG EUI. All TTIG EUIs start with 58A0CB

EDIT: I guess that was obfuscation on your part. Did you claim the second gateway? You don’t need to delete it to claim it again.

Hi.

I have two TTIG and both are placed in outdoor housing and used as outdoor gateway. I have thrown away the housing and the box with WiFi password. One of the gateways is also very difficult to access (I need whole day to get there). Is there any other option to claim the TTIG in the V3 console? Shouldn’t be the active connected gateway in V2 console with my ownership enough to “claim” ?

Please search the forum for numerous discussions on this matter.

Short answer, no, you need to get the wifi password & EUI, other forum posts for details.

Sadly no not yet.

You would think but not yet the case!

Have several remote units myself waiting to move. Do any of the tips I gave in post above 29 days ago help you? I was able to get site host for a gw over in Hamburg to access unit and take a photo for me and send through…was able to successfully migrate that one Monday night/Tues this week…just waited for 24 hrs after claiming in V3 for it to pick up the latest config vs having to powercycle so minumum impact to functionality :slight_smile:

1 Like

Hi. I have TTIG which was working well in V2 but now I am now lost with migration.

My Gateway EUI is 58a0cbfffe800514.

I was trying to claim the gateway via the web console, but got this error:

"message": "error:pkg/deviceclaimingserver:gateway_not_authorized (gateway with EUI 58A0CBFFFE800514 already exists and is not authorized for claiming)"

OK, I need to authorize it first. So I have installed CLI and tried:

ttn-lw-cli -c ttn-lw-cli.yml gateways claim authorize 58a0cbfffe800514

The result:

INFO	No API Key provided. Creating one
WARN	Finished unary call	{"duration": 0.1463, "error": "rpc error: code = PermissionDenied desc = error:pkg/auth/rights:no_gateway_rights (no rights for gateway `58a0cbfffe800514@ttn`)", "error_correlation_id": "da4477bb6ce44d4e91de60a4ac11eab2", "error_name": "no_gateway_rights", "error_namespace": "pkg/auth/rights", "grpc.method": "CreateAPIKey", "grpc.service": "ttn.lorawan.v3.GatewayAccess", "grpc_code": "PermissionDenied", "namespace": "grpc", "request_id": "450884f0-bed8-4885-a176-a9c3b880e436"}
error:pkg/auth/rights:no_gateway_rights (no rights for gateway `58a0cbfffe800514@ttn`)
    uid=58a0cbfffe800514@ttn
    correlation_id=da4477bb6ce44d4e91de60a4ac11eab2

The CLI works fine as I can list my applications. Maybe the gateway is somehow “lost” (or orphaned) as discussed here. But I did not find any relevant clue to my issue.

Any ideas, please? Thanks.

Is this gateway registered by you or someone else?

Yep, we have been using it in the office for quite some time and I was using it under my account in V2 (user ID hardwario). Thanks.

I tried both. It doesnt work either way.
If I try to claim the gateway before registering (as suggested by htdvisser), the error message tells me:
“listen pal, you can’t do that because the gateway is not registered” (error code 5 as noted above)

By the powers of deduction I try as the error suggests. I register and the claim.
In that case I get: “gateway xxx already exists and is not authorized for claiming”

As I tried to point out I have two ttigs.
The first one I can claim both ways: claiming it before registering, or registering before claiming.
The other one won’t work either way.

The point is that I have two TTIG gateways that show difference in behaviour.
I’m trying to find out what could this difference be based on…