RFID sensor, no messages from MQTT GW (reboot on sending)

[mortommy]

hi guys,
I'm trying to set up my rfid locker starting from the sketch in the examples. Instead of using the EEPROM I request the current status to the controller in the initialization step. The set up works fine, after the request to the controller the sensor receives the current status (so the radio module is ok). The sensor does read the rfid devices, and sends the the new status to the controller, but the sensor does not processes any incoming message, except for the first one after the request. here is my sketch:

// Enable debug prints to serial monitor
#define MY_DEBUG 

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

#define MY_NODE_ID 10

#include <SPI.h>
#include <MySensors.h>  
#include <Wire.h>
#include <PN532_I2C.h>
#include <PN532.h>


// Add your valid rfid keys here. To find you your key just run sketch; hold your new RFID tag in fron ot the reader; 
// and copy the key from serial output of this sketch.
const uint8_t maxKeyLength = 7;
uint8_t validKeys[][maxKeyLength] = {
                    { 0x64, 0x5F, 0x10, 0x2B, 0x00, 0x00, 0x00 },    // ADD YOUR KEYS HERE!
                    { 0xC6, 0xDD, 0x32, 0x5E, 0x00, 0x00, 0x00 }};
int keyCount = sizeof validKeys / maxKeyLength; 


#define CHILD_ID 0   // Id of the sensor child

// Pin definition
const int redLedPin = 4;          // (Digital 4)
const int greenLedPin = 5;        // (Digital 5)
const int speakerOut = 6;         // (PWM 6)

bool initialazingMessageReceived = false;
bool lockStatus;

MyMessage lockMsg(CHILD_ID, V_LOCK_STATUS);
PN532_I2C pn532i2c(Wire);
PN532 nfc(pn532i2c);

void setup() {

  pinMode(redLedPin, OUTPUT);
  pinMode(greenLedPin, OUTPUT);
  pinMode(speakerOut, OUTPUT);

  //at the begining led are switched off
  digitalWrite(redLedPin, LOW);
  digitalWrite(greenLedPin, LOW);

  nfc.begin();
  uint32_t versiondata = nfc.getFirmwareVersion();
  if (! versiondata) {
    Serial.print("Couldn't find PN53x board");
    while (1); // halt
  }
  Serial.print("Found NFC chip PN5"); Serial.println((versiondata>>24) & 0xFF, HEX); 
  Serial.print("Firmware ver. "); Serial.print((versiondata>>16) & 0xFF, DEC); 
  Serial.print('.'); Serial.println((versiondata>>8) & 0xFF, DEC);
  // Set the max number of retry attempts to read from a card
  // This prevents us from waiting forever for a card, which is
  // the default behaviour of the PN532.
  nfc.setPassiveActivationRetries(0x3);

  // configure board to read RFID tags
  nfc.SAMConfig();
}

void presentation()  {
  sendSketchInfo("RFID Lock", "2.0");
  present(CHILD_ID, S_LOCK);
}

