Water Sensor Issue

[Dan S.]

I took the Rain and Moisture sketch an modified it by reversing the interrupt so it triggered when water was detected rather than the no water trigger. I also added a buzzer function that was called when the interrupt was triggered. Used this as a water detector near the basement water heater. Also set Vera to email me if moisture was detected.

All went well for several days, Vera showed the water sensor as armed but not triggered. Then suddenly I started receiving multiple Vera emails notifying water detection. Checked Vera and found that the water detector trigger was being triggered on and off and if I set it to off, it triggered on again. I verified that the sensor was not detecting water and even unplugged the board but yet the node was indicating that it was being updated when the trigger status changed.

The sensor sketch as I modified it would go into an endless buzzer loop if triggered, i.e., it could not go back to untriggered status unless it was reset. So I know it was not triggered. There was no buzzer when Vera reported the triggers, and I tested and verified again that it would go off if water was detected by holding a wet finger on the sensor.

I am at a loss to explain the cause of Vera suddenly reporting multiple changes in the trigger status of the sensor even though no status change was detected or reported by the sensor.

Would appreciate any suggestions on how to proceed. I have since deleted the node/sensor from vera and will include it again from scratch to test further.

[BulldogLowell]

@Dan-S.

Post the code you were using... perhaps you just overflowed a variable or there is another issue in the program.

The sensors test out OK (on their own)?

[Dan S.]

The code is below (I assume you meant post rather than upload):

#include <SPI.h>
#include <MySensor.h>

#define DIGITAL_INPUT_WATER_SENSOR 3 // Digital input did you attach your soil sensor.
#define INTERRUPT DIGITAL_INPUT_WATER_SENSOR-2 // Usually the interrupt = pin -2 (on uno/nano anyway)
#define CHILD_ID 0 // Id of the sensor child

MySensor gw;
MyMessage msg(CHILD_ID, V_TRIPPED);
int lastWaterValue = -1;
//beep delay
unsigned char delayms = 200;
// declare pin # for buzzer analogwrite output:
int buzzpin = 5; //can only analogwrite to 3, 5, 6, 9, 10, and 11

void setup()
{
gw.begin();

// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Water Alarm Sensor", "1.0");
// sets the soil sensor digital pin as input
pinMode(DIGITAL_INPUT_WATER_SENSOR, INPUT);

//declare the buzzer pin as output
pinMode(buzzpin, OUTPUT);

// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID, S_MOTION);
}

void loop()
{
// Read digital soil value
int WaterValue = digitalRead(DIGITAL_INPUT_WATER_SENSOR); // 1 = Not triggered, 0 = In water
if (WaterValue != lastWaterValue) {
Serial.println(WaterValue);
if (WaterValue==0)
{
Serial.println("no water");
gw.send(msg.set(0));
}
else
{
Serial.println("WATER!");
gw.send(msg.set(1)); // Send tripped when water detected
//sound alarm with endless loop
alarm();
}
lastWaterValue = WaterValue;
}
// Power down the radio and arduino until digital input changes.
gw.sleep(INTERRUPT,CHANGE);
}

void alarm()
{
while( 1 ) // endless loop
{

analogWrite(buzzpin, 20); // Almost any value can be used except 0 and 255
// experiment to get the best tone
delay(delayms); // wait for a delayms ms
analogWrite(buzzpin, 0); // 0 turns it off
delay(delayms);
} // wait for a delayms ms
}

[Dan S.]

I cleared the eeprom and tried to reinclude the sensor and I keep getting a node of 0 rather than 3 (this is my third node). which I got when I previously included it. Don't know what is causing the node 0 assignment.

[BulldogLowell]

@Dan-S ,

have you tried:

gw.begin(NULL, RADIO_ID, false);

where RADIO_ID is defined as:

#define RADIO_ID 3

instead of:

gw.begin()

?

[Dan S.]

Tried gw.begin(NULL,3); Gave me a node 3 and sensor 3.0, but surprisingly also gave me a node 0 and sensor 0.0. I deleted node 0 and sensor 0.0 from Vera. Node 3 and sensor 3.0 appear to be working fine along with the sensor itself. All sensors appear to be working normally as before.

[BulldogLowell]

@Dan-S. said:

define CHILD_ID 0

you didn't change this did you:

#define CHILD_ID 0

you should have node 3 and sensor zero...

[Dan S.]

No. Only the the gw.begin. It should be (and is) node 3 and sensor 3.0 (and 3.1 if I had a second sensor attached to the sketch.

[MagKas]

@Dan-S.
Might be a long shot but can it be a message sent from another sensor you have where the radio-id 'changes' to the one of your water alarm sensor?

I mean: when I was testing different values of capacitors on the radio modules and even played a little with the PA_LEVEL for the radios I noticed that sometimes the gateway received a radio message from my test sensor and sent it to Vera but with different values/radio-id. Not that the gateway changed the radio-id but the message was received with some bits changed. I hope you understand what I try to say here...
And it couldn't have been another sensor because I only had made one at that time.

Don't know if the radio message from sensor to gateway has a CRC check, but it definitely should have it.

So, if you don't find another reason for this behaviour, you might check the Vera log for messages that seems messed upp a little. Or try to power down some other sensors that might generate same kind of messages as your water alarm sensor.

Maybe you moved a sensor to a different place so that it's radio got a worse reception?

[BulldogLowell]

@Dan-S.

yeah, I wasn't reading what you wrote!

works good now, then?

[Dan S.]

Yes, it's back to working now but I still don't know what caused the issue in the first place. I'm certain the on/off tripping was not the result of the sensor sending tripped/untripped messages. Am concerned it may happen again. Need more stability than that for an alarm type sensor.

@Magas:: My other sensors are light and temp/humidity and not motion sensors.

I also want to find out why I keep getting a node 0 sensor on include unless a use a static id. Didn't have this problem before and it may be related to the issue.

I appreciate the suggestions.

[Dan S.]

Anybody have any insights on what would cause the include process to create a zero node?

[Dan S.]

OK I found out what was causing my node zero. I had deleted the sensor from Vera and cleared the eeprom with a generic program I had downloaded from the internet--not the one provided on mysensors.org. Unfortunately the program I downloaded cleared the eeprom by filling it with zeros, not 255 which is the default initial value of each byte in a new arduino eeprom. The my sensors.org program correctly fills all bytes with 255.

So in effect, by filling the eeprom with zeros I had designated it as node zero--live and learn.

[Dan S.]

Something else I discovered in looking at the zero node issue. As soon as I download a sketch to the arduino and the sketch executes, it is given a node id by the gateway--before the any formal include process is started. I thought the node id was generated during the inclusion process. Is this right?