Hi everybody, maybe a dummy question sorry in advance… I have setup my RAK gateway, I can join and send data tha’s all good. But now I am wondering how I can allow anyone to benefit from my own gateway? Is there any way to share access? There is a public/private mode I can setup on the sensor side, is there anything I can do to allow anyone having a LORA sensor to beneficiate from my gateway?
thanks
Florent
On the same topic, as a newbee, I’m wondering how to use a public gateway to be used by one of my nodes ?
I have my gateway setup and working at home and I’m now trying to use a node from another place.
Thanks in advance.
Patrice
indeed that would be excellent we can all share and beneficiate from all individual gateway setup here and there all over the planet by makers!
1 Like
By default with your Gateway registered on TTN, it will forward any TTN registered node data. So its already open to everyone.
3 Likes
Thanks for your reply! In that case how to retrieve the data if the external user is not registered on my gateway? From my gatweay with my own sensors I setup a POST method to a dedicated ip address…an external user will have to retrieve his data from where?
When using TTN, you’d use its APIs and/or integrations to handle the data, not some direct POST from a specific gateway. So, it seems you’re not using TTN, which this forum is about? That’s too bad, see https://www.thethingsnetwork.org/forum/t/why-do-you-need-ttn/20040/
On the other hand, https://www.thethingsnetwork.org/u/florentcoste shows you’ve got two gateways connected to TTN?
I use TTN I guess … 
I use HTTP integration from TTN, is there anything wrong if I want to share my access?
Thanks
Okay, the HTTP Integration is not running on your gateway, and is not limited to just a single gateway. Instead, it’s assigned to an application, which will receive data from all TTN gateways that happen to receive your device’s transmissions.
You’re all set then. Any TTN-registered device that is close to your gateway will have its transmissions forwarded to their application.
1 Like
yes you right, I use the TTN http integration (not on my gateway). But if someone external is say passing by my gateway (so not registered), can he take advantage of my gateway to transmit his data back to his end server/database?
1 Like
Yes 100%. I have roamed between hundreds of Gateways in the UK with my GPS nodes for mapping.
OK cheers! So say I have my current sensor already successfully transmitting on my gateway, I travel by other gateways (set as public by other makers) and I shall receive my data also? (I guess I have to make sure to allow public network mode on my sensor)
1 Like
There is no such thing. When you’re using TTN’s community network then your gateway is “public” by definition.
Note that contact details and location might be hidden by an owner, but even then the gateway will just forward all LoRa packets it receives to the network it’s connected to, in this case TTN. TTN will ignore messages sent by devices from other networks, but all devices properly registered with TTN will see their data end up in their application, when received by a gateway that is registered with TTN.
1 Like
OK thanks! I will try this out thanks so much. Indeed what is odd to me is the fact that the device must send a JOIN command prior sending data. With weak coverage, I guess the sensor must detect when it is not any more JOINED to a gateway (especially when moving like a tracker on a car) and send another JOIN command prior sending new data.
No. A join just registers a device with the network, not with a specific gateway. Once joined, it just transmits, regardless if it’s still close to the gateway(s) that were involved in registering with the network, and regardless if those gateway(s) are still operational. It might not even notice that transmissions are not received; it just transmits and hopes that one or more gateways will forward its data to TTN.
Using things like ADR or confirmed uplinks might make it detect that too many transmissions have not been received. But even when that happens, it does not need to join again. Instead, the LoRaWAN stack on the device would then (eventually) lower its SF or increase its transmission power.
See https://www.thethingsnetwork.org/docs/lorawan/ and https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192
2 Likes
Thanks a lot Arjan
I assume that here on TTN you registered your gateway and can open your gateway page here on TTN?
Your gateway is a pass-through towards TTN servers and transparently transmit the data to and from he TTN servers.
Any access from these 3rd party nodes either have a TTN account set up to retrieve/redirect the data on their TTN account towards a cloud where they can sell services and provide apps to get that data without users to have to login TTN.
Only the node communicates to your gateway, but node users should not directly use your gateway IP address. They should use the TTN servers instead.
When you have set up the gateway on your TTN console page, you can also set up applications.
Those applications can then get devices connected to it.
When you register new devices in your new application you will get be able to register ABP or OTAA.
Both ABP and OTAA setup contains special unique keys that every node must be programed for so the TTN servers can redirect your specific node to the specific application.
With ABP you only get data sent from the TTN gateway to your application if the increment counter increase. If you do a firmware update, or when you powered off the node that transmit counter gets set to 0 but the TTN gateway will not redirect the data until it reached the last known counter value.
OTAA has the possibility to register your node automatically after the power went down and you start up the node again. You still need a special key so the TTN servers can match your node to your application. These keys are found when you register your node.
When you set up your gateway, you can also create some code on a server or PC that has a callback registered to TTN servers gets notified that there is new gateway messages, or application messages. So nothing gets stored on TTN, you are responsible to catch that data and store it.
OR you can set up in your application “integrations” that either stores data on this TTN server for 7 days, or redirects it to your cloud severs automatically. In that case you only have to get your data from your e.g. AWS database.
1 Like
Just a quick clarification on following to write:
Is This is a gateway not TTN network server issue. Thus this will true to any 3rd party gateway not just TTN gateway. My understanding was intelligence us build in Lora end node stack and network server. Gateway is just a plain pass-through switch.
Thx
This is not a gateway issue, it is not a TTN issue either. It is a LoRaWAN security feature to prevent replay attacks. Anyone considering it to be an issue should invest a bit more time to study the LoRaWAN specifications.
Understood - thx for clarification, you write up was confusing. I have read the spec and understand.