Building the doorbell controller

2 days ago the hardware for the doorbell controller arrived; a JeeNode v6, a Carrier Board, an Ether Card and a Utility Plug. After building the first 3 items on the day they arrived, I was ready to do some tests yesterday. I installed the latest Arduino IDE, the latest RF12, Ports and Ether Card library and hooked up the JeeNode to a USB BUB. I saw the RF12demo sketch appearing in the Serial Monitor; so far so good.

Let’s see if there’s an example sketch in the JeeLabs Ether Card Libary I can quickly modify for testing; yep, the getStaticIP sketch looks OK; I changed some IP addresses, the page to request on my web server and the request interval. I pushed a patch cable into the RJ45 plug, uploaded the sketch and bingo!

Ready! Hmm, no, not really. It all seemed to work perfectly, but after a while I saw strange replies in the Serial Monitor window and I could tell they didn’t belong there. These replies came at times where there hadn’t been a request for several seconds, so where was this reply coming from? I searched the code but couldn’t find out what the status code 3 meant that was returned with these strange replies. Hmm, I don’t like this. Just ignoring those strange replies was easy to do but it just didn’t feel right. There had to be something wrong; I mean, have you ever heard of a garbage filter on a NIC? Me neither.

I decided to dig a little bit deeper. The next morning, while on my way to the office, it hit me: the HTTP 1.1 protocol, doesn’t it use persistent connections by default? And does the connection get closed by either side after the reply has arrived? I checked RFC 2616 and I was right, so the first thing I did when I came home was checking my IIS logs and found the evidence for open connections being closed by IIS after a certain idle period:

192.168.10.203 3031 192.168.10.13 80 - - - - - Timer_ConnectionIdle

That could very well be the cause of those garbage replies I saw on the JeeNode!

Looking at the sketch I saw that the request didn’t contain a Connection:close header line. So my server did not close the connection.. after changing the request to HTTP 1.0, the behavior of the server changed and it closed the connection after sending the reply. This was also visible by the extra header line the server added to the reply: Connection:close. And guess what: the garbage replies no longer appeared and everything’s fine now. Now that traffic between server and JeeNode was clean, I could start working on the enclosure.

I disconnected the USB BUB, grabbed an enclosure and started cutting out holes for the DC jack and the RJ45 plug:

Doorbell controller in enclosureDoorbell controller in enclosure

 

 

 

 

 

 

With the enclosure almost finished I connected a 5V power adapter to the DC jack, put the patch cable back in and I saw the requests arriving at my server again. Perfect!

Doorbell controllerDoorbell controller: case closed

Finishing the Doorbell

 

Today I finished modifying the doorbell with which I started yesterday. I drilled a 4.5 mm hole through the back of the doorbell and led a solid core CAT5 cable through that hole. This cable will be used to connect the doorbell switch and the 2 LEDs (a white and blue one) to the Jeenode that will be placed in the fuse box which is only 2 meters away. The legs of the LED were bent sideways right there where they come out of the LED housing and these legs were temporarily glued to the doorbell housing to secure the position of the LED for easy soldering. You can still see some residue of the glue (the white blur on the housing surface) where the legs of the right LED touch the doorbell housing.

Finishing the hardwareFinishing the hardware

 

 

 

 

 

 

To get a good insulation from the outside world, I pushed the cable through the hole, put hot glue on it and pulled the cable back  a few millimeters; this should suffice for proper insulation. After the wires were cut to the right length and soldered to the legs of the LEDs, it was time to check if everything was working. So I put the 2 halves of the doorbell housing on each other, pressed them firmly, and put the other side of the wire on a breadboard. With a 5V power supply, two 330 Ω resistors and a multimeter I convinced myself that everything was OK.

BTW, it’s a good thing I didn’t choose red as one of the colors for the LEDs; otherwise, a visitor might think he’s being held at gunpoint by a sniper with laser sight 🙂 In other words, the LEDs are a bit too bright, so I think I’ll use a higher resistor value in the final version – that’s why I left the resistors out of the housing in the first place, cause I was anticipating “tuning” issues like this.

Well, now that I have verified that the doorbell is working OK, I can move on to the next step: the JeeNode, some more hardware and the software that goes with it!

 

A new doorbell

One of the things I never liked, was our doorbell. You’ve probably seen or used them, those mostly black plastic boxes with some pieces of copper strips inside; the mechanism relies on those 2 copper spring-like strips to make contact when the button is pressed and return to their old position when the button is released. However, more than once it has happened that if someone pushes the button too hard, the button doesn’t work that well anymore because the strips are bent. Time to do something about this annoying issue and solve this once and for all.

So here’s the most important requirement: the new doorbell should always work. Besides that, I wanted the doorbell to have a distinctive ‘click’ as physical feedback and if possible, also a visible feedback for the person standing in front of our door pushing that doorbell button. Last but not least, the visitor should be able to find the doorbell while standing in front of the door while it’s dark outside. A white LEDs should be able to do just that.

