Not to my knowledge.

Generally you'd create a function that takes an input value, and change that?

Sounds and looks good. I hope they make an I2C version. Imagine its library being drop-in compatible with the existing OLED displays. That would be something.

Hmm, this doesn't look good:

The display is 'write only' which means that it only needs 3 pins to send data. The downside of a write-only display isthat the entire memory must be buffered by the microcontroller driver.

If you have one of the older 96x96 pixel versions, then 96x96 bits = 1,152 bytes. On an Arduino Uno/Leonardo that'shalf the RAM available and so it might not be possible to run this display with other RAM-heavy libraries like SDinterfacing.

It has been accepted.

I've submitted a new version of the add-on that supports this.

Version 1.0.0 has been submitted to Mozilla.

• Support for time-outs. After a user-defined period of not receiving any sign of life (data/heartbeat), a node will be set to disconnected.
• Support for the new WebThings thermostat capability.

@mfalkvidd said in MySensors gateway and network reliability:

@alowhum MySensors resets the watchdog every time loop() is exited, so there is no need to call wdt_reset() unless you do something that takes a long time. If you do stuff that takes a long time you should call wait() instead, so messages can be processed.

Very interesting! If I don't call wait() manually, when does the library process messages? Also at the end of the loop?

Maybe the mysensors code should enable watchdog by default?

Sounds good to me! What is the code/memory overhead of doing this?

If the wdt_reset function is already being called in every loop, doesn't that imply that Arduino also already loads the entire watchdog code? Otherwise, wouldn't that cause a "function not found" error?

I wanted to do a quick test of the watchdog function on the serial gateway.

So originally I had a variable that would increment, and then make a wait() function take increasingly long. But to my surprise, this didn't trigger the watchdog.

#include <MySensors.h>                              // The MySensors library, which takes care of creating the wireless network.
#include <avr/wdt.h>                                // The watchdog timer - if the device becomes unresponsive and doesn't periodically reset the timer, then it will automatically reset once the timer reaches 0.

// Clock for the watchdog
#define INTERVAL 1000                               // Every second we reset the watchdog timer. If the device freezes, the watchdog will not re reset, and the device will reboot.
unsigned long previousMillis = 0;                   // Used to run the internal clock

int boogyman = 0;

void setup()
{
  Serial.begin(115200);                             // For serial debugging over USB.
  Serial.println(F("Hello, I am a Candle receiver"));

  wdt_enable(WDTO_2S);                              // Starts the watchdog timer. If it is not reset once every 2 seconds, then the entire device will automatically restart.                                 
}

void presentation()
{
	// The receiver does not have any extra children itself.
}

void loop()
{
  if(millis() - previousMillis >= INTERVAL){        // Main loop, runs every second.
    previousMillis = millis();                      // Store the current time as the previous measurement start time.
    Serial.print("resetting watchdog. Boogyman:"); Serial.println(boogyman);
    wdt_reset();                                    // Reset the watchdog timer
    wait(boogyman);
    boogyman = boogyman + 300;
  }
                              
  //delay(boogyman);
}

Even if the increasing variable would theoretically call the wait function for more than 2 seconds (the watchdog timeout), it just kept on increasing.

if I changed the wait() into a delay(), it would actually trigger the watchdog.

So, I'm curious: how does the wait function work? The Arduino can't do multi-tasking, right? So how is it possible that the loop that runs every second is still able to keep the watchdog at bay?

While I'm at it, I am also curious how the MySensors library integrates itself into the Arduino. It seems to manage the messages in the background perfectly well. Is that because the 'interupt' acts like a very basic multi-tasking?

I was under the assuption that using the loop above, this loop would never run 'paralel'. Is that assumption still correct?

This is actually a good reminder to implement a watchdog on the gateway

// Update:
Here's my new code:

/*
* 
* The Candle receiver acts as the bridge between the Candle devices and the Candle Controller. 
* 
* It only allows communication with other Candle devices that use the same encryption password as it uses itself. 
* When you install the Candle Manager, a random password is generated for you. If you ever want to change the encryption password used by your network, this can be done in the Candle Manager settings. 
* Be warned that you will have to re-create this receiver as well as all your devices, since they will all need to have new code with the new password in it.
* 
* If you have already installed the MySensors add-on, please temporarily disable it before creating this receiver. Otherwise the MySensors add-on may try to connect to it during the creation process, and thus disrupt it.
* 
*
* SETTINGS */ 

// You can enable and disable the settings below by adding or removing double slashes ( // ) in front of a line.

