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.