How to migrate TTIG to v3 cluster

[pierrot10]

Hello

I am a bit afraid because an pilot experience to monitor the bud temperature (spring froze) is starting very soon. I am using the v2 cluster and I noticed is going to shutdown soon.

Is there a date? A delay to migrate?

Actually, I am using one application for two vineyard field, but I would like now to create one application by field, then I will need to create two application. I wonder if it is time to migrate and doing all in v3 cluster.

But my action should not stop my measure (for one day, it’s OK), so it’s bit critial.
Second issue, all of my devises and the gateway are in the fields.

I login to v3 cluster and try to create a new gateway to register the gateway which is in the field.
That action will not give troubles to gateway register in v2 cluster?

The step to register a gateway in v3 cluster is a bit different (it look like)

Following the above image, in v3 cluster, I am not sure what I have to enter in Gateway ID and Gateway EUI fields

a Gateway ID is an unique, human-readable identifier for your gateway
A Gateway EUI is a 64 bit extended unique identifier for your gateway

But in my above image, the Gateway ID contain the EUI 64 bit code

In v3 cluster, I supposed, I should give a gateway ID, as TTIG-1
and in the Gateway EUI field, I should copy the id eui-58…?

If now, I want to continue the migration.

• I create two new applications, one for year field
• I create all devises. 7 in the application 1, 5 in the application
• I go to the field, and update the devise software with the key
• Then, I can delete the devise and application in v2 cluster with may a couple of hour with an interruption of service.

For now my concern is to migrate ma TTIG and TTOG, and my personnal gateway gateways

Many thanks for your clarification. I am afraid making a issue now as the projet is running

[robputt796]

Please see

The Things Indoor Gateway migration V2 to V3

Hi, how can I migrate my “The Things Indoor Gateway” from V2 to V3? Kind regards Marco

Availability of V3 compatible TTIG

@descartes When we bought the TTIG gateways did we not get promised “Can connect to any network backend of choice.”? It even says it in the product information - https://www.thethingsnetwork.org/docs/gateways/thethingsindoor/index.html. It turns out we indeed cannot join it to any network backend of choice. Also your idea about paying for it is interesting, as we have already paid for the gateways and where promised network portability, unfortunately it is stuck on TTN V2 due to the feature not…

TTN V2 to V3 migration

Packet Broker currently routes traffic from gateways connected to The Things Network V2 to V3. That is, gateway coverage of V2 is available in V3. But not the other way around : gateways already connected directly to V3 will not be available for applications in V2. As a friendly request, both as a user of TTN and as the maintainer of TTN Mapper, please keep your gateways on TTNv2, until as late as possible. People in your city that have not yet migrated their application from v2 to v3 will…

or the TLDR:

• No it doesn’t support V3 yet.
• Yes it’s coming
• We don’t know when
• Migrate gateways last

[pierrot10]

May be let me ask you a addtional question about strategy.
My project is to measure bud temparture in two wineyard and later more.
For now in TTN console, I have created one application with an HTTP intregartion pointing to a PHP files. That’s work fine.
Would it be a good idea to create two applications (on application by winyard) pointing to the same PHP files? My “worry” is if later a wine owner stop the project, I could delete the application without affecting the othe wine owner. Also, I could detect from which application the measures are collected.

[pierrot10]

@robputt796

• No it doesn’t support V3 yet.
• Yes it’s coming
• We don’t know when
• Migrate gateways last

Ok thank, then I will not migrate yet, but after the experiment, in may or june 2021

[robputt796]

Hi @pierrot10,

Just seen you additional post about multi tenancy, V3 has support for organisations which allows you to group tenants and their devices, they can of course use the same HTTP integration.

Other stuff you should plan for in V2 to V3 migration include:

• For OTAA devices they need to rejoin, some devices do this automatically, others need a restart, you may be wandering between the vines.
• The decoder script format changes from from function decoder(bytes, port) to function decodeUplink(input) where bytes and port and a whole bunch of other data are child objects of the input object.

Until then the best way to segregate tenants is probably having separate applications in V2 and adding collaborators from each tenant to the application.

However in this use case it sounds like your end user are non techies and more about growing grapes so I would argue they should not need TTN access at all and instead should just have some friendly web portal where they can see their data and be abstracted from the tech. Just my thoughts.

