Search not working for me . Firefox browser.

Hi all,

This is what I Simply ended up with to clear the eeprom,

// load core modules only
#define MY_CORE_ONLY

#include <MySensors.h>

void before(){
  Serial.begin(115200);
  Serial.println("Started clearing. Please wait...");
  for (uint16_t i=0; i<EEPROM_LOCAL_CONFIG_ADDRESS; i++) {
    hwWriteConfig(i,0xFF);
  }
  Serial.println("Clearing done.");
}

void setup()
{
	  Serial.begin(115200);
  Serial.println("Started clearing. Please wait...");
  for (uint16_t i=0; i<EEPROM_LOCAL_CONFIG_ADDRESS; i++) {
    hwWriteConfig(i,0xFF);
    Serial.println(i);
  }
  Serial.println("Clearing done.");
}

void loop()
{
	// Nothing to do here...
}

@tomtastic
Hi, I had similar problems in the last year. There is definitely a issue with the clear eeprom sketch, I ended up having to make changes myself, in order to correctly wipe it. When I'm next on my pc I'll post the sketch.

Regards Nigel

Hi.
I have been using a child to report signal strength. All working on various nodes at 2.2.0
Gateway is now at 2.3.2
Nodes that thabe been upgraded to 2.3.2 now only ever report zero for the
send(msgRxRSSI.set(transportGetSignalReport(SR_RX_RSSI)));
I have set the define MY_SIGNAL_REPORT_ENABLED
Having found the requirement in the forum (didn't need to set in 2.2.0)
What else?

To reiterate builds of the same code in 2.2.0 work. Builds of 2.3.2 don't.

Suggestions please.

Regards Nigel

I have built new node, reusing PIR sensor, discrete resistors and caps, plus regulator. New pro mini and rfm69 and base PCB. Had to replace these items at once, as no real possibility of removing them. Worked straight away. I am assuming that the output stage of the rfm69 module had died, given that mysensors wasn't complaining about coms to the module.

@GardenShedDev

Hi,

Yes cheap clones for me too.
Vcc remains at 3.282v (external egulator) after having been away from it for 10 days, lipo battery is still at 4.08v, with it constantly trying to find a parent.
Decent explanation though, I'm going to have to build another I think.

Many thanks,
Nigel

Hi all,
A quick sence check please, before I have to build a new node.
One of my battery powered PIR sensors in the home, suddenly stopped communicating, node has been in existence for well over 18 months, working flawlessly, no hangups or anything.
I received a email from my domoticz system, when there had been no coms for a period of time from the node.
I looked at the reported battery voltage, and thought, ok, time for a recharge (LIPO battery), in fact it's first recharge.
after charging, nothing, did not show up again in domoticz, so plugged into the pro-mini, to see the serial output, of which there wasn't any, as the debug wasn't enabled. Reflashed code, with debug enabled, and node cannot find any parent? whilst I am going this, I am sat on my sofa, 10 feet from the gateway, and another node which is a repeater. I fiddle with the tx power, to make sure it's now not too high, for its current (temporary location) I try it in it's normal location as well, equally no joy.

Here is the log, well a bit of it

60194 TSF:TRI:TSB
Motion 0
60246 !MCO:SND:NODE NOT REG
RAWbatcount :987
batV :4.10
batP :88
60665 !MCO:SND:NODE NOT REG
60667 !MCO:SND:NODE NOT REG
Sleep 3000
60672 MCO:SLP:MS=3000,SMS=0,I1=255,M1=255,I2=255,M2=255
60678 !MCO:SLP:TNR
Sleep infinit
63680 MCO:SLP:MS=3600000,SMS=0,I1=1,M1=1,I2=255,M2=255
63686 !MCO:SLP:TNR
66232 TSM:FAIL:RE-INIT
66234 TSM:INIT
66236 TSM:INIT:TSP OK
66240 TSM:INIT:STATID=21
66242 TSF:SID:OK,ID=21
66244 TSM:FPAR
67246 ?TSF:MSG:SEND,21-21-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
69255 !TSM:FPAR:NO REPLY
69257 TSM:FPAR
70260 ?TSF:MSG:SEND,21-21-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
72269 !TSM:FPAR:NO REPLY
72271 TSM:FPAR
73273 ?TSF:MSG:SEND,21-21-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
73689 MCO:SLP:MS=3589999
73691 TSF:TDI:TSL
73693 MCO:SLP:WUP=1
73695 TSF:TRI:TSB
Motion 0
73748 !MCO:SND:NODE NOT REG
RAWbatcount :987
batV :4.10
batP :88
74166 !MCO:SND:NODE NOT REG
74168 !MCO:SND:NODE NOT REG
Sleep 3000
74172 MCO:SLP:MS=3000,SMS=0,I1=255,M1=255,I2=255,M2=255
74178 !MCO:SLP:TNR
75282 !TSM:FPAR:NO REPLY
75284 TSM:FPAR
76288 ?TSF:MSG:SEND,21-21-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
Sleep infinit
77180 MCO:SLP:MS=3600000,SMS=0,I1=1,M1=1,I2=255,M2=255
77187 !MCO:SLP:TNR
78297 !TSM:FPAR:FAIL
78299 TSM:FAIL:CNT=4
78301 TSM:FAIL:DIS
78303 TSF:TDI:TSL
87189 MCO:SLP:MS=3590000
87191 TSF:TDI:TSL

here is the battery voltage graph before failure

and a switch log, showing the working connection, when the voltage had dropped / dropping.

given that the voltage has dropped very quickly in recent time , see years chart below.

Do people think there has been a catastrophic failure on the radio module (RFM69HW)?
Here is the sketch, in reflashing this node to enable the debug, the version migrated from 2.2.0 to 2.3.2
I have also tried clearing the eeprom, and have restarted domoticz.

// Enable debug prints
//#define MY_DEBUG
//#define MY_DEBUG_VERBOSE
//#define MY_DEBUG_VERBOSE_RFM69
//#define MY_DEBUG_VERBOSE_SIGNING
//#define MY_SIGNING_SOFT
//#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
//#define MY_SIGNING_REQUEST_SIGNATURES
#define   MY_SPLASH_SCREEN_DISABLED
//#define   MY_DISABLE_RAM_ROUTING_TABLE_FEATURE
#define MY_TRANSPORT_WAIT_READY_MS 20000
// Enable and select radio type attached
//#define MY_REPEATER_FEATURE
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_433MHZ // Set your frequency here
//#define MY_RFM69_MAX_POWER_LEVEL_DBM (13)   // max. TX power 10dBm = 10mW
#define   MY_RFM69_TX_POWER_DBM (13)
#define MY_IS_RFM69HW // Omit if your RFM is not "H"
//#define MY_RF69_IRQ_PIN 2
//#define MY_RFM69_CS_PIN 9 // NSS. Use MY_RF69_SPI_CS for older versions (before 2.2.0)
//#define MY_RFM69_ENABLE_ENCRYPTION
//#define MY_RFM69_NETWORKID 100  // Default is 100 in lib. Uncomment it and set your preferred network id if needed
#define MY_NODE_ID 21

//#include <MyConfig.h>
//#include <Filter.h>
#include <MySensors.h>
//#include <TimeLib.h> 
       


//#include <Bounce2.h>
//#include <avr/wdt.h>
#include <Vcc.h>


#define VCC_MIN 3.0
#define VCC_MAX 4.25
Vcc vcc;


int rawbatteryLevel = 0;
int prevbatterylevel=0;
int scaledbatterylevel = 0;
uint8_t batP = 100;
float batV = 3.250;
int oldBatteryPcnt = 0;
const float BatVccMin   = 3000;           // Minimum expected Battery Vcc level, in Volts.
const float BatVccMax   = 4250;        // Maximum expected BatteryVcc level, in Volts.
const int MaxBattCount = 1023;
const float BatVccCorrection = 4.15 / 4.18; // Measured Battery Vcc by multimeter divided by reported Vcc




#define CHILD_ID_PRESENCE 4
#define CHILD_ID_RX_RSSI 5
#define CHILD_ID_BATVCC 6


int BATTERY_SENSE_PIN = A0;  // select the input pin for the battery sense point

const int PresenceDetect = 3; 

const long interval = 20000;   

unsigned long previousMillis,previousrelayMillis,previouprescence= 0;
unsigned long debouncetime =0;

bool  myprescenceDetected = 0;

bool Relaystate = 0;
bool uplinkAvailable = true;
bool requestState;
bool firstStart = true;



unsigned long MYsleepTime = 3600000;//SLEEP_SEC*1000 * SLEEP_MINS * 60  ; //period_t is an enum type defined in the LowPower library (LowPower.h)

int sleepcnt =0;
volatile long currenttime = 0;
volatile long temptime = 0;
//long lightLevel = 0;

// Initialize  message



MyMessage msgPrescenceDetect(CHILD_ID_PRESENCE, V_TRIPPED);
MyMessage msgRxRSSI(CHILD_ID_RX_RSSI, V_LEVEL);
MyMessage msgVcc(CHILD_ID_BATVCC, V_VOLTAGE);


void setup() {  // put your setup code here, to run once:


  pinMode(PresenceDetect, INPUT);      // interruptPin
  pinMode(2, INPUT_PULLUP);      // interruptPin2
  EIFR = (1<<INTF0) | (1<<INTF1);// prevent initial trigger, clear interrupt
  wait(100);
  EIFR = (1<<INTF0) | (1<<INTF1);
//  attachInterrupt(digitalPinToInterrupt(PresenceDetect), prescenceDetected, RISING);

 wdt_disable(); // Might be redundant as the bootloader should have done this already

analogReference(INTERNAL);
     
 }//end setup

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Motion Sensor", "1.0.1");


  // Register all sensors to gw (they will be created as child devices)
 //   present(CHILD_ID_LIGHTLEVEL, S_LIGHT_LEVEL,"LIGHT_LEVEL",true);
 //     wait(250);
    present(CHILD_ID_RX_RSSI, S_SOUND, "Motion RX RSSI",true);
      wait(1000);
      present(CHILD_ID_PRESENCE, S_MOTION, "Prescence", true);
       wait(250);
       present(CHILD_ID_BATVCC, S_MULTIMETER, "Motion Battery V");
  
}//end presentation




