Water Sensor Issue
-
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 childMySensor 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 11void 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
} -
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.
-
@Dan-S ,
have you tried:
gw.begin(NULL, RADIO_ID, false);where RADIO_ID is defined as:
#define RADIO_ID 3instead of:
gw.begin()?
-
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.
-
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.
@Dan-S. said:
define CHILD_ID 0
you didn't change this did you:
#define CHILD_ID 0you should have node 3 and sensor zero...
-
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.
-
@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?
-
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.
-
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.
-
Anybody have any insights on what would cause the include process to create a zero node?
-
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.
-
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?