smart sleep inconsistent?

CrankyCoder

I have a node I setup and configured for smart sleep. It's set to check in every 30 seconds. But it's not consistent. I understand without a real time clock ect that it may not be 100% on the wake up procedure... but i am getting BIG gaps of time where it just isn't reporting in. The below graph is monitoring my mqtt broker and you can see big gaps and that is just over the last hour. 1 gap was for 12 minutes then ok for a bit, then a gap for 15. I monitored during my last meeting so i could confirm it wasn't me messing with something.

This has been going on for a couple weeks. The only thing I can think of is maybe it's doing the FPAR like I saw awhile back. I have changed out the arduino, changed the radio, changed to another radio from a different batch.

Not sure if anyone has any experience with the smart sleep, but so far it doesn't seem super reliable. Not enough so for me to be willing to have it not turn off my water for a couple hours till it decides to wake up after flooding my neighbors drive way.... not speaking from experience or anything lol

CrankyCoder

additional information:

wemos d1 mini mqtt gateway
tried with and without repeater
tried moving gateway closer to node (easier than moving node)

mfalkvidd

@CrankyCoder can you share the node sketch?

You don’t happen to have gateway and/or node debug logs?

mfalkvidd

Oh, and what hardware is your node? Atmega328?

CrankyCoder

@mfalkvidd sketch is here. I don't have the debug logs off the gateway, but ill hook up serial to it this weekend and get some logs. (i need to just make one of those bluetooth to ftdi adapters lol)

hardware is 3.3v arduino pro mini for the node and wemos d1 mini for the gateway.

/*
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2019 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Henrik Ekblad
 *
 * DESCRIPTION
 * Example sketch showing how to control physical relays.
 * This example will remember relay state after power failure.
 * http://www.mysensors.org/build/relay
 */

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95
#define MY_NODE_ID 18
int BATTERY_SENSE_PIN = A0;
// Enable repeater functionality for this node
//#define MY_REPEATER_FEATURE
#define CHILD_ID_HOSE 0
#define CHILD_ID_VOLT 1
uint32_t SLEEP_TIME = 30000;
#include <MySensors.h>
MyMessage msg(CHILD_ID_HOSE, V_STATUS);
MyMessage msgVolt(CHILD_ID_VOLT, V_VOLTAGE);
#define HOSE_ON 1  // GPIO value to write to turn on attached relay
#define HOSE_OFF 0 // GPIO value to write to turn off attached relay
int oldBatteryPcnt = 0;
int in1 = 5;
int in2 = 6;
unsigned long start_time; 
unsigned long timed_event = 1000;
unsigned long current_time;

void before()
{
	pinMode(in1, OUTPUT);
  pinMode(in2, OUTPUT);
}

void setup()
{
#if defined(__AVR_ATmega2560__)
  analogReference(INTERNAL1V1);
#else
  analogReference(INTERNAL);
#endif
 
 SendBatteryUpdate();
 directionControl(HOSE_ON);
 delay(100);
 directionControl(HOSE_OFF);
 
}

void presentation()
{
	// Send the sketch version information to the gateway and Controller
	sendSketchInfo("Garden Soaker Hose Control", "1.0");
  present(CHILD_ID_HOSE,S_BINARY);
  present(CHILD_ID_VOLT, S_MULTIMETER);
	digitalWrite(in1, LOW);
  digitalWrite(in2, LOW);
  current_time = millis();
  start_time = current_time;
 
}


void loop()
{
  static bool first_message_sent = false;
  if ( first_message_sent == false ) {
    Serial.println( "Sending initial state..." );
    send_status_message();
    first_message_sent = true;
  }
  
  
  current_time = millis(); // update the timer every cycle
  if (current_time - start_time >= timed_event) {
    SendBatteryUpdate();
    start_time = current_time;  // reset the timer
  }

  #ifdef MY_DEBUG
    Serial.println("Going to sleep");
  #endif
  smartSleep(SLEEP_TIME);
  
  #ifdef MY_DEBUG
    Serial.println("Awake Now");
  #endif
  

}

