Receiving messages from more than 1 application

We are working to build support for The Things Network in our service, Triggi. Our aim would be to allow any TTN user (what I now define as “anyone who owns some ‘application’, or otherwise has access to the data coming from an application”) can easily make rules to do something with the data coming from their TTN devices, possibly combined with data from any other of the channels supported by Triggi. A very simple use-case would be for example to store all received values from some TTN-connected sensor into a google sheet. But of course there are many other things you could do.
I have a few questions about this.

  1. What would be the best way to let TTN users link their data with Triggi? What I have in mind right now is that they would add their applications to their Triggi profile, by providing us with the application ID and an access key for each of the applications they want to work with. This means that anyone who knows the relevant information for an application, can use the data from it. So for example, if some organization puts a bunch of sensors in some area and wants to expose the readings from those sensors, they’d provide the application ID and an access key to anyone interested.
    Do you guys think this is the right way to go?
    Another way would be to have some Oauth-based account coupling. but this would
    A) require TTN to provide an oauth-login screen, plus application key & secret, to parties such as us
    B) that you only get access to your own applications - it would not facilitate sharing ‘public’ applications

  2. What would be an efficient way to receive events from many (or all) applications? The straight-forward way would be to set up many mqtt connections, each with the credentials of one of the applications. But this would be very inefficient for both sides.
    So then the question is - is it possible to receive events related to more than 1 application on 1 mqtt connection? (we don’t need them to be decoded, as we can access the security keys using the application credentials). From what I’ve seen, if I connect to mqtt using the credentials that belong to a specific app, it only exposes messages related to that app.

Any help or insights would be greatly appreciated!

  1. I think building this as an “integration” would be best. If you go to the “Integrations” tab in your application on the console, you should definitely check out the “HTTP Integration” that simply does a HTTP POST to a remote URL.

1A) Send an email to johan@thethingsnetwork.org and we’ll see if we can arrange this.

1B) There is no such thing as public applications. Application owners have to actively enable sharing of data.

  1. We are looking at more efficient ways, but for now this is the way to go

Hi Hylke,
Thanks for your insights. I’ve also looked into building it as an integration, or just use the existing HTTP integration (as it would already give us almost everything we need, except for device discovery). However that would still require the ‘application owner’ to set up such an integration for every individual that would want to use the application. And I do think that, even though the concept of ‘public application’ doesn’t actually exist [yet], it would be a very interesting case to explore.

For example, I’m thinking about the ‘The Next Web’ conference in Amsterdam next week. There is said to be a huge array of sensors of all sorts that will be installed, exposing their values through TTN. It is the intention that many people will make all kinds of hacks with those sensors, so they will need access to their data. If the application owner will just create and share one access key for this purpose, it would make it very easy for all participants to get the readings. The application owner can even decide to revoke that key after the event.

Similar use-cases can be thought of for cities, companies or enthusiasts looking to expose some collections of sensors. This is basically why I think it makes sense to link at the application level, without actually needing to be the owner of the application.