I am playing with the new Cayenne myDevices integration. My data (payload) is formatted according to the Cayenne Low Power Payload specifications found here: https://mydevices.com/cayenne/docs/#lora-cayenne-low-power-payload.
My device shows up in the Cayenne dashboard, but as “payload” there is only RSSI and SNR shown in the Cayenne dashboard (the values correspond to the metadata I can see in the TTN console). My own payload however does not show up.
What do I have to do to get my payload transferred to Cayenne myDevices?
Hi,
No data except RSSI/SNR means the payload has unexpected format.
Could you provide some payload samples your are sending and expected result ?
Best,
@eptak Thank you for your hint about “unexpected format”. After trying with some hardcoded values and succeeding, I found out that I did malformat the data of one of my channels.
Is there a way to find debug information or some logs over at myDevices that would help identifying such problems?
At MWC I saw @jdp at Microchip’s stand using a Cayenne LPP library. @eptak is that available somewhere? Can’t find it and doesn’t seem part of your Arduino library. Would be very convenient.
@dittrich not yet, logging feature and tab with raw payload and decoding result will be added later by Q2.
@johan Microchip did their own stack for Arduino, we only have an experimental mBed library right now that I use with the Semtech shield. But I’m not sure how far Microchip completed the support for the DataTypes. I also plan to build an Arduino version of the library asap.
The library used at MWC was from SODAQ. I believe they just took the LPP example code (C++) from Cayenne docs page and made the library from that. It was very convenient for formatting various payloads
@Johan, do you really feel that LPP is nice for mainstream use?
With LPP, every sensor value needs an additional 2 bytes for “channel” and “type”, which often just doubles the application’s payload size. (I know, one will always need to send the 13 bytes LoRaWAN header, so it does not double the air time. Or maybe it does, as it invites one to send whenever a sensor value comes in, rather than collecting multiple sensors.) Also, a location always includes a 3 bytes altitude, which for most use cases is really not important.
With the nice TTN payload functions (also equally easy implemented in one’s own application), I really wonder why it would be so hard to do without something like LPP. The only use case I see is where not all node’s sensor values are available in each uplink. But even then “type” could still be maintained/determined in the application, given the channel (the sensor’s id), assuming the payload length or LoRaWAN port number could not be used to also get rid of that channel.
For mainstream use, I guess I’d prefer an approach such as @joscha’s lora-serialization library, but then with more generic names such as “percentage” rather than “humidity”, support for 16 and 24 bits signed values (with sign-extension when decoding), and maybe 6 bytes for coordinates.
True @arjanvanb. I can’t make any judgement for all use cases, although in general optimizing payload for the specific use case is more compact.
Now, sometimes, we need to deal with dynamic fields from the device, where based on all kinds of circumstances you send or don’t send data (e.g. significant changes in readings). In that case, info about the field is required, and this may result in less payload than sending all the values all the time.
So what I like about Cayenne LPP is its standardization, its flexibility and its support on both ends. Yes, at the expense of overhead. People will need to make their own decision what’s better, but for prototyping it’s ideal.
Can we use the “Payload Functions” (Decoder, Converter and Encoder) when integrating with Cayenne myDevices? This way we could optimize for airtime and enjoy standardized sensor data…
@eptak My encoding routine was based on the example provided for addAnalogOutput (Cayenne LPP C++ payload builder). The line buffer[cursor++] = value; should be removed, as else there are 5 bytes added and not just 4 as define with LPP_ANALOG_OUTPUT_SIZE.
Slightly offtopic - I think when I wrote it I wasn’t looking at it in a generic enough way - happy to revise humidity to percentage and add more types (pull requests welcome!). I actually added a bitmap type yesterday for @Caspar .
There was also some talk last year to add protocol buffers as first-class-citizens to the TTN side (see https://github.com/TheThingsNetwork/sdk/pull/19) - I was talking to @johan at the time, but the issue got closed and I lost track. Maybe we can pick that up again.
Hi all, have been investigating the LoraWan network in Australia, running a rpi and a multitech lora 915 card as the gateway and a Sodaq one as the node, which is running great but it is a pain to decode the data that I send … and it’s all been very generic data: lat, lon, bat, temp
I have been reading about the LPP on the myDevices Docs, now I think it would be absolutely fantastic if there was a inbuilt TTN decoder that adheres to the LPP standard so if we were to use the rest data intergration in the TTN, or view from the data tab, we would be presented with the data that we are most fond of … a json object with pretty properties of temp, hum, lat, long etc … that we didn’t have to decode manually … yay!
The LPP standard would also reduce the amount of manually sticking bits into a buffer on the arduino side also, reducing the complexity for beginners, the only library I have found for the LPP on the arduino side is Zenseio/CayenneLPP, which seems to support the standard, maybe there is more?
If the node always sends the same data, do you feel LPP is that much easier than lora-serialization? I’d prefer something like the latter to be integrated in the payload functions. Arduino side:
LoraMessage message;
message.addTemperature(-1.45)
.addHumidity(30.10)
.addUint16(3900) // anything, like maybe voltage
.addLatLng(-33.905052, 151.26641); // et cetera
Decoder (if the library would be integrated in TTN; right now one needs to first copy/paste it into the Decoder function manually):
function Decoder(bytes, port) {
// Define the order in which the fields are sent, and their
// names in the JSON output
return decode(bytes,
[temperature, humidity, uint16, latLng],
['temp', 'humidity', 'battery', 'location']);
}
That’s 12 bytes† for the application payload (with the 13 bytes LoRaWAN header: total of 24), whereas LPP would then use an additional 11 bytes (including 3 for the altitude which on roads is hardly useful).
One could even do smart things with bits to tell if data is skipped (rather than using 16 bits for each field).
† Well, currently 2 more, as it sends 8 bytes for coordinates while 6 would suffice.
@arjanvanb thanks the lora-serialization library indeed does solve many of my issues, thanks for the explanation of the the size difference also.
But… if it is working correctly at the myDevices side as I haven’t tested, the major bonus of using the LPP is that the UI is generated for you, adhere to the LPP and myDevices supposedly will expose the data for the UI automatically… this is the closest I’ve seen to a interoperable standard I’ve seen in my brief experience in low powered data. I believe whole heartily that this should be the direction forward.
I’ll go for a decoder solution on the TTN Backend. Since then it doesn’t matter how I transmit the data over the air. If I use the STM Stack it’s not so easy to implement a Arduino Stack, if i use a board running python and the microchip module, i need to reemplement the whole Arduino library.
That would be great indeed. Unfortunately, the payload functions expect an object as the result. When just trying to return an array of (modified) bytes, one cannot save the Decoder function:
function Decoder(bytes, port) {
return bytes;
}
Error(“Could not dry-run uplink on Handler: Decoder not valid: does not return an object”)
So, even if the payload functions are executed before the integration is invoked (I don’t know for Cayenne; they are certainly called for the Data Storage integration), then currently one cannot enhance/convert the node’s payload into a Cayenne LPP.
