Handling NACKs in the gateway

[4994james]

I have set up a 2 way channel from an MQTT gateway (into openhab as controller as it happens but not really relevant) and a wireless sensor / actuator. The sensor detects humidity and sends to the gateway, openhab logic picks up the MQTT message and applies some calculations and sends back a fan speed. Most of the time this works fine however I have noticed that sometimes there are NACKs. In particular there are NACKs on the controller to node direction so that the node doesn't get the new fan speed. My question is: how can I handle these NACKs in the gateway? I haven't actually written any code as it all just done for me in the libraries. Here is the gateway code:

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enables and select radio type (if attached)
#define MY_RADIO_RF24
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

#define MY_GATEWAY_MQTT_CLIENT

// Set this node's subscribe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-1"

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with
// radio on the same spi bus.
#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 14
#define MY_SOFT_SPI_MISO_PIN 16
#define MY_SOFT_SPI_MOSI_PIN 15
#endif

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#ifndef MY_RF24_CE_PIN
#define MY_RF24_CE_PIN 5
#endif
#ifndef MY_RF24_CS_PIN
#define MY_RF24_CS_PIN 6
#endif

// Enable these if your MQTT broker requires username/password
#define MY_MQTT_USER "openhabian"
#define MY_MQTT_PASSWORD "X17572gM"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,20

// MQTT broker ip address or url. Define one or the other.
//#define MY_CONTROLLER_URL_ADDRESS "m20.cloudmqtt.com"
#define MY_CONTROLLER_IP_ADDRESS 192, 168, 1, 13

// The MQTT broker port to to open
#define MY_PORT 1883

#define MY_MAC_ADDRESS 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xE1

#include <Ethernet.h>
#include <MySensors.h>

void setup()
{
    // Setup locally attached sensors
}

void presentation()
{
    // Present locally attached sensors here
}

void loop()
{
    // Send locally attached sensors data here
}

and here is the node:

// Enable and select radio type attached 
#define MY_RADIO_RF24
//#define MY_RADIO_RFM69
//#define MY_RS485

#define CHILD_ID_HUM  0
#define CHILD_ID_TEMP 1
#define CHILD_ID_FAN_SPEED 2

// Define pwm pin
int PWMpin = 6;

//for RS485 connection or if using MQTT gateway  then you must manually define the node id before including mysensors.h 
#define MY_NODE_ID 100

static bool metric = true;

#include <MySensors.h>  

// test every 10s
static const uint64_t UPDATE_INTERVAL = 10000;

//temp humidity module library
#include <SI7021.h>
static SI7021 sensor;

int fan_speed = 0, humidity = 0, humidity_last = 0;
float temperature = 0, temperature_last = 0;

void presentation()  
{ 
Serial.println(F("presentation!"));
  // Send the sketch info to the gateway
  sendSketchInfo("PWM humidity controlled fan", "1.0");

  // Present sensors as children to gateway
  present(CHILD_ID_HUM, S_HUM,   "Humidity");
  present(CHILD_ID_TEMP, S_TEMP, "Temperature");
  present(CHILD_ID_FAN_SPEED, S_COVER, "Fan speed");
}

void setup()
{
  Serial.println(F("setup!"));
  pinMode(PWMpin, OUTPUT);
  //TCCR2B = TCCR2B & B11111000 | B00000001; // for PWM frequency of 31372.55 Hz
  //TCCR2B = TCCR2B & B11111000 | B00000010; // for PWM frequency of 3921.16 Hz
  //TCCR2B = TCCR2B & B11111000 | B00000111; // for PWM frequency of 30.64 Hz
  TCCR0B = TCCR0B & B11111000 | B00000010; // for PWM frequency of 7812.50 Hz
  analogWrite(PWMpin, fan_speed);
  
  while (not sensor.begin())
  {
    Serial.println(F("Sensor not detected!"));
    delay(1000);
  }
  delay(1000);
}


void loop()      
{  
  // Read temperature & humidity from sensor.
  temperature = float( sensor.getCelsiusHundredths() ) / 100.0;
  humidity    = float( sensor.getHumidityBasisPoints() ) / 100.0;
  
  #ifdef MY_DEBUG
    Serial.print(F("Temp "));
    Serial.print(temperature);
    Serial.print('C');
    Serial.print(F("\tHum "));
    Serial.print(humidity);
    Serial.print(F("\tSpeed "));
    Serial.println(fan_speed);
  #endif

  //if humidity has changed significantly since last report then send to controller
  if ((abs(humidity - humidity_last) > 5 ) or (abs(temperature - temperature_last) > 0.5))
  {
    static MyMessage msgHum(CHILD_ID_HUM,  V_HUM );
    send(msgHum.set(humidity, 2)); 
    static MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
    send(msgTemp.set(temperature, 2));
    static MyMessage msgSpeed(CHILD_ID_FAN_SPEED, V_PERCENTAGE);
    send(msgSpeed.set(fan_speed, 2));
    humidity_last = humidity;
    temperature_last = temperature;
  }

  // wait until next update
  wait(UPDATE_INTERVAL);
}