void loop() { // put your main code here, to run repeatedly:


    // Read digital motion value
    wait(50);// wait a bit, then read in level, avoid spurious noise as PIR holds high state for 27sec
    bool Motion = digitalRead(PresenceDetect) == HIGH;

    Serial.print("Motion ");
    Serial.println(Motion);
    send(msgPrescenceDetect.set(Motion?"1":"0"));  // Send tripped value to gw

    // get the battery Voltage
    

if(Motion == 0){
  wait(5);
  rawbatteryLevel = analogRead(BATTERY_SENSE_PIN);// 
  if(prevbatterylevel != rawbatteryLevel){

  wait(5);

    long tempV=0;
    for(int i=1;i<=50;i++){
      wait(5);
      rawbatteryLevel = analogRead(BATTERY_SENSE_PIN);// 
      tempV=tempV + rawbatteryLevel;
    }
      rawbatteryLevel = tempV/50;
      prevbatterylevel = rawbatteryLevel;
  
      float scaledbatterylevel =  map(rawbatteryLevel,0,MaxBattCount,0,BatVccMax );// changed it to milivolts
      float batV = scaledbatterylevel /(1000); // Battery voltage
      uint8_t batP = (((scaledbatterylevel - BatVccMin)*100)/(BatVccMax-BatVccMin)); //((input - min) * 100) / (max - min)

     
      #ifdef MY_DEBUG
                          Serial.print("RAWbatcount :");
                                          Serial.println(rawbatteryLevel);
                        Serial.print("batV :");
                                          Serial.println(batV);
                        Serial.print("batP :");
                                          Serial.println(batP);
      #endif
      
      wait(100);

               float volts = vcc.Read_Volts();
               send(msgVcc.set(batV,2),false);

                  if (oldBatteryPcnt != batP) {
                      sendBatteryLevel(batP);
                      oldBatteryPcnt = batP;
                  }

     RX_SEND();
  
}
    
  }
  
    Serial.println("Sleep 3000");

sleep(3000);
    Serial.println("Sleep infinit");
   // EIFR = 1;// clear interrupts
   // EIFR = 2;
    EIFR = (1<<INTF0) | (1<<INTF1);// clear interrupts
sleep(digitalPinToInterrupt(PresenceDetect), CHANGE, MYsleepTime);




}// end loop



