Since the v3.13 update of last week, we can exchange traffic between TTN V2 and The Things Stack Community Edition, both ways. Meaning that you can start migrating your gateways as it won’t impact the coverage of the public network.
Unless someone shouts and says something is broken or discovers an integration related issue it looks like we have green light to migrate our GW’s
It may be prudent to start with one or two each or by co-ordination within communities to test as you go.
We would recommend that migration is undertaken WITHOUT DELETING GW FROM V2 - for now! Just in case you need to roll back whilst resolving any discovered issues.
Also if your GW is a TTIG - HOLD ON V2 FOR NOW! We await formal announcement of CUPS support under TTS(CE) aka TTN V3. We will shout it on the Forum once TTIG migration is a supported option - testing is currenty underway and we will keep you updated under seperate threads/announcements.
Note: One of the roadblocks for myself and others in taking this step has been the lack of Cayenne/myDevices integration OoTB under Webhooks (formerly http integrations) in V3, with this change of guidance it shoud be the case that any V2 Cayenne integrations should continue to work with data fed through V3 GW’s until V2 shutdown (?) reducing risk…anyone interested in Cayenne should start to lobby myDevice hard for an off the shelf V3 integration (TTI have done their bit - it is up to myDevices to step up now).
Did a quick check in between other tasks and yep its there - so quickly added integration to an existing V3 registered Laird RS186 t&h sensor that was used for early V3 tests and is running fine.
However, where I see payload decoded just fine in V3 console:
There is a problem with Cayenne display that I will need to investigate further when I have a few mins (think I have seen this reported previously with an easy fix but damned if I can find quickly now I need it!)
Office/Workbench a bit of a sweatshop but not that bad!
Guess I have no excuses for GW migration now - just have to find time! (And figure out how to get around Covid travel bans…e.g. guess Hamburg GW off limits for now! )
I have migrated v2 gateway to v3 with gateway id, however status is ‘Disconnected’ in V3. The status in V2 is Connected. In V3 live data i coluld see the message:
“The stream connection was lost due to a network error”
I have not activated any devices in V3 as of now. But planning to move all devices currently in V2 to V3. For this purpose as first step I moved the v2 gateway and encountered the error as mentioned. Are you saying by adding a new device to V3 stack may resolve the problem ?please let me know.
Has anyone observed this working in the AU cluster? ie. gateways configured on the V3 community au1 cluster forwarding to apps on the V2 AU/meshed cluster. Doesn’t seem to work for us.
Hi, I have 2 gateways, one on V2 and the the other in V3, and a couple of devices in each.
In the V2 console I see both gateways in the application metadata.
In the V3 console I only see the V3 gateway in the application traffic metadata.
I can take a look in node-red this evening to see if I get both from V3 via MQTT.
For gateways using V3 band plan “Asia 920-923 MHz (used by TTN Australia)”, there is no corresponding band-plan in V2 and packets do not seem to be forwarded. For gateways using the “Asia 920-923 MHz” band plan, this maps to a V2 band plan and works OK. AU915 gateways will probably be fine.
- so quickly added integration to an existing V3 registered Laird RS186 t&h sensor that was used for early V3 tests and is running fine.
)