Motion Sensor, flaky behavior

[epierre]

I am to say I have the same issue...

I have a big difference between what the serial displays and what the gw receives... even when adding such to prevent too much radio...

if (lastValue != tripped) {
gw.sendVariable(CHILD_ID, V_TRIPPED, tripped?"1":"0");  // Send tripped value to gw     
}
lastValue=tripped;

here it is pointing to the ground:

2014-07-26 20:47:03 4 1 1 0 26.1
2014-07-26 20:47:04 7 0 1 16 0
2014-07-26 20:47:04 7 0 1 16 1
2014-07-26 20:47:05 7 0 1 16 0
2014-07-26 20:47:08 7 0 1 16 1
2014-07-26 20:47:11 7 0 1 16 0
2014-07-26 20:47:14 7 0 1 16 1
2014-07-26 20:47:16 7 0 1 16 0
2014-07-26 20:47:20 7 0 1 16 1
2014-07-26 20:47:24 7 0 1 16 0

[epierre]

oooppppssss... wiring error.... @hek always told me to double check...

Here some hysteresis could be added, as commercial grade motion sensor, a value the gateway could send to modify how long the presence sensor will not send the "alarm is over", avoiding thus lots of notifications on server side and lot of redundant messages, here one every 2s ...

[naveen]

I'm wondering if there is some way to do this:

-send tripped command to gw/vera
-poll gw/vera for the state of the tripped command (this is the step I have no idea how to do)
-if value of tripped which was sent does not match the value in vera, resend command
-repeat

That way you ensure the message is continually sent until it is received (up to some finite number of times to prevent infinite loops)

[hek]

If you would consider moving your sensor network to 1.4 you can ask for an ack from gateway when you send in your tripped status.

This mean the gateway will reply back to you sensor and you can pick up this answer (or choose to resend status again after some timeout if ack never reaches your node).

[epierre]

@hek is there a way to make an interrupt with time ?

I mean:

• if it is tripped and previous status was untripped, send the alarm
• if it is untripped but below a certain time don't send anything
• after a while, the timer sends an untrip after the amount of time

[hek]

@epierre

Yes, all this should be possible.
Untripped should probably still be handled by the motion sensor (you will get an interrupt when state changes and can use the trimpot to change delay).

[epierre]

@hek you mean only the hardware way ?

Here if under 20s (in arduino time) I get my untrip, I don't send it. If a timer don't occurs, the untrip will never be sent.

any idea ?

[hek]

@epierre

How do you keep track of time while sleeping your Arduino?

[epierre]

@hek do the millis does it ? else I can add a rtc

[naveen]

@hek

Is there any reason I should avoid 1.4? I wouldn't mind upgrading if it'll make my sensors a bit more robust. I'm waiting for 5V power supplies in case the 12V power supply I have is what is causing my issues

[hek]

@naveen

No, not really. Go for it. But things might still change (protocol/api) in 1.4. But that does not mean you have to update every day :smiley:

[BulldogLowell]

@Yveaux said:

@naveen Did you check the 5v with a multimeter?
I have an identical breadboard supply and fried mine with a "12v" adapter. After measuring the output of the adapter it appeared to be around 16v and the onboard voltage converter (ams1117 if I recall right) had it's maximum input set to 15v or so...

that happened to me once too.

[jendrush]

@BulldogLowell I fried my breadbord power supply by connecting broken power adaptor(it have me about 13-14V instead of up to 12V), this fried AMS1117 5V. I replaced it, and it's working proper again.