Node ACK issue
-
Sorry fot the late response.
This is what I see in the log when the connection breaks:2018-05-23 22:00:26,524 INFO [mc-th-pool-9] [org.mycontroller.standalone.provider.EngineAbstract:228] Seems like failed to send this message. There is no ACK received! Retried 3 time(s). MessageImpl(gatewayId=3, nodeEui=1, sensorId=2, type=Set, subType=Status, ack=1, payload=1, isTxMessage=true, timestamp=1527105625011, properties=null) 2018-05-23 22:00:35,260 INFO [mc-th-pool-9] [org.mycontroller.standalone.provider.EngineAbstract:228] Seems like failed to send this message. There is no ACK received! Retried 3 time(s). MessageImpl(gatewayId=3, nodeEui=1, sensorId=2, type=Set, subType=Status, ack=1, payload=0, isTxMessage=true, timestamp=1527105633732, properties=null)
Just one more detail I forgot: the node and the GW are really close during this tests (more or less 2 meters of air).
-
I did another experiment: I defined a dummy sensor, and every time I receive a new message, I push the value I received on this dummy sensor.
In this case, even with the ack turned off, after 5 or 6 status changes the node goes offline.
Seems like the continuous exchange of messages hangs something after a while.PS: I only have an ethernet GW, sincce the position where I have my Raspberry with Mycontroller is not easily reachable with wireless connection.
-
@daniele Dummy sensor attached with dummy node? If yes, it is expected behavior(as dummy node does not response for node alive check).
I do not have ethernet GW at this time. I will try to set up locally.
Do you have only one node or more than one? If more than one, same behavior across all the nodes?
Next time when it goes offline, can you reboot your GW alone and check everything comes normal? -
@jkandasa dummy sensor on the same real node, disabling ack on the GW (please look at commented lines in the code):
// Enable debug prints to serial monitor #define MY_DEBUG // Enable and select radio type attached #define MY_RADIO_NRF24 #define MY_RF24_PA_LEVEL RF24_PA_MIN #define MY_RF24_DATARATE RF24_250KBPS #define MY_RF24_CHANNEL 125 #define MY_NODE_ID 1 #define CHILD_ID_RELAY 2 //#define CHILD_ID_RELAY_C 3 #define relayPin 5 #define ledPin 6 #define ventolePin 7 #define RELAY_ON 1 // GPIO value to write to turn on attached relay #define RELAY_OFF 0 // GPIO value to write to turn off attached relay #include <MySensors.h> //MyMessage msgRELAY(CHILD_ID_RELAY_C, V_STATUS); unsigned int relay; unsigned int new_msg = 0; void before() { pinMode(ledPin, OUTPUT); pinMode(relayPin, OUTPUT); pinMode(ventolePin, OUTPUT); // Set relay to last known state (using eeprom storage) relay = loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF; digitalWrite(ledPin, relay); digitalWrite(relayPin, relay); digitalWrite(ventolePin, relay); } void setup() { } void presentation() { sendSketchInfo("P0 - PIR Caldaia", "1.2"); present(CHILD_ID_RELAY, S_BINARY, "P0 Consenso Caldaia"); //present(CHILD_ID_RELAY_C, S_BINARY, "P0 Consenso Check"); } void loop() { if (new_msg == 1){ digitalWrite(ledPin, relay); digitalWrite(relayPin, relay); digitalWrite(ventolePin, relay); saveState(CHILD_ID_RELAY, relay); //send(msgRELAY.set(relay)); new_msg = 0; #ifdef MY_DEBUG Serial.print("Relay: "); Serial.println(relay); #endif } wait(500); } void receive(const MyMessage &message) { #ifdef MY_DEBUG Serial.println("*** Receiving ***"); #endif if (message.type == V_STATUS && message.sensor == CHILD_ID_RELAY) { relay = message.getBool()?RELAY_ON:RELAY_OFF; new_msg = 1; } }
I have more than one node, but just another is an actuator, and is connected to a different ethernet GW (and it seems to be much more stable, even if not 100%).
I'll try to reboot the GW and let you know the result.
-
@daniele Thank you for the update. After implemented ack feature, I never tested ethernet gateway. I will do it when I get time. Kindly update your findings. It might help us to narrow down the issue.
-
Apparently nothing changes if I reboot the ethernet GW, the node remains disconnected.
-
@daniele looks like the problem on node side.
-
I fully agree with you, but I cannot understand what can be causing the issue.
On the software side, do you suggest any change on the node code?
Could it be an hardware issue?
I tried changing both the arduino and the NRF24, but without any luck.
I tried switching from the 3.3V pin to the 5V pin with a voltage regulator, but still the same issue. -
@daniele Can you try with a different version of MySensors library? What the current version of MySensor library?
-
I'm using version 2.2.0, which is the last one.
-
@daniele ok, When I get time, I will try to reproduce this locally.
-
@daniele said in Node ACK issue:
pinMode(ledPin, OUTPUT);
pinMode(relayPin, OUTPUT);
pinMode(ventolePin, OUTPUT);// Set relay to last known state (using eeprom storage)
relay = loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF;Hi!,
Might not be an issue, however from a code perspective you should set the stuff below in the setup loop:
pinMode(ledPin, OUTPUT); pinMode(relayPin, OUTPUT); pinMode(ventolePin, OUTPUT); // Set relay to last known state (using eeprom storage) relay = loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF;
Before() is called prior to setup... not sure if this really is an issue, but just try it...
What might help is the example from the mysensors site. It contains an example to control relays:
https://www.mysensors.org/build/relayIt does basically the same you want... can you try the example?
-
That's exactly the example I started with, then I changed it trying to avoid this issue (basically I only change the value of a variable during the receive() function to reduce the time needed to process a new message).
I also tried using the setup() instead of the before(), but the effect is the same.
-
@jkandasa , the ack issue is probably related to some hardware interference, not to your code.
Yesterday as a last test I turned off a wireless thermostat I have close to arduino (working on 433 Mhz, so really far from the 2.4 GHz I use with NRF24), and the disconnections suddenly disappeared!
I'm sorry I bothered you.
Thank you very much for your support!
Daniele -
@daniele no worries. I am happy that you find the root cause of the issue