SensorMotion to send both tripped and not tripped


  • Contest Winner

    This post is deleted!


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

    @mar.conte great to hear it is working now! For anybody else interested in these parameters, setDebounce() will set a debounce interval, e.g. the value of the input is checked after the interval from the wakeup so to avoid false positives, while seTriggerTime() ignore any input after the pir has triggered to avoid the sensor to trigger continuously. Btw, very nice and clean packaging!

    Just wanted to say first of, this node manager is great for someone like me who has been playing around with my sensors but really struggling to get past the basic example sketches.

    I've been trying to put together a motion sensor using an AM312 PIR.
    but I'm having problems like others with the sensor always remaining tripped.
    I've read through all the documentation but I'm having troubles figuring out how and where to add the extra sensor parameters.
    do these go in the config.h sketch? if so how and where?
    or do I change them in the NodeManager.h

    sorry for such a basic question but I'm not really good with arduino or coding and have read your instructions over and over but I cant figure out how to add these parameters to my sketch.

    Any help would be appreciated.



  • @tubby
    Hi, i try with parallax pir setdebounce(50) and its very stable no trigger false positive and each our send level battery, i test this for many daysvand its good by



  • @mar.conte thanks for the reply.
    I've read that adding the debounce helps, but I just don't know how to add it to the sketch.
    I'm arduino/coding illiterate I manage to bluff my way through most things but this one has me stuffed.

    Where and how do I add debounce to my sketch?



  • @tubby
    Like this

    NodeManager nodeManager;
    SensorSwitch swiTch(1,3);
    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(MY_BAUD_RATE);  
      /*
       * Register below your sensors
      */
    swiTch.setDebounce(50);
    swiTch.setTriggerTime(4000);
      nodeManager.setSleep(SLEEP,60,MINUTES); 
      nodeManager.registerSensor(SENSOR_MOTION,3);``````

  • Contest Winner

    I have a couple of AM312 sensors around here and they are working ok without any debounce or trigger time, I guess I've been just lucky 🙂 The only issue I had has been a lot of false positives when placed outside and the light changing (e.g. the sun shines over them) but I think this is somehow expected.

    @mar.conte in your example you are creating a switch object, adjusting its settings but then NOT using it since when yo call register sensor it will create and register a new object 🙂
    Either you call register sensor and then retrive the object in this way:

    nodeManager.setSleep(SLEEP,60,MINUTES); 
    sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);
    
    SensorMotion* sensorMotion = ((SensorMotion*)nodeManager.getSensor(sensor_id));
    
    sensorMotion->setDebounce(50);
    sensorMotion->setTriggerTime(4000);
    
    

    Or you create your own sensor, adjust the settings and register it by passing the object's instance but then you also need to setup the interrupt manually so I'd recommend the option just above. In your example (if this is what you are using) you basically have a standard sensor with neither debounce nor triggertime set 🙂



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

    I have a couple of AM312 sensors around here and they are working ok without any debounce or trigger time, I guess I've been just lucky 🙂 The only issue I had has been a lot of false positives when placed outside and the light changing (e.g. the sun shines over them) but I think this is somehow expected.

    @mar.conte in your example you are creating a switch object, adjusting its settings but then NOT using it since when yo call register sensor it will create and register a new object 🙂
    Either you call register sensor and then retrive the object in this way:

    nodeManager.setSleep(SLEEP,60,MINUTES); 
    sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);
    
    SensorMotion* sensorMotion = ((SensorMotion*)nodeManager.getSensor(sensor_id));
    
    sensorMotion->setDebounce(50);
    sensorMotion->setTriggerTime(4000);
    
    

    Or you create your own sensor, adjust the settings and register it by passing the object's instance but then you also need to setup the interrupt manually so I'd recommend the option just above. In your example (if this is what you are using) you basically have a standard sensor with neither debounce nor triggertime set 🙂

    I appreciate the help.
    Ive tried adding your code to my sketch but I get this error.

    Arduino: 1.8.1 (Windows 10), Board: "Arduino Nano, ATmega328"
    
    In file included from C:\Users\Daniel\Documents\NodeManager_testing_motion\NodeManager_testing_motion.ino:24:0:
    
    sketch\NodeManager.h:388:26: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
    
         char* _description = "";
    
                              ^
    
    sketch\NodeManager.h:400:28: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
    
         char * _value_string = "";
    
                                ^
    
    sketch\NodeManager.h:403:33: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
    
         char * _last_value_string = "";
    
                                     ^
    
    C:\Users\Daniel\Documents\NodeManager_testing_motion\NodeManager_testing_motion.ino: In function 'void before()':
    
    NodeManager_testing_motion:36: error: 'sensor_id' was not declared in this scope
    
       sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);
    
       ^
    
    exit status 1
    'sensor_id' was not declared in this scope
    
    This report would have more information with
    "Show verbose output during compilation"
    option enabled in File -> Preferences.
    

    'sensor_id' was not declared in this scope..
    Is the error that stops it from compiling, I always get the other errors when compiling but the sensor still works, tested on dht sensor (but this may be the problem)

    I'm guessing i'm missing something in the sketch.
    I'm really sorry for the pathetic questions.

    With this basic sketch:

    /*
    NodeManager is intended to take care on your behalf of all those common tasks a MySensors node has to accomplish, speeding up the development cycle of your projects.
    
    NodeManager includes the following main components:
    - Sleep manager: allows managing automatically the complexity behind battery-powered sensors spending most of their time sleeping
    - Power manager: allows powering on your sensors only while the node is awake
    - Battery manager: provides common functionalities to read and report the battery level
    - Remote configuration: allows configuring remotely the node without the need to have physical access to it
    - Built-in personalities: for the most common sensors, provide embedded code so to allow their configuration with a single line 
    
    Documentation available on: https://github.com/mysensors/NodeManager
     */
    
     
    // load user settings
    #include "config.h"
    // include supporting libraries
    #ifdef MY_GATEWAY_ESP8266
      #include <ESP8266WiFi.h>
    #endif
    // load MySensors library
    #include <MySensors.h>
    // load NodeManager library
    #include "NodeManager.h"
    
    // create a NodeManager instance
    NodeManager nodeManager;
    // before
    void before() {
      // setup the serial port baud rate
      Serial.begin(MY_BAUD_RATE);  
      /*
       * Register below your sensors
      */
      nodeManager.setSleep(SLEEP,1,MINUTES); 
      sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);
    
      SensorMotion* sensorMotion = ((SensorMotion*)nodeManager.getSensor(sensor_id));
    
      sensorMotion->setDebounce(50);
      sensorMotion->setTriggerTime(4000);
    
      
      /*
       * Register above your sensors
      */
      nodeManager.before();
    }
    
    // presentation
    void presentation() {
      // call NodeManager presentation routine
      nodeManager.presentation();
    }
    
    // setup
    void setup() {
      // call NodeManager setup routine
      nodeManager.setup();
    }
    
    // loop
    void loop() {
      // call NodeManager loop routine
      nodeManager.loop();
    
    }
    
    // receive
    void receive(const MyMessage &message) {
      // call NodeManager receive routine
      nodeManager.receive(message);
    }
    
    // receiveTime
    void receiveTime(unsigned long ts) {
      // call NodeManager receiveTime routine
      nodeManager.receiveTime(ts);
    }
    
    
    

    I get this node log on serial:

    0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
    3 MCO:BGN:BFR
    REG I=1 P=2 P=1 T=16
    NodeManager v1.5
    INT1 M=255
    INT2 M=3
    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:
    1125 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    1130 !TSF:MSG:PONG RECV,INACTIVE
    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:
    2120 TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    2125 TSF:MSG:FPAR OK,ID=0,D=1
    3100 TSF:MSG:READ,0-0-1,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    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
    6124 TSM:UPL
    6126 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    6458 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    6463 TSF:MSG:PONG RECV,HP=1
    6465 TSM:UPL:OK
    6467 TSM:READY:ID=1,PAR=0,DIS=1
    6471 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    6478 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    6483 !TSF:MSG:PONG RECV,INACTIVE
    6490 TSF:MSG:READ,0-0-1,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    6497 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
    6505 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
    RADIO OK
    8513 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=OK:NodeManager
    8522 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
    8563 !TSF:MSG:SEND,1-1-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=NACK:
    PRES I=201, T=30
    8605 !TSF:MSG:SEND,1-1-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=1,st=NACK:
    BATT V=4.57 P=100
    SEND D=0 I=201 C=0 T=38 S= I=0 F=4.57
    8683 !MCO:SND:NODE NOT REG
    8725 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=2,st=NACK:100
    PRES I=1 T=1
    8767 !TSF:MSG:SEND,1-1-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=3,st=NACK:
    READY
    
    8773 MCO:REG:REQ
    8811 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=4,st=NACK:2
    10818 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=5,st=OK:2
    12825 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    13209 TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    13214 MCO:PIM:NODE REG=1
    13216 MCO:BGN:STP
    MY I=1 M=1
    13218 MCO:BGN:INIT OK,TSP=1
    SLEEP 60s
    
    13222 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    13230 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:12
    13236 TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    13241 MCO:PIM:NODE REG=1
    13736 MCO:SLP:TPD
    13737 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    13741 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    13748 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:530
    14254 MCO:SLP:TPD
    14255 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    14258 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    14265 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1047
    14772 MCO:SLP:TPD
    14773 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    14776 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    14783 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1565
    15290 MCO:SLP:TPD
    15291 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    15294 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    15337 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=NACK:2083
    15843 MCO:SLP:TPD
    15844 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    15847 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    15890 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=1,st=NACK:2636
    16396 MCO:SLP:TPD
    16397 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    16400 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    16443 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=2,st=NACK:3189
    16949 MCO:SLP:TPD
    16950 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    16953 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    16960 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=3,st=OK:3742
    17467 MCO:SLP:TPD
    17468 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    17471 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    17478 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4260
    17985 MCO:SLP:TPD
    17986 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    17989 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    17996 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4778
    18503 MCO:SLP:TPD
    18504 MCO:SLP:WUP=-2
    AWAKE
    BATT V=4.61 P=100
    SEND D=0 I=201 C=0 T=38 S= I=0 F=4.61
    18615 !TSF:MSG:SEND,1-1-0-0,s=201,c=1,t=38,pt=7,l=5,sg=0,ft=0,st=NACK:4.61
    18658 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=1,st=NACK:100
    SLEEP 60s
    
    18665 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    18707 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=2,st=NACK:5454
    19214 MCO:SLP:TPD
    19215 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    19218 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    19261 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=3,st=NACK:6007
    19767 MCO:SLP:TPD
    19768 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    19771 MCO:SLP:MS=60000,SMS=1,I1=255,M1=255,I2=0,M2=3
    19814 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=4,st=NACK:6560
    20320 MCO:SLP:TPD
    20321 MCO:SLP:WUP=-2
    AWAKE
    SLEEP 60s
    
    

    I know I'm loosing a lot of communication but, I'm just trying to test at the moment.

    Oh and I don't have any sensors connected to this node at the moment, so there is no PIR sending pin high.
    the voltage between ground and pin 2 is 0.28v

    I'm really struggling with this.

    If I run the mysensors example it works as expected.

    any help would be much appreciated


  • Contest Winner

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

    sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);

    sorry my bad, I should have tested the code before pasting it here 😞

    That sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3); should be a int sensor_id = nodeManager.registerSensor(SENSOR_MOTION,3);

    I forgot an int.



  • @user2684 thanks mate.
    Ill try that tommorrow.

    Really wish I know how to code, but I just don't know where to start.



  • 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


  • Contest Winner

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



  • @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?


  • Contest Winner

    @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



  • @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


  • Mod

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



  • @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...


  • Mod

    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


  • Contest Winner

    @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


  • Contest Winner

    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



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


  • Contest Winner

    @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!



  • @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.


  • Contest Winner

    @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 🙂



  • 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)


  • Contest Winner

    @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!



  • @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.


  • Contest Winner

    @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


  • Contest Winner

    @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



  • @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.


  • Contest Winner

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



  • @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. 😉


  • Contest Winner

    @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



  • @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.



  • @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.


  • Contest Winner

    @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!



  • @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?


  • Contest Winner

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



  • @user2684 If you are stil looking for comments on whether the expected behavior is CHANGE or RISING, its CHANGE for my purposes. My motion sensor is set to reset after 5 minutes or so without motion, and I want that reported as well as the initial motion. So I needed to change the mode.


  • Contest Winner

    @jaylove thanks, CHANGE has been made the default option indeed in v1.6-dev. Btw in case you can give it a try, it would be great (https://github.com/mysensors/NodeManager/tree/development) Thanks!


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 11
  • 2
  • 1
  • 1

0
Online

11.2k
Users

11.1k
Topics

112.5k
Posts