Auto resend on NACK

[alowhum]

@electrik Is this a correct understanding?

• Hardware ACK is just that is reaches the next node in the network, right? It could be a repeater saying "I got something from you". It doesn't 100% guarantee that it reached the controller correctly.
• Software ACK is the controller sending back the exact same message you sent, but this time with the ACK bit set to true? It goes up and down your entire network. It's the best way to be sure that the message reached the controller, since you could theoretically even check if the message details are still the same as when you sent it.

Both will happen when you set ACK to true in your send() function?

So:
if (send(msgFgeHum.set(fgehum),true)) is just checking the hardware ACK, meaning it got sent away ok.

And then for software ACK you should use the receive function to check for a returning "echo" message:

void receive(const MyMessage &message)
{
	// We only expect one type of message from controller. But we better check anyway.

  Serial.print("Incoming message for child: ");
  Serial.println(message.sensor);

  if (message.isAck() && message.sensor == RELAY_1_CHILD_ID) { // We got the ACK!
    Serial.println("- Received ACK for relay");
    retryCounter = 0;
  }

Is this a correct summary?

[alowhum]

As a quick follow-up: is this a message stating that the hardware ACK failed?

362547 !TSF:MSG:SEND,27-27-0-0,s=3,c=1,t=37,pt=2,l=2,sg=0,ft=0,st=NACK:120

[mfalkvidd]

@alowhum yes

[electrik]

@alowhum said in Auto resend on NACK:

Hardware ACK is just that is reaches the next node in the network, right? It could be a repeater saying "I got something from you". It doesn't 100% guarantee that it reached the controller correctly.

Yes exactly

@alowhum said in Auto resend on NACK:

Software ACK is the controller sending back the exact same message you sent, but this time with the ACK bit set to true? It goes up and down your entire network. It's the best way to be sure that the message reached the controller, since you could theoretically even check if the message details are still the same as when you sent it.

Yes

@alowhum said in Auto resend on NACK:

Both will happen when you set ACK to true in your send() function?

Yes correct again

@alowhum said in Auto resend on NACK:

Is this a correct summary?

I didn't use the software ack myself but I think this last point is also correct.

[mfalkvidd]

@alowhum said in Auto resend on NACK:

Both will happen when you set ACK to true in your send() function?

This is incorrect. Setting ACK to true in the send() function will enable software ACK.

Hardware ACK is not affected by the vale of ACK in the send() function.

[alowhum]

@mfalkvidd Then how is hardware ACK enabled? I that what you enable in the presentation?

present(TEXT_CHILD_ID, S_INFO, F("Status"),true);

I always thought that enabling it in presentation() just means you didn't have to do it manually anymore, that it would be done for all messages of that child.

Or it hardware ACK always on? And it's just a matter of whether you use the return of the send function or not?

[mfalkvidd]

@alowhum said in Auto resend on NACK:

Or it hardware ACK always on? And it's just a matter of whether you use the return of the send function or not?

Exactly.

There might be some way to turn it off, but I don't know how.

[alowhum]

Thanks.

While we're on the subject: is there any built-in retry functionality for the hardware and/or software ACK? I believe if you set the ACK bit in the send function, then the hardware ACK will try to re-send the message a few times? I seem to remember seeing the ft value increase by one each time after a NACK.
2070 TSF:MSG:SEND,27-27-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
I suspect this hardware-retry only works if you set the ACK to true?

And another one:

Does the isTransportReady() function check..
A. If the radio works
B. If there is a connection to a neighbour (repeater or gateway)
C. If a handshake had been made with the controller

  if(isTransportReady()){
    Serial.println(F("Connected to gateway!"));
  }
  else {
    Serial.println(F("! NO CONNECTION"));
  }

[mfalkvidd]

@alowhum again, setting the ACK parameter in the send call will NEVER affect hardware ack.

For nrf24, up to 15 retries will be done by the hardware ack.

[mfalkvidd]

isTransportReady will return true if the node has seen a valid route to the gateway and there have been fewer than MY_TRANSPORT_MAX_TSM_FAILURES transport failures since the node saw the valid route. I do not know what constitutes a transport failure though. I think "Failed uplink counter" (ft= in the log) is the counter that's used for comparison.

The controller is not involved in isTransportReady

So maybe something between B and C.

[alowhum]

@mfalkvidd Thank you so much for the explanation! I feel I'm getting a grasp on things.

[Mark Swift]

@mfalkvidd said in Auto resend on NACK:

https://forum.mysensors.org/post/33832

Would someone be kind enough to point me in the direction of a good software acknowledgement example? I've been building MySensors for 4 years and still have sensors that don't send reliable messages. While most have been replaced with ESP's - these sensors are extremely remote and battery powered (MySensors wins here!).

Currently I use:

void resend(MyMessage &msg, int repeats) {
        int repeat = 1;
        const int repeatDelay = 100;
        boolean sendOK = false;
        while ((sendOK == false) and (repeat <= repeats)) {
                if (send(msg) == true) {
                        sendOK = true;
                } else {
                        sendOK = false;
                        #ifdef MY_DEBUG
                        Serial.print(F("Send error: "));
                        Serial.println(repeat);
                        #endif
                        repeat++;
                        wait(repeatDelay);
                }
        }
}

But this doesn't seem to ensure reliable delivery (some nodes send 10 msgs before sleeping). Often I get multiple messages arriving (I assume this is the burst), but some (often vital) never make it.

[electrik]

You will get multiple messages, if the message arrives correctly but the hardware ACK doesn't.

Do you have a repeater in between the sender and gateway? It could be that the repeater does receive the initial message (and the sensor gets a hardware ACK), but that never reaches the gateway because of a transmission error between the repeater and the gateway.