void receive(const MyMessage &message) {
  // We only expect one type of message from controller. But we better check anyway.
  if (message.isAck()) {
     #ifdef MY_DEBUG
     Serial.println("+Ack FMGW");
     #endif
  }
  
                        #ifdef MY_DEBUG
                               Serial.print("*InMsgty :");
                               Serial.print(message.type);
                               Serial.print(" MsgComd:");
                               Serial.print(message.getCommand());
                               Serial.print(" childID:");
                               Serial.print(message.sensor);
                        
                               Serial.print(" Switch:");
                               Serial.println(message.getFloat());
                        #endif
                        

  if (message.type == V_STATUS || S_HEATER || V_LIGHT || V_HVAC_SETPOINT_HEAT || V_TEMP || S_HVAC) {


       if (message.getCommand() == 2){// THIS PROCESSES THE CONTROLLERS EXPECTED STATE OF THE OUTPUT
                       // put code here to be executed when the message is from a request
                        #ifdef MY_DEBUG
                                  Serial.print("REQ_Msg :");
                                  Serial.print(message.type);
                                  Serial.print(" MsgCmd:");
                                  Serial.print(message.getCommand());
                                  Serial.print(" childID:");
                                  Serial.print(message.sensor);
                                  Serial.print(" Switch:");
                                  Serial.println(message.getBool());       
                       #endif

                  switch (message.sensor) {// the child ID

                    case 1:
                        
                      break;
                         case 6:
                         
  
                          break;

                 

                                                
                           

                         
                   } // end switch
                                                        


    
      }// end msg=2

        if (message.getCommand() == 1){// THIS PROCESSES DIRECTED COMMANDS

          
           #ifdef MY_DEBUG
                                          Serial.print("*InMsgty :");
                                          Serial.print(message.type);
                                          Serial.print(" MsgComd:");
                                          Serial.print(message.getCommand());
                                          Serial.print(" childID:");
                                          Serial.print(message.sensor);
                        
                                          Serial.print(" Switch:");
                                          Serial.println(message.getBool());
           #endif                 

         


                  switch (message.sensor) {// the child ID

                    case 1:
                        
                          break;
                          
                         case 3:
                         
                          break;

                         case 6:
                         

                          break;
                        
                                                       
                         

                         
                   } // end switch



                   
          }// end if msg = 1


    }// end msg type function

}// end void loop