void SendBatteryUpdate()
{
  // get the battery Voltage
  int runningTotal=0;
  
  for (int x=0;x<10;x++)
  {
    runningTotal=runningTotal+analogRead(BATTERY_SENSE_PIN);
  }
  
  
  int sensorValue=runningTotal / 10;
  //int sensorValue = analogRead(BATTERY_SENSE_PIN);

  #ifdef MY_DEBUG
    Serial.println(sensorValue);
    //973 = 4.05v
  #endif

  

  
  
  
  #ifdef MY_DEBUG
    float batteryV  = (sensorValue * 3.34) / 1024;
    Serial.println(batteryV);
    batteryV = batteryV / 0.7802721088435374;
    //batteryV = batteryV / 0.4857457520453115;
    batteryV = batteryV / 0.5291330073696145;
    int batteryPcnt = (batteryV / 8.4) * 100;
    Serial.print("Battery Voltage: ");
    Serial.print(batteryV);
    Serial.println(" V");
  
    Serial.print("Battery percent: ");
    Serial.print(batteryPcnt);
    Serial.println(" %");
  #endif
  if (oldBatteryPcnt != batteryPcnt) {
    // Power up radio after sleep
    sendBatteryLevel(batteryPcnt);
    send(msgVolt.set(batteryV,1));
    oldBatteryPcnt = batteryPcnt;
    }


  Serial.print("sensorValue:");
  Serial.println(sensorValue);
  
}

void receive(const MyMessage &message)
{
	// We only expect one type of message from controller. But we better check anyway.
	if (message.getType()==V_STATUS) {
		// Change relay state
    directionControl(message.getBool()?HOSE_ON:HOSE_OFF);
		//digitalWrite(message.getSensor()-1+RELAY_PIN, message.getBool()?RELAY_ON:RELAY_OFF);
		// Store state in eeprom
		saveState(message.getSensor(), message.getBool());
		// Write some debug info
		Serial.print("Incoming change for sensor:");
		Serial.print(message.getSensor());
		Serial.print(", New status: ");
		Serial.println(message.getBool());
	}
}

void send_status_message()
{
  
    send(msg.set(1));
}

void directionControl(int ONOFF) {
  // Set motors to maximum speed
  // For PWM maximum possible values are 0 to 255
  
  // Turn flip circuit on for 1/4 second
  if (ONOFF == HOSE_ON)
    {
      Serial.print("turning hose: ");
      Serial.println(ONOFF);
      digitalWrite(in1, HIGH);
      digitalWrite(in2, LOW);
      delay(250);
      send(msg.set(HOSE_ON));
    }
  else
    {
      // turn off circuit for 1/4 second
      digitalWrite(in1, LOW);
      digitalWrite(in2, HIGH);
      delay(250);
      send(msg.set(HOSE_OFF));
    }
  
  // disable
  digitalWrite(in1, LOW);
  digitalWrite(in2, LOW);
  
}

mfalkvidd

@CrankyCoder if I understand correctly, the mqtt plot you provided is how often the battery status is sent?

And your expectation is that the battery status would be sent approximately every 30,000 milliseconds?

If so, the problem is that millis() is frozen during sleep. So the logic in the sketch is wrong. The sensor will report battery status after being awake 30000 milliseconds.

You can verify this by printing or reporting the value of millis() on the node.

CrankyCoder

The 30 seconds is what is passed to the smart sleep function based on the smartsleep() documentation. In this case SLEEP_TIME = 30000. The other stuff in the code around the millis() check i understand would be halted, but I believe the smart_sleep is different based on the documentation.

  #ifdef MY_DEBUG
    Serial.println("Going to sleep");
  #endif
  smartSleep(SLEEP_TIME);
  
  #ifdef MY_DEBUG
    Serial.println("Awake Now");
  #endif

CrankyCoder

Another quick update. I hooked my gateway up to my computer to get some debug logs off it. I am not seeing ANYTHING coming from that node using smartsleep at all. So it does appear the issue is specifically with that node.

