Can understand your reaction and perspective Johan, but it absolutely IS relevant - if we start hemoeraging users or GW providers in the meantime
(Hi Jeroen BTW!)
myDevices may be dragging their feet but they need to appreciate they risk loosing a lot too - profile and position as a (the?) leading external integration with TTI/TTN, but also just as you may accidentaly be opening door to Helium et al, they may be opening door for other dashboards and integrations. (Several clients I have consulted with and demonstrated TTN+Cayenne to have subsequently gone on to order IoT-In-A-Box type products and they risk loosing that easy customer capture…).
Have been impressed by some of the Conf presentations & Demo’s… would consider testing a few if Cayenne is going to be a headache, especially if they can support LPP so no node changes required, but e.g. Datacake yesterday (Simon?) (and I think another today) talked about generously allowing free registration of just 2 devices… 2 (WTF!)… make it 100 like cayenne and there would be a stampede - great biz opp you may want to pass on! Over time I have seen dozens of sensors/nodes I or potential clients have bought or that were sent to me to try/evaluate/consider and to try an alternate platform like that I would expect to try and load up a couple of each to see what capabilities and how platform performs over (long) time so entry point to a new dashboard/integration platform (for me at least & I know a few others) is start somewhere from say 25-250off for a free/developer/tester tier otherwise may not be worth the effort of committing to learn and evaluate.
Whether owner is public or not, it should at minimum be possible to get in contact with owners, for reasons described. This can be done with a private (email) messaging system similar as used on www.marktplaats.nl where buyers/sellers can send each other messages without knowing the others’ details. This does not require the owner to be public.
Just to be clear: in the context of The Things Network a gateway owner is public already even if only his/her Things ID (aka TTN account name) is published for that gateway.
Effectively that is what we have now - the user contacted by message through TTN Forum or Console message Most names on the system are fake or a user handle vs full name (bluejedi, Jeff-UK?!)
Sort of but not exactly. For V2 when owner was public for a gateway this meant that the TTN account name was public.
When the account name is published the owner’s account is not private anymore.
Making the owner private does not allow you to see to which TTN account a gateway belongs. So this is where the comparison breaks.
Yes, similar to private messages on the forum you do not know who (which person) is behind the TTN Account (unless they added those details to their profile).
But in order to keep owner private, the TTN account name shall not be published/shared for communication about a gateway.
I nudged them again and I heard that my team already did so as well. There’s apparently something in the pipeline. We help platforms to get their webhook templates ready, like we did with Datacake, Ubidots and others. We are not on the critical path.
What I meant in TTN V2 to The Things Stack V3 Transition - #52 by johan above is that we have collaborators (access) and contact information. The latter allows for contacting the person. That may be the owner, it may also be the representative or the person living next to the gateway. It doesn’t have to be the owner, or the funder or the sponsor. That is why we probably need three fields: collaborators (access), contact information (send thanks, ask questions) and owner or sponsor (who paid for it).
Is there anything the (a few!) users need to do to lobby or cajole them that might help your case or is that just noise and hinderance if you think progressing in a timely manner
So far I have the following observations / issues:
A test gateway setup using V3 alongside my old V2 gateway.
A test node that used to live in V2 using ABP moved to V3, when I first moved it I saw packets just fine but now I do not see any packets, the node has ephemeral packet count that does not survive a reboot, is there anyway to disable packet counting? I only see “reset” which I presume resets it to 0 not disable the check entirely. Yes I know really I should care more about packet counting, but thats a different discussion.
A bunch of nodes from V2 using OTAA which I have added to V3, these are out in the field so I don’t really want to remove them from V2 until they are working in V3 due to fear of having to hire a cherry picker. I copied the App EUI, Device EUI and App Session Key from V2, I see no packets for these in the application, the V2 gateway receives the packets fine and the nodes still work fine in V2, the V3 gateway however just says… “Host cluster failed to handle message: No device matches uplink” I presume this is because it doesn’t know the device as it was activated against V2 activation server not V3. How do we transition such devices cleanly?
I have tweaked my decoder code for the new 1 parameter style decoder in V3 for the test node and configured MQTT integration. I setup my MQTT client to use the new hostname, username and API key from V3. The MQTT client says it’s connected and I see the following in the applications data feed “Subscribe application”, however I receive no messages, I guess I have the topic wrong, so I tried a wildcard, again no messages. How do we get MQTT to play nicely? - this one is now fixed, topic changes from APP/devices/+/up to v3/APP@ttn/devices/+/up
Unplugging my V3 gateway I do not always see packets for V3 devices forwarded via the V2 gateway, is the forwarding of packets from V2 to V3 buggy or unreliable?
We deploy a number of TTI Indoor Gateways which we do not have physical access to without requesting so from building owners. When the time comes how do we move these with the BasicStation push config stuff? I heard in the Slack chat it currently only works with TTN V2 despite being network neutral in the product details (feels a bit mis-sold).
When will JP & the community have V3 support in TTN Mapper? Will V3 gateways be flagged as V3 only so V2 users can differentiate coverage based on their needs? For now I am shoving my mapping activities for V3 into InfluxDB, hopefully I can replay these into TTN Mapper later.
Some of this is probably my ignorance, but personally I find this transition messy and with a fair bit of heavy lifting and pitfalls. Hopefully soon we’ll get a for dummies transition guide. Any help before then with the above is greatly appreciated.
Reminder for Windows users of lorawan-stack-migrate CLI should not blindly copy paste from readme.md.
export TTNV2_APP_ID=“abc” should be set TTNV2_APP_ID=abc for example.
I deleted my gateway from V2 (was using the UK Digital Catapult ttn.thingsconnected.net) and recreated the gateway and app in V3 in EU1. The application works, although my gateway shows as disconnected in V3. When I inspect traffic routing for the application it appears the gateway is still connected via V2 with forwarding, although I don’t have any listed. Could this be something to do with the fact I was using Digital Catapult initially? Not sure how to resolve? Please can you help.
That is 50% of the work. On the gateway you need to point it to V3 as well. (For TTIG there will be a use interface to do this later this year)
however the moment you move it to V3 all V2 apps won’t get data. All applications of other TTN community member that rely on your gateway will fail. So for now please do not migrate gateways just yet. Give everyone a chance to move their applications (and devices) first.
The idea that has been discussed between the Forum Mods and core staff it to hopefully amend the TTN Map displays in the future to perhaps colour code to differentiate between V2 & V3 Gateways in same way current vs not seen for a time are also coded (before older items aged off Map if not seen for extended period). With lots of others work to be done this may be awhile. For now a bigger issue is to make user migrating GWs or adding new ones in V3 make sure they still show their gw location and make public otherwise wont be seen at all! Default ( I understand) is currently box unticked…so Please All go share! )
what is best process for migrating TTGW (Kickstarter Gw), once finally ready to lift & shift? I may need to go play with that one to see how best done… area well served by other V2’s so little risk to my or others V2 devices & Apps
Thank you for your reply. This makes more sense now, I thought it would automatically pick up the change when associating. No problem, I guess I can reregister the gateway back in V2 and then build my applications in V3. Thanks again.
Is there a specific order to remove apps/devices after moving to v3? Eg : first : remove API keys, then integrations, then …, then collaborators, or will removing the application delete all that (cascaded delete) ?
Over time I have seen dozens of sensors/nodes I or potential clients have bought or that were sent to me to try/evaluate/consider and to try an alternate platform like that I would expect to try and load up a couple of each to see what capabilities and how platform performs over (long) time so entry point to a new dashboard/integration platform (for me at least & I know a few others) is start somewhere from say 25-250off for a free/developer/tester tier 
Most names on the system are fake or a user handle vs full name (bluejedi, Jeff-UK?!)
what is best process for migrating TTGW (Kickstarter Gw), once finally ready to lift & shift? I may need to go play with that one to see how best done… area well served by other V2’s so little risk to my or others V2 devices & Apps