![image](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/6/c/6cd7a4e53471c006cdf92ec6d8df72cc7297c407.png)
Hi,
I’m using a TTN Uno with my own gateway. Payloads (pic attached) are:-
- My 7 byte payload consists of 4 arduino digital input pins plus 3 A/D readings. This is sent whenever there is a change of input. It’s one byte per pin, rather than one bit per pin simply because I haven’t worked out how to do that yet!
- My 3 byte payload is the 3 A/D readings again. Sent every hour, once testing is done.
I will have multiple nodes. End goal is to:
- Identify which pin on which node has detected an event
- Be able to send an SMS to alert someone
- Graph the hourly voltage readings.
I would appreciate any words from the wise to point me in the right direction. I’ve done plenty of reading but maybe I’m not getting my search terms right. I guess the first question is - How do I differentiate between the 3 byte vs 7 byte payloads? If I consolidate all the inputs into a single byte then the same question applies I believe.
I would welcome any pointers, appreciating that it’s a slightly open ended request, but I don’t have enough feel yet for the architecture to ask specific stuff.
Thanks in advance. Some great answers in here. Hopefully I’ll be answering some soon.
I think the usual approach is to use different ports for the different message types, like use port 1 for the digital inputs and use port 2 for the hourly voltage readings.
You can’t use port 0, it’s reserved for MAC commands.
Be aware that LoRaWAN can be lossy, so it’s possible that you miss a message. And it would be annoying if that was the message that should have triggered an alert.
What you could do instead of sending a single bit right when an event occurs, is send a count of the number of events on a specific pin, so even if you missed a message, your backend code can tell that an event occurred later on because the event count changed.
Have a look at the payload of the TBMS100 motion detector, this device immediately sends a message when movement is detected. As long as movement keeps getting detected, it sends a another message every 10 minutes. If movement is no longer detected, it sends a message 5 mins after the last event. The payload has an event count. The payload also contains a minutes-since-last-movement field, so even if you missed the first message you can reconstruct the moment of the movement later.
1 Like
Thanks for that. Rather than consolidating the bytes I think I’ll have 1 bit for current status & use the other 7 bits for a rolling count to 128 of events, as you suggested.