Discussion: Reliable delivery
-
I have to chime in and share my agreement. This seems like a fundamental piece of information, I mean, we all want reliable delivery right? For now I've copied a resend function I found on the forums (with some tweaks), but in my opinion, such code should at least me in the core - with the appropriate explanation.
-
The new and still experimental, but quite extensive Doxygen documentation contains the documentation stuff that's available in the source code. For the return value of the send function, see https://ci.mysensors.org/job/Verifiers/job/MySensors/branch/development/Doxygen_HTML/group__MySensorsCoregrp.html#gadbea3e429757e7fbc66a54776590a2e8
-
-
Returns true if message reached the first stop on its way to destination
What will be returned in the case of NRF24L01 as gateway's receiver at destination and internal nrf24 buffer is already contains 3 unread messages?
-
Returns true if message reached the first stop on its way to destination
What will be returned in the case of NRF24L01 as gateway's receiver at destination and internal nrf24 buffer is already contains 3 unread messages?
-
Hi Guyz,
I have been watching this wonderful forum for a while silently now and just started looking at few implementations myself. I am really surprised to know that so much work has been put in MySensors and this area is not given more attention and I second few opinions here that reliable delivery is one of the most important thing especially for actuators. I will try to do an example of end to end (node to gateway) reliable delivery as gateway to controller is pretty much reliable anyways. Meanwhile if anyone has any example already created, please do share over here.
-
Hi Guyz,
Not sure if anyone is interested in this but I would like to share my thinking here.- For reliable delivery, Only source and destination should be taking part, transport can do its best but as its can change we cannot expect it to behave precisely.
- For the sake of simplicity I am assuming all message to be Idempotent. (i.e if this is executed multiple times result will be same. say turn on a switch). I know about OFF ON OFF scenario but for most of our requirements and times involved, I would say that we can assume that when we are delivering one message other will not come. However if any actuator changes so frequently we should think about it.
- For Controller to to Actuator delivery, I am implementing a solution where actuator send its state back to controller on every change. When controller sends a command out to actuator it will wait for a second or two to see if the state is updated. If not it retries and it retries for a max number of times everyday which is getting logged to keep track of reliability in transport. This way if my max retry is not reached I can be sure that every message has reached actuator.
- For actuator to controller delivery I am planning to do similar where it sends until it returns true with a acknowledge requested and keep sending it until either ack has come or max retry has been reached. Also keeping track of attempts it had to make and send those as well reliably to controller for analysis. I know this will not ensure gateway to controller delivery but I will see how this one works and if needed will add that later. But not doing it now to avoid dependency of controller on my individual node.
-
@gahlawathome said in Discussion: Reliable delivery:
When controller sends a
Hi,
ad. 1. Do You reffer to source and destination as a piece of code that uses MySensors lib ? If yes then I agree.
ad. 2. I think that OFF ON OFF scenario is more related to user interfece that to actual message passing. I think that Your assumption is the basics of reliable delivery.
ad. 3. I would divide this to: Controller -> GW than GW -> Acturator. Basically because communication GW -> Controller is much much more reliable and it simplifies a lot the implementation of the Controller. I would like to know how current implementation of mysesnors mqtt gateway handles this. For now I'm assuming that it does not request ack or if it does then it is not something very fancy (like try couple of times). So in my setyp (OH2) I do not update switches or slider automaticaly but i'm waiting for update from Actuator, if update arrives it changes state of the button, if not the button will not change and i know that (probably) the light didn't turned on. But this is no good for automatic rules, so I would like to be sure that this will be handled by the GW.
ad. 4. Again I would divide this to Acturator -> GW and GW -> Controller. -
@gahlawathome said in Discussion: Reliable delivery:
When controller sends a
Hi,
ad. 1. Do You reffer to source and destination as a piece of code that uses MySensors lib ? If yes then I agree.
ad. 2. I think that OFF ON OFF scenario is more related to user interfece that to actual message passing. I think that Your assumption is the basics of reliable delivery.
ad. 3. I would divide this to: Controller -> GW than GW -> Acturator. Basically because communication GW -> Controller is much much more reliable and it simplifies a lot the implementation of the Controller. I would like to know how current implementation of mysesnors mqtt gateway handles this. For now I'm assuming that it does not request ack or if it does then it is not something very fancy (like try couple of times). So in my setyp (OH2) I do not update switches or slider automaticaly but i'm waiting for update from Actuator, if update arrives it changes state of the button, if not the button will not change and i know that (probably) the light didn't turned on. But this is no good for automatic rules, so I would like to be sure that this will be handled by the GW.
ad. 4. Again I would divide this to Acturator -> GW and GW -> Controller.@rozpruwacz Thanks for your response.
- No I meant source as system trying to send message (i.e. Controller for point 3) and destination (Actuator for point3). Transport means mqtt, ethernet gateway, repeater, radio, wires, cloud, ir or anything else in between to reach my destination.
- Thanks agreed.
- I get your point but home automation system being a small size (finite and few hundred meters) system we do not need to intelligent hops.The moment we introduce GW in picture, a. Gateway becomes intelligent and needs to store information, b. It will not know what to do if it cannot pass the information ultimately. For example lets say that my controller wants to turn actuator ON. It makes sure message reaches GW but the actuator is down at that time. After some time when GW has done everything to reach it needs to take corrective action (even more intelligent GW) and send a message back to controller telling about this but by this time controller might have already initiated some logic (still not fulfilled the purpose ) based on actuator turning on. Hence if we follow just Controller -> Actuator, GW can be dumb as a brick, our controller will only trigger further logic once it is sure that actuator is turned on. I completely agree with you if its a huge network (like internet) or turnaround time is very high.
Now to answer your question Yes Controller to Gateway is very reliable and although I do not think it has any acknowledgement, I have never seen a failed message here in my setup.
For Manual action as you mentioned I would know by switch but for automatic I am implementing a retry in rules which will try a finite number of times and keep a track of numbers as well for analysis. Once the tries are exhaused I can take corrective action right there.. e.g if it couldn't turn the boiler ON announce and alert people accordingly. - I think lets first just discuss 3 and then we can come to 4.
-
Hi! I am trying to create a reliable communication with MySensors. I am using ESP8266 as an MQTT gateway and frm95 modules for nodes communication. I am trying to implement an end to end acknowledge. I see that in mqtt topic there is an ack bit so my controller would send back an ack message if required. But where is that bool variable on the node side? I can't set this bit in MyMessage object and I can't set it in send method. There is a requestEcho parameter in send function but it is only the hardware echo, not the end to end ack parameter. Thanks!
-
Hi! I am trying to create a reliable communication with MySensors. I am using ESP8266 as an MQTT gateway and frm95 modules for nodes communication. I am trying to implement an end to end acknowledge. I see that in mqtt topic there is an ack bit so my controller would send back an ack message if required. But where is that bool variable on the node side? I can't set this bit in MyMessage object and I can't set it in send method. There is a requestEcho parameter in send function but it is only the hardware echo, not the end to end ack parameter. Thanks!
Welcome to he forum Imre.
@Imre-Telek said in Discussion: Reliable delivery:
There is a requestEcho parameter in send function but it is only the hardware echo, not the end to end ack parameter.
The above statement is false. Could you share where you found the information? Hopefully we can correct it at the source.
requestEcho will request that the destination node echos the message to the sending node.
MySensors does not have an ent to end ack feature.
Also, here is no such thing as hardware echo in MySensors.
-
Welcome to he forum Imre.
@Imre-Telek said in Discussion: Reliable delivery:
There is a requestEcho parameter in send function but it is only the hardware echo, not the end to end ack parameter.
The above statement is false. Could you share where you found the information? Hopefully we can correct it at the source.
requestEcho will request that the destination node echos the message to the sending node.
MySensors does not have an ent to end ack feature.
Also, here is no such thing as hardware echo in MySensors.
@mfalkvidd Thanks for quick answer!
After my question I have researched more in forums and finally I found that I misunderstood "end to end" echo. I thought it means that it goes through gateway and mqtt to controller and I have to manually send echo back to original sender node. If it would be true the node could be 100% sure that the message is received. I don't know why I thought this. Maybe because there is an ack bit in mqtt topic. Maybe because I haven't found information about the details how it works. I on this page: https://www.mysensors.org/download/sensor_api_20 under Sending data/echo there should be more info. (e.g.: Echo will be send back automatically from gateway to node + Echo doesn't goes through gateway to mqtt,etc.) By the way it would be a good feature if there would be an other bool parameter in send method (e.g.: gatewayEchoPassthrough) which tells the gateway that this message requires echo from the real destination (controller). -
Welcome to he forum Imre.
@Imre-Telek said in Discussion: Reliable delivery:
There is a requestEcho parameter in send function but it is only the hardware echo, not the end to end ack parameter.
The above statement is false. Could you share where you found the information? Hopefully we can correct it at the source.
requestEcho will request that the destination node echos the message to the sending node.
MySensors does not have an ent to end ack feature.
Also, here is no such thing as hardware echo in MySensors.
@mfalkvidd: So you are right, requestEcho is the end-to-end echo parameter but end-to-end means something else what I thought.
Meanwhile I tested the other direction: controller (node-red) ->mqtt -> gateway -> sensor_node message sending with ack turned on in mqtt message. I found that in this direction the sensor node sends back echo automatically to the controller through gateway and through mqtt. So it is real (full) end-to-end echo If the controller sending command to my-sensor node, but it is not that if the node sends data to controller (in that case gateway sends back echo to node). I haven't found a description in documentation about this behavior. Is it planned to add this feature to tell the gateway to enable pass through echo request to controller? So communication in both direction whould be symmetric. Thanks!
