@ServiceXp

My PCBs are winging their way to you (sorry, got forgot to send them for a week or two). They may solve your problem. Let me know when you get them.

Oh yeah, I'm also scouting around for a nice enclosure that will snugly fit the PCB and 2xAA battery holder side-by-side (around 60mmx 60mm) and with room for the PIR motion sensor sitting on top of those. Haven't found anything yet. I may have to buy a 3d printer to make my own...

Thanks for your interest, guys!

My PCB is getting really close, but I'm not entirely happy with it. I've made up 5 of them and scattered them around my place. For the most part, they're working well. However I have the following issues:

• The battery voltage varies. I don't think my cap is quite doing the job, so I may need to tweak the PCB to get it closer to the voltage divider. I'm running Domoticz and it does a good job of averaging the battery level out, so it's not completely bad, but I'd really like to fix it in the next version of the PCB.
• My moisture sensor (the one from the MySensors store) doesn't work very well. It chews the battery (cos the sensor from the store has 2 leds on it, plus it's always "on". I'll pop those off and see how it goes. However I think I can do the moisture sensor better. I'm thinking of including another voltage divider, and run the sensor off the digital pin for power. That way, I can power the sensor down in between samples.

I think that I can also include my own step up voltage converter. I'm not entirely happy with the chinese step up converter. So far my 2xAA batteries have lasted several weeks, and they're still going strong, but I suspect that I'll only get a few months out of them. I'm aiming for a year.

I'm designing our new house at the moment, which is taking up a lot of time, but I'll get onto rev 2 shortly. Once I'm happy with it, I'll put the design up here so that you guys can get your own made up.

Ok, back from meeting.

So, for sketches that don't need to sleep on interrupt, then things are ok because I can code around it like this:

if ((unsigned long)(millis() - timeOfLastSensorSend) >= MIN_SAMPLING_INTERVAL) {
    // read sensors and send to gateway
    timeOfLastSensorSend = millis();
}
gw.sleep(SLEEP_TIME);
timeOfLastSensorSend -= SLEEP_TIME;

My rationale here is that if millis doesn't increment then I should make my variable decrement by the same amount. Same effect.

However, the catch is when sleeping with interrupt. My thinking was to modify MySensors.cpp to change the return value of sleep. Something like this:

unsigned long MySensor::internalSleep(unsigned long ms) {
    unsigned long origMs = ms;
    while (continueTimer && ms >= 8000) { LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); ms -= 8000; }
    if (continueTimer && ms >= 4000)    { LowPower.powerDown(SLEEP_4S, ADC_OFF, BOD_OFF); ms -= 4000; }
    ...
    if (continueTimer && ms >= 16)      { LowPower.powerDown(SLEEP_15Ms, ADC_OFF, BOD_OFF); ms -= 15; }
    return (origMs - ms);
}

unsigned long MySensor::sleep(unsigned long ms) {
    // Let serial prints finish (debug, log etc)
    Serial.flush();
    RF24::powerDown();
    continueTimer = true;
    return internalSleep(ms);
}

unsigned long MySensor::sleep(int interrupt, int mode, unsigned long  ms) {
    // Let serial prints finish (debug, log etc)
    unsigned long sleptFor = 0;
    Serial.flush();
    RF24::powerDown();
    attachInterrupt(interrupt, wakeUp, mode); //Interrupt on pin 3 for any change in solar power
    if (ms>0) {
            continueTimer = true;
            sleptFor = sleep(ms);
    } else {
            Serial.flush();
            LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
    }
    detachInterrupt(interrupt);
    return sleptFor;
}

So rather than return a boolean on sleep(x,y,z), return the amount of time it slept for before it was interrupted. The check of the boolean is replaced with a check if return code > 0.

Hopefully my ramblings make some kind of sense.

@John
Your project looks great! I'm looking around for an home automation controller and was tossing between domoticz, openhab and FHEM.

My criteria are:

• MySensors support (whether directly or through a gateway)
• Z-Wave support
• Visual floor plan
• Runnable on a Pi

May have to add yours to the mix to trial.

How difficult would it be to compile openzwave and integrate it by some mechanism to PiDome, do you think?

@hek
I'd like to ask for a small change to be made to the sleep function.

When we call gw.sleep(x) or gw.sleep(x,y,z) then the arduino disables the interrupt timer (to save power) that triggers the counter that drives millis(). So the value returned from millis() stalls when we sleep.

This is ok on our battery powered devices, since it's saving power, but makes it hard to determine how long it's been since we sent values to the gateway.

For example, if I use this code:

if ((unsigned long)(millis() - timeOfLastSensorSend) >= MIN_SAMPLING_INTERVAL) {
    // read sensors and send to gateway
    timeOfLastSensorSend = millis();
}
gw.sleep(SLEEP_TIME);

Then it doesn't work because millis() does not increment while the the sketch is asleep.

I have a thought on how we can solve this but I have a to get to a work meeting.

Thanks @Yveaux
I think I'm pretty safe there because I'm relying on the MySensors library to do the interrupt [ie, the sleep(int, int, long) method]. In that method, the library disables the interrupt itself [in MySensor::sleep it performs a "detachInterrupt(interrupt);" ]

I got it going reasonably well by doing two things. I moved the code that tests the D3 pin towards the beginning of the loop(). This helps avoid flapping (ie, if the pin fell low between the time the the interrupt was triggered to the end of the next loop() then it might cause flapping). I also changed my sleep call from:

sleep(INTERRUPT, CHANGE, 30000)

to

sleep(INTERRUPT, RISING, 30000)

This way, a flapping motion sensor doesn't affect me as much. Those two changes worked a treat. My multisensor sketch works well now!

Thanks again for all your advice on this forum.

@Yveaux
True. The library is changing constantly (for the better!).

I've not encountered any major bugs in the 1.4 beta libraries that I've tried. So if the OP was just starting out then there's value in pulling down the latest 1.4 (which should be quite stable) and starting their sketches from there. Once 1.4 goes to production, then upgrading sketches will be much easier from 1.4b -> 1.4 than from 1.3 -> 1.4.

I'm coming close to finalising my multisensor sketch. I'll post code once I clean it up a little. I have a newborn at home, so if I forget to put code here then somebody please remind me in a little while

My ipad doesn't have a "valid" browser. Which means that I can't scroll inside the code box to even read the code