Assuming you’re not really suggesting to send text (don’t) and use field separators: one could use Cayenne’s LPP Low Power Payload which also has a TTN Arduino library and an integration in TTN Console for quick prototyping. But I don’t like the additional data such solutions need, especially when it’s not prototyping any more. (A two bytes value needs four bytes in LPP. But of course every LoRaWAN message needs a 13 bytes header anyhow, so the increase might be relatively small when not sending many values.)
When administering many nodes, you’ll surely also have other details to keep track of. Like maybe:
- The device hardware version, software version, installation date, battery type
- For devices on a fixed location: coordinates, height (see also below)
- For each sensor in a device: calibration details, measurement intervals to detect broken sensors, serial numbers for warranties
So, I feel it is easy to also administer each node’s sensor setup.
Next, you might be using data from a mix of devices for actual (future) applications, where the very same sensor data is applicable to different use cases, or might even be enriched with third-party data. And when replacing a device you get an unrelated new DevEUI for the very same location, for which you might want to merge the data. Or when moving a device the very same DevEUI might be used for a new unrelated location, in which case you might want to separate measurements.
So I would define a single application in TTN Console and simply have TTN forward the raw data to my own server (say: subscribe using MQTT). I would decode the raw payload in my own code, based on the device details that are stored in my own database, matched with information that is always known for each uplink:
- Device EUI to know which device sent the data (
hardware_serial
in TTN MQTT data)
- Port number if a single device can use multiple formats (like: only including battery level in every Nth message)
Finally, I would always keep the raw measurement data (or the decoded measurement data) so one can improve any conversion formulas at a later time, and recalculate derived values. (Say: when measuring particle matter, temperature and humidity, be sure to always store those actual measurements, rather than only storing some derived indication for air quality.)
All above also allows you to move (some) devices to another network in the future.
For LMiC, the port number is the first parameter in:
LMIC_setTxData2(1, buffer, sizeof(buffer), 0);
In the TTN Arduino library, it’s the last parameter in:
ttn.sendBytes(buffer, sizeof(buffer), 1);
I don’t know for the LoPy. The port number is always included in the data, like for MQTT.
MQTT example
{
"app_id":"arjanvanb-app-1",
"dev_id":"arjanvanb-bb-1",
"hardware_serial":"70B3D5B020035CD1",
"port":2,
"counter":7165,
"payload_raw":"CWUMqw0LDNM=",
"metadata":{
"time":"2017-04-27T10:07:27.207187339Z",
"frequency":868.1,
"modulation":"LORA",
"data_rate":"SF7BW125",
"coding_rate":"4/5",
"gateways":[
{
"gtw_id":"eui-b827ebffff5fe05c",
"timestamp":532315708,
"time":"",
"channel":0,
"rssi":-57,
"snr":9,
"latitude":52.37447,
"longitude":4.63576
},
{
"gtw_id":"eui-5ccf7ff42f1970ec",
"timestamp":1284851361,
"time":"2017-04-27T10:07:26.494026Z",
"channel":0,
"rssi":-49,
"snr":9,
"rf_chain":1,
"latitude":52.374523,
"longitude":4.635771,
"altitude":4
}
]
}
}