use of ACK

[rozpruwacz]

Hey,

I made a battery powered door sensor. Ideally, the change on the interrupt pin triggers a message send to the gateway and in beetween those interrupts the node should sleep. This would probably make the node last on the battery very long. The problem is that the radio is not 100% reliable and sometimes the message may not be recieved by the gateway, so I added the timeout to the sleep function. 10 minutes. So every ten minutes the message is sent to the gateway. This makes my node run only for about 2 months. I read more about the MySensors API and ack, and I think (I'm not shure) that i should use the ack function to make sure that the message is rcieved by the gateway instead of sending message quite frquently. As I understand if the send function with the ack set to true returns false it means that the ack was not recieved and i should resend the message. This way I can enlarge the sleep timeout or even remove it and still be sure that the message will be recieved by the gateway. I'm I right ?

[Boots33]

@rozpruwacz I have not used it but yes I think you are correct.

It should be simple enough to try if you have a spare node.

if (send(msg.set(state), true)){       
                  
      // put code here to run if connection ok
   
 }
    else {

    //put code here to run when ack has failed

} 

This will only confirm that the gateway is available I think. If the controller is down you may still get a true result.

[rozpruwacz]

I tested it and it works as expected.
I have the controller and the gateway on the same machine, so i think that ACK functionality is enough for me :)

[gohan]

Wouldn't it be better to use a "while" cycle that sends message until it it gets an ack? Of course it would have to hit a timeout or a certain amount of fails and have some delay in order not to drain battery.
In this case where signal isn't probably enough strong, maybe a repeater node in the middle would solve the problem, or not?

[flopp]

try this
https://forum.mysensors.org/topic/1424/resend-if-st-fail/9

[rozpruwacz]

the resend algorithm is not in scope of this topic. Boots33 just gave an example how to check if the ACK functionality works as I suspected. Resend algorith must be much smarter than just a "while" loop with send function. Fo example You must take into account that the sensor state might change while trying to resend. Aafter this change You have to send new message instead of resending the old one. I think that better solution is to have dynamically conifgured sleep time. In the simplest situation when the node just reports one value, the sleep time should depend on the result of send function, when no ack recieved, the sleep should be short, when recieved ack the sleep should be long or even no timeout.

[gohan]

@rozpruwacz
I agree, but since it's a door sensor you probably don't want to miss an event that would trigger the alarm, that's why I was thinking to have a solution that tries to find a way to send the message that the door has been opened

[rozpruwacz]

yeah, good point. The algorithm must take the purpose of the node into account also. This is generally a deep topic.

[Boots33]

@rozpruwacz Great that it works, you and I have both now learned something new :)
@gohan Yes there will probably be a few ways to approach this problem depending on what the node is being used for, thanks for your input.

rozpruwacz another thing to consider with the node is that when it is booting up it will not continue to the loop if it can't establish the uplink to the gateway. This could be a problem for a battery powered node as it will not execute the sleep.

If you are using MySensors V2.1 one solution may be add

//set how long to wait for transport ready in milliseconds
#define MY_TRANSPORT_WAIT_READY_MS 3000

before #include <MySensors.h>

This will set how long the node will try to connect before it will move on to execute the loop code, in the line above that will be 3 seconds.
If the node connects before the time is up it will move on as well.

[rozpruwacz]

ok, thanks. As I understand this will only affect battery powered node when changing the batteries (or rebooting the node in some other way). Without MY_TRANSPORT_WAIT_READY_MS the gateway must be up and running and in the range of the node, if not the node may drain the batery quickly.