Is their an option to enable ack for messages the gateway originates?
-
@rayven MyController will not support for ack.
-
Is this a possible feature or is there an insurmountable obstacle?
-
@rayven If the packet reaches mysensors gateway, it will try to send 5 times(I guess, if failed to reach destination).
Alternatively you may check status on MyController from your sensor node every N minutes. It should be a easy solution for this cause. For this you have to call
request(uint8_t childSensorId, uint8_t variableType)and response will be handled automatically on yourreceivefunction.To implement ack support with MyController needs lot of work. May not be possible at this time.
-
@rayven Did you solve this on client side? I would be interested in your code as this seems to be a common issue with relays in areas with bad reception.
-
I moved to trying to use ack between two nodes to better understand what is being done. In the receive function I was unable to tell which node sent the ack. Like int NODE_ID = message.originatingNode similar to msg.setDestination(int NODE_ID). Seems like you would need to set a timer when you send a message to check and see if a ReceivedAck flag had been set in a TIMEOUT period. And in the receive function when we test for ack set the ack flag to true. My issue is not knowing what is being ack'ed. Are you acking my last message or the one of the previous messages. So I clearly dont understand the ack from the receive functions point of view....
It is my understanding that the node sending the message that is requesting the ack will resend the message if no ack is heard within the parameters set in the mysensors code.
-
@jkandasa I think the main issue here is a visual switch going from ON to OFF without the confirmation if the command really has been received.
This is actually a showstopper for many use cases with involving relays.Could we implement a mode where the switch goes into 'undefined' (like when it was created) and sends a 'request state' to the node x milliseconds after the 'set 0' command. Then it sets the switch according to the received state
- either back to ON (if the user generated 'set 0' was unsuccessful),
- still 'undefined' if the 'request state' has not been successful,
- or OFF if the 'set 0' and 'request state' have been successful.
-
@rayven AFAIK Mysensors does not resend automatically.
I understood we cannot rely on ACK as the gateway gives you the ACK without ensuring the End Node has ACKed first!
That means for switching applications it is currently useless and we simply cannot rely on the protocol but have to implement a check in the controller before presenting a supposed state to the user.https://forum.mysensors.org/topic/2189/serial-api-noack-when-sending-with-ack-failed
-
Are you sending the msg from the gateway or a node? If from a node then you could add a 'sensor' on the sending node that the second relayactuator could update as it switches the relay on. if the sending nodes 'sensor' isn't updated in the TIMEOUT period then it will resend the message.
-
@rayven the sending node/switch could set the state of the ackSensor to UNDEFINED and the receiving node/relayActuator can update it as to the STATE of the relay. So the receiving node/relayActuator needs to know which nodes to send an ackSensor STATUS update to. Because it wont know which node/sensor sent the message. All this goes out the window if the user toggles the switch quickly or there is more than one sender like the gateway and the node/switch.
-
@ragflyer I think you are right. Right now we do not have any option to know status set on end device. I will try to address this soon. Thanks to report this one.
-
@rayven I like your sensor workaround, will do this until we have a better solution, thanks!
-
it may be a more universal solution for the node/switch to use the request(uint8_t childSensorId, uint8_t variableType) function and resend the command to the node/relayActuator after a timeout. This is what @jkandasa mentioned in his post earlier. Still if the node/switch receives the request() it does not know what sensor sent it. If this was contained in the message variable we could implement a fairly robust solution to this.
