Thanks for confirming this.
I will have to be careful when swapping code for testing purposes. I restored the Domoticz database and all seems back to how it was.
I will probably create another post for the actual issue I am having with the node....will try and figure it out myself first. something not right with my code as about 15 unknown childs have been created and the node has high power consumption, like it is restarting constantly. I have ruled out hardware.

I have a problematic sensor running PIR/Voltage/Temp/Hum

I uploaded some different code (PIR/Voltage Only) to test but it messed up the childs in Domoticz so I deleted them
Now when I restart the node they do not get re-recognized.

I know that deleting the entire node causes Domoticz to forget it forever. Is this the same with child objects?
I will restore from backup for now.

@Yveaux Makes sense now. Thanks again. :hugging_face:

@Yveaux

Thanks for that explanation. Understanding this, the bit I am still confused about is how I can use wait() and still able to listen for incoming messages. Is that an exception to the rule? What stops the processing being blocked in this case?

Hope ok to ask here as I am struggling a bit to understand wait() in context with loops. I have used it with success with a separate receive function but need a bit of clarification.

I have read on another post that wait is the same as using the millis method but can't get my head around how to use it.
If using millis I would use the state machine if else method as suggested by @scalz

How do I use wait in one place and then get another loop or process to run in the meantime?

I have watched the video and tried to follow along. here
My test board is a pro mini 3.3V 8Mhz
I can read the fuses with AVRDUDESS and I get
L FF
H DA
E FD

This does not seem to match with the recommended settings but there is no mention what to do on the video?
The text suggests burn other values.
I am guessing I have an external oscillator as I can see the crystal on the PCB? The instructions don't show settings for 8MHz external.

Next I have copied over the necessary boards.txt information, but there are 2 options for 8MHZ. MYBL8 and MYSBLNRF.
Both show up in the arduino IDE as 8MHz RC in the boards/frequency section.
I dont't know which one to choose.

Also if I want to to use a channel greater than 110, I need to compile the hex file.
Is there a guide on how this is done. I have searched but drawn a blank.

Any guidance appreciated.

@trond-arntzen I just use a voltage divider with 1Megaohm and around 82K resistor for measuring my solar charged battery.

@Mustang65 That ups board looks good. I could do with something similar as a battery backup for my raspberry pi's. Of course they would need a 12V to 5V conversion.

@mfalkvidd said in Sample sketch for test node including hardware and software acknowledgement:

char messagestring[100];
message.getString(messagestring);
Serial.println(messagestring);

@mfalkvidd Fantasic. Thank you. That is what I was looking for . It works now !!!

@BearWithBeard Thanks for confirming this. I had tried most of the options listed on the MyMessage page.

I have tried both ways you suggest again just now - getString() returns nothing and getUInt always returns zero.
At the moment it does not matter as I can see the value listed at the end of the echo(as posted previously) it would just be nice to be able to "harvest" it.
For now I will use the value that has just been sent - for resends etc.

@Yveaux Thanks for the link.
I'm not sure if I am missing something simple?

So I can see the echo in the monitor :

173 TSF:MSG:READ,0-0-9,s=1,c=1,t=16,pt=2,l=2,sg=0:111
182 TSF:MSG:ECHO

In this case the original sent value was 111 and I can see it in the echo message.

If I do

Serial.println(message.isEcho());

I get a 1 printed. Is there a message.something that contains the original sent value?

@Yveaux said in Sample sketch for test node including hardware and software acknowledgement:

@grumpazoid said in Sample sketch for test node including hardware and software acknowledgement:

Transportready seems to report good even when lots of hardware NACKS occur.

Transportready is just an indication that your radio is good to go. It does not depend on your link quality.

I've also seen the echo come back as good even though the ack did not.

Welcome to the wonderful world of radio communications! :smile:

Thanks. That explains why Transportready always reports good.

In my day job I work with wired and wireless networks that mostly use TCP/IP so as long as the radio link is there failed messages are handled automatically.
I've updated my sketch now and added an extra bool variable for when echo is received. So now the node can be set to only sleep when it hears an echo. Good stuff.

A message can be correctly received by the target node, while the ack gets lost. The target node then echoes the message back to the source, which receives it correctly.
Perfectly viable scenario.

Great that's what i thought was happening. Good to have it confirmed.

Is it possible to serial print (or store in a variable) the returned message payload? I can see how to print the other parameters but not the payload itself.

Recently, I have been trying to test out the quality of my node to gateway communication, as I know that occasionally messages from nodes don't make it through.

I could not find a simple test sketch that had examples of how to perform the different types of message delivery checks, so I have searched the forums and produced a simple sketch that may be of use to others.

The hardware is as simple as can be:

The sketch will send alternating 1 and 0 to simulate a switch. Each time it will check for :
Transportready
Radio Hardware ACK
Software Echo.

Results are displayed in the debug serial window.

It it interesting to note that the results so far are different from what I expected.
Transportready seems to report good even when lots of hardware NACKS occur.
I've also seen the echo come back as good even though the ack did not.

Here is the sketch

// Mysensors test sketch 1.3 by grumpazoid

#define MY_DEBUG // Enable debug prints

// #define MY_PARENT_NODE_ID 0 // use this to define next node on route e.g. a repeater
// #define MY_PARENT_NODE_IS_STATIC // dont allow node to search for other repeaters
// #define NODE_ID 200 // enable this if you want the node to have a specific ID

#define MY_RADIO_RF24 //Enable and select radio type attached
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

#define MY_RF24_PA_LEVEL RF24_PA_MAX   // Set Radio Power. Values can be MIN LOW HIGH MAX.  FOR PA+LNA MODULE LOW CAN WORK BETTER!! 

#include <MySensors.h>

#define CHILD_ID 1
int STATE = 0;
 
// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);
 
void setup() 
{ 
  sendSketchInfo("Test sensor", "1.3");
  present(CHILD_ID, S_DOOR); 
}

 
void loop()
{
   //TEST FOR TRANSPORT READY
   if (isTransportReady())
    {
         Serial.println ();
         Serial.println ("Tranport Ready");  
    }
 
// SEND MESSAGE
// send(msg.set(STATE),true); 

 //TEST FOR HARDWARE ACK
 if (send(msg.set(STATE), true))  // This appears to also send the message
{                        
      Serial.println("HARDWARE ACK----UPLINK AVAILABLE");
      
}
else {
      Serial.println("HARDWARE ACK----UPLINK IS NOT AVAILABLE. NO HARDWARE ACK RECEIVED");
}

  #ifdef MY_DEBUG
  Serial.print("current vale of STATE = ");
  Serial.println(STATE);
#endif;

// Change state ready for next time
    if (STATE==0) { 
     (STATE=1); 
      }
    else if (STATE==1){
    (STATE=0) ;
    } 

   #ifdef MY_DEBUG
  Serial.println("Going to wait a few seconds for echo message");
#endif;
   wait(3000); // Wait 3 seconds
 
   
   // We shaould have WAITED long enough now for echo message so let's have a sleep.
     
     #ifdef MY_DEBUG
  Serial.println("Going to sleep for 10 seconds");
#endif;

   sleep(10000); // Sleep 10 seconds   
}

// END OF MAIN LOOP


//Listen for incoming messages
void receive(const MyMessage &message) {
   
  if (message.isEcho()) 
  {
     Serial.println("SOFTWARE ECHO RECEIVED---- from gateway");
  }
}

On my test node I have enabled Echo and am using if (message.isEcho())
It is working.

I have searched and searched and looked at the API docs but am still unclear :

If the node sends a value, should it be able to read that same value back in the echoed message.

I know I can use message.sender , message.type etc, but how would I print the whole echoed message and/or the echoed value.

Here's a quick vid of this morning's project. Getting Alexa to speak the values from the node in my garden.
https://youtu.be/ZcgGLup8iZo

Credit goes to those who made the node red nodes to make it work!

@mfalkvidd Thanks. Yes that is indeed what I mean. I just wanted to make sure my understanding was correct before going any further. I am over obsessing really but it is now a bit of a challenge. I went about 24hrs without a a single missed message then just a couple of hours ago started getting lots. I am of course guessing as some local interference being the most likely. Will try another channel number when I can. I have however found a couple of errors in my sketches that need changing - I have been using delay instead of wait and also I have been pointlessly sending some serial prints.

I have cobbled together a simple test sketch that sends alternating values to the gateway every x seconds - Attached below (feel free to correct bad coding).

Are we saying that when I get a NACK response in the serial monitor such as :

37315 !TSF:MSG:SEND,9-9-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=NACK:20

That the sending radio has attempted to send its message AND listened for, but not heard, a response from the gateway 15 times?

I say this because what I observe is the code moving on to send the next message in the sequence.

// Enable debug prints
#define MY_DEBUG
#define MY_PARENT_NODE_ID 0
#define   MY_PARENT_NODE_IS_STATIC // dont allow search for repeater
// Enable and select radio type attached
#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95
#include <MySensors.h>
#include <SPI.h>

#define SENSOR_INFO "Test sensor"
//#define NODE_ID 200
#define CHILD_ID 1
int STATE = 10;

 
// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);
 
void setup() 
{ 
  //begin(NULL, NODE_ID, false);
  sendSketchInfo(SENSOR_INFO, "1.1");
  present(CHILD_ID, S_DOOR); 
}
 
void loop()
{
  
   if (isTransportReady())
    {
        //  uplink OK
         Serial.println ("Tranport Ready");  
    }
         
   send(msg.set(STATE)); 
   
  #ifdef MY_DEBUG
  Serial.println(STATE);
#endif;

// Change state ready for next time
    if (STATE==10) { 
     (STATE=20); 
      }
    else if (STATE==20){
    (STATE=10) ;
    } 

 
   
    //pause
     delay(5000); // Wait 5 seconds
   
}

@Yveaux Thanks. Yes behaviour is strange.
PIR messages that wake via interrupt seem to kick a node back into life somehow. Maybe because they are keeping it awake for communication to establish again?

Thanks for the replies and info.

@Yveaux are you saying if the node did not achieve success after 2 or 3 attempts it would carry on and reach its limit of 15 attempts - then give up. i.e. it would never achieve a successful transmit at say attempt 10 or 11?

I may have do do some testing and experiments myself with a node connected to a laptop in debug mode.

So this week, just for fun, I thought I would try and investigate why the occasional battery voltage (sent every 2 minutes) does not get through. I'd just like to understand the sequence of events a bit better as regards to node to gateway communication.

I am running 2.3.2 on gateway and some nodes, 2.3.1 on others. A lot of posts I have found date back to 2016 so am unsure if they are still valid.

Am I correct In thinking a node will retry 15 times before it gives up?
At this point the message is lost as I have no code to try and resend.

All my battery nodes sleep for 2 minutes or until they are woken by PIR in some cases. At what point after wake up will the node try and establish communication again? I ask this because sometimes a node seems to stay offline for a long time even though it may be close to the gateway and all other nodes are reporting in fine.

is it still valid in 2.3.2 to use if(isTransportOK()) as seen in older posts to keep the node awake until it sends the message or is there a better way to do this?

@Yveaux Yes I had manually changed MyConfig.h to reflect the channel number I use. I thought I had read that was the way to do it. Okay thanks for putting me straight. Good to know it was just normal behaviour. I'll add it to each of my sketches in future.
Thanks.