Posts made by Bandra

@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

@hek thanks for putting that together.

I'm designing my new house at the moment and have planned to have a custom arduino-driven RFID reader at the front door. I was debating including it into the mysensors network.

My current line of thinking is to connect it to my LAN and have it make a call back to the controlling system (Vera?). The controller has the list of valid cards and it then calls to the z-wave lock to tell it to disengage.

There's two reasons doing it this way. It keeps the valid/invalid logic off the RFID arduino, making it harder for attackers to compromise the system. Also, the mysensors wireless network is not secure. Finally, it also makes it easier to program new cards, since I don't have to put a new sketch onto the RFID reader.

However, I was thinking about making it easier to build anciliary systems, such as shed door, front gate, etc, and this sketch would be perfect.

@warawara , the development branch is very stable. At this point there is no reason not to use it. It is superior in every way to 1.3.

Moved my solder point to the H pad. Also bridged the H pad with centre pad. All works now. Thanks everyone!

Interesting observation. The motion sketch works very well. But when I try my multisensor sketch it always reads high and keeps triggering. Must be a problem with taking too long in the interrupt. I recall a small discussion about that. Time for some searching...

@marceltrapman
The auto-route feature in Eagle attempts to make the most efficient board layout it can. To do that, it seems to join the traces where ever it can. When you click on the rats nest button, it will combine any GND traces that it can. Since the cap sits on GND, for example, it assumes it can put it anywhere on a GND trace, and physically dislocates it from the radio pins. I just noticed that on my board, for example, the nRF24 cap doesn't sit directly across + and -.

So my next go I would manually route those traces first then auto-route the rest.

It's no big deal, because if I get bad reception then I can always solder the decoupling cap directly onto the radio.

I did choose the option to check my board. It's my very first PCB (which is why I didn't pick up the problem) so I was expecting for them to find lots of problems. But it turns out that technically my board is correct. It's the "logic" of the board that's wrong, so iTead could not have picked this up.

Lesson learned!

@ServiceXp
Thanks mate! I've soldered up 3 of the boards now and they're all working fine.

So far I've made one just with temp and light. One with temp, light and humidity, and one with temp, light, humidity and pressure. I'll make one more tonight that will just have temp and soil moisture.

I'm not entirely happy with the two caps at the bottom of the board. The auto-route feature of Eagle is good, but I don't think it quite got that right. Seems to run fine without the two caps so the PCBs are not a write-off.

I've got way more boards than I need. So I'm happy to send 3 off to you. PM me your address.

Hah! I am at this very stage right now. Finding the right enclosure is HARD!

Ideally I want a vented enclosure so temp, humidity, pressure all work. Seems like all of the boxes on fleabay are waterproof, not vented.

In your sketch you may just be sleeping on a timer. Ie:

gw.sleep(SLEEP_TIME);

With the 1.4 beta improvements, there's now provision to sleep on timer AND on interrupt. Like this:

#define DIGITAL_INPUT_SENSOR 3   // D3 is the only interrupt pin left (radio uses D2)
#define INTERRUPT DIGITAL_INPUT_SENSOR-2
unsigned long SLEEP_TIME = 30000;

void setup() {
  pinMode(DIGITAL_INPUT_SENSOR, INPUT);      // sets the digital pin as input
}

void loop() {
    ...
    gw.sleep(INTERRUPT,CHANGE, SLEEP_TIME);
}

That may not all be exactly right, but it should be pretty close.

Yeah, the sketch I found waits for it to warm up. I'll increase the warmup period and try again. Thanks for the suggestion!

Just for completeness, my PCBs came in and I've had a chance to solder them up. The PCBs are really nice. iTead have done a great job. @Zeph, turns out that I didn't need to cut my PCBs because the friendly folk at iTead cut them for me.

Here's a photo of a few things soldered on:

Underneath the APM I have a 1M and 470K resistors for the battery voltage check. There's also a 4.7K resistor for the Dallas DS18B20 temp sensor. Finally there's a 4.7K resistor for the LDR divider circuit.

You can also see the 4x2 header for the radio, the LDR itself, and the 3.3v step-up converter.

Here's the (almost) finished package:

You can see all the exposed solder pads for my various sensor configurations (motion, humidity, baro pressure, door reed switch, distance and soil moisture).

The range on the nRF24 is fine. I put my gateway at one end of the apartment and it easily picked up my sensor at the other end of the apartment (about 10m away through two thick internal walls). So I'm not worried about the nRF24 being parallel to the GND plane.

I actually took off the 4.7uF cap. It's probably my PCB (don't think the auto-route did a great job of it) but it made the radio flaky. Works just fine without it.

Now to find a box to put it in...

Thanks for the replies, @lininger and @Yveaux. Do you bridge H and the centre solder pad?

Here's my solder effort:

I checked with my multimeter, and soldering a 3.3v wire onto the 7133 leg gets 3.3v to the H solder pad. So I'm pretty sure that I've done the equivalent of yours.

And yet, it doesn't seem to work. After a few seconds my output pin just goes high and never drops low. I've tried to tune the pots but it makes little difference.

Just wanted to check that at least I got the power right. Thanks guys!

Does anybody who has bypassed the onboard regulator on the HC-SR501 be able to post up a photo of where you soldered?

