TTN - 18.000 enddevices

End Devices (Nodes)
1

Sir

Plans to 2022 is to implement 18.000 enddevices to works with TTN (i am using DRAGINO LoRaWAN gateway);

Can you give to tips about ?

Wich will be the cost to use the TTN service ? I will use their MQTT service to redirect packages to our MQTT server.

We will install about 8 DRAGINO LoRaWAN gateway

We plan to transmit 1 package per day or week!

The package size is 2 bytes.

Wich cooperation / obligation / cost must i have with TTN ?

Give me tips and advices!

Thank you so much!

Miguel Wisintainer

2

It is free as a community service :slight_smile: You might want to consider if you need an SLA around routing - doesnt help with radio capture and I gather SLA limited to point of Data egress so YMMV wrt value of any SLA.

Your obligation if you use TTN - as a community network, is to ensure your GW’s are also open (do not attempt any end device dropping/blocking or traffic shaping, etc.) to others in the surrounding community and to not exceed the TTN FUP however I would note that:

This level of traffic activty per device is well inside the FUP limits and looks on 1st view as idea traffic for use through LoRaWAN & TTN :slight_smile:

Note:

That is a good contribution to the community and is not excessive - many owners run that number or significantly more on TTN - I have >40 registered as my personal fleet, with another 150-200 deployed on behalf or other contributors, collaborators and clients done or directly assisted by me and another 250-300 (at last count) where clients and collaborators have deployed based on what I have spec’d etc. so you are by no means stretching the system :wink:

Any further guidance from the community would likely be dependent on details - what type of nodes (function/manufacturer/DIY etc.) and where in the world. Also IME look to achieve GW coverage redundancy and overlap (a few extra GW’s wont cost much in your context but can deliver great benefit in terms of back up, improved network densification and hence improved data rates/reduced battery fatigue etc.) - a failed GW can have a greater impact otherwise on your nodes ability to deliver data and the overall quality of service c/w most anything else. Also if you have a high density of nodes in an area make sure they are not all starting or updating at the same time (e.g. after a local power cut!) as they may fight each other for service - stagger uplink times, add some degree of timing dither around a chosen update rate etc. What you are looking at is typical of a e.g. a small scale local (say village/town level) LoRaWAN based utility metering application, etc.

3

Interesting number of devices. Can you share for what type of application these will be used?

The more relevant information you (can) share about your case, the better other users will be able to give relevant advice.

The FUP can be found here: TTN Fair Use Policy

4

Jeff-UK
Thanks to the awesome feeback!
And the most important, interval do send the package!
Application: HYDROMETER LECTURES
I will use LOM204, and STM32 + SX1276 module.

5

Hi again!

I will use to those 18000 hydrometer, 18.000 MQTT topics on TTN MQTT;

Is that right ?

6

Why do you need a connection per hydrometer?

How will you be deploying these 18,000 devices?

How will you manage these 18,000 devices on a free service?

What happens if the free service goes off line - what is the impact of not getting data from all these devices?

7

@descartes (Nick)

Why do you need a connection per hydrometer?
Maybe is not necessary, on mqtt i can use #, right ?
Something as
v3/smartcore-dht11-1@ttn/devices/#, right ?

How will you be deploying these 18,000 devices?
We will train a team to that. In february we will put 100 prototypes to test.

How will you manage these 18,000 devices on a free service?
We already have a MQTT BROKER. But…looks that we will have to use your TTN MQTT broker, then we be a MQTT CLIENT (subscribe)

How will you manage these 18,000 devices on a free service?
We could to transmit 1 package each 1 week, or each 3 each days in differents intervals. Data are acumulative inside the end device, no problem if not transmit that time.

We hope to install about 8 Dragino Gateways without community access restrictions.

Nick, can you give us more suggestions ? Tips, thank you!

8

You tell me - think about how you would manage 18,000 connections - that would be 18,000 threads - how many sockets can a computer reasonably support? Where will this data be stored? How will it be accessed / analysed?

Not mine, everyone’s, TTN is a community network.

I was wondering how you will manage 18,000 devices, not what the uplink frequency would be. How will you spread the devices over applications, how will you identify where to go to manage a device, how will you manage failures …

That’s good to hear - as it’s a requirement of TTN that there are no restrictions on the gateway.


Did you manage to get the sleep current on the WISOL module down from 5mA or are you not using batteries?

9

You tell me - think about how you would manage 18,000 connections - that would be 18,000 threads - how many sockets can a computer reasonably support? Where will this data be stored? How will it be accessed / analysed?

"I never implemented a big SERVER but i will advice the team about number of Threads. Our server will SUBSCRIBE (connect) to the TTN MQTT TOPIC and get END DEVICE info when TTN PUBLISH on that TOPIC. Data will be stored in our SERVER."

I was wondering how you will manage 18,000 devices, not what the uplink frequency would be. How will you spread the devices over applications, how will you identify where to go to manage a device, how will you manage failures …