Best Regards,

Rob

[pierrot10]

However in this use case it sounds like your end user are non techies and more about growing grapes so I would argue they should not need TTN access at all and instead should just have some friendly web portal where they can see their data and be abstracted from the tech. Just my thoughts.

Hello, yes that’s correct

That question come into my mind, because I am using a Jeedom box with MQTT to generate an alarm when a temprature is below a limit.

All of the measures are sent to a MySQL via TTN and I provide a web application to see the graph of the temperatures.

But to generate the alarm, I chose jeedom. With MQTT, I can read the message sent to TTN. That’s work a bit in parallel. But the advantage, I can send a Telegram message and the wine owner can validate the alarm. Additionally, when a alarm “ring”, the domotic will allow me to ring a siren, or turn on a gyrophare ot the light of the wine domain.

That question, about one or two application by wineyard, come into my mind, because (from Jeedom) I can not detect from which wineyard the message are collected and receive via MQTT. I could update the station, adding a new parameter to identify the field, but I want to keep the messages as short as possible.

As in TTN payload, I can read ‘dev_id’, I could create to application, one for each field

{“dev_id”:“wineyard-1”}
{“dev_id”:“wineyrad-2”}

I beleive that a good idea, specialy if the one owner leave the project.

I am checking my existing application in v2 cluster, and I observed, the Process ID of the HTTP integration , has the name as my application. I beleive the dev_id value is the name of your application and NOT the name of the Process ID of the HTTP integration?

PS: For now the user will not have access to TTN console. They will not understand, as I do not understand wine, excepted in a glass

Cheers and have a nice day.

[MicroKedas]

Can I now move my TTIG-868? how long?
since I need to move it together with my devices if I want coverage

[Jeff-UK]

@MicroKedas

since I need to move it together with my devices if I want coverage

Not yet - will be announced with a big fanfare on the Forum I’m sure when finally happens…

No you dont! You can start moving your devices now and move the GW later when ready (are there no other V2 GW’s near you also? ) V2 GW’s will pass data to your migrated V3 devices and applications via the PacketBroker. The only fly in the ointment right now with that arrangeent is PB strips the receiving GW ID from the data on the way through so if your application is somehow dependent on knowing the GW ID then hold those applications back for now (e.g. a V2 GW Canary node cant use V3 yet without additional hasles and tinkering with s/w as PB removes the ID - unless you know for certain that yours is the only GW in range (some may be marked as private and not show on the map…)

[remcoploeg]

I removed my TTIG from v2 (deleted) and added it in v3 (together with a reset of the TTIG). But it stays disconnected for a while now. Is this normal or does TTIG still not support the V3 stack?

[descartes (Nick McCloud)]

@remcoploeg

Is this normal

Yes, totally normal - and it will stay disconnected as v3 does not yet support TTIG. That is the current normal.

And by deleting it from v2, despite the warnings on the console and on here, you are a bit stuck.

[kersing (Jac Kersing)]

@remcoploeg

I removed my TTIG from v2 (deleted) and added it in v3

Welcome to the vast horde of people that don’t bother to read. The messages above yours clearly state TTIG is not V3 ready yet.
Also while deleting the gateway from V2 you will have gotten a warning that you’re unable to add the gateway back to V2. So basically you now have a gateway where you can’t access its traffic in any console. You will have to wait for TTIG to become ready for V3. (The gateway will still forward traffic, so keep it connected)

If I sound harsh, consider how many messages regarding this subject have been posted that you choose not to take into account,

[kersing (Jac Kersing)]

In the hopes to have at least one person not make the same mistake multiple users already made:

TTIG is not ready for V3 yet. Do not attempt to migrate.

This message will ne updated when you can migrate, don’t attempt before.

Do not delete your TTIG from V2 as you won’t be able to add it once it has been deleted!

[thomas_leuchtkultur]

I did the same error now… as the new v3 console was now standard on the website and the old could not be accessed by the website directly. Additionaly it gives a message that v2 will be switched off soon and that users should migrate now.

This is all very confusing for new users. Sorry to say this.
But as it still works and recieves messages also in v2 its not so important.

[mono (モノ)]

Have a look here. This solution vor V3 is working with my TTIG: https://www.thethingsnetwork.org/forum/t/move-your-ttig-to-v3-yes