I bought a wireless doorbell once, thinking I could remove the wireless part and just use it as a simple switch . But I was wrong; the button and wireless part were too much integrated for me to do something useful with the PCB that was inside. This wireless doorbell cost me about 30 euro, the looks were OK and I didn’t want it to end up on the shelf with all the rest of the things I’ve bought but never used. Sounds like a good opportunity for some DIY 😉

I removed the PCB from the doorbell, glued a piece of experimenting board into the doorbell and soldered a PCB switch on top of the board:

New Doorbell

Fits perfectly. With this switch you get instant feedback on whether the switch sensed your push because of the audible and tactile click, you can both hear and feel it very well. As visible feedback for pressing the button I decided to use a blue 3mm LED. This LED should cooperate with the white one, which should take care of night visibility: resulting in a blue indicator above the button when it’s pushed, and a white indicator while it’s dark outside.

While working on the new interior of the doorbell, I decided to use a JeeNode with EtherCard to control it all, thereby creating my own Ethernet-enabled doorbell. Why? Because I can! 🙂

To be continued.

 

The Allegro A3214 Hall-Effect Switch

As I mentioned yesterday, I’m currently testing a new sensor: the Allegro A3214 Hall-Effect switch. This very small sensor looks like a very good candidate for my own Door & Window sensors. A sample of this sensor was given to me by Jean-Claude Wippler a few weeks ago, and now that I’m waiting for some Mantis parts I ordered and have no more time to spend on the Arduino Workshop, it was time for something new.

Some characteristics of the A3214:

  • 2.4 to 5.5V battery operation
  • minimal power requirements
  • pole independent switching
  • small size

How small is small??

This is small!

Allegro A3214

The magnet (upper left) measures 3x3x3 mm, the sensor dimensions are 4 x 3 x 1.5 mm. Yep, that’s really small 🙂

First thing I did yesterday, was putting this sensor on a breadboard and connecting it to a JeeNode. I wrote a small sketch that used LED2 of the Bridge Board to visually show the status of the sensor output:

#include <Ports.h>
#include <RF12.h>

Port one (1);
Port four (4);

void setup() {
  one.mode(OUTPUT); // LED2 of Bridge Board is connected to Port 1 Digital.

  four.mode(INPUT); // the sensor is connected to Port 4.
  four.digiWrite(HIGH);  // enable pullup
}

void loop() {

  one.digiWrite(four.digiRead());
}

It worked, wow! Moving the magnet towards the sensor made the LED go off (the output is high when the magnetic field isn’t strong enough), moving the magnet away made the LED go on again. The distance between sensor and magnet when the output value changes is approx. 10 mm.

Today I wanted to do some power usage measurements, so I changed the sketch a bit:

#include <Ports.h>
#include <RF12.h> // needed to avoid a linker error :(
#include <Sleep.h>

#define DEBUG 0

int INTpin = 3;
Port one (1);

volatile boolean wdt_expired=0;

// Interrupt Serive Routine that will be executed when the Watchdog Timer expired.
ISR(WDT_vect) {
  wdt_expired=1;
}

//****************************************************************
// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec
void setup_watchdog(int ii) {

  byte bb;
  int ww;
  if (ii > 9 ) ii=9;
  bb=ii & 7;
  if (ii > 7) bb|= (1<<5);
  bb|= (1<<WDCE);
  ww=bb;

  MCUSR &= ~(1<<WDRF);
  // start timed sequence
  WDTCSR |= (1<<WDCE) | (1<<WDE);
  // set new watchdog timeout value
  WDTCSR = bb;
  WDTCSR |= _BV(WDIE);
}

void setup(void)
{
  pinMode(INTpin, INPUT);
  digitalWrite(INTpin, HIGH);

  one.mode(OUTPUT); // LED2 of Bridge Board is connected to Port 1 Digital.

  #if DEBUG
  Serial.begin(9600);
  #endif
}

void loop(void)
{
  #if DEBUG
  Serial.print(millis(), DEC);
  Serial.print(" I'm awake, caused by ");
  #endif

  if (wdt_expired==1){
    wdt_expired=0;
    #if DEBUG
      Serial.println("the WDT");
    #endif

    // Do something, like sending a heatbeat
    // sometimes

  }
  else
  {
    // External interrupt triggered!
    byte val = digitalRead(INTpin);

    // disable LED during power measurements
    //one.digiWrite(val);

    #if DEBUG
    Serial.print(val, DEC);
    Serial.println(" INT0");
    Serial.print("Doing some serious stuff now...");
    #endif

    // measure awake
    delay(5000);

    #if DEBUG
    Serial.println("finished!");
    #endif
  }

  //
  #if DEBUG
  Serial.print(millis(), DEC);
  Serial.println(" Sleeping...");
  delay(100);     // wait for serial to finish
  #endif

  // go to sleep and wake up
  // on watchdog or IRQ pin change
  setup_watchdog(9);
  Sleep.powerDownAndWakeupExternalEvent(1, CHANGE);     // sleep function called here
}
The A3214 output was moved to an external interrupt pin, I disabled LED2 and wrote down the power usages with the JeeNode, Bridge Board and A3214 connected to a 3 x AA battery pack producing 4.1 V:
  • JeeNode awake: 7 mA;
  • JeeNode asleep, magnet in range of sensor: 38 μA;
  • JeeNode asleep, magnet out of range: 14 μA.