// handle inbound new fan speed message from controller
void receive(const MyMessage &message)
{
  String PayLoad = message.getString();
  #ifdef MY_DEBUG
    Serial.print("Value received: ");
    Serial.println(PayLoad);
  #endif
  fan_speed = PayLoad.toInt();
  analogWrite(PWMpin, fan_speed);
  #ifdef MY_DEBUG
    Serial.print(F("\tSpeed "));
    Serial.println(fan_speed);
  #endif
  //report back fan speed when changed
  static MyMessage msgSpeed(CHILD_ID_FAN_SPEED, V_PERCENTAGE);
  send(msgSpeed.set(fan_speed, 2));
}

So my thinking is that the node has periods where it is doing something else like reading the sensor and when it is executing that code it will be deaf to inbound traffic and hence the NACKs.

Any help on how to program the logic IN THE GATEWAY to handle this would be gratefully received. I could, of course handle this in openhab but this seems should be something that is handled at the transport layer I think.

Thank you

[mfalkvidd]

@4994james the nrf24 radio is able to buffer up to 3 messages, and your node doesn't do anything that takes a lot of time so I don't think the problem is that the node is busy doing something else.

The gateway tries sending up to 15 times by default. If there are 15 failed attempts in a row, I don't think trying even more time will help much.

Do you have capacitors on gateway and node? How are they powered? Stabilizing power helps in more than 99% of the cases I've seen.

If stabilizing power doesn't help, the easiest way would probably be to let the node request the fan speed at regular intervals (maybe every 5th time the loop executes, depending on how often the speed is changed).

Sorry for not giving you a solution to "program the logic IN THE GATEWAY" but I don't think that would be easy, nor effective.

[4994james]

@mfalkvidd thank you for this helpful response. I will respond once I get a chance to have a look at this properly again.

[4994james]

Hi
I have read around this a little bit and also investigated my hardware.

1. I did find an issue in the node (receiving) hardware that was causing the NACKs at the gateway. This is now fixed and consequently I now have far less occurrences which is good but...
2. I still do occasionally get NACKs. Here is an example of the debug output from the gateway of an apparently successful message:

TSF:MSG:SEND,0-0-100-100,s=2,c=1,t=3,pt=0,l=3,sg=0,ft=0,st=OK:220

and one where there has been a NACK:

!TSF:MSG:SEND,0-0-100-100,s=2,c=1,t=3,pt=0,l=3,sg=0,ft=0,st=NACK:220

So I am assuming that the NACK at the end of this debug message is telling me that this is a software handled NACK. I am assuming (and the problem is I haven't easily found a documented explanation for this) that what has happened is that the radio hardware ACK has failed for all of its 15 attempts and the gateway did not receive a requested ACK message.

What appears to be not possible is to handle that lack of an ACK in the code in the gateway sketch.

Regardless of the fact I have made the problem less of an issue by fixing my hardware problem it seems to me that the ability to handle this is a must if I want to use the platform to reliably control actuators. The most logical thing would be to amend the code so that the occurrence of a NACK is reported to the controller. I think that would have to be done by either:

1. amending the library code: I could have a go at doing that but will take some getting my head round the cpp code and i am sure i would end up doing this in a non-re-usable way (I am using the mqtt version of the gateway transport).
2. somehow detecting the debug message in the sketch.

Am I on the right track?

[electrik]

If this is desired, the most transparent way would be to implement this function in the controller. You can request a software echo, and if you don't get that, you can send the message again

[4994james]

@electrik thanks. Good thought. Will report back once I have looked at this.

[electrik]

Okay. Note there is a difference to the ack in the other topic and the echo. The echo status can be requested by the gateway, also if it is on mqtt.

[4994james]

I have now "seen the light" about how this has been designed, amended the outbound mqtt message from the controller to request ACK:
and this is working and sending back an echo message:

mygateway1-in/100/2/1/1/3 100
mygateway1-out/100/2/1/1/3 100

So I can now build a rule round this in openhab to handle errors. I suppose I should have thought this through before pestering the forum but then again that is what it's for! Thanks again.

[electrik]

Exactly. Better to ask then waste many hours