Since it's battery powered i am going to see if i can get serial connected up without a reset and see what's it saying but i have a feeling it's going to be what ive seen before and it's having a hard time finding a parent for some reason. Not sure how to fix that.

skywatch

@CrankyCoder I have similar issue with a couple of nodes. Sometimes it looses signal for hours at a time...

It might be external interference from other devices like wifi, bluetooth or microwave oven.

It can also be connection issues especially with the push-on dupont connectors as when the temperature/humidity/air pressure change then the connectors can move slightly. Also they might be badly crimped in the first place.

So check all connections are good and can't move (soldering is best here), and then look for sources that might be an issue.

It could also be another node closer to the GW is sending at the exact same time as the problem node and masking the signal.

Batteries are susceptable to variations due to temperature too, they are a chemical reaction. So try a better source of power for testing too.

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

Also you are using sleep but have a receive function - what happens to messages when the node is asleep?

You are sending battery level every second? That is too often. How long will the batteries last? This wastes battery power a lot. I check betteries once a day on my security sensors, they don't change for weeks at a time....

Have you modified the pro mini as per the battery page on this site? Have you added capacitors to the radio module?

directionControl seems like it will always turn off both digital pins regardless of the message as //disable are the last statements to be actioned?

You can try changing

#define MY_RADIO_RF24

to.....

#define MY_RADIO_RF24
#define MY_RF24_PA_LEVEL RF24_PA_HIGH

options for power are MIN, LOW, HIGH, MAX. - it might help.

CrankyCoder

@skywatch said in smart sleep inconsistent?:

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

battery is only sent when there is a change in the voltage.

@skywatch said in smart sleep inconsistent?:

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

Where do you see that? i get 1 and 0 reported as needed based on the state.

@skywatch said in smart sleep inconsistent?:

Also you are using sleep but have a receive function - what happens to messages when the node is asleep?

That is what smartsleep does. It tells my controller (homeassistant) to queue up the messages. Which works fine, as long as the node wakes up.

@skywatch said in smart sleep inconsistent?:

Have you modified the pro mini as per the battery page on this site? Have you added capacitors to the radio module?

Correct, modified for battery use, and capacitors to the radio module.

@skywatch said in smart sleep inconsistent?:

directionControl seems like it will always turn off both digital pins regardless of the message as //disable are the last statements to be actioned?

This is correct, this is a directional H-bridge controller to pulse a latching solenoid valve, so I do not need them on but very briefly.

CrankyCoder

@skywatch said in smart sleep inconsistent?:

#define MY_RF24_PA_LEVEL RF24_PA_HIGH

I have the node and gateway on my desk now for testing, so I am going to reflash with this now! Fingers crossed it helps. :)

CrankyCoder

Got some more info. Here is some debug log off the gateway. The node in question is node 18

22:02:47.582 -> 28832653 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:03:51.377 -> 28896448 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:03:51.422 -> 28896512 TSF:MSG:BC
22:03:51.422 -> 28896533 TSF:MSG:FPAR REQ,ID=18
22:03:51.468 -> 28896566 TSF:PNG:SEND,TO=0
22:03:51.513 -> 28896594 TSF:CKU:OK
22:03:51.513 -> 28896615 TSF:MSG:GWL OK
22:03:51.967 -> 28897026 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:05:01.405 -> 28966464 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:05:01.497 -> 28966569 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:07:04.200 -> 29089296 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:07:04.246 -> 29089359 TSF:MSG:BC
22:07:04.292 -> 29089380 TSF:MSG:FPAR REQ,ID=18
22:07:04.337 -> 29089414 TSF:PNG:SEND,TO=0
22:07:04.337 -> 29089442 TSF:CKU:OK
22:07:04.382 -> 29089463 TSF:MSG:GWL OK
22:07:05.152 -> 29090214 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:10:01.430 -> 29266499 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:10:01.521 -> 29266604 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:10:59.660 -> 29324730 TSF:MSG:READ,38-38-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:10:59.706 -> 29324794 TSF:MSG:BC
22:10:59.706 -> 29324815 TSF:MSG:FPAR REQ,ID=38
22:10:59.751 -> 29324848 TSF:PNG:SEND,TO=0
22:10:59.797 -> 29324877 TSF:CKU:OK
22:10:59.797 -> 29324897 TSF:MSG:GWL OK
22:11:00.523 -> 29325594 !TSF:MSG:SEND,0-0-38-38,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