#define RF_NANO                                     // RF-Nano. Enable this if you are using the RF-Nano Arduino, which has a built in radio. The Candle project uses the RF-Nano.

/* END OF SETTINGS
*
*
*
*/


// Enable MySensors debug output to the serial monitor, so you can check if the radio is working ok.
//#define MY_DEBUG 

#ifdef RF_NANO
// If you are using an RF-Nano, you have to switch CE and CS pins.
#define MY_RF24_CS_PIN 9                            // Used by the MySensors library.
#define MY_RF24_CE_PIN 10                           // Used by the MySensors library.
#endif

// Enable and select radio type attached
#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

// Set LOW transmit power level as default, if you have an amplified NRF-module and
// power your radio separately with a good regulator you can turn up PA level.
//#define MY_RF24_PA_LEVEL RF24_PA_MIN
//#define MY_RF24_PA_LEVEL RF24_PA_LOW
//#define MY_RF24_PA_LEVEL RF24_PA_HIGH
#define MY_RF24_PA_LEVEL RF24_PA_MAX

// Enable serial gateway
#define MY_GATEWAY_SERIAL


// Mysensors advanced security
#define MY_ENCRYPTION_SIMPLE_PASSWD "changeme"      // The Candle Manager add-on will change this into the actual password your network uses.
//#define MY_SECURITY_SIMPLE_PASSWD "changeme"      // Be aware, the length of the password has an effect on memory use.
//#define MY_SIGNING_SOFT_RANDOMSEED_PIN A7         // Setting a pin to pickup random electromagnetic noise helps make encryption more secure.

// Mysensors advanced settings
//#define MY_RF24_CHANNEL 100                       // In EU the default channel 76 overlaps with wifi, so you could try using channel 100. But you will have to set this up on every device, and also on the controller. You can even try 115.
//#define MY_RF24_DATARATE RF24_250KBPS             // Slower datarate increases the range, but the RF-Nano does not support this slow speed.
#define MY_RF24_DATARATE RF24_1MBPS                 // This datarate is supported by pretty much all NRF24 radios, including the RF-Nano.
#define MY_SPLASH_SCREEN_DISABLED                   // Saves a little memory.

#include <MySensors.h>                              // The MySensors library, which takes care of creating the wireless network.
#include <avr/wdt.h>                                // The watchdog timer - if the device becomes unresponsive and doesn't periodically reset the timer, then it will automatically reset once the timer reaches 0.

// Clock for the watchdog
#define INTERVAL 1000                               // Every second we reset the watchdog timer. If the device freezes, the watchdog will not re reset, and the device will reboot.
unsigned long previousMillis = 0;                   // Used to run the internal clock

void setup()
{
	// Setup locally attached sensors

  wdt_enable(WDTO_2S);                              // Starts the watchdog timer. If it is not reset once every 2 seconds, then the entire device will automatically restart.                                 
}

void presentation()
{
	// The receiver does not have any extra children itself.
}

void loop()
{
  if(millis() - previousMillis >= INTERVAL){        // Main loop, runs every second.
    previousMillis = millis();                      // Store the current time as the previous measurement start time.
    
    wdt_reset();                                    // Reset the watchdog timer
  }
}


/**
* 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-2018 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.
*/

@rozpruwacz said in Build retry funtionality into the mysensors library:

It may turn out that there is no ONE algorithm that will fit all cases ...

Agreed. It seems to me that a small home with about 10 to 15 devices should be able to run on Arduino Nano's and offer a decent level of predictability. If all devices send, on average, one message per minute, then this would mean one message every 70 milliseconds. Most of these devices will be connected to the gateway directly. Let's say half of them require

So in a basic home situation a buffer for two messages would be fine, and three would be a luxury.

If you want to run a large scale sensor network, then it makes sense to upgrade your parts too (bigger antenna on the gateway, more ram on nodes that extend the network).

Retry functionality, in the normal home scenario, probably isn't so much about how many messages are buffered, but about how long people turn on the microwave oven, which disrupts the network. So for me it's about having control over the (exponential) time period that the node keeps retrying. The memory/buffering capacity of my home network is fine, it's just that I don't want to implement this "keep retrying for longer" routine myself.

Which #define values could I already change today to get the nodes to keep retrying for longer than just a few seconds?

@mfalkvidd said in idea: allow the present function to indicate if an echo will be sent:

To my knowledge, the MySensors library itself will send an echo when requested. There is no need to present if the node supports echo or not, echo is always enabled.

Very interesting!