void loop() {

  //the first time request current alarm system to the controller, during this process led blink
  
  if(!initialazingMessageReceived)
  {
      Serial.print("Requested alarm system current status to the Gateway for initializing.");
      request(CHILD_ID,V_LOCK_STATUS);
      
      digitalWrite(redLedPin, HIGH);
      digitalWrite(greenLedPin, HIGH);
      delay(1000);
      digitalWrite(redLedPin, LOW);
      digitalWrite(greenLedPin, LOW);
      delay(1000);
      digitalWrite(redLedPin, HIGH);
      digitalWrite(greenLedPin, HIGH);
      delay(1000);
      digitalWrite(redLedPin, LOW);
      digitalWrite(greenLedPin, LOW);
      delay(1000);
      digitalWrite(redLedPin, HIGH);
      digitalWrite(greenLedPin, HIGH);
      delay(1000);
      digitalWrite(redLedPin, LOW);
      digitalWrite(greenLedPin, LOW);
      delay(1000);
      digitalWrite(redLedPin, HIGH);
      digitalWrite(greenLedPin, HIGH);
      delay(1000);
      digitalWrite(redLedPin, LOW);
      digitalWrite(greenLedPin, LOW);
      delay(1000);
      digitalWrite(redLedPin, HIGH);
      digitalWrite(greenLedPin, HIGH);
      delay(1000);
      digitalWrite(redLedPin, LOW);
      digitalWrite(greenLedPin, LOW);
      delay(1000);
  }
  else
  {
    
    bool success;
    uint8_t key[] = { 0, 0, 0, 0, 0, 0, 0 };  // Buffer to store the returned UID
    uint8_t currentKeyLength;                 // Length of the UID (4 or 7 bytes depending on ISO14443A card type)


    // Wait for an ISO14443A type cards (Mifare, etc.).  When one is found
    // 'uid' will be populated with the UID, and uidLength will indicate
    // if the uid is 4 bytes (Mifare Classic) or 7 bytes (Mifare Ultralight)
    success = nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, &key[0], &currentKeyLength);

    if (success) {
      Serial.print("Found tag id: ");
      for (uint8_t i=0; i < currentKeyLength; i++) 
      {
        if (i>0) Serial.print(",");
        Serial.print("0x");Serial.print(key[i], HEX); 
      }
      for (uint8_t i=currentKeyLength; i < maxKeyLength; i++) 
      {
        Serial.print(",0x00"); 
      }
  
  
      Serial.println("");
  
      bool valid = false;
      // Compare this key to the valid once registered here in sketch 
      for (int i=0;i<keyCount && !valid;i++) {
        for (int j=0;j<currentKeyLength && !valid;j++) {
          if (key[j] != validKeys[i][j]) {
            break;
          }
          if (j==currentKeyLength-1) {
            valid = true;
          }
        }
      }
      if (valid) {
        // Switch lock status
        setLockState(!lockStatus, true);       
      }
  
      // Wait for card/tag to leave reader    
      while(nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, &key[0], &currentKeyLength));
    }//if success 
  }//else 
 
}//loop 



// Unlocks the door.
void setLockState(bool state, bool doSend){
  
  if (!state) 
  {
     Serial.println("open lock");
     tone(speakerOut, 329, 500);
     wait(400);
     tone(speakerOut, 329, 500);
     digitalWrite(redLedPin, HIGH);
     digitalWrite(greenLedPin, LOW);
  }
  else
  {
     Serial.println("close lock");
     tone(speakerOut, 261, 500);
     wait(250);
     tone(speakerOut, 294, 500);
     digitalWrite(redLedPin, LOW);
     digitalWrite(greenLedPin, HIGH);
  }

  lockStatus = state;

  //send the new status to the controller and request the new status to the gateway
  if (doSend)
    send(lockMsg.set(state));    
}

void receive(const MyMessage &message) {
  // We only expect one type of message from controller. But we better check anyway.
 
  if (message.type==V_LOCK_STATUS) {
     setLockState(message.getBool(), false); 
     
     // Write some debug info
     Serial.print("Incoming lock status:");
     Serial.println(message.getBool());

     initialazingMessageReceived = true;
   } 
}

any idea? thank you for your help.

[mfalkvidd]

@mortommy the comment at the end of setLockState says

//send the new status to the controller and request the new status to the gateway

but as far as I can see, there is no code for actually requesting.

Will your controller automatically send a new message? If so, can you verify in the logs that the message is actually being sent?

You could also add a serial print at the very start of receive to check if the node receives something different from what you're expecting.

[mortommy]

hi @mfalkvidd ,
yes that comment was from a different logic I had implemented, now I decided to send just the new status and don't request it to the controller (the new status will be sent anyway from the controller).

The controller sends the status to the MQTT Gateway when it changes, I already verified that the mqtt broker receives the correct message from the controller (it the same message sent when the sensor requests the status in the initialization step). I have monitored the sensor, I can see log from the receive method only when the the sensor receives the first initialization message and then nothing.

Thank you.

[mfalkvidd]

@mortommy ok. So you know the mqtt broker receives the message and that the node does not receive it. That should mean that the message is getting lost in one of the following places:

• from the broker to the gateway
• in the gateway
• from the gateway to the node

What does the gateway log say when the initial message goes through all the way? What does the gateway log say when the later message is lost?

[mortommy]

thank you again @mfalkvidd .
We are in the in the second case: in the gateway

I run this test.

