Build retry funtionality into the mysensors library
-
@mfalkvidd said in Build retry funtionality into the mysensors library:
I guess some sort of timestamp when the last send attempt occurred, and a retry counter is needed to be stored per message as well?
Yes, could be useful for debugging purposes. In the ideal setup retry counter should be always 0 :)
-
@rozpruwacz you use a constant interval between retries? (No exponential backoff)?
@mfalkvidd said in Build retry funtionality into the mysensors library:
(No exponential backoff)?
its expotential, but no more than hardcoded value (don't remember what value)
-
@rozpruwacz that sounds like an interesting solution. Do you statically allocate the ram needed to store the transmitted values, or are you able to do it dynamically without causing fragmentation? How much extra ram is required? Is there support for larger messages, such as V_TEXT? How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?
Would be awesome if we could work towards a pull request that could add this functionality to MySensors. Dropping support for repeaters would be a very big drawback for some uses though. Many users already complain about the ram requirements, so we'd have to consider our options regarding ram as well.
@mfalkvidd said in Build retry funtionality into the mysensors library:
How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?
How MQTT qos 1 does? I think it should be similar to it.
Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.
-
@mfalkvidd said in Build retry funtionality into the mysensors library:
How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?
How MQTT qos 1 does? I think it should be similar to it.
Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.
@sergio-rius said in Build retry funtionality into the mysensors library:
How MQTT qos 1 does? I think it should be similar to it.
Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.But MQTT broker is not running on the 1kB ram mcu. Having lots of memory available it is not a brain teaser to implement such functionality. For a small mcu You have to make some compromise. In one case droping messages is completely ok, but for other is not. It may turn out that there is no ONE algorithm that will fit all cases ...
-
@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
#definevalues could I already change today to get the nodes to keep retrying for longer than just a few seconds? -
@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
#definevalues could I already change today to get the nodes to keep retrying for longer than just a few seconds? -
@sergio-rius said in Build retry funtionality into the mysensors library:
How MQTT qos 1 does? I think it should be similar to it.
Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.But MQTT broker is not running on the 1kB ram mcu. Having lots of memory available it is not a brain teaser to implement such functionality. For a small mcu You have to make some compromise. In one case droping messages is completely ok, but for other is not. It may turn out that there is no ONE algorithm that will fit all cases ...
@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. -
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.
-
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. -
I am not sure how retrying even more times will help anything
