Building web applications around TTN: how to best store the data

Hi Guys,

I’m currently thinking about an architecture for a web application with following functionality:

  • Generate sensor data charts (up to years) from an environment sensors that I’ve connected to TTN.

I’m aware of Cayenne but I’d like to build my own application.
Currently, I’ve already integrated a couple of RaspberryPis over MQTT witih following architecture:
RPI → internet connection / MQTT → Amazon IoT & DynamoDB → Query Data from a Django server and show it to the User.

I’d like to keep Django, which runs on, as my backend. I have checked and tried the Amazon AWS Api:

I also know the swagger and how to work with it:
Is there any restriction on how often a Request can be send? I didn’t find anything.

I would just like to reach out for your help to check my options for storing and accessing sensor data. How would you do it?

First off, the V2 stack will go away so don’t do too much without checking it’s going to be portable to V3.

I use Data Storage as a backup to HTTP Integration (V2) aka WebHooks (V3). DS gives you the basic data and is stored for up to 7 days but it doesn’t have all the meta data that is useful for checking on signal strength and so forth. So if you have a web server (or even just shared hosting) on the internet, I’d use HTTP/WebHooks with DS as a backup.

Whilst there are no currently enforced restrictions on many of the APIs, there’s no reason with DS to retrieve any more of the data than you’ve already got - so my DS solutions look for the most recent data timestamp and then ask for everything from then onwards. For one desktop solution I do that every 30 minutes and it all runs sweetly.

If you try to use the DS as a data repository, apart from only going back 7 days, you will put a load on the servers - so please please store what you retrieve so you don’t have to go and get it again.

Another option is to run an MQTT client somewhere, which is like sucking data rather than TTN servers blowing the data via HTTP. I prefer HTTP because it doesn’t require a server process that’s ‘different’ - with HTTP you just need a web server, a database and a scripting language. Being very very old, I use Apache, mySQL and PHP, but it could be a Nginx, Couchbase and Python. Or NodeJS and Mongo. Or Go and Cockroach.

@descartes thank you! I think I’ll go for WebHooks (V3) and try to get it integrated in a python framework (thank you for answering my other post)

I’ll keep you posted if I can add some value here.

Ideally choose a scripting language that’s most suited to a web server with a good uptime.

Hiya @ecospph,
If you are comfortable with MQTT then I would suggest you carry on with that. TTN V2 and V3 both work well with MQTT so you shouldn’t have any trouble.
Just get your python MQTT client subscribed to your application/devices (see - read the note at the top for the link to the v3 docs) and then it can feed your DynamoDB or other database of your choice.

Excepting he wants to do WebHooks not MQTT, hence my comment

@descartes and @mark-stanley thank you both guys, I don’t really care whether to use webhooks or MQTT, experimented with both of them previously. Anyways, don’t wanna snip more time from you away before digging more into the API references :).
My biggest worry was porting from v2 to v3 with Gateways and Devices but it seems acceptable and I guess there will not be a things stack release every year like for Javascript :D…hopefully.

The prime consideration with MQTT is you have to have a machine which you have access to the desktop/command line to run it on full time and configure it to do so as a background task / process so that it survives restarts. Which is OK if you are OK with that. The bonus on this is that it gets through typical NAT routers in offices or homes.

Whereas renting a bit of webspace (or even some free space) with a database mostly takes care of itself and isn’t prone to disconnection by cleaners / children / bosses-that-know-better.

I do all five (MQTT on a VPS, MQTT in the office (not cat proof) and web space (free, paid for and VPS).

I actually recommend the free webspace option - some hosting providers give you a bit of space to run a small WordPress setup with only a small amount of outgoing bandwidth when you buy a domain from them - pay for three/five years and you can never forget to pay the bill - unlike a client who recently bounced the VPS rental with their ISP and lost three days of data (which I retrieved via Data Storage).