"i hope that the info is here in the TOPIC:
{“end_device_ids”:{“device_id”:“eui-88571dfffeeexxxx”,“application_ids”:{“application_id”:“smartcore-dht11-1”},“dev_eui”:“88571DFFFEEExxxx”,“join_eui”:“0000000000000000”,“dev_addr”:“26xx589F”},“correlation_ids”:[“as:up:01FMQWDSKCVTHMSSW0FKVZAFY8”,“gs:conn:01FMHQJ60T9G456WB6AW07GMA9”,“gs:up:host:01FMHQJ6913P18Y4JQ6MQQRRAD”,“gs:uplink:01FMQWDSCSGWJZTC2VPDAXAGDK”,“ns:uplink:01FMQWDSCTW5KCEAE27PMBYSCT”,“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FMQWDSCT29REC5P3X6DZ01TB”,“rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FMQWDSKCA3ZBGKVS72GV5MCE”],“received_at”:“2021-11-17T21:21:44.046350123Z”,“uplink_message”:{“session_key_id”:“AX0vC2z+LsWKyQDSEcxFMQ==”,“f_port”:1,“f_cnt”:189,“frm_payload”:“MTg4”,“rx_metadata”:[{“gateway_ids”:{“gateway_id”:“a840411bb0544150smartcore”,“eui”:“A840411BBxxxxx150”},“time”:“2021-11-17T21:21:43.660266Z”,“timestamp”:572797164,“rssi”:-65,“channel_rssi”:-65,“snr”:9.8,“uplink_token”:“CicKJQoZYTg0MDQxMWJiMDU0NDE1MHNtYXJ0Y29yZRIIqEBBG7BUQVAQ7OGQkQIaDAjn5NWMBhDG2JaNAyDgs/zq1YAvKgwI5+TVjAYQkLjrugI=”,“channel_index”:6}],“settings”:{“data_rate”:{“lora”:{“bandwidth”:125000,“spreading_factor”:7}},“coding_rate”:“4/5”,“frequency”:“918000000”,“timestamp”:572797164,“time”:“2021-11-17T21:21:43.660266Z”},“received_at”:“2021-11-17T21:21:43.834670412Z”,“confirmed”:true,“consumed_airtime”:“0.051456s”,“network_ids”:{“net_id”:“000013”,“tenant_id”:“ttn”,“cluster_id”:“ttn-au1”}}}"

If fail transmition, wait for a new transmition…data is acumulative!

Did you manage to get the sleep current on the WISOL module down from 5mA or are you not using batteries?

"yes, about 20uA sleep, sleeping during 3/7 weeks, then wake up to transmit! yes, using Battery!

Because we are using too a HALL detector!

10

v3/smartcore-dht11-1@ttn/devices/#
Using this way, will subscribe to all devices right ? 18.000 threads in my side ? (MQTT CLIENT)
will my client side (MQTT CLIENT) have problem ? The 18.000 LOM204 wont transmit in the same time.
In this example, the MQTT FX i am receiving data of two LOM204, then i got 2 mqtt events
image
What should be the worst case ?

11

If your 18000 end devices transmit once per day, that’s about one message every 4.8 seconds on average. You don’t need 18000 connections or threads for that. I think it can probably be handled by a single MQTT client, simply subscribed to all devices of the application, with a topic like “v3/+/devices/+/up”, where the first “+” is a wildcard for the application id (the one you used as login credential for the MQTT server) and the second “+” is a wildcard for the device id.

You can manage devices using the TTN console: https://console.cloud.thethings.network/ The TTN console is basically a front-end for various APIs that TTN expose to manage devices, applications, gateways. You could also write your own application that talks to the API, e.g. to do bulk operations on devices.

12

Hello Bertrik

Exactly this was my plan from beginning! Yes i did some changes on TOPIC SUBSCRIBE to use the # (wildcard)

“Our compromisse is to open all our Gateways to communitity”

Btw, is the some API to

I will report here the progress! Thank you Bertrik and Nick!

13

As I said before, this isn’t appropriate thinking - it’s not a compromise, it’s what’s expected if you use TTN.

Really? What was this then:

and

I’m also wondering how the management of devices will go with 18,000 in one application …

I think it would help @Smartcore more if they concentrate on the 100 device trial and not try to plan for the 18,000 devices until they’ve transitioned from 100 to 1,000 and start to get a sense of the scale of the issue, what needs to be known & tested so it’s not venturing an idea with a question mark on here.

If the project has a community benefit, it would be a shame to have it come unstuck with a roll out until the wrinkles have been discovered.

I’m curious as to what needs humidity readings only once a week …

14

“18.000 MQTT topics on TTN MQTT”
my fault put this TITLE make misunderstood, sorry!

“I think it would help @Smartcore more if they concentrate on the 100 device trial and not try to plan for the 18,000 devices until they’ve transitioned from 100 to 1,000 and start to get a sense of the scale of the issue, what needs to be known & tested so it’s not venturing an idea with a question mark on here.”

Yes, i agree!

“I’m curious as to what needs humidity readings only once a week …”

It will not Humidity, my client had created the Application-Id name with “DHT11” text, but it will not Humidity, fault him.

It will measure acumulative data.

Thank you again!