void prescenceDetected() { // action when interrupt button doesnt really do anyhing as edge triggered
  currenttime = millis();
  if ((currenttime - debouncetime) > 2000) {
   myprescenceDetected = 1;


  }
  debouncetime = currenttime;
}



void RX_SEND()
{

    send(msgRxRSSI.set(transportGetSignalReport(SR_RX_RSSI)));

}  





void sendBatteryReport() {
 
  float p = vcc.Read_Perc(VCC_MIN, VCC_MAX, true);
  int batP = static_cast<int>(p);
#ifdef MY_DEBUG
  Serial.print("Battery is: "); Serial.println(batP);
#endif
  sendBatteryLevel(batP);
}

/*

// This is called when a new time value was received
void receiveTime(unsigned long controllerTime) {
  // Ok, set incoming time 
  #ifdef MY_DEBUG
    Serial.print("Time value received: ");
  #endif 

  if (controllerTime > 1525129200){
 
  setTime(controllerTime);  
    #ifdef MY_DEBUG
        Serial.print("Time value valid: "); 
          Serial.println(controllerTime);
   #endif

 // RTC.set(controllerTime); // this sets the RTC to the time from controller - which we do want periodically
  timeReceived = true;
  
  #ifdef MY_DEBUG
                         
         
  Serial.print(hour());
  Serial.print(" ");
  Serial.print(minute());
  Serial.print(" ");
  Serial.print(second());
  Serial.print(" ");
  Serial.print(day());
  Serial.print(" ");
  Serial.print(month());
  Serial.print(" ");
  Serial.print(year()); 
  Serial.println(); 

   #endif
 }
  
}
*/

Any suggestions gratefully received.

Regards
Nigel

@dbemowsk
I can only comment on the Controlicz skill. I did a trial for myself, lasting 5 or 6 months, and it worked very well. I discontinued only because of my basic tennet of not wanting to allow data outside of where it needs to be, and wanted to see if the convenience of voice control was worth it. I decided for me, it is too high a price to pay, but it did work very well.

Regards Nigel

@cvdenzen
I for one am interested, I have raised issues I have had with sleep, and interrupts in other forum entries.

Entry here

I Guess given the lack of response, that the answer is no.

I am passing the child ID to my function as a separate int.

@Bren
Hi, I don't use blocky myself, however 2 questions for you.

1. for something so simple, why not use the timer feature to turn on at xx mins before sunset, and turn off at another time.
2. what triggers your blocky? If it's never being called, then your comparison is never made or actioned.

Regards Nigel

Hi,
In my ongoing effort to ensure end to end data transmission of some more critical data, is it possible to extract / retrieve the constituent elements of a message, just sent. in the manner of an incoming message in the receive() function?
i.e. can I in a separate function, handling the "logging" of outgoing messages (to be compared to incoming echos) do something like

