does MySensors use a guaranteed transport protocol or a best effort ?

[dualarrow]

I'm looking at using MySensors for various controls and it looks pretty good so far, but I have been unable to locate anything that indicates if it uses a guaranteed delivery protocol or a best effort. Eg, if I used it to control a sprinkler valve and a repeater sends out a message to turn it off but the receiver misses the 1st message, what happens ? Does the sprinkler valve get left on or will it retry the transmission ?

[hek]

It's up to the controller to implement the resend functionality.
I think some of them will retry a few times (if they don't receive the ack-message from the node).

[dualarrow]

So am I correct in saying the gateway gives no guaantee that a message a controller asks it to send will actually reach a node ?

Presumably you would have to have a sensor on the node that could read the state of the switch so the controller could send the message then conform it was received.

It would be good in that event to have a ping capability on the node so that if the node loses communication wih the gateway (or controller) that it could put itself in a default state. In the case of a sprinkler, that could be an off state.

[boylucky]

@dualarrow - what about to try implement a mechanism that would send the same message which was received by the controller or better by the gateway back to the node. Then the node would check if such message received and the node will be sure that the message arrived or in your question vice versa (node would send the message back to the gateway).

[mfalkvidd]

@boylucky sounds a bit like MySensor's software ack feature? Documentation: https://www.mysensors.org/view/167#sending-data (see the "ack" parameter)

For a very confusing earlier discussion on a smilar topic, see https://forum.mysensors.org/topic/3346/discussion-reliable-delivery

[hek]

@boylucky

This is exactly what the destination node(or gateway) does when ack is enabled on the message.

@dualarrow
No "guaranteed" delivery. But if you receive an ack message back, you know it has been delivered. If no ack (within a reasonable time), then you have the possibility to resend the message again. The main reason this hasn't been implemented has been discussed a few times over the years. TL;DR Requires large buffers in repeaters/nodes.

[boylucky]

@mfalkvidd and @hek - ok, thanks for this info I did not know that as I am new in mysensors. Good to know that it is already implemented in mysensors.
Thanks.

[NeverDie]

@hek said in does MySensors use a guaranteed transport protocol or a best effort ?:

Requires large buffers in repeaters/nodes.

How large is "large"? e.g. the nRF52840 has 256K of RAM memory, and 1MB of flash.... ESP32 has 512KB of SRAM.... Maybe worth revisiting?

The sprinkler valve scenario given by the OP is a good example of where you want to be absolutely sure the message got through.

[JohnRob]

I'm just starting with MySensors so here I'm just thinking at a system level.
I have two suggestions / questions regarding the status of "important" nodes.

1. is it not possible to pole the sensor and request status?

2. If in this case the the valve controlling node could be programmed to report the status of the valve at an increased rate when it is "on". Or perhaps better, increase the report rate for a time after shutting off.

[Carywin]

@neverdie The bulk of MySensors nodes run on Atmega328P, with 2k of SRAM they're already quite resource-constrained in some of these sensors.