• Enabled debug in gateway
• powered on the gateway
• sent a test message to a knew working sensor (ID 3, V_STATUS = 0)
• sent a test message to a knew working sensor (ID 3, V_STATUS = 1)
• powered on the rfid sensor (ID 10)
• then the rfid sensor sent the request initial status to the gateway
• the controller sent the message to the gateway (V_LOCK_STATUS = 0)
• the gateway sent the message to the sensor and the sensor went to V_LOCK_STATUS = 0
• I sent manually a new status to the rfid sensor using directly the mqtt broker (same mqtt message used by the controller)
• the gateway receives the message but it reboot by itself!

I saw in the past this behavior for power issue, but my gateway is working for a while now, and it is working with other sensors.

here's the gateway log

IP: 192.168.XXX.XX
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;Sending message on topic: mysensors/SI/0/255/0/0/18
0;255;3;0;9;Sending message on topic: mysensors/SI/0/0/0/0/7
0;255;3;0;9;Sending message on topic: mysensors/SI/0/1/0/0/6
0;255;3;0;9;Message arrived on topic: mysensors/SO/3/0/1/0/2
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=0,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=1,t=2,pt=2,l=2,sg=0:0
0;255;3;0;9;Sending message on topic: mysensors/SI/3/0/1/0/2
0;255;3;0;9;Message arrived on topic: mysensors/SO/3/0/1/0/2
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=0,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=1,t=2,pt=2,l=2,sg=0:1
0;255;3;0;9;Sending message on topic: mysensors/SI/3/0/1/0/2
0;255;3;0;9;TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=10
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSF:MSG:PINGED,ID=10,HP=1
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=0,t=17,pt=0,l=5,sg=0:2.1.1
0;255;3;0;9;Sending message on topic: mysensors/SI/10/255/0/0/17
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=6,pt=1,l=1,sg=0:0
0;255;3;0;9;Sending message on topic: mysensors/SI/10/255/3/0/6
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=11,pt=0,l=9,sg=0:RFID Lock
0;255;3;0;9;Sending message on topic: mysensors/SI/10/255/3/0/11
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=12,pt=0,l=3,sg=0:2.0
0;255;3;0;9;Sending message on topic: mysensors/SI/10/255/3/0/12
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=0,c=0,t=19,pt=0,l=0,sg=0:
0;255;3;0;9;Sending message on topic: mysensors/SI/10/0/0/0/19
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,10-10-0,s=0,c=2,t=36,pt=0,l=0,sg=0:
0;255;3;0;9;Sending message on topic: mysensors/SI/10/0/2/0/36
0;255;3;0;9;Message arrived on topic: mysensors/SO/10/0/1/0/36
0;255;3;0;9;TSF:MSG:SEND,0-0-10-10,s=0,c=1,t=36,pt=0,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;Message arrived on topic: mysensors/SO/10/0/1/0/36
0;255;3;0;9;!TSF:MSG:SEND,0-0-10-10,s=0,c=1,t=36,pt=0,l=1,sg=0,ft=0,st=NACK:1
0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGA--,VER=2.1.1
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
IP: 192.168.178.34
0;255;3;0;9;MCO:BGN:STP
Setup start...
Reading temperature from HTU21D
T: 25
H: 55
Setup end.
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
IP: 192.168.178.34
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;Sending message on topic: mysensors/SI/0/255/0/0/18
0;255;3;0;9;Sending message on topic: mysensors/SI/0/0/0/0/7
0;255;3;0;9;Sending message on topic: mysensors/SI/0/1/0/0/6

thank you

[mfalkvidd]

@mortommy great! So we know there is nothing wrong with the node, which is great news.
I think I have seen several posts in the forum the last few weeks about rebooting gateways. I don't think I have seen any solutions unfortunately

[mortommy]

thank you for your support, yes the sensor is working. It is the first time I'm using the request status logic, I'll try something different to be sure it is not related to the issue.

[gohan]

@mfalkvidd weren't the reboot related to boards definitions?

[mortommy]

No news, nothing changes. It happens only if I define a sensor with an id greather then 9

[mortommy]

@gohan , boards definition? The sensor type?
Thank you.

[gohan]

@mortommy i read that some people had the gateway reboot issue and downgraded the arduino board definitions (in board manager) back to 1.6.13 and they solved the problem

[mortommy]

ok, some news here:

• first of all I fixed my issue with the gateway disabling the debug as suggested here.
• I had anyway some messages lost. Looking at the mqtt broker I couldn't see any message telling me the gw was rebooting and not only messages from gw to sensor were lost also between sensor and gw. I tried to remove the decoupling capacitor and is everything working.

thank you