send(msgSPFlag.set(SPupdateFlag), true);
ChildIDtoCheck = message.sensor;

My aim would be to put the sent childID's into a buffer and then loop through the childID's (in the buffer) in the receive function, and then remove them from the buffer on successful receipt of an echo, if this works, I could possibly expand this to check the actual message payload against what was sent, but that is probably unnecessary.

If that isn't possible, than I'll just have to pass the child to my function as well, but it would be nicer if I can "extract" it.

Many thanks Nigel

Dear all,

I have removed code for "resending" if no hardware ack.

I have come to the conclusion that having wait(200); or even wait(1000); after a send, but before another send, can result in the above recursive calls log entries, when "collision" occurs in the code,

My node is now stable again, and running on 2.3.2.
I still loose many transmissions to the node, but am compensating, (as I had prior to the resending code) by the setting of flags, both in the node and on the controller, such that the controller resends the data, untill the " I have had an update on child x" flag is reset, this works, although not in a near realtime way, but sufficient for the changing of setpoints on the thermostat.
I did try a repeater, but that didn't help.

Many thanks for the input
Nigel

@virtualmkr
The logs already show that preceding the recursive calls that TXError1 for example proceeds the entries. In and off itself I thought it a little suggestive, as I couldn't see any without a retransmitted effort. (There wouldn't be a entry at all if the first transmission successfully occurred)
I'll wind things back to no retransmissions, and see how that behaves. I'm not sure how to use a state machine for this, I've got some reading and experimenting to do. Any hints or know of any other code out there in the mysensors world to check for successfull end to end transmissions, and consequently retransmissions?

Many thanks for the input

Regards Nigel

@virtualmkr

Many thanks for the input. I don't use wait() within the receive function, however, as part of my "mittigation" for lost / failed coms, I have the following code. Do you believe looking at it, that the wait(repeatdelay); after the send(msg,ack); preceeding it, may end up with "collisions" in the case of a delayed response?

If these occurrences are not harmful as such, I am not sure what else I may have done to cause the vast decrease in the node's stability.

bool resend(MyMessage & msg, bool ack, int repeats)
{
  if ((millis() - lastTXtime) < 200) wait(millis() - lastTXtime);
  Watchdog.reset();
  TX(1);// flash Tx iCON on HMI
  int repeat = 1;
  int repeatdelay = 0;
  volatile boolean sendOK = false;

  if (ack == false or ack == 0) {
    send(msg, false);
  }
  else {
    while ((sendOK == false) and (repeat < repeats)) {
      if (send(msg, ack)) {
        sendOK = true;
        //Serial.println(" Sent OK ACK Received");
      } else {
        sendOK = false;
        Serial.print("Tx Error ");
        Serial.println(repeat);
        repeatdelay += 200;
        if (repeatdelay >= 1000) {
          repeatdelay = 1000;
        }
        Watchdog.reset();
      }
      repeat++;
      wait(repeatdelay);
    }
    lastTXtime = millis();
  }
  return sendOK;
}

Also on requests

bool RErequest(int Child, int Type, int repeats)
{
  if ((millis() - lastRXtime) < 200) wait(millis() - lastRXtime);
  Watchdog.reset();
  int repeat = 1;
  int repeatdelay = 0;
  volatile boolean REQOK = false;

  while ((REQOK == false) and (repeat < repeats)) {
    if (request(Child, Type)) {
      REQOK = true;
      Serial.println(" Request OK ACK Received");
    } else {
      REQOK = false;
      Serial.print("Rx Error ");
      Serial.println(repeat);
      repeatdelay += 200;
      if (repeatdelay >= 1000) {
        repeatdelay = 1000;
      }
      Watchdog.reset();
    }
    repeat++;
    wait(repeatdelay);
    //wait(repeatdelay,message.getCommand(),message.getType());
  }
  lastRXtime = millis();
  return REQOK;
}

In an effrot to help with things, and to point either to my code, or the library version, I have rolled back the node to 2.2.0, only having to change isEcho() to isAck(), so I'll see how the stability goes.

Many thanks again, Nigel

