Which seems to work OK, I got this from somewhere on the ttn pages a long time ago showing how to use the ttn-node.
But now I’m exploring adding additional nodes that give different data and so need to be interpreted differently.
For example the ttn example ‘send’ sketch for the UNO node after setting up is this,
// Read the sensors
data.motion = true;
data.water = 682;
data.temperature_celcius = 30;
data.temperature_fahrenheit = 86;
data.humidity = 97;
// Encode the selected fields of the struct as bytes
TheThingsMessage::encodeDeviceData(&data, &buffer, &size);
Now if use the UNO node the data it sends goes through the same payload format as the ttn-node obviously the data is then presented wrong.
How do I use different payload formats for the ttn-node and the UNO node??
Knowing that would help getting other nodes working too.
If your data formats can never occur as options from the same device, you can make them specific to different Applications.
If your data formats are a variety of possibilities which might occur in some combination on the same devices now or in the future, tell them apart by embedded information. The LoRaWAN port number is the most obvious choice: since it is (most of) a byte you “pay” to send regardless if you use it or not, you might as well use it and not waste it.
In the unlikely even that you run out of distinct ports you could could embedded other information, or even use the packet length as an additional distinction allowing you to re-use port numbers between brief and longer form formats.
(But remember of course that the maximum packet length supportable depends on the region and spreading factor; most LoRaWAN stacks will refuse to send overly long packets rather than shorten them)