Hi,
I'm on my 16th node with mysensors (2.2.0) library and first time with this kind of issue. I have a sensor on Arduino Nano and in order to save battery, as usual, I use the sleep function:

sleep(sleep_seconds_between_measures);

the variable value is 900000. The problem is, the node wake ups too early, the debug is:

Sleep for seconds: 900000
1116278 MCO:SLP:MS=900000,SMS=0,I1=255,M1=255,I2=255,M2=255
1116288 TSF:TDI:TSL
1116399 MCO:SLP:WUP=-1
1116401 TSF:TRI:TSB

so according to the log parser, values are correct and the node wakes up by the timer interrupt (1116399 MCO:SLP:WUP=-1), but it happens straight away after the sleep command.

Any clue? Can be any flag that should be reset used by the timer?

Thank you for your help.

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.

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.

yep :disappointed_relieved:

Yesterday evening I was in my living-room when a bad, and well knew, from who works with electronic, smell came out. I suddenly thought that something was burning and after few minutes I found out that my gateway was not working anymore. Unfortunately I realized that one of the capacitor of my nano clone was completely burned. Now I'm without gateway and waiting for a new one (this time an original one).
That's only to share my frustration.

Hi,
very interesting project. How did you choose the fan? Did you calculate the CFM or something else (f.i. why Silent 14 and not 12)? How do you assemble the fans, will you replicate any of the commercial solutions?
Thank you.

Great news!

Regarding OH, I didn't have the opportunity to play with the v2.0 yet, I'm still on 1.8.1.
I have a serial mysensors gateway and this is my set up:

OH (v1.8.1) <-> OH MQTT binding (as MQTT client) <-> Mosquitto (as MQTT server) <-> mosquitto to serial (python script that reverts messages with topic mysensors to the serial port and vice-versa) <-> serial gateway.

So my items in OH are based on mqtt binding.

I guess OH2 and mysensors openhab binding make everything easier.

Which module are you using? if it is NRF24L01+ be sure it is the "plus" version.

Hi,
you can try this:

if (message.type==V_RGB)
{
      char convBuffer[8];
      hexstring = strtol(message.getString(convBuffer),0,16);
      Serial.println(hexstring);
      r=(int)(hexstring>>16);
      g=(int)(hexstring>>8)& 0xFF;
      b=(int)(hexstring)& 0xFF;
}

Hope it helps.

ok, something is definitely wrong with the radio module. Can you check the connection according to this page?

@pentti12 ,
add the line

#define MY_DEBUG

at the begging of the sketch so via Serial Monitor you'll be able to see the messages pushed by the commands println. You can add other println commands in other point to see the steps covered.