Water Sensor Issue

[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?