SensorMotion to send both tripped and not tripped

tubby

Thanks guys got it running.
after a lot of stuffing around

the problem I'm having now is the controller always say that its tipped (Using home assistant)
It looks to me that the node doesn't send an off trip, only an on.

here is my node output

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 MCO:BGN:BFR
REG I=1 P=3 P=1 T=16
NodeManager v1.5
INT1 M=3
INT2 M=255
6 TSM:INIT
10 TSF:WUR:MS=0
17 TSM:INIT:TSP OK
19 TSF:SID:OK,ID=1
21 TSM:FPAR
57 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2064 !TSM:FPAR:NO REPLY
2066 TSM:FPAR
2102 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2928 TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
2933 TSF:MSG:FPAR OK,ID=0,D=1
4110 TSM:FPAR:OK
4111 TSM:ID
4112 TSM:ID:OK
4114 TSM:UPL
4117 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
4126 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1
4131 TSF:MSG:PONG RECV,HP=1
4134 TSM:UPL:OK
4135 TSM:READY:ID=1,PAR=0,DIS=1
4141 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
4147 TSF:MSG:READ,0-0-1,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
4154 TSF:MSG:SEND,1-1-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
4163 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
4802 TSF:MSG:READ,0-0-1,s=255,c=3,t=6,pt=0,l=1,sg=0:M
RADIO OK
4809 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=OK:NodeManager
4818 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
PRES I=200, T=23
4827 TSF:MSG:SEND,1-1-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=OK:
PRES I=201, T=30
4835 TSF:MSG:SEND,1-1-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=0,st=OK:
BATT V=4.57 P=100
SEND D=0 I=201 C=0 T=38 S= I=0 F=4.57
4912 !MCO:SND:NODE NOT REG
4920 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
PRES I=1 T=1
4928 TSF:MSG:SEND,1-1-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
READY

4934 MCO:REG:REQ
4937 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
4951 TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1
4956 MCO:PIM:NODE REG=1
4958 MCO:BGN:STP
MY I=1 M=1
4960 MCO:BGN:INIT OK,TSP=1
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=0 T=16 S= I=1 F=0.00
4966 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

4973 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
4980 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:21
5487 MCO:SLP:TPD
5488 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
5493 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

5502 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
5510 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:551
6017 MCO:SLP:TPD
6018 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
6023 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

6032 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
6039 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1080
6546 MCO:SLP:TPD
6547 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
6552 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

6561 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
6568 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1609
7076 MCO:SLP:TPD
7077 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
7083 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

7092 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
7099 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:2140
7606 MCO:SLP:TPD
7607 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
7612 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

7621 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
7628 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:2669
8135 MCO:SLP:TPD
8136 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
8141 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

8151 MCO:SLP:MS=60000,SMS=1,I1=1,M1=3,I2=255,M2=255
8158 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:3199
8665 MCO:SLP:TPD
8666 MCO:SLP:WUP=1
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
8671 TSF:MSG:SEND,1-1-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
SLEEP 60s

is this correct? Looks to me that the node sends a (1) when tripped but not a (0) when motion stops.
This makes my controller think that there is constant motion

user2684

@tubby SENSOR_MOTION reacts on RISING only so you will not get the low tripped. Try adding the following:

sensorMotion->setInitial(LOW);
sensorMotion->setMode(CHANGE);

This should send a message on both RISING and FALLING.

tubby

@user2684 I really appreciate the help.
and now I'm able to use all the extra inbuilt features of the code, now that i know how to add them to the sketch.

And I hate to be a pain but I cant seem to get this damn motion sensor to work properly.
I've tried the examples you have given me, I've played around with every possible thing I can think/read.
But for the life of me cant get it to send a (0) for non tripped.

I assume the (CHANGE) interrupt option should be sending a msg on a motion detect ie: (1)
and then when the pin goes low it should send a (0), but it seem that the node has already gone to sleep and the changed state is not being recorded.

What else could I try?

user2684

@tubby said in NodeManager: plugin for a rapid development of battery-powered sensors:

assume the (CHANGE) interrupt option should be sending a msg on a motion detect ie

Correct, when mode is set to CHANGE, the node wakes up with both RISING (0 to 1) or FALLING (1 to 0) interrupts and regardless of the value previously sent, the pin's value is read again and a new message sent back to the gw. The only situation I think this would not work is when the node is NOT sleeping since the interrupt is configured only before entering a sleeping cycle. So if you have a 1 and then immediately a 0, the node has not entered the sleep cycle so the interrupt is lost. For how long does the pin stays to 1 after triggering the motion? Thanks

tubby

@user2684 exactly what I thought about the (change) .