That’s very good… I’m sure this power usage will be good enough to live on 1 set of AA batteries for a long time. 🙂

Of course, Door & Window sensors is the most obvious application for these sensors. But the small size makes me wonder if I can come up with more useful ideas…

On to the next step!

Different breadboards

As part of preparation for the Arduino Workshop, I was soldering a new Bridge Board a few days ago. The Bridge Board is, just like the AA Power Board, a very handy tool that helps you  keep all those experiments you do on a breadboard clear, simple and easy to build.

After soldering the row of pins that will be pushed into the breadboard, I wanted to see what it was going to look like. I took a random breadboard and immediately saw something was wrong here.. I’ll never be able to connect the JeeNode to the Bridge Board ?! This is strange; this being a design flaw was out of the question of course, so I took another random breadboard. Now the Bridge Board (better: the breadboard :-)) dimensions are correct! Just look at the horizontal white line across the Bridge Board; this should be in line with the outside of the breadboard:

CorrectWrong!

The cause is quite obvious: not all breadboards are equal in size (click the images for more detail). The left breadboard that fits perfectly has a width of 54.2 mm while the breadboard on the right, which is unusable in combination with the Bridge Board, measures 64.5 mm. Well, this is something I never realized before: even breadboards with the same amount of tie points can have different dimensions. So much for standardization…

So if you’re a potential Bridge Board user, watch out what breadboards you buy.

Preparing for the Arduino workshop

The Arduino workshop I mentioned before, is actually going to happen! 🙂 This will be a busy day, for both the organizing party as well as the attendees! A short list of the things we will be doing during that day:

  • Building an Arduino on a breadboard
  • Soldering a JeeNode
  • The Arduino IDE and testing the JeeNode
  • Experimenting with sensors and actors
  • Building a Room board
  • HomeSeer integration.

Enough to fill a complete day I’d say!

For the HomeSeer integration we’ll be using a slightly modified version of JeeNode for HomeSeer. This script based solution will help the attendees to integrate the hardware they created into HomeSeer in a very simple way. And since all the source code is provided, everyone can extend and/or modify it so that it will fit their personal needs the way they want.

Although I’m not a HomeSeer user, I do have a HomeSeer license that was paid for by a fundraiser that took place earlier this year. So I can play with HomeSeer whenever I like without any dirty tricks while I’m working on the Plugins I created or when I’m doing stuff like this.

I soldered a new JeeNode v4, a Room Board, uploaded the JeeNode sketch and connected it to the AA Power Board:

JeeNode with Room Board

JeeNode with Room Board

The JeeLink sketch was uploaded to the, eh, JeeLink, and I added an extra line to the HomeSeer startup script to get the JeeNode script running. After some initial configuration like setting the JeeLink COM port and some RF related settings, I was good to go:

HomeSeer Status

HomeSeer Status

OK, it’s all working; I can see the Room Board sensors in HomeSeer. Now it’s time to upgrade the JeeNode sketch to make it more power usage aware, cause I assume that will be important for those who attend this workshop. Back at home, they’ll probably start creating their own battery powered sensors, so a good starting point is essential. And that’s what I’m working on right now.

Notes about the pull-up

The motion sensor i finished yesterday needed some last tests; namely, what resistor should i use? Internal? External? And in the case of external, what value? Now the internal pull-up resistors of the Arduino are 20 k. But why not try to use a higher value, cause even with this resistor the rule V = I * R applies, right? When the JeeNode is in power down mode, i measure 1.36V over the external (100 k) resistor I used till now. That means there’s a current of 13.6 μA going through the resistor. With the internal 20k resistor this would be 5 times more: 68 μA! Yuck! And all that in power down mode, no way!

OK; i bought a huge case with an assortment of resistors a few years ago, ranging from 12Ω to 1 MΩ. Hey, let’s try that last one, 1 MΩ. This will add an additional factor of 10 to the external resistor value, resulting in the current dropping to 1.36 μA. And guess what; with this resistor the behavior of the PIR didn’t change; this is very nice! I hope I’m not overlooking or breaking any electrical laws or rules by doing this, but this seems the right thing to do..

