Use of ack sending messages

  • Hello,

    I'm taking my first steps with MySensors and using a couple of Arduino nanos and the "home Assistant" controller in a Raspberry PI 2 (with a nano acting as serial gateway).

    Anyway, I sometimes have the feeling that not all the messages arrive form the nodes to the gateway.

    For instance, I have a PIR sensor that detects some presence and sends the corresponding message to the gateway (sensor =1). The Home assistant shows it as "on", but sometimes keeps it for long time, until other presence is detected and then timed-out (sensor = 0). What I believe it may be happening is that first the "sensor = 0" message wasn't received, so the controller still believes the sensor is ON, until it gets a off (but from a post event).

    Having this in mind, I was thinking in using the ack flag in the send function, so the node would keep retrying the message send until it gets a confirmation it got there. However, it seems its not as simple as adding the "bool ack" in the message function. (sorry, my C programming skills are not the best, I know 🙂 )

    Anyone have any example of the ack usage? Would this be the correct usage for ack?


  • Contest Winner

    Most controllers don't show a change in a sensor immediately in their webinterface. The reason for this is to keep the traffic to the Domotica controller as low as possible. If your controller keeps logs of the sensors you could check if when the state of a sensor changes.

    I would try that first, so that you know that everything is working correctly. It's allways good the turn on the debug in one of the sensors that looks suspicious and see if the communication is really failing.

    Adding a capacitor to the Radio stabilizes the Radio's and thus the communication. You can find all details on ACK in the API:

    The sensors should present themselves before they start reporting sensor data to the controller.
    void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);
    childSensorId - The unique child id you want to choose for the sensor connected to this Arduino. Range 0-254.
    sensorType - The sensor type you want to create.
    description An optional textual description of the attached sensor.
    ack - Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.

    So for a simple temp sensor this should turn ACK on:

     gw.present( TEMP_CHILD_ID, S_TEMP, "temp sensor", true  );

  • Thanks TheoL,

    I'm amazed how simple that was... I guess I was overcomplicating...

    I added the TRUE statement in the sensor presentation and also when sending the message. It compiled successfully. The changes were:


    MyMessage msg(CHILD_ID_MOTION, V_TRIPPED);
    gw.present(CHILD_ID_MOTION, S_MOTION);


    MyMessage msg(CHILD_ID_MOTION, V_TRIPPED);
    gw.present(CHILD_ID_MOTION, S_MOTION, "PIR", true);
    gw.send(msg.set(tripped?"1":"0"), true);  

    Looking good, will do some more tests.

  • Hi,

    I've just tried using "ack".

    243 134.172896000 15 0 Cmd:SET, ReqAck:1, IsAck:0, Type:DUST_LEVEL, Sns:33, Data:36
    251 134.194524000 0 15 Cmd:SET, ReqAck:0, IsAck:1, Type:DUST_LEVEL, Sns:33, Data:36

    It seems to work in so far as the controller will respond to an ACK request by sending an ACK.

    Just to make this clear for me: the thing about "ack" is that the sender will continue sending until it receives the "ack" signal from the addressee? Nothing else to do for me?
    And what about the pay-off for using it? Is thereany? Apart from producing more traffic?


  • Admin

    The "payoff" is that you know if you need to resend value or not.

    I would only use it for important values, like when you turn on/off a light or something. Asking for ack on sensor values doesn't give much benefit.