I have a test rig setup at the moment and I have been pulling the pin high and low manually with a jumper wire.
I've held the pin high for up to 30 seconds.
The node sends a high value. Than the sleep msg.
Up to 30 seconds latter I disconnect the high and connect to low but nothing happens, the node just sleeps either till the amount in the timer or if the pin is pulled high again.

I imagine this is the sort of behaviour you would see with a (rising) state

gohan

@user2684 It is an issue I discussed some time ago and a solution was to set a shorter sleep time when the pin was high so it could report the pin low within a reasonable amount of time and then sleep normally.

tubby

@gohan How would I implement that?
I only see options for overall sleep time, none that allow me different sleep time for only when the pin is high.

I'm sorry for all these questions, I feel like an idiot, but I'm so close to getting all the sensors that I need on one board. That I would have no hope of configuring without node manager.

One hurdle left...

gohan

one way would be to use the sleep time as a variable that you can change it to 5000 when the pin goes high and back to the original value when pin goes low with a normal IF statement

user2684

@gohan I may have probably missed this one sorry. Did you just shorten the debounce time? My guess @tubby is that you are sleeping for too long after the tripped message. When you say sensorMotion->setTriggerTime(4000);, the node will do nothing for 4 seconds after the "on" message. If the "off" happens during those 4 seconds, the event will be lost. Try lowering this down a bit or compare it with the time it takes for the signal to be restored to low. Thanks

user2684

Hi, I finally got a chance to run some more tests but I see the expected behavior even if here looks like different people are experiencing the opposite.
This is my sketch:

nodeManager.setSleep(SLEEP, 30, MINUTES);
  int sensorPIR_Id = nodeManager.registerSensor(SENSOR_MOTION,3);
  SensorMotion* sensorMotion = (SensorMotion*)nodeManager.getSensor(sensorPIR_Id);
  sensorMotion->setMode(CHANGE);
  sensorMotion->setInitial(LOW);

And those are my logs:


WAKE P=3, M=1
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
SLEEP 1800s

WAKE P=3, M=1
AWAKE
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00
SLEEP 1800s

As you can see as motion is detected a 1 is reported (and the board goes to sleep), after a couple of seconds the board wakes up to report the 0.
I'm not using debounce or trigger time here which instead may have an impact (both debounce and trigger time puts the board to sleep and if the signal changes during it, the interrupt will be lost).
Let me know if I'm doing something different.
Thanks

Sergio Rius

In fact, what I experience is something different. Sensor detects movement so wakes, but it still wakes every 3sec until low threshold is sent back from the pir:

WAKE P=3, M=3
AWAKE
ON P=5
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
OFF P=5
SLEEP 60
WAKE P=3, M=3
AWAKE
ON P=5
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
OFF P=5
SLEEP 60
WAKE P=3, M=3
AWAKE
ON P=5
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
OFF P=5
SLEEP 60
WAKE P=3, M=3
AWAKE
ON P=5
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
OFF P=5
SLEEP 60
WAKE P=3, M=3
AWAKE
ON P=5
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
OFF P=5
SLEEP 60
WAKE P=3, M=3
AWAKE
BATT V=3.12 P=73
SEND D=0 I=201 C=0 T=38 S= I=0 F=3.12
ON P=5
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00
OFF P=5
SLEEP 60

So I don't know if the "low" is triggering or simply it stops querying when the value is low.

user2684

@Sergio-Rius got it but that's really weird. If we assume when the board wakes up the first time the signal stays HIGH for a while, when goes back to sleep there should not be any interrupt unless the signal continuously moves between LOW and HIGH. I'd try the following: first of all remove the power pin (it should not matter but better removing any background noise) and second, check with a multimeter how the signal really behaves.
PS. Are you using CHANGE or RISING?
Thanks!

Sergio Rius

@user2684
I'm using CHANGE. What do you mean with remove the power pin? Cutting power to the sensor? Pulling the signal cable and testing it with a multimeter?
I have a led wired in parallel that lights when the sensor sends high. I can't see anything strange.

user2684

@Sergio-Rius I meant just registering the pir and not the other sensor (a DHT if remember correctly) and avoid using setPowerPins(). Just to keep it simple and ensure there are no other variables influencing the test for now. Good to know the led is telling you the signal stays high consistently, we need to know now why the board gets the interrupt while it shouldn't :)

Sergio Rius

Deactivating all the modules and sensors except the PIR, revealed that the node still wasn't detecting the low signal. The sensor is configured with approx. 30sec reset delay.

  /*
     Register below your sensors
  */

  nodeManager.setSleep(SLEEP, 60, SECONDS);

  int sensorPIR_Id = nodeManager.registerSensor(SENSOR_MOTION,3);
  SensorMotion* sensorMotion = (SensorMotion*)nodeManager.getSensor(sensorPIR_Id);
  sensorMotion->setMode(CHANGE);
  sensorMotion->setInitial(LOW);

  /*
     Register above your sensors
  */