Programming the XBee and placing it in the breakout board is all there’s left to do; I guess you could say this 3rd sensor is finished! 🙂

Last tests…

This evening I started building the first ELV PIR13 based motion sensor. Looking at the time right now, I think it took me 2.5 hours; during that time I soldered a JeeNode, attached a cable to the PIR13, soldered a XBee breakout board, soldered the wires to the JeeNode, drilled some holes in the enclosures,  … well here’s the result:

Almost finished

With each sensor that I build, it’s becoming less time consuming to build the hardware. With the sketch compiled and uploaded in debug mode, i wanted to see if everything was working OK, and it did. One last thing has to be resolved before i can move this sensor to it’s final location, and that’s if I can enable the internal pull-up on the interrupt pin. I probably can,  but maybe that’s not such a good idea. I mean, a pull-up resistor consumes power, so it matters if it’s 100 Ω or 100 kΩ, right? What if the resistor can have a higher resistance (and the PIR still working well) than the internal pull-up? Would that save me energy? And how much? An issue to spend the next evening with, cause this is all to new for me to decide based on experience or knowledge…

So that’s why i added a header on JeeNode port 2 (click the image and you’ll get a more detailed view) and put a resistor in there, between P and I; so I don’t have to rely on the internal pull-up if I don’t want to but can also discard that external resistor – based on what I think is best based on my findings.

PIR13 Motion sketch progressing

Although i came home rather late this evening, i had about an hour left to proceed with the ELV PIR13-based motion sensor.  Let’s see if I can get the PIR13 working on an interrupt pin…

I took the sketch from motion sensor v2 as a start, changed some minor things and uploaded the sketch to the JeeNode. Bummer, I forgot that now the PIR13 output pin is attached to an interrupt pin, there’s no more internal pull-up enabled. That’s why the thing isn’t working! Adding an external resistor between + and the PIR output solved this as you can see by looking at the output:

[Motion_PIR13]
0
1
0
1
1
0
0
0
etc....

The changes that had to be made to the sketch to get the PIR13 running were minimal, so I will change the Motion v2 sketch in a way that it can be used with the Panasonic PIR as well as the PIR13; just to keep the number of sketches used to a minimum.

Lamp replaced by "DIY Ambilight"

LED strips

Even in full daylight and the LED strips @ 50%, this already looks VERY OK to me! Can’t wait till it’s dark outside..

After some small tests during the last couple of weeks, it was time to finish replacing a lamp near the TV with LED lighting. It’s still a big cable mess in the corner where the TV is located, but you can’t start cleaning up when you’re not finished, right? A lamp, holding 2 energy saving light bulbs, consuming 11W, has now been replaced by LED strips attached to the back of the TV. I call it my “DIY ambilight” project 🙂

The following components were used:

  • 1 x JeeNode v4;
  • 2 x MOSFET Plug;
  • 3 meters of warm white LED strip;
  • XBee series 2 module;
  • XBee breakout board;
  • 3.5 mm mono plugs;
  • 12V power supply.

And 3 x software; 1 for my Home Automation system, 1 for the JeeNode and 1 for the Touchscreen. The Pronto will follow soon.

From my Home Automation system i can control each of the 4 segments individually; i created a new device type and when i send a “L=30” command to this device, the LED strip on the left of the TV goes to 30%. When i send a “B=0“, the bottom LED strip goes to 0%. A “*=10” will result in all 4 LED strips to go to 10%.

The hardware (power supply, JeeNode, LED strips) is controlled by a PLCBUS appliance module, so when it’s time to go to bed, i don’t have to worry about additional standby power usage.

On the Touchscreen i added a popup form so i can change the settings of the LED strips:

TV LED control

Although I’m technically able to, i didn’t put 4 trackbar controls on this form to control each LED segment individually. The reason for that is that I don’t think it will ever be used by anyone else but myself. I think, in daily practice, these 4 LED strips will only be switched on and off, once a brightness level has been set that suits the ligthing in the rest of the living room.

The sketch that is running on the JeeNode is pretty straight forward, once you’ve seen Jean Claude Wipplers sketch to control RGB strips. I think it’s needless to say that without his hardware, software and sharing of knowledge, i would probably still be watching blinking LEDs… well, sort of 🙂

Well, anyway, here it is.

Curious about how the back side of the TV looks right now? Here you can see where the LED strips are attached to the back side of the TV and where i placed the 12V adapter and the enclosure that holds the MOSFET plugs, JeeNode and XBee.

Once i had it all (more or less) figured out, it took me 2 afternoons to go from a cardboard test setup to what it is now. Based on the response from wife and children, this is the best thing that has happened since the introduction of the touchscreen. Which I implemented 18 months ago… 😕 And what has happened to that $$$ Roomba???

Update:

Power consumption? The LED strips provide enough light @ 16%, resulting in a total of 2W power usage. Not bad!