This is just a part of the collection of things that are waiting to be assembled. Due to the hot weather lately, i haven’t had that much opportunity to spend time on making new nodes or start new projects. So the desk next to me is becoming a real mess by the constant arrival of new parts and pieces that are needed for the things i want to do in the near future. In fact I’m waiting for lower temperatures…

4 JeeNodes, an enclosure for my ZigBee Coordinator and (to the left) a black enclosure for something new: controlling LED strips with a JeeNode (and more), inspired by some posts on Jean-Clause Wipplers weblog.  More on that somewhere in August; before that, i’ll finish some loose ends, like the ZigBee Coordinator that’s still here in the office, occupying space on my desk. This Coordinator will be moved to where all my other controllers are, i.e. to the meter cabinet. There i can combine all the separate power supplies used for each controller to a smaller number of more powerful ones, in order to reduce power usage (or power loss, to be precise). Maybe that will save me some power that was used by the air-conditioner in the last couple of weeks…

Another project is almost finished; my JeeLabs Lux Plug moved inside an enclosure.

JeeNode Lux Plug

The Lux Plug is inside the enclosure with the rest: battery holder, JeeNode and XBee module. In my opinion there was no need to put the sensor in it’s own small enclosure like i did with the motion sensor; there are enough places where i can place this enclosure in such a way that the sensor can measure the light intensity and still be relatively invisible. So this Plug is fitted directly into one of the 4 JeeNode ports and a hole in the enclosure is enough for this sensor to work well.

Another fun project! I saw a Z-Wave sensor a few days ago, costing >100 Euros. Ok, it has a LCD and a beep tone ofcourse (who can live without that!), but basically, it does the same thing: measuring lux! In my opinion, i got more value for money… but hey, who am i

With a bit of soldering, some code and a lot of fun you can create your own!

#include <Ports.h>
#include <RF12.h>
#include <avr/sleep.h>
#include <NewSoftSerial.h>

#define DEBUG 0

NewSoftSerial XBSerial = NewSoftSerial(2, 3);
PortI2C myBus (1);
LuxPlug sensor (myBus, 0x39);

int pinCTS=6;                         // to monitor CTS
int pinXBee=5;                        // to Control XBee on/off

static int SampleInterval = 30000;
static int HeartBeatInterval = 90000;
static int CTS=0;                     // value of XBee CTS pin

static void lowPower (byte mode) {
    // prepare to go into power down mode
    set_sleep_mode(mode);
    // disable the ADC
    byte prrSave = PRR, adcsraSave = ADCSRA;
    ADCSRA &= ~ bit(ADEN);
    PRR &= ~ bit(PRADC);
    // zzzzz...
    sleep_mode();
    // re-enable the ADC
    PRR = prrSave;
    ADCSRA = adcsraSave;
}

EMPTY_INTERRUPT(WDT_vect); // just wakes us up to resume

static void watchdogInterrupts (uint8_t mode) {
    MCUSR &= ~(1<<WDRF); // only generate interrupts, no reset
    cli();
    WDTCSR |= (1<<WDCE) | (1<<WDE); // start timed sequence
    WDTCSR = bit(WDIE) | mode; // mode is a slightly quirky bit-pattern
    sei();
}

static byte loseSomeTime (word msecs) {
    // only slow down for periods longer than twice the watchdog granularity
    if (msecs >= 32) {
        for (word ticks = msecs / 16; ticks > 0; --ticks) {
            lowPower(SLEEP_MODE_PWR_DOWN); // now completely power down
            // adjust the milli ticks, since we will have missed several
            extern volatile unsigned long timer0_millis;
            timer0_millis += 16L;
        }
        return 1;
    }
    return 0;
}

static MilliTimer SampleTimer;     // Interval for reading a sample from the BMP085
static MilliTimer HeartBeatTimer;  // forced maximum interval (Heartbeat)
word payload;

static byte periodicSleep (word msecs) {
    // switch to idle mode while waiting for the next event
    lowPower(SLEEP_MODE_IDLE);
  // see http://news.jeelabs.org/2009/12/18/battery-life-estimation/
  if (loseSomeTime(SampleTimer.remaining()))
    SampleTimer.set(1); // really did a power down, trigger right now

  // return true if the time has come to do something meaningful
  return SampleTimer.poll(msecs);
}

static unsigned long tBusy0;
static unsigned long tBusy1;
static unsigned long tBusyPrev;

static void Send() {

  unsigned long tXB1;    // time XBee was woken up
  unsigned long tXB0;    // time XBee was put to sleep

  HeartBeatTimer.set(0);  // disable heartbeat

  CTS = HIGH;
  tXB0=millis();
  // wake up Xbee
  digitalWrite(pinXBee,LOW);

  // wait for CTS to become LOW
  do
  {
    CTS=digitalRead(pinCTS);
  } while (CTS != LOW);
  tXB1=millis();
  // wait 2 msec otherwise data will be received all messed up
  delay(3);

#if DEBUG
  Serial.print(millis());
  Serial.print(" Send ");
  Serial.print(tXB1-tXB0);
  Serial.print(" ");
  Serial.println(payload);
#endif

  // send dummy data
  XBSerial.print(tBusyPrev);
  XBSerial.print(" ");
  XBSerial.print(tXB1-tXB0);
  XBSerial.print(" ");
  XBSerial.println(payload);

  // wait for XBee to finish transmission
  delay(4);

  // switch off XBee
  digitalWrite(pinXBee,HIGH);    

  HeartBeatTimer.set(HeartBeatInterval);
}

