SensorDoor + Backup Send

[Nalith]

Hi All

I have a simple sensor I want to use for my doors and windows that is interrupt based however I have noticed that if a door/window is opened and closed too quickly the incorrect value could be sent through to my controller. I was hoping to be able to force my node to update all its sensor values every xx minutes even if there has been no change however for the life of my I can't seem to figure this out. Is there a way I can force a interrupt based sensor to send updated values through at specific intervals as a backup to the normal interval based send?

Thanks

[skywatch]

You can do this, but be aware that if the nodes are battery powered it will drain the batteries much more quickly.

I have a microwave motion sensor that on the controller seems to 'stick' on a high trigger level. For some reason the return to a low state doesn't always get through it seems.

[Yveaux]

@nalith See the sleeping section in the API description.
The sleep function takes one or two interrupts to wake up the node on triggering, and an optional ms parameter that defines the amount of milleseconds to sleep before waking up anyway.
The return code of the sleep function indicates what woke the node, e.g. (untested!):

#define PIN_DOORALARM          (2)            // only 2 & 3 are supported on ATMega328!
#define SLEEP_TIME_MS          (60*1000)      // sleep 60.000 milliseconds -> 60 seconds
#define DEBOUNCE_TIME_MS       (15)

void setup ()
{
    pinMode(PIN_DOORALARM,  INPUT_PULLUP);
}

void loop()
{
    // ... do whatever you like ...

    // Sleep until node wakes up by interrupt or timeout
    uint8_t result = sleep( digitalPinToInterrupt(PIN_DOORALARM), FALLING, SLEEP_TIME_MS );
    if ( MY_WAKE_UP_BY_TIMER  == result )
    {
        // woke by timer -> e.g. send current status
    }    
    else if ( digitalPinToInterrupt(PIN_DOORALARM) == result )
    {
        // woke by interrupt -> send current status / raise alarm

        // debounce might be required; depending on your switches
        delay(DEBOUNCE_MS);
    }    
}

[zboblamont]

@yveaux In addition to what you explained, if the Int were triggered on "change" and a hi/low check made on the pin before update to the Gateway, would this not report either correct state short of inhuman speed?
I recall having the opposite problem with the gas meter reed lasting ca 6 seconds in hi state, solved by a short while/sleep to verify it had gone Lo before entering deep sleep. A variant in this case might be to check which state it is in after updating to ensure it hadn't changed prior to sleeping.

[Yveaux]

@zboblamont said in SensorDoor + Backup Send:

would this not report either correct state short of inhuman speed?

I guess it would, but there's always the chance of missing a message, so a regular status update could help there.