Handling ACK from MySensors

[hek]

End-to-end ack is handled by the library. But re-sends are not.

If you request ack from controller (through the serial protocol), the node will automatically send one back.

If you request an ack from the node when sending in a value to controller, the gateway will send ack back to node automatically.

[martinhjelmare]

@hek

Thanks for clarifying!

Although I think the feature that the gateway answers with an ack, could possibly be a bad idea? Since the gateway is not really an endpoint, the message might not have reached the controller, or if the controller also want to acknowledge, two acks will be sent. What do you think about this?

[hek]

Agree that it isn't optimal now when the WiFi gateway option exist (where messages actually could get lost).

We would need updates of the protocol between GW and Controller to support this. We're also drafting a future binary protocol. I'll add a note about this.

[Mihai]

I think the problems may occur if a lot of messages are sent inside the NRF24 network. Sometimes it happened that two (ore more?) nodes (including the gateway) start sending almost in the same time.
One example is group switch: the controller send several messages shortly one after other; the node get the first message, set its relay accordingly and send back to the controller the new state; in this moment the controller should change also the corresponding switch on its interface; but the node may be busy to receive other messages or may be during reply transmission.
For me it happens that the node message doesn't reach the controller, the corresponding switch on the interface doesn't change even if the node get the message from the controller and perform the right command (for example a light on).
I propose several settings on MySensors side that could improve this a little bit, not to solve:

• increase the transmission speed from 250kb/s to 1 or even 2 Mb/s; this will shorter the transmission time by 4 or 8, so decrease the probability of collisions; the drawback is shorter radio range;
• increase the interval between node updates; the examples start with 30s, in my opinion it is not necessary to get temperature of a room so often, may be 1, 3 or 5 min is enough for most situations;
• node send the same message 2 or 3 times at very short random intervals without test anything else, like ACK (still testing here, may be ~20-100ms is ok).

All of those are quite simple actions.
I don't know how to modify the gateway to send the messages to the node as I mentioned - several times, only from the node to the gateway. Any advice (or better - example) could help.
For WiFi gateway, my opinion it that WiFi may not made troubles because its higher speed allow to exchange a lot of messages with the controller via broker, so no bottle neck here.
I have mentioned on the Bug Reports that the gateway act also for its relays if they have the same CHILD_ID as other node, this also could have a negative influence in message sending.
Of course, an automated mechanism end to end will be the best, but here the problem seems to be on the NRF24 network side, so some improvements are needed here.
An automated ACK between nodes and gateway that include resending of the message few more times at short random interval will help a lot.

[Mihai]

I have checked the serial monitor while stress the node with a lot of switch on/off and from time to time I got some errors like:

read: 0-0-10 s=9,c=1,t=2,pt=0,l=2,sg=0:ON
send: 10-10-0-0 s=9,c=�J*�pt=0,l=2,sg=0,st=ok:ON
send: 10-10-0-0 s=9,c=1,t=2,pt=0,l=2,�+�Vt=ok:ON
send: 10-10-0-0 s=9,c=1,t=2,pt=0,l=2,sg=0,st=ok:ON

More info here: http://forum.mysensors.org/topic/3144/multiple-sensor-node-freeze/2
So the missing messages could be related to this: some of them goes out with errors, if they go.

[martinhjelmare]

@Mihai

Nice investigating!

Talking about imrpovements, I don't think sending more messages arbitrarily is wise, when the radio space seems crowded already. I would say that ack and resend when ack absolutely failed, is the only real solution.

[rollercontainer]

There is a second way for end2end verification:
1.) Controller sends command "Relais: ON" -> Gateway -> Node
2.) Controller asks for the state of the Relais -> Gateway -> Node (reads pin and creates answer) -> Gateway -> Controller
3.) If the states doesnt match, the controller has to send the command again.

Requesting a state is done like here:
http://forum.mysensors.org/topic/1467/how-to-deal-with-a-request-for-information-from-controller/19

[martinhjelmare]

@rollercontainer

Hi!

What's the advantage using this method compared to ack?

[rollercontainer]

Endpoint to endpoint, not only from node to gateway. Controllers knows the exact state.

[martinhjelmare]

@rollercontainer

I think it's possible to use ack from controller to node, although I haven't tried this. I know Domoticz uses this. Don't know how effective though.

I think you can simplify your approach even more. The controller sends a command and waits for a state feedback from node. If no feedback is received within certain time limit, the command switch is reset to previous position. This is how it currently works in home assistant. Automatic resend is not implemented though.

[Mihai]

In HomeAssistant, if you use MQTT switch for example, with state and command topic, the command is send to the gateway when requested from the interface, but the switch on the interface change itself when it receive back the status from the gateway. If the message doesn't reach the destination and comes back with the new status, the interface doesn't change the switch state.
I encounter this situation a lot of times. After many tests, my findings show that the messages are lost between the nodes and the gateway, but I never miss a message between the gateway and the controller.
So, while it will be nice and useful to have an end-to-end implementation with ACK and automatically retries, the real problem can be solved if such mechanism will be available between nodes and gateway.