Hi,
I have some Door/window sensors, powered by a cr2032 coin battery and I was able to run them for 1 year. The sketch above it seems ok, but the secret it's not only the software, it depends on hardware too:

• remove voltage regulator and led from the arduino
• choose a ceramic decoupling capacitor for your radio module, and avoid electrolytic capacitors (they have a bigger leakage current)
• I don't use any step-up converter, and use the battery to power both the radio module and arduino (reported both to work at 3V)
• a capacitor (again ceramic) of 100uF across the cell’s terminals could sustain a peak current load.

It's also better to avoid messages sending in a short time, and put some sleep in the middle, but I don't see that situation in the sketch.

Hi guys,
what do you think if we create on this forum a section about sell/exchange electronic spare parts? Probably we bought some 5 or 10 pieces packs from Chinese sellers and we don't use all of them, keeping stocked in our shells, but they can be useful for someone else. We could save time avoiding to wait shipping from China, like now I wold like to have in my hands an additional radio module but I have to wait at least 2 weeks.
Regards.

Hi,
I had started to analyze the communication protocol and the project. I found this site very useful. The problem is the sizing. I'd like to keep everything hided so a very small circuit is requested.

It is a while now I'm using my 2.0 GW (because I wanted to manage sensors connected directly to it) with 1.5 sensors node and everything is running fine.

If you are powering the device by batteries, I'd suggest to avoid electrolytic decoupling capacitors and go for ceramic or film one since the latter have a smaller leakage current, avoiding battery drain.

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

With an external regulator it has been running already for 24h
thank you.

I want also to specify that my sensor was running under library 1.5.4. At the moment I'm experiencing an issue under the library 2.1.1 that makes the sensor continuously wake up, so the battery discharges itself after few hours. Better under library 2.0.0 but the initialization process has many transmissions failure that give to the battery a heavy blow.

Juts to leave a record about the issue. I changed the GW radio module with a NRF24L01 + PA + LNA one, powered by the AMS1117 and the ugly fix. Everything seems to working fine now.
Thank you to every one.

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

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

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

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.

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

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.

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.

I have 4 sensors (temp/hum and contact switch) powered by 3V coin battery and with the library 1.5.4 they run for a year. I also decided to upgrade them to the library 2.1.1 and I got some issues. For example the binarysqwitchsleepsensor doesn't sleep. I also noticed that the initialization has many messages sending failure and that is a heavy blow for the battery, I went back to the 1.5.4.

I had similar issues. I had a serial GW with a NRF24L01+PA+LNA and the option MY_RF24_PA_LEVEL to HIGH and worked for more than one year; than I decided to convert it to an Ethernet GW and I had many failure in sending messages. When I was out of ideas (after checking connection wiring and power issues, adding capacitor, making the ugly shield fix) I decided to play with the MY_RF24_PA_LEVEL, and it started to work again with the value MIN.

I want also to specify that my sensor was running under library 1.5.4. At the moment I'm experiencing an issue under the library 2.1.1 that makes the sensor continuously wake up, so the battery discharges itself after few hours. Better under library 2.0.0 but the initialization process has many transmissions failure that give to the battery a heavy blow.