Running it through the log parser it would appear the gateway is responding to the find parent request.

BUT. The node it self seems to be failing to find parent periodically. Like it's not getting the message back from the gateway.

22:12:10.465 -> Going to sleep
22:12:10.465 -> 44562 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:10.465 -> 44572 !MCO:SLP:TNR
22:12:20.399 -> 54491 TSM:FAIL:RE-INIT
22:12:20.399 -> 54493 TSM:INIT
22:12:20.399 -> 54499 !TSM:INIT:TSP FAIL
22:12:20.444 -> 54501 TSM:FAIL:CNT=5
22:12:20.444 -> 54503 TSM:FAIL:DIS
22:12:20.444 -> 54505 TSF:TDI:TSL
22:12:20.489 -> 54575 MCO:SLP:MS=19999
22:12:20.489 -> 54577 !TSF:SND:TNR
22:12:21.035 -> 55080 TSF:TDI:TSL
22:12:42.255 -> 55083 MCO:SLP:WUP=-1
22:12:42.301 -> 55085 TSF:TRI:TSB
22:12:42.301 -> 55091 !TSF:SND:TNR
22:12:42.301 -> Awake Now
22:12:42.301 -> 1010
22:12:42.301 -> 3.29
22:12:42.301 -> Battery Voltage: 7.98 V
22:12:42.301 -> Battery percent: 94 %
22:12:42.301 -> sensorValue:1010
22:12:42.301 -> Going to sleep
22:12:42.301 -> 55099 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:42.301 -> 55109 !MCO:SLP:TNR
22:12:51.744 -> 64509 TSM:FAIL:RE-INIT
22:12:51.744 -> 64512 TSM:INIT
22:12:51.744 -> 64518 !TSM:INIT:TSP FAIL
22:12:51.744 -> 64520 TSM:FAIL:CNT=6
22:12:51.744 -> 64522 TSM:FAIL:DIS
22:12:51.744 -> 64524 TSF:TDI:TSL
22:12:52.330 -> 65112 MCO:SLP:MS=19999
22:12:52.330 -> 65114 !TSF:SND:TNR
22:12:52.829 -> 65617 TSF:TDI:TSL

mfalkvidd

!TSM:INIT:TSP FAIL indicates that the radio chip is not responding to the arduino's commands.

The most common cause is unreliable wiring. But it could be something else. Define MY_DEBUG_VERBOSE_RF24 to get more details.

mfalkvidd

Btw, are you using MySensors 2.3 on the node and the gateway?

skywatch

@CrankyCoder Do the data drop outs have any correlation to the solenoid valve operating and does the valave use the same power supply as the node MCU?

CrankyCoder

@mfalkvidd Will add this now.

CrankyCoder

@mfalkvidd said in smart sleep inconsistent?:

Btw, are you using MySensors 2.3 on the node and the gateway?

Correct 2.3 on node and gateway.

CrankyCoder

@skywatch unfortunately no. This is for a sprinkler valve that I haven't set up any automations for yet since the questionable reliability at the moment would flood my yard lol

CrankyCoder

Not sure if this helps or if anything jumps out, but here is the node and gateway side by side. Node does find parent request, gateway sees it, responds with 0. But node never gets it.

mfalkvidd

@CrankyCoder I am not sure but to me it looks like it takes a bit more than 1 second for the gateway to send the response? And by then, the node has already gone to sleep so it can't receive the message.

smart sleep inconsistent?

19

11.7k

11.2k

113.1k