I thought it was pretty simple and soldered my 3.3V lead to the leg on the 7133. It seems to power up (at least, so says my voltmeter), but the trigger (output) pin just goes high immediately and never changes. So on my sensors network it is just constantly triggering (even when there's no motion).

I'm doing something wrong, but not sure what it is. Any hints?

Nice! Just want to mention that my design has two connectors. The 5 pin one you mention, as well as a 3 pin one that breaks out D3.

@Zeph
For cutting the boards I'll be using a really sharp Stanley knife. I live in an apartment with my young family, so containing the dust is a big consideration for me. A Stanley knife is about the "cleanest" way to cut them. It just takes a little more elbow grease.

I've left about 3mm between each board (since I have 3 x 3cm boards to fit across 10cm). Plenty of room to cut between

Yeah, I know that Nordic recommend not to run the antenna over a plane. I plan to solder a 2x4 header onto my PCB and slot the nRF into that. My prototype had pretty decent range when I tried it. I'll see how it works when my PCBs come in. I may need a rev 2 yet

@therik
D3 is an interesting one. As you can see on my board, I've broken it out with a +'ve and -'ve and together called the 3 pins "motion". However, it's dead easy just to use D3 and either the positive or neg for the door switch (depending on whether I want a high or low switch (so it supports both normally open and normally closed).

The only drawback is, of course, (as you point out) that I can't run motion and door switch on the one sensor node. But that's ok. I've tried really hard to cram as many sensors onto each node, but the door switch sensors will just have to be dedicated. For the price of each node, I'm ok with that.

I like your layout. I was fearful of making the node too tall, which is why I'll connect my PIR with wires rather than sit it on the board. It should sit inside a plastic case a bit better that way. I'll see if I can take some photos of my prototypes to show you my thoughts.

I tried the recommended light sensor from the store. It's very nice, in that it reports quite an accurate lux level. However there's 2 drawbacks with it:

• It's very expensive when I want one on every board.
• It draws a lot of battery power.

So I settled on using just a bog standard photoresistor instead that you can buy very cheaply off ebay. To detect light, you use it in a standard voltage divider configuration (since the cell itself is a resistor). I've got a fixed 1k resistor (under the pro mini) for the other resistor. I went with 1k to give enough headroom in both the light and dark side. It's not as accurate (ie, I couldn't even get close to telling you the actual lux level) but it does a good job of reporting a figure. I've already created a map in my sketches of what constitutes low, medium and high light levels. Good enough for me.

I've just sent my PCB off for manufacturing. My design spec was pretty close to your requirements. It looks like this:

It's 5x3cm. I've panelised it so that I fit 3 across on a 5x10 board. Total cost for 30 boards from itead is $20. It's 5x3 because that's the size of a double AA battery holder. So I'll have two options: either hot-glue it onto the top of the battery holder, or mount it beside a battery holder (making a total footprint of 5x6) which will half the height to fit into most plastic cases.

It supports the 3.3v and 5v pro minis, with access to A5 and A6. It uses the space underneath the APM for the 4 resistors on the board (voltage divider plus others).

It has a socket for the nRF24L01+. It doesn't hang over the edge, it actually hangs over the APM. My spaghetti board prototype showed no problems with this configuration. It makes it much more compact.

It has space for a DHT-11 and a BMP180 for pressure. It has space for the 3.3v step-up converter. It has a DS1820 onboard and also a photoresistor light cell. It then breaks out several pins for motion, soil moisture and distance sensors. The "generic" breakout exposes Vcc, Gnd, D7, D8 and A2.

All in all, it provides support for all my standard configurations, which are:

• All sensors have light, temp and motion on board
• Configuration A: Humidity (DHT-11)
• Configuration B: Humidity (DHT-11) and baro pressure (bmp180)
• Configuration Door reed switch
• Configuration Distance
• Configuration E: Soil moisture

Based on the conversations recently about the inefficiency of the step-up converter, I'm yet to decide whether I'll make my own step-up converter board that fits in the same slot on my PCB, or whether I'll create v2 that scraps the step-up and uses the XC9140A331 or something else onboard.

@axillent Looks like a much-needed part for our battery sensors. Is there any chance of moving the pins together to emulate the current step converter in the store? Ie, having three pins in a row: Vout GND Vin. This makes it a drop-in replacement for the existing part.

@therik

@therik said:

@Bandra Great, would you be able to share your run times so that we can get some real world data? That is, how long can you run a node before the battery is discharged?

I was thinking about making a board using one of the high efficiency boosters listed in the first post, if they prove their worth. I get my components in on Saturday, so sometime next week I should have preliminary results.

I only sent my pcb's off for production a couple of days ago. They have a 5cm x 3cm footprint which is designed to fit perfectly on top of a 2xAA battery holder. If the analysis of the chinese cheapie step up converters is right then it may be a couple of months before I run out of battery and have some real world results. However they have the battery level sensing circuit on them so I may have some results sooner once I tweak the algorithm for the 1.2 volt cells. Will let you know how I go.

I've (perhaps naively) built my battery powered MySensors pcb's around the 3 pin configuration of the ebay cheapie. If many others have done the same then I can see some value in someone creating a drop-in replacement board based on the more efficient chips. I'd definitely buy the more efficient version if someone created it, whether pre-made or solder-it-yourself.