Here is a sample debug output from nodemanager:

REG I=1 P=3 P=1 T=16
NodeManager v1.5
INT1 M=3
INT2 M=255
RADIO OK
PRES I=200, T=23
PRES I=1 T=1
READY

MY I=3 M=1
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=0 T=16 S= I=0 F=0.00
SLEEP 60
<= HERE I PUT MY FINGER ON SENSOR
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
SLEEP 60
**HERE LOW CONDITION HAPPENED**
<= HERE I PUT MY FINGER ON SENSOR
WAKE P=3, M=3
AWAKE
SWITCH I=1 P=3 V=1
SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00
SLEEP 60
**HERE LOW CONDITION HAPPENED**
**Nothing happens until sleep cycle ends**
AWAKE
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00
SLEEP 60
AWAKE
SWITCH I=1 P=3 V=0
SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00
SLEEP 60
...

The same hardware, using my custom sketch, just works properly. There's the output. It's configured to sleep 10min between ambient measurements, wake on pir (M:) high and low. The graph at the end of the lines shows time request and reception and multiple measurements with running average.

Initialising...
Update interval: 10 min (600000 ms)
Sampling size: 5 samples
Ready!
?......!0*1*2*3*4*
[7:13:11:01][M: 0][BAT: 3252mV / 96% ][T:*25.50º / H:*59.84% ]  SLEEP! ?0*!1*2*3*4*
[7:13:13:10][M: 1][BAT: 3261mV / 97% ][T: 25.50º / H:*59.64% ]  SLEEP! ?0*!1*2*3*4*
[7:13:13:28][M: 0][BAT: 3261mV / 97% ][T:*25.54º / H:*59.62% ]  SLEEP! ?0*!1*2*3*4*
[7:13:15:32][M: 1][BAT: 3261mV / 97% ][T:*25.60º / H:*59.40% ]  SLEEP! ?0*!1*2*3*4*
[7:13:15:52][M: 0][BAT: 3261mV / 97% ][T: 25.60º / H:*59.42% ]  SLEEP! ?0*!1*2*3*4*
[7:13:16:41][M: 1][BAT: 3261mV / 97% ][T: 25.60º / H:*59.66% ]  SLEEP! ?0*!1*2*3*4*
[7:13:17:01][M: 0][BAT: 3261mV / 97% ][T: 25.60º / H:*59.64% ]  SLEEP! ?0*!1*2*3*4*
[7:13:28:20][M: 0][BAT: 3261mV / 97% ][T:*25.50º / H:*59.90% ]  SLEEP!

I'm trying to find the NM problem by debugging it but I just can't find anything relevant. Perhaps we should reduce the code to only movement fuctionality... Perhaps some debounce functionality that interferes even being deactivated (thinking aloud)

user2684

@Sergio-Rius thanks a lot for the debugging so far. The only difference I clearly see is the mode which is reported when waking up. In your case is always 3 (RISING), in mine and with your custom sketch is instead 1 (CHANGE). Would you mind commenting out setMode(RISING) in the constructor of SensorMotion in your NodeManager.cpp?
My concern is that with v1.5 setMode just changing the local variable and not the interrupt's setting which is what is used to wake up when passing it to MySensors' sleep(). The other try would be to see if with https://github.com/mysensors/NodeManager/tree/development the situation changed since that part of the code has been almost completely rewritten.

Thanks!

Sergio Rius

@user2684
If the code has seen so many changes, then I'll first try the development branch and tell you something. I'll be more productive debugging the new version.
Thank you.

PD: On the pull I'd made, you where right I need to redo my fork with your instructions. I'll make it as soon as I have some spare time.

user2684

@Sergio-Rius thanks, yes, probably trying with the dev version would be quicker even if still I'd probably need a hotfix to make it work with 1.5 as well.
No problem regarding the pull request, my fault not providing decent instructions since the beginning but I'm learning along the way as well ;-) Thanks

user2684

@Sergio-Rius FYI I've just merged into the development branch a pretty massive change in the way interrupts are handled, conforming the behavior between sleeping and not sleeping nodes (more information on https://github.com/mysensors/NodeManager/pull/151). If you will pull the updated development branch, you should get the new changes as well. No major changes in the API, it is more related to what happens behind the scene. Thanks

Sergio Rius

@user2684 Thanks for the info, I've udpated my local copy for using the last changes. I see that the presence sensor work properly with the dev branch.

SensorMotion to send both tripped and not tripped

21

11.7k

11.2k

113.1k