This is indeed a real issue. The reason why all gateway coverage of V2 is available in V3, is really to remove the immediate need to reconfigure gateways. There is no reason now to migrate gateways.
If we need to clarify this further, I’m happy to do so, and I’d like to know in which way you suggest.
The increased RX1 delay will make the downlink path more reliable. If gateways have a high latency backhaul or if you want to have application-layer downlink responses in the RX1 or RX2 window, this will now most likely all work. When devices join The Things Network V3, they will automatically get the new RX1 delay.
I just migrated a device (RAK7200 GPS tracker) with LPP data format from v2 to v3 stack.
Unfortunately I cannot find the myDevices(Cayenne) integration.
Many of our community members are no techies, so they will have many trouble with using a non gui tool like ttnctl. As suggestion, is it possible to make an simple export function in the old V2 console? So the user can click on a few buttons and became as result the json of the choosen devices for importing them in V3.
They’re scheduled for early February. We’re gonna closely watch the eu1 cluster next week and tag a 3.11 release, so we can go ahead with the other clusters.
myDevices unfortunately does not support the V3 webhook format. These are minimal changes. I’ll contact them again to add support.
It’s a good suggestion, but the V2 Console is really EOL.
We might still find away to add an “import” screen in the V3 Console where you can enter your V2 application ID, access key and potentially list of devices.
Ok, that would be easier. The login data is the same when login in V3 as in V2, in that case after the login, the system identifies the user and his applications and devices in V3 and V2 too. With this, it is not possible to list the devices from V2 in the “import” screen in the V3 Console?
Ooops, thats new - and a bit of a show stopper…one of the most used Integrations I suspect and certainly one of my go to’s for a quick demo to potential clients or to show Community users the art of the possible/benefits of LoRaWAN & TTN…
For TTN community connected GW’s default should be status & location public, though I can understand that with e.g EU GDPR owner may now have to be opt-in vs opt out (but not neccessarily in other parts of the world?) - though sure should be there to opt in to as an enabler for community communication and info exchange and also to request help in debugging and checking coverage etc…
Also as a Community Initiator where I see new GW’s pop up in any of the Communities I have set up I often reach out to the owner and invite them to join the local TTN community, if not already a member, as part of the process - if I dont see who the owner is that initiative of Community building breaks!
Well that’s great for Helium but that’s completely irrelevant.
Like I said, myDevices doesn’t support The Things Stack V3, and I will notify them again on the importance of being able to process data from The Things Stack V3.
There’s really no such thing as an owner. This was already the case with V2, but that was a bit hacky. There are collaborators only, and those can be users or organizations.
So we have two things now:
Collaborators: users and orgs that have access
Contact information: name, email and phone, that can be public or private
The third thing we may want to add here is the owner, or the sponsor in terms of TTN, which could be a user or an org.
Gateway location and status is not considered personal data. We may, however, want to add some “circle” and round the exact coordinates, so that it is not exactly clear on which roof the gateway is installed. But I don’t see legal limitations here.
Indeed this is a use case that we should keep supporting. I included this in the issue I linked above.
That can simply be the GW deployers choice - do they want to show actual placement or do they want to ‘place’ it a bit away on the map. I already do that for most of mine - the position I post when setting up can be anywhere from 20-150 away (think a couple are actually nearer 250-300m from site proper as too easy to guess otherwise!) from actual - especially for security reasons - dont want som tea-leaf (theif!) using the map to pin point valuable goodies and go steal - especially those in remote or more public areas or little visited sites (otherwise have to start loading security costs). No need for system to ‘dither’ location as user makes choice at time of set up…
Also
Absolutely should have some mechanism for declaring that - as legally and for insurance may need to be able to contact the ‘responsible’ owner…what if the device is defective and starts causing interference, or is associated with an ‘insured event’ we must have a way to find out who is owner and how to reach them (legislation may of course vary around the world!)
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.