Someone elseâs finger trouble is nothing to do with the seller.
Do you have a compelling need to have it on v2? If not, leave it be. If yes, you could put your case to TTI on the Slack support channel to see if they could add you as a collaborator to take ownership.
But it should still route for you anyway, youâll just not see traffic on the gateway console.
Turns out the seller had gateway A registered. âJust once, just for testingâ.
So⌠my problem ist fixed, both gateways are now connected to V2.
Thanks for pointing out to me that gateways shouldnât be deleted in TTN. I also discovered the âtransfer ownershipâ link and will use it in the future.
My compelling need is: Iâd like my gateways to show up in the TTNmapper map. And the way I read the beginning of this topic means that the need to be in V2 to do so, at least for now. No?
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.