At the moment I have separate applications set up for each type of sensor. They send different types of payloads depending on the sensor, therefore requiring different payload decoding. Is there a way to choose certain payload decoders for different sensors within the same application? In other words, would I be able to combine my applications into one, and have the decoder determine each sensor before decoding it?
You could use different ports for different payloads to determine which decoder to use.
2 Likes
You could use Cayenne LPP 2.0 protocol.
I have experienced the same situation, when sometimes a device has a different sensor configuration. In the decoder I do some checks based on message length. For example, if message is 9 bytes or longer, we read the GPS coördinates from the first 9 bytes, and if the message length is 40 bytes, I know there is some dB audio info I can read from the last few bytes.
2 Likes
Dear Navaska,
This is what Cayenne LLP protocol is for. Each sensor has a type and a port, and art the other end you can then determine what dat came from what sensor. This means that in one payload you can have multiple sensor data, and even ( for example ) two temperature sensors. There is a data overhead using Cayenne, b ut it has been specifically designed for small payload data transmission.
I would add that I found the CayenneLPP very easy to use.
I built a GPS tracker and decided to add a temperature sensor as device 2, building the code was easy;
//channel 1
loraData[0] = 0x01;
loraData[1] = LPP_GPS;
loraData[2] = lat >> 16;
loraData[3] = lat >> 8;
loraData[4] = lat;
loraData[5] = lon >> 16;
loraData[6] = lon >> 8;
loraData[7] = lon;
loraData[8] = altitudeGPS >> 16;
loraData[9] = altitudeGPS >> 8;
loraData[10] = altitudeGPS;
//channel 2
loraData[11] = 0x02;
loraData[12] = LPP_TEMPERATURE;
loraData[13] = temp >> 8;
loraData[14] = temp;
And using CayenneLPP does avoid the use of voodoo json code in the payload decoder …
3 Likes
See also How to best write an application that contains many nodes with different measure data types (also explaining how to set the port number in some libraries, or how to use the DevEUI which is not available in a Payload Format, but is exposed by other APIs).
And some examples:
-
A Decoder for the Zane Ztrack, using the LoRaWAN port number, hence adding no extra overhead.
-
ESP32-Paxcounter, using both the LoRaWAN port number and the message length for fixed-order but variable-length payloads, adding no extra overhead.
-
Nemeus NIS-UL – Ultrasonic sensor, using a single byte as a bit mask to describe what sensor values are in the variable-length but fixed-order payload, and another byte to define the number of reported measurements per sensor.
-
Elsys payload for their own devices, adding 1 byte of overhead per value for a variable-length payload, but requiring a fixed-order if multiple sensors are of the same type.
-
Cayenne Low Power Payload (as mentioned above, and supported in the TTN Arduino library and the myDevices integration), adding 2 bytes of overhead per value, but allowing for multiple sensors of the same type in a variable-length payload.
-
How to decode Elvaco CMi4110 standard M-Bus payload?, adding 2 bytes of overhead per value, using some sort of standard “M-Bus encoding”.
-
CBOR, like as supported by the AllThingsTalk integration, but adding a lot of overhead despite being advertised as suitable for LoRaWAN.
Beware that some standards, such as Cayenne LPP, have a fixed list of supported types, which might not fully match one’s use case.
2 Likes