[Solved] Node not reconnecting

[tekka]

@kk02067 If your node is out of range, all uplink messages will fail and after 5 consecutive uplink fails, the node will search for a new parent and try to (re)establish the link to the GW.
If you put your node asleep while the link is being established (last line in loop() ), the node won't reconnect. You can prevent this from happening by substituting

sleep(30000);

with

if(isTransportOK()){
    sleep(30000);  // transport is OK, node can sleep
  } 
  else {
    wait(5000); // transport is not operational, allow the transport layer to fix this
  }

[mfalkvidd]

@tekka wouldn't it be better if the library handled that automatically? The library is so good at taking care of everything else. Or maybe I'm just getting spoiled :)

[kk02067]

Ok. Will try something like that.

Is mysensors libraryfunctions interuptdriven? If so I understand why my sketch fails. Is there a complete list of useful functions besides going thru the sourcecode?

Thanks alot for your support.

[TheoL]

@kk02067 Haven't played with 2.0 yet. But looked at the Api which doesn't say what the return value of msg means. In your code you presume that the return values of msg states the success of sending the message. I'm however not sure whether msg() is a blocking call. Meaning that the message is immediately send when you call send. It might be queued until MySensors is ready to handle the sending of messages. And in that case it just can't predict whether it might be able to send a msg in the future. If it could, I'd hire the engineer who developed that algorithm. He'd probably make me rich in no time ;-)

If msg is a non-blocking call, than determining whether the msg was successfully by MySensors, by checking the return value of the call to msg doesn't make sense. And you actually disturb the whole resend and connect mechanism by doing a soft restart after 6 consecutive fails.

But then again haven't played with it. But thought this might help. I think I'd would first try to improve the sending range and try to find out what the cause is. Because it might be a hardware problem. And if you can tackle it, it might solve all of your problems.

[kk02067]

This post is deleted!

[tekka]

@kk02067 As @TheoL pointed out, there is no need to reset the node after 6 failed messages, the transport layer takes care of that:

• After 5 consecutive uplink fails, the node search for a new parent (with an established GW-link)
• After 3 unsuccessful find parent attempts, the radio is re-initialised.

Send() returns true if the message was successfully delivered to the next (i.e. parent node), however, this does not imply that the GW/controller received the message.

[kk02067]

@tekka Thanks for the info, I will now rework the sketch after this new information.

My understanding of the library grows with every question.

This is so fun. So much to build, so little time.

[tekka]

@kk02067 Welcome to the club :) Too little time...

[tekka]

@mfalkvidd Yes, you are spoiled :stuck_out_tongue: - I already implemented that after reading a few comments, just have to push the PR.

[kk02067]

I have now implemented the changes discussed here. It now seems to work flawlessly. I tested the node to see its behaviour when i powered down the gateway. As it said in the thread the node tried to reconnect after a couple of failed transmissions. And when I powered up the gateway again the node reconnected and started to go to sleep again.

Thanks for the help on this.

A Quick question a bit of topic Before I go build new nodes. If I want to run the cpu at only 1 MHz, do I have to do something else other then define the cpu frequency in the sketch? Is it possible to set the cpuclk prescaler at runtime?

[TheoL]

@kk02067 if I remember correctly, the example Sensebender sketch (MS 1.5) switches between 8mHz to 1Mhz 1. And there was a reason for that, which I can't remember. You could look at that sketch. Hope it helps you.

[corbin]

@tekka said:

if(isTransportOK()){
    sleep(30000);  // transport is OK, node can sleep
  } 
  else {
    wait(5000); // transport is not operational, allow the transport layer to fix this
  }

I've only just found this post, and these lines of code have me excited! fixes my problem, thank you!