#define WITH_SENSOR TRUE

[johnhulth]

Instead of:

define WITH_I2C TRUE

We should do:

define WITH_BME76 TRUE

define WITH_BME TRUE

define WITH_TMP TRUE

define WITH_VL TRUE

define WITH_MLX TRUE

define WITH_AS TRUE

[johnhulth]

Even better would be to add run intervall to give defult values:

define WITH_BME76 60 //run every 60 min

define WITH_BME 5 //run every 5 min

define WITH_TMP 0 // don't use and dont compile

define WITH_VL 5 //run every 5 min

define WITH_MLX 5 //run every 5 min

define WITH_AS 0 // don't use and dont compile

[ArcticSnow]

The idea is:

1. reduce the memory usage of the program and cherry pick sensors to run
2. have an initial time sampling we can preset. Because at the moment when uploading the script to a new waspmote, all sensors are by default all set to a sampling interval of 10 min. Each sensor needs to be modified manually, which is quite cumbersome when in the field.

[jdavid]

(1) To reduce memory usage there's something simple we can do. The api is full of code that is run only for some features we don't use. for instance I would do something like this:

diff --git a/waspmote-api/WaspPWR.cpp b/waspmote-api/WaspPWR.cpp
index 73250a9..0a224d7 100644
--- a/waspmote-api/WaspPWR.cpp
+++ b/waspmote-api/WaspPWR.cpp
@@ -331,6 +331,7 @@ void WaspPWR::switchesOFF(uint8_t option)
        // check if an Agriculture Sensor Board is used. In this case, 
        // switch off the digital pins so as not to waste energy
        if (WaspRegisterSensor & REG_AGRICULTURE)
+       if (false)
        {
                // switch off sensors power supply
                digitalWrite(DIGITAL7, LOW);

The compiler will omit this unreachable code. Or we could simply remove it.

This way we may free enough memory to enable all the sensors again.

[jdavid]

(2) These values are read from the eeprom, each action takes 2 bytes. First we should define a special value that means: "null, use the default", for instance it may be 0xFFFF.

But it's not so simple. If we add a new sensor, for instance, it will read this value from some location in the eeprom. And most often it won't read our special 0xFFFF value, but something else, so it won't use the default.

To implement this we first need to add versioning to our code. Detect when the mote boots for the first time with a new version, and initialize the eeprom fields for the new actions. So it's quite some work. There's already an issue to version our code.

[jdavid]

Well, there's a better approach actually. I was thinking about storing this information not in the eeprom, but in a file in the SD card. This will bring more flexibility, and will allow to implement these defaults. But it's also quite some work.

[ArcticSnow]

(1) Absolutely, skimming off unnecessary code seems a simple primary fix then (2) not critical, however it would simplify deployment and reduce chances of having unproper settings.

[jdavid]

(1) I've done this one, but it only saves about 512 bytes, not enough

[ArcticSnow]

This has been worked on a fair can be closed