Well, ‘Make owner public’ - owner is at least how this has been presented to users the last 4+ years.
The ‘owner’ was previously also displayed in gateway details on The Things Network Map (but not anymore lately).
What was (hacky) owner in V2 then?
Is it just me or is that contradictory (confusing at least) with the previous quote?
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).
Right?
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
how can i issue a “force rejoin” from the community backend to a remote device ?
Yes, if you have any @mydevices.com in your address book, send them an email
This is not in the LoRaWAN 1.0.x spec unfortunately. This will only be possible with 1.1.x devices.
In LoRaWAN 1.0.x, end devices ideally have a link check mechanism and reversion to join mode. Otherwise, you might need to power cycle the device.
This depends entirely on whether your device supports the ability to be remotely rebooted via downlink.
Hello,
So far I have the following observations / issues:
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?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.
Best Regards,
Rob
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) ?