Auto resend on NACK
-
@mfalkvidd Thanks for the fast reply.
Is there a clear example anywhere of how to achieve reliable delivery?
I just need to know that the message got to the controller (or GW if that is the best we can do) and resend if not.
Thanks.
Thinking about what you said, would this do it???
switch (send_ack){ case 1: send(msgFgeHum.set(fgehum),true); receive() if (send(msg.set(fgehum)),true){ send_ack = 2; } wait(200); break;This would send the message, go to receive, test if ack was sent by receiver, if it was increment to next case and continue after 200ms.
If no ack it would re-send the message and then run the receive and test again.
Or not... ??? -
Here's some ACK experiment code, might be useful. I've left all the messy stuff in, might be interesting.
The important thing is the retry counter. When a message is sent this is set to 3. If there is no acknowledgement, the message will be sent again, and the counter goes to 2. When it reaches 0 it stops trying to resend.
If an ACK message is received, it also sets the counter to 0 - resending is not required anymore.
/** * The MySensors Arduino library handles the wireless radio link and protocol * between your home built sensors/actuators and HA controller of choice. * The sensors forms a self healing radio network with optional repeaters. Each * repeater and gateway builds a routing tables in EEPROM which keeps track of the * network topology allowing messages to be routed to nodes. * * Created by Henrik Ekblad <henrik.ekblad@mysensors.org> * Copyright (C) 2013-2015 Sensnology AB * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors * * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * ******************************* * * REVISION HISTORY * Version 1.0 - Henrik Ekblad * * DESCRIPTION * Example sketch showing how to control physical relays. * This example will remember relay state after power failure. * http://www.mysensors.org/build/relay * * * * Only sends a quick pulse via a reed relay. Useful to hack other devices with push * buttons. In my case, a cheap IKEA dishwasher that didn't have a timer. */ // security //#define MY_SIGNING_SIMPLE_PASSWD "changeme" //#define MY_ENCRYPTION_SIMPLE_PASSWD "changeme" //#define MY_RF24_DATARATE RF24_250KBPS // Slower datarate offers more range. Only the + version of the radio supports 250kbps //#define MY_RF24_DATARATE RF24_1MBPS //#define MY_RF24_DATARATE RF24_2MBPS //#define CE_PIN 10 //#define CSN_PIN 9 // Enable debug prints to serial monitor #define MY_DEBUG // Enable and select radio type attached //#define MY_RADIO_RFM69 #define MY_RADIO_NRF24 //#define MY_RF24_PA_LEVEL RF24_PA_MIN #define MY_RF24_PA_LEVEL RF24_PA_LOW // Enable repeater functionality for this node //#define MY_REPEATER_FEATURE #include <MySensors.h> // MySensors children #define DEVICE_STATUS_ID 0 // The first 'child' of this device is a text field that contains status updates. #define RELAY_1_CHILD_ID 1 // MySensors child ID #define DONE_CHILD_ID 2 // MySensors child ID #define RELAY_1_PIN 3 // Arduino Digital I/O pin number for first relay (second on pin+1 etc) #define NUMBER_OF_RELAYS 1 // Total number of attached relays #define RELAY_ON 1 // GPIO value to write to turn on attached relay #define RELAY_OFF 0 // GPIO value to write to turn off attached relay #define PULSELENGTH 500 // How long the pulse should last (how long the button should be pressed). #define LOOPDURATION 600000 #define ON_TOO_LONG 9 // If it's been on for X * 10 minutes, then it should send a message. #define RADIO_DELAY 150 // Keeps the bad Chinese radio happy / supplied with stable power. byte loopCounter = 0; boolean state = 0; byte retryCounter = 3; MyMessage charmsg(DEVICE_STATUS_ID, V_TEXT); // Sets up the message format that we'll be sending to the MySensors gateway later. The first part is the ID of the specific sensor module on this node. The second part tells the gateway what kind of data to expect. MyMessage relaymsg(RELAY_1_CHILD_ID, V_STATUS); MyMessage donemsg(DONE_CHILD_ID, V_TRIPPED); void before() { //for (int pin=0; pin < NUMBER_OF_RELAYS; pin++) { // Then set relay pins in output mode // pinMode(pin + RELAY_1_PIN, OUTPUT); // Set relay to last known state (using eeprom storage) // digitalWrite(pin, LOW); //} pinMode(RELAY_1_PIN, OUTPUT); // Set relay to last known state (using eeprom storage) digitalWrite(RELAY_1_PIN, LOW); } void presentation() { // Send the sketch version information to the gateway and Controller sendSketchInfo(F("Dishwasher"), F("1.1")); wait(RADIO_DELAY); present(DEVICE_STATUS_ID, S_INFO, F("Status")); wait(RADIO_DELAY); present(RELAY_1_CHILD_ID, S_BINARY, F("Start")); wait(RADIO_DELAY); present(DONE_CHILD_ID, S_MOTION, F("Done?")); wait(RADIO_DELAY); //send(relaymsg.setSensor(RELAY_1_CHILD_ID).set( RELAY_OFF )); wait(200); //for (int i=0; i<NUMBER_OF_RELAYS; i++) { // Register all sensors to gw (they will be created as child devices) //present(sensor, S_BINARY, F("Start")); wait(100); //send(relaymsg.setSensor(RELAY_1).set( RELAY_OFF )); wait(100); //} } void setup() { wait(1000); Serial.begin(115200); Serial.println(F("Hello world, I am a dish washer.")); if(isTransportReady()){ Serial.println(F("Connected to gateway")); send(charmsg.setSensor(DEVICE_STATUS_ID).set( F("Dishwasher turned on"))); wait(RADIO_DELAY); send(relaymsg.set(state?false:true), true); wait(RADIO_DELAY); // Send new state and request ack back send(donemsg.setSensor(DONE_CHILD_ID).set(0)); wait(RADIO_DELAY); }else{ Serial.println(F("Not connected to gateway")); } } void loop() { static unsigned long lastLoopTime = 0; // Holds the last time the main loop ran. if (millis() - lastLoopTime > LOOPDURATION) { lastLoopTime = millis(); sendHeartbeat(); // Having fun with status messages if( loopCounter < 251 ){ loopCounter++; } if( loopCounter == ON_TOO_LONG ){ send(charmsg.setSensor(DEVICE_STATUS_ID).set( F("Probably done"))); wait(RADIO_DELAY); send(donemsg.setSensor(DONE_CHILD_ID).set(1)); wait(RADIO_DELAY); } if( loopCounter == ON_TOO_LONG * 2){ send(charmsg.setSensor(DEVICE_STATUS_ID).set( F("Turn me off please"))); wait(RADIO_DELAY); } if( loopCounter == ON_TOO_LONG * 3){ send(charmsg.setSensor(DEVICE_STATUS_ID).set( F("PLEEAASE turn me off!"))); wait(RADIO_DELAY); } if( loopCounter == 250){ send(charmsg.setSensor(DEVICE_STATUS_ID).set( F("OMG I am still on??"))); wait(RADIO_DELAY); } } //if( retryCounter > 0 ){ // retryCounter--; // send(relaymsg.set(0), true); wait(RADIO_DELAY); // Send new state and request ack back //} } /* void messageRepeat(MyMessage &message, bool ack = true) { int repeat = 1; int repeats = 10; int repeatdelay = 0; boolean sendOK = false; SerialPrint("Sending message of child "); SerialPrintln(message.sensor); while ((sendOK == false) and (repeat < repeats)) { if (send(message, ack)) { sendOK = true; SerialPrint("Send OK"); } else { sendOK = false; SerialPrint("Send ERROR "); SerialPrint(repeat); repeatdelay += RADIO_DELAY; } if (ack == true) { SerialPrintln(" With ack "); } else { SerialPrintln(" Without ack "); } repeat++; wait(repeatdelay); } } */ 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; } else{ // Change relay state Serial.println("-Gateway wants to change relay position"); if (message.type==V_STATUS) { Serial.print ("-Received V_status:"); Serial.println(message.getBool()); if( message.sensor == RELAY_1_CHILD_ID ){ boolean desiredState = message.getBool()?RELAY_ON:RELAY_OFF; if(desiredState == RELAY_ON){ //digitalWrite(message.sensor-1+RELAY_1_PIN, RELAY_ON); //wait(PULSELENGTH); //digitalWrite(message.sensor-1+RELAY_1_PIN, RELAY_OFF); Serial.print ("-Switching relay on..."); digitalWrite(RELAY_1_PIN, RELAY_ON); wait(PULSELENGTH); Serial.println ("Switching relay off."); digitalWrite(RELAY_1_PIN, RELAY_OFF); retryCounter = 3; } } //digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF); // Store state in eeprom // saveState(message.sensor, message.getBool()); // Write some debug info } } } -
@skywatch said in Auto resend on NACK:
@electrik & @Marek - Are you both sure about that? It seems to me that both those statements are doing what was intended.
Now that I see it again, I'm not so sure anymore actually.
In your code you used the variable msg. That should be one of msgFgeHum, msgFgeTemp, msgFzrHum, msgFzrTemp.
That is why the compiler complains msg is unknown.You also enabled the ack message, this is just a software acknowledge, while the send function returns the status of the hardware acknowledge. So if you check with
if (send(msgFgeHum.set(fgehum),true)) { // this is sent ok } else { // sending failed }you check if the hardware acknowledge was successful. The software ack should be tested differently and some more logic is needed for it.
Hope this helps
-
@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?
-
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 -
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 -
@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.
-
@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 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.
-
@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 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?
-
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
ftvalue 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 controllerif(isTransportReady()){ Serial.println(F("Connected to gateway!")); } else { Serial.println(F("! NO CONNECTION")); } -
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
ftvalue 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 controllerif(isTransportReady()){ Serial.println(F("Connected to gateway!")); } else { Serial.println(F("! NO CONNECTION")); } -
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.
-
@mfalkvidd Thank you so much for the explanation! I feel I'm getting a grasp on things.
-
@mfalkvidd said in Auto resend on NACK:
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.
-
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.