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…
4 Likes
True, it is almost mandatory…
Helium supports myDevices
2 Likes
Gateway Privacy Settings
In V2:
In V3:
and
Questions
-
Why is ‘Gateway status Public’ default disabled in V3?
-
Why is ‘Publish location’ default disabled in V3?
-
Has option ‘Make owner public’ been removed?
Is owner now private or public?
Status and location need to be public to make the gateway visible on maps so others can check if they are within range of network coverage.
Owner by default should be private.
1 Like
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! 
If status and location are not enabled by default, many (new) users will just not be aware or leave them disabled (‘just because’).
GDPR may play a role here but user is not clearly and explicitly informed about these choices. This will need to be improved in the console.
(Otherwise) we may end up with very empty gateway maps after the migration.
1 Like
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.
We should probably make this enabled by default for public networks, like The Things Network, indeed. I filed an issue: Make default for public gateway status, location and contact info configurable · Issue #3712 · TheThingsNetwork/lorawan-stack · GitHub
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.
What do you think @kschiffer ?
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.
1 Like
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.
2 Likes
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.
2 Likes
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?
2 Likes
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:
- 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
clusterfailed 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.
Best Regards,
Rob
1 Like