Sensor not sleeping properly when Gateway is down?
-
I'm starting a new thread about this as previously I hijacked someone else's old thread.
I'm currently playing around with MySensors and the first sensor I'm trying to build using it is a door sensor. It's battery powered and it's working just fine (using about 6uA while sleeping, so batteries should last a good while). But when I don't have my Gateway (a Raspberry Pi Zero W with MQTT Gateway) online, the power consumption seems to stay pretty high (3mA or so). So it seems that the sensor is not sleeping properly, but instead tries to reconnect to the Gateway all the time?
This is my sketch:
// Enable debug prints to serial monitor //#define MY_DEBUG // Set how long to wait for transport ready in milliseconds #define MY_TRANSPORT_WAIT_READY_MS 3000 // Enable and select radio type attached #define MY_RADIO_NRF24 // Set this nodes id. Needs to be unique between nodes (value = 1-254) #define MY_NODE_ID 102 #include <SPI.h> #include <MySensors.h> #define CHILD_ID 3 #define DOOR_PIN 3 // Arduino Digital I/O pin for button/reed switch #define SLEEP_TIME 3000 // Sleep time between heartbeats (seconds * 1000 ms) int oldValue = -1; MyMessage msg(CHILD_ID, V_TRIPPED); void setup() { pinMode(DOOR_PIN, INPUT); } void presentation() { present(CHILD_ID, S_DOOR); } void loop() { int value = digitalRead(DOOR_PIN); if (value != oldValue) { send(msg.set(value == HIGH ? 1 : 0)); oldValue = value; } wait(10); Serial.println("Going to sleep now..."); smartSleep(digitalPinToInterrupt(DOOR_PIN), CHANGE, SLEEP_TIME); }
I tried enabling debug and this is what I get in the loop:
30812 MCO:SLP:MS=0,SMS=0,I1=0,M1=1,I2=1,M2=1 30818 !MCO:SLP:TNR Going to sleep now...
And yes, I know it's not very efficient to only sleep for 3 seconds, that's there only for testing this thing out.
-
@Tinimini have you checked with longer sleep duration ?
Can you provide the log after the "going to sleep now" line ?Because in the configuration of the library you can set the duration during which it will try to connect to gateway before going to sleep and default duration is 10s :
MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS 10000 Timeout (in ms) to re-establish link if node is put to sleep and transport is not ready.From what I see in the code after reconnexion process is finished it will calculate the remaining sleeping time and only sleep for the remaining duration. If your sleep time is less than the reconnect timeout it will not sleep.
// Do not sleep if transport not ready if (!isTransportReady()) { CORE_DEBUG(PSTR("!MCO:SLP:TNR\n")); // sleeping not possible, transport not ready const uint32_t sleepEnterMS = hwMillis(); uint32_t sleepDeltaMS = 0; while (!isTransportReady() && (sleepDeltaMS < sleepingTimeMS) && (sleepDeltaMS < MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS)) { _process(); sleepDeltaMS = hwMillis() - sleepEnterMS; } // sleep remainder if (sleepDeltaMS < sleepingTimeMS) { sleepingTimeMS -= sleepDeltaMS; // calculate remaining sleeping time CORE_DEBUG(PSTR("MCO:SLP:MS=%lu\n"), sleepingTimeMS); } else { // no sleeping time left return MY_SLEEP_NOT_POSSIBLE; } }
-
Okay, that seems to explain this. I changed the sleeping time to 20 seconds and sure enough, after about 10 seconds the current draw dropped down to ~7uA. So looks like I'm good now.
So what did I learn from this? Well... I better start reading the source code for MySensors Either that, or write my own lib so I know what is going on
Thanks for the help!
-
@Tinimini great that you found a solution. It might not be necessary to read the source code. Reading the documentation might be easier. MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS is documented at https://www.mysensors.org/download/sensor_api_20#configuration
-
@mfalkvidd said in Sensor not sleeping properly when Gateway is down?:
@Tinimini great that you found a solution. It might not be necessary to read the source code. Reading the documentation might be easier. MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS is documented at https://www.mysensors.org/download/sensor_api_20#configuration
Exactly, read the doc ! It just takes a few mins for an overview of the config keys available.
Then by curiosity you can just search for the config key in the code to see how it was used, but that's in no way mandatory.
-
Oh yeah... Read the docs.. Yes, I probably should do that too Thanks!