Build retry funtionality into the mysensors library

[alowhum]

@rozpruwacz said in Build retry funtionality into the mysensors library:

It may turn out that there is no ONE algorithm that will fit all cases ...

Agreed. It seems to me that a small home with about 10 to 15 devices should be able to run on Arduino Nano's and offer a decent level of predictability. If all devices send, on average, one message per minute, then this would mean one message every 70 milliseconds. Most of these devices will be connected to the gateway directly. Let's say half of them require

So in a basic home situation a buffer for two messages would be fine, and three would be a luxury.

If you want to run a large scale sensor network, then it makes sense to upgrade your parts too (bigger antenna on the gateway, more ram on nodes that extend the network).

Retry functionality, in the normal home scenario, probably isn't so much about how many messages are buffered, but about how long people turn on the microwave oven, which disrupts the network. So for me it's about having control over the (exponential) time period that the node keeps retrying. The memory/buffering capacity of my home network is fine, it's just that I don't want to implement this "keep retrying for longer" routine myself.

Which #define values could I already change today to get the nodes to keep retrying for longer than just a few seconds?

[Yveaux]

@alowhum said in Build retry funtionality into the mysensors library:

So in a basic home situation a buffer for two messages would be fine, and three would be a luxury.

Each nrf24 has this luxury of a 3 message hardware buffer :-)

[Sergio Rius]

@rozpruwacz said in Build retry funtionality into the mysensors library:

But MQTT broker is not running on the 1kB ram mcu

I'm not saying to make a mqtt broker run on an arduino. Just picking the process logic as a guideline.
MQTT is not a protocol made for raspberries, it's only that often run on them.

[mfalkvidd]

The main thing mqtt has (that MySensors doesn’t) is ”packet identifier” in mqtt lingo. It is similar to tcp’s sequence number.

Mqtt also assumes that

• the broker (I guess the analogue is the MySensors gateway) has persistent storage, or at least sufficient ram to buffer all messages until they have been marked as delivered
• everything is single hop (no repeaters)
• there is a DUP flag
• clients have sufficient ram to buffer all outgoing messages until they have been marked as delivered, and has timers to retransmit messages

I am not sure how mqtt handles ordering of messages. I think mqtt doesn’t guarantee ordering, regardless of qos level.

[Sergio Rius]

Voilá.
And it maintains a live inventory of clients.
Some points are so difficult to achieve. But I was looking at message identification as a response to the sequence switch problem.

[efix durov]

I am not sure how retrying even more times will help anything