Is there any way to have uplink and downlink messages sent from/to devices somehow carry a unique id that can be used to understand what uplink was sent as a “response” to a given downlink message?
It’s handled by the LoRaWAN procotol. It’s called ACK.
@clavisound acks are only posted on the way DOWN to the device though. In the resulting UP message that I get from the devices there is no matching id to ensure that the UP message is about that one, specific DOWN I had initially sent. Is that correct?
First of all. Don’t use ACK’s.
LoRaWAN is not suitable for bi-directional communication. Otherwise you abuse the network and you create noise. The gateway is deaf when it sends a downlink.
What you want to achieve? The right thing is NbTrans. Maybe you want to use different ports for different kind of message / information if you don’t want to change the bytes of the payload.
No, see Confirmed Data Up
Incorrect. Send downlink with ACK so the uplink will have ACK.
If your application can’t handle ACK’s send a verification byte.
But please DON’T do that. Re-read the start of my message.
I want to know that an UP from a device is the result to an exact DOWN I had sent to the device. For example, I have an energy meter, and once a day I want to know how many kWh it has consumed. So I send a DOWN message to the meter. However, the meter might be sending other messages UP of the same type, but for other reasons. So I am not interested in those other messages, and I need some kind of “session” mechanism to make sure that the UP message the meter is sending is the response to that exact DOWN message I had initially sent. That’s what I am trying to do.
We are making circles. This is already answered.
- Use ack. This is a temporary session. But it’s useless to your example and it creates noise to the network.
or
- Add a byte in the downlink to be confirmed by the device. For a meter device I don’t see a reason to do that.
or
- use different port for different reasons.
or - new idea -
- If the device received downlink in the next message can notify about this in the payload. But again for a meter, I don’t find a reason to send a downlink.
This is bad example. I don’t get it.
You can send downlink only if a meter sends an uplink. If the meter sends an uplink you have the measurement, why the need of the downlink?
Unless we are talking about Class B, or Class C?
Still don’t get it. You can define other reasons with different port.
1 Like
Ok, I think I have figured it out. If one wants a concept similar to the one of session in sync flows, it must be implemented in the hardware of the device, so it’s in the layer above.
@clavisound leaving your condescendence aside, thanks for replying 
You may put a few bytes in the uplinks and downlinks to keep them tracked together?