SensorMotion to send both tripped and not tripped

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

[user2684]

@Sergio-Rius cool, glad to hear this is working fine with the dev branch

[Sergio Rius]

@user2684 said in SensorMotion to send both tripped and not tripped:

Would you mind commenting out setMode(RISING) in the constructor of SensorMotion in your NodeManager.cpp?

I've checked it and if commenting the line, the sensor works as expected. ;)

[user2684]

@Sergio-Rius do you mean that with RISING does not work at all or would be better to have CHANGE instead? I'm ok in changing the default behavior if this is what users like the most

[Sergio Rius]

@user2684 In my code, I'm using CHANGE. Leaving the library as is, CHANGE doesn't function properly. For better answering your question I would have to understand what does setMode(RISING); at line 1200 of NodeManager.cpp.
My understand is that if you offer changing the behaviour, user changes should not been overidden. so I guessed that line was a default setting. But seems that doesn't respect user values.

I would experiment with the other possible Mode values leaving that line commented.

[Sergio Rius]

@user2684 said in SensorMotion to send both tripped and not tripped:

changing the default behavior if this is what users like the most

Depending on how is it programmed and it's application. Can I ask for everything?
Most cases I prefer versatility. Nowadays you can get instructions for doing almost anything on raising online communities, but Very often they also offer corseted (popular, stereotypical) solutions.

Let me find an example: It makes sense to control rising status on a movement sensor because most of people would like to sense movement on a small room. But it makes more sense for some others to monitor absence of movement. For power saving, for example. You could have a discrete power system for all IoT, a solar supply and wanted to disable not using components.
A simple security system would also fail with the controller I'm using, because it stays "in alarm" until the movement has gone (receives low).

Again, most solutions I find on inet are ok for a small sized flat, but gives trouble on a medium sized house.
In my house, for example, until repeaters where implemented, mysensors was nothing but a playtoy for me. But I guess having a large sized, stone house (24cm stone thickness and heating floorings really kill radio signals), with displaced floorplans (problematic wire routings) placed just at the frontier with another country (that doesn't seem to care for radio regulations and interference) is not very common.

[user2684]

@Sergio-Rius let me give some more context. What is provided to setMode() is eventually used when invoking MySensors' sleep() function and instruct the board when to wake up. If RISING is set, the board will wake up (and report "1" to the controller) only when the sensor triggers, if using CHANGE it will wake up and report "1" when the sensor triggers and will wake up again and report "0" when the signal goes down again. I'm personally using RISING because in my controller if goes to 1 and then to 0, I lose the motion but I understand it is dependent on the controller.
When I need to understand is:

• is the CHANGE vs RISING behavior the expected one? In my test it is, in yours we have that mode = 3 instead of 1 which we cannot easily explain
• if the behavior is the expected one (so the implementation is correct), what is best for the majority of the controllers, reporting upon a CHANGE or upon RISING.

The first one will tell me if the implementation is correct, the second what is the most suitable default behavior. For me of course either way is fine.

Many thanks!

[Sergio Rius]

@user2684 I can't tell you what is the desirable default behaviour. The only thing we can expect, is that if we change the mode, it correctly overrides the default.

Just a question, then... your controller how it knows when to "turn the security icon from red to green"? Is it a timer?
But then, if the PIR is set to repeating signal, this couldn't be a problem?

[user2684]

@Sergio-Rius that's the point, I'm still trying to understand if changing the mode, the default is overridden which it is the case in my test, looks like not in yours :-/ Regarding my controller, it checks every minute if the value is set to 1 and then triggers the configured action and resets the value to 0. If triggering multiple times it is not an issue, I will get just one alert per minute but I can understand mine is a very peculiar requirement, this is why I'd rather change the default behavior to CHANGE.