int ReadSensor() {

#if DEBUG
  Serial.print(millis());
  Serial.println(" Readsensor");
#endif

    sensor.begin();
    sensor.getData();
    payload = sensor.calcLux();

    return 1;        // always report for now.
}

void setup() {

  // setup XBee
  pinMode(pinXBee,OUTPUT);
  digitalWrite(pinXBee,LOW);
  pinMode(pinCTS,INPUT);
  digitalWrite(pinCTS,LOW);
  delay(10);

  XBSerial.begin(9600);
#if DEBUG
  Serial.begin(9600);
#endif
  // give XBee some time to join PAN
  delay(5000);

  // let the world know we're here
  XBSerial.println("[Lux002]");
#if DEBUG
  Serial.println("[Lux002]");
#endif
 delay(5);

 watchdogInterrupts(0); // 16ms
}

void loop() {
    if (periodicSleep(SampleInterval)) {
      // sensor values changed or heartbeat interval elapsed?
      tBusy0 = millis();
      if (ReadSensor() || (HeartBeatTimer.poll(HeartBeatInterval)))
      {
         Send();
         tBusy1 = millis();
         tBusyPrev = tBusy1-tBusy0;
       }
    }
}

Lennart Herlaar and me are really hooked up to all this Arduino(-compatible) stuff; we both started somewhere in September 2009 with our first ‘trials’. My first experiment was with an Arduino Duemilanove and some LEDs; resulting in instant addiction! Once you discover what can be done with this platform and how you can use it, every day new ideas and interesting projects pass by. Exciting!

We decided to see if we could share our enthusiasm with a larger group of Domoticans; cause there are a lot of Domotica related things you can do with the Arduino platform. Normally Domotica related hardware is quite expensive and closed, in the sence that every manufacturer creates its own proprietary protocol and tries to keep it a secret as much as possible; even changing it for the sole purpose of making all knowledge gathered by reverse engineering useless(!). Interaction between products of different companies is still very hard (if at all) to find – and most Domoticans are forced to use commercial Home Automation software like Homeseer to tie it all together. However, without a Plugin available for that special type of hardware you’d like to use, you’re practically doomed…

So when we started thinking about organizing an Arduino workshop for the members of the Domoticaforum Europe, we knew right away that we couldn’t do that without also supplying a Homeseer Plugin with it; well at least create a framework that would enable the workshop attendees to connect their new Arduino-based hardware to the most used HA software here in the Netherlands.

And that’s exactly what’s going to happen; when we get enough response (a mimimum of 15) to our post on the Domotica forum and we decide to go ahead with organizing this workshop, we’ll also have to start thinking about how to create an easy to use, flexible, future proof Plugin that can interface with the Arduino platform and it’s compatibles like (my favorite) JeeNodes..

It will be fun! As always

I have the feeling i’m getting somewhere

I updated my ZigBee network webpage and added a configuration panel with which i can configure all the XBee radios in my WSN (well, it’s a WSAN actually).

XBee config

Since my Home Automation system doesn’t have a GUI of itself and configuring XBee radios from a touchscreen without keyboard didn’t sound like a good idea either, i thought it would be best to create a web page for that. There’s still some work to be done in showing the XBee response on the page after the remote AT command has executed, but that’s a minor thing; “under water” i can see everything is working fine. With a click of the ‘Send’ button the values entered on the page are concatenated into a single string with a special delimiter and then sent off to my system using XMLRPC. The ZigBee API interface will then construct 1 or more ZigBee frames based on the values, send those frames to the targeted XBee radio(s) and wait for the responses to arrive. That’s it, basically.

Being able to do all this, is what makes me feel i’m getting somewhere; now that i’m able to monitor and configure my XBee radios in a convenient way, it’s time to really move on and start ‘mass production’ of all kinds of sensors and other stuff that are on my wish list.. starting with a bunch of motion detectors and a LED strip controller! After that, some room-oriented sensors (combining motion, temperature, light and perhaps humidity in one package) will be made. Can’t wait!

With an increasing amount of XBee modules operational (6, at the time i write this)  and the nature of a ZigBee network, i felt the need to monitor some network related stuff; what’s going on in there?? Do my End Devices make use of a Router when i relocate them, further away from the Coordinator? What about signal strength? All those questions can be answered with the ZigBee Network monitor i created last weekend.

It’s totally integrated into my Domotica system of course, which takes care of 95% of all the work; what was left was parsing the Remote AT Command responses coming back from the XBees. For example, a response byte of 33 to the ‘DB’ command means that the RSSI of the last received packet is -51 dBm.  Task scheduler, database storage, events being triggered on value changes, it’s all available. Want to create a chart of RSSI values? Easy. Receive SMS alert when a XBee is ‘lost’? Consider it done.

I created a webpage that shows the current values for some XBee configuration values, produced by this ZigBee Network monitor. No more X-CTU for me (OK, not completely: uploading the right firmware and changing some initial settings will still be done from behind the PC…) But once the right PAN ID has been set and the XBee has joined, local configuration isn’t needed anymore. This makes life a lot easier!

X-CTU tool