full integration via TTN api & MQTT

[noerw]

I discovered that it is possible to automate device registration and LoRa-message subscription via APIs provided by TTN. This would free the user from the hassle of registering at 2 services, and keep the configuration state in sync.
The current webhook could still be provided for users with existing TTN applications, sending data via the TTN HTTP Integration.

• ttn-osem-integration has its own TTN app_id, used to manage ALL devices from oSeM
• device management via TTN Application Manager REST API
• subscription to messages via TTN MQTT broker
• TTN node SDK implements clients for those APIs

proposed workflow

1. user provides TTN config at oSeM (decoding profile + options only?)
2. oSeM pushes notification to ttn-osem-integration (or ttn-osem-integration polls for changes)
3. ttn-osem-integration creates new device in TTN
4. ttn-osem-integration subscribes to new device, and decodes as is implemented so far

[noerw]

Possible issue is authentication; how is ensured that only the correct physical LoRa device can submit measurements?
Assuming we choose app_id = 'opensensemap' and dev_id = box._id for all boxes,
these IDs are no secrets, and would allow anybody to submit measurements via LoRa.

idea: set dev_id = box._id + randomSalt()

[ubergesundheit]

The integration is a really good idea! The the random String for identifying the senseBox is also a good idea for the main API

[noerw]

Progress can be found on branch feature/mqtt:

The integration now has its own TTN application, on which devices can be registered.
This registration is done by calling /v1.1/ttndevice/:boxId, which then returns TTN device information for a given box.
This info can then be used to generate a sketch for example.

A subscription to messages from devices that were registered using this route is automatically set up via TTN MQTT broker.

TODOs:

• tests
• generate correct TTN keys. currently they are randomly generated which likely will not work. see https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space
• proper route authentication. currently done via an IP whitelist (i know, right?)