Dear All,
I have a newish issue with a node, which only seems to have manifested since I upgraded to 2.3.2 on the node (gateway still on 2.2.0)
The node is my "smart" thermostat, which has been operating at various revision levels for 3 years or more, generally without issue. this node platform is a Teensy 3.2 operating at 24MHz see this post
Since upgrading to 2.3.2 to "resolve" issues previously encountered forum entry here although this particular node doesn't sleep, I am in the process of migrating nodes to 2.3.2. Subsequent to a code / library version revision to this thermostat node, it has started to "lock up / stop transmitting " of a semi regular basis. I recently asked about determining that a node is "off line" from the nodes perspective here and was spending a few happy hours playing, and was musing about leaving a laptop connected to the serial OP of the node and logging to file the output, to assist in fault finding. whilst doing this I have had the node connected to my PC for several hours, and have seen several occurrances of the situation described here and referenced above.
example

6173359 TSF:MSG:READ,0-0-10,s=1,c=3,t=16,pt=0,l=0,sg=0:
6173369 TSF:MSG:SEND,10-10-0-0,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=1,st=OK:<NONCE>
6174314 TSF:MSG:READ,0-0-10,s=1,c=1,t=45,pt=0,l=4,sg=1:19.0
6174316 TSF:MSG:ECHO REQ
6175680 !TSF:MSG:SEND,10-10-0-0,s=1,c=1,t=45,pt=0,l=4,sg=0,ft=0,st=NACK:19.0
*InMsgty :45 MsgComd:1 childID:1 Data:S/19.0 Data:I/ 19 Data:B/ 1
 Incoming SET TempSP:19.00
6176899 !TSF:MSG:SEND,10-10-0-0,s=1,c=1,t=45,pt=7,l=5,sg=0,ft=1,st=NACK:19.0
TX Error 1
6176899 !MCO:WAI:RC=1
6176899 !MCO:PRO:RC=1
6176899 !MCO:PRO:RC=1
6176899 !MCO:PRO:RC=1
6176899 !MCO:PRO:RC=1
6176899 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1
6176900 !MCO:PRO:RC=1

there are THOUSANDS of such lines, sequentially. way too many to put in a post, although I can make the full log available on a file share
As I understand it this is an issue relating to 2.3.2 and signing.

Is there any liklyhood of this being resolved (fixed) in the immediate future?
If not, am I best to roll back to a previous revision of MySensors? If so, which?
I should obviously prefer NOT to turn off signing for this node.
The node is currently falling over every day to a week, which is clearly undesirable. This node prior to changing to 2.32. would go for many months, without falling over, the "issues" I have had related to not receiving data in particular (now mostly resolved by workarounds)

I know this is going to be a awkward issue to help with, bur many thanks in advance...

Regards
Nigel

@TheoL
Are you willing / is it in a state where you can share your code?

regards
Nigel

@mfalkvidd
If I understand correctly, isTransportReady() relates to the transmitter (rfm69 in my case) and the setup / interfacing with the mcu, rather than the connection or lack thereof with the gateway / controller?

transportCheckUplink() looks like it might do the trick, if I poll the check periodically.

I already check for ack's ( send(msg,true) ) as part of my coping mechanism for often failed coms , so I can use this to set a flag myself (say 3 failed sequential attempts ), I was wondering however if there is an inbuilt register / boolean responce from the library, where it keeps track of the connection, or lack of to the gateway. It seems to me that reading through things, that the library will re-ititialise finding a parent for example, subject to some seeming loss of coms. I was hoping I could simply tap into this, recovering this "coms / uplink" status, rather than "re-inventing the wheel". Space and memory isn't an issue for me in this instance, as I am using a Teensy as the MCU, so I can just add a bit more code, Just wondering if there was a way to "retrieve" the info that almost certainly exists within the library somewhere.

Many thanks for the thoughts.

Regards Nigel

HI,
I have a node that is my central heating thermostat, does all sorts of nice to have stuff, in conjunction with the controller and other nodes.
In the event that the controller is completely off line, for what ever reason, it would be good to KNOW this from the nodes perspective, after all I still need the thermostat to perform it's basic function. I already make periodic receive requests, and can set my own flag based on this, but is there a MySensors internal library call I can make to retrieve the state of the transport system?

Something like "isTransportuplinkOk()"

In the case that the node is offline, I should prefer to not keep sending and asking stuff for a period of time, and perhaps skip parts of code and perhaps display a much simpler screen, with setpoint and actual temperature only.

Many thanks in advance for your knowledge.

@Yveaux

Thank you, at least I'm not going mad.
Would this issue likely be the root cause of the curious inverse clock speed / performance results / performance?

regards Nigel