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

This is what you get when a battery powered XBee is struggling to stay alive cause the batteries aren’t supplying enough ‘juice’ anymore:

FF FF FF FF FF FD 7A 1F 33 40 00 A2 13 00 01 FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 1D 00
01 53 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00
00 73 A0 73 B6 70 E0 73 CC 73 E2 06 40 75 5C 76 F0 76 3C 76 B4 76 3C
76 3C 73 F8 74 0E 74 22 75 1C 75 EC 75 60 74 2C 46 50 E6 00 01 02 00
00 00 00 E8 00 01 02 00 00 00 00 F3 E0 58 A0 FF FE 00 EC 30 BC 75 CA
A8 D8 B6 D5 9F FD 5A 7B FF FE 00 00 FF FE 00 00 FF FE 00 00 FF FE 00
00 FF FE 00 00 FF FE 00 00 FF FE FF FF 79 BE 01 4A 01 B0 01 62 01 4E
01 66 01 AC 01 60 01 82 01 9C 01 68 01 B2 01 94 08 1C 08 29 08 34 02
etc. etc. ...

For those not really experienced in recognizing XBee API frames from a byte stream: there’s not a single valid frame to be found inside all those bytes. But this is what my Coordinator received today.

But that’s OK; i intentionally left the XBee running on low batteries; I wanted to see what would happen. My code that should recognize valid XBee API packets just got it’s ultimate real life test. Cause normally, the byte stream coming from the Zigbee Coordinator is so clean you can hardly test it without writing a special tool that creates a mix of garbage, valid and invalid frames. Now i know for sure my code works!

Another good thing i saw, is that this ‘dying’ XBee didn’t create that much traffic resulting in other XBee’s not being able to get their messages to the Coordinator anymore.

This is really important actually; imagine you’re on holiday and a sensor runs out of battery power; do you really want to monitor your Home Automation system for that kind of trouble while you’re at the other side of the world? Become a slave of your own system? And have to call your neighbor that feeds the cat to remove the batteries or worse ? (“I don’t care how you do it, just do it.. Cut some red wires if you have to!”) Just to keep the system running? Not me!

In the meantime, this really nice weather only makes you want to play outside; sitting behind a computer with an airco blowing cold air in your neck is not my favorite right now:

Batteries are being charged!

Here are the results of the test i started 3 days ago. After 3 days of monitoring the XBee supply voltage the alkaline batteries were empty and with a bit of tweaking i got the data out of the logs and into an Excel sheet so i could create a chart:

XBee Supply Voltage

OK, this looks good and it’s easy to do; all you need are some changed settings on the XBee, a Domotica system that can fire the ‘IS’ remote AT Command to your XBee and your done. Well, almost

The JeeNode has been running a small sketch that transmits a dummy string every 5 seconds; without any sleeping and also keeping the XBee on all the time:

#include <NewSoftSerial.h>

#define SERDBG 1
NewSoftSerial XBSerial = NewSoftSerial(2, 3);

int CTSpin = 7;
int XBpin  = 6;

static void Send () {
  // send a dummy string
  XBSerial.print(millis());
  XBSerial.print(" ");
  XBSerial.println("XBeeaaaaaa");
#if SERDBG
  Serial.print(millis());
  Serial.print(" ");
  Serial.println("XBeeaaaaaa");
#endif
}

void setup() {
  // setup XBee
  pinMode(CTSpin,INPUT);
  pinMode(XBpin,OUTPUT);
  digitalWrite(XBpin,LOW);
  digitalWrite(CTSpin,LOW);
  delay(10);

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

  // let the world know we're here
  XBSerial.println("[XBeeVoltage]");
#if SERDBG
  Serial.println("[XBeeVoltage]");
#endif
}

void loop() {
  delay(5000);
  Send();
}

The JeeNode stopped working at around 2/3 of the horizontal axis, so after 48 hours or so where the voltage had already dropped to 2,64 V. The XBee is still working as i write this, with a voltage of 2,3 V. I wonder how long it takes for the XBee to give up too…

Conclusion: this can definitely be used as a way to remotely monitor my battery powered sensors; Yippee!

One thing i would really like, is being able to monitor the voltage the JeeNode and XBee are running on. Now the XBee has a %V command, specially for reading the voltage on the Vcc pin. So let’s see of i can use this.

The first thing i noticed was that the XBee i configured with the AT End Device firmware, didn’t respond to the %V command. Hmm, correct; the manual was very clear about it: the %V command is only supported by a Router  and not by a Coordinator or an End Device. And it’s those End Devices  (which will run on batteries) that i want to monitor…

OK.. next command to have a look at was the ‘IS‘ command, which stands for Force Sample; this command forces a read of all enabled digital and analog input lines and a small comment told me it could also return the supply voltage: “Analog samples are ordered sequentially from AD0/DIO0 to AD3/DIO3, to the supply voltage.”  So lets try this one, shouldn’t be to hard i guess?

So i added support for this command to my API and started sending frames to the XBee:

Sending frame:7E 00 0F 17 01 00 13 A2 00 40 33 1F 7A A2 ED 00 49 53 FB

I won’t go into detail of every byte in the frame above, but the 2 bytes marked in red are the ASCII codes for ‘I’ and ‘S’: yes, ‘IS’, the command we want to be executed on the remote XBee. The response that came back from the XBee was encouraging, however, no supply voltage was present, only the values of some random Analog input lines i enabled:

Rcvd Frame:97 01 00 13 A2 00 40 33 1F 7A A2 ED 49 53 00 01 00 00 02 02 09
FrameID=1, Command=IS, Status=0, Command Data size = 6 (01 00 00 02 02 09)

With the help of an example i found out the meaning of the Command data:

IS response example

OK… the frames that were being received looked nice, but it’s not what i want… where’s the supply voltage? The example above doesn’t show it either.. but it must be possible, right?

After searching for more than an hour, i suddenly bumped upon a setting in the X-CTU tool (in the I/O Sampling section), that had the following description:

Configure the supply voltage high threshold.  If the supply voltage measurement equals or drops below this threshold, the supply voltage will be included in an IO sample transmission.  RANGE:0-0XFFFF

Aahh, that must be it… this setting has a default of 0, causing the supply voltage to never be included in an IO sample! I set the value to FFFF, disabled all other I/O lines on the XBee et voila:

Rcvd Frame:97 01 00 13 A2 00 40 33 1F 7A A2 ED 49 53 00 01 00 00 80 0A BC
FrameID=1, Command=IS, Status=0, Command Data size = 6 (01 00 00 80 0A BC)

This means there is 1 sample set, containing the supply voltage, and the value is: 0ABC.

Multiply this with 1200/1024 and you get the supply voltage in mV:

($0ABC =) 2748 * 1200/1024 = 3220 mV. Great!

Tomorrow i’ll add some code to my HA system to periodically send an IS command to this XBee and store the results. And then just wait and see what happens when i let a JeeNode and XBee running on alkaline batteries 24/7…

After my problems with the MS13 sensors yesterday, i managed to find some spare time (even though, or maybe because it was father’s day) to write a sketch for the new motion sensor i created during the last couple of weeks. Always taking one step at a time, i located the first prototype of this sensor at a place where i can see the enclosure LED from the living room: i want to know how it performs…

New motion sensor

Now powered by 3 rechargable NiCd batteries and with all hardware nicely put away in the enclosure. In due time the enclosure will be moved out of sight so only the PIR will be visible. I’ve decided to use 3.5 mm jack plugs to be able to disconnect the enclosure from the sensor, so i can easily take the enclosure back to my office, because i don’t think the JeeNode is already running the final version of the ‘PIR’ sketch…

A new class, 2 database records and 1 line of code were enough to get the sensor working in my Domotica system:

procedure TAMN31112.ProcessInterfaceData;
begin
  Pin(1).AsBoolean:= (O.Data[1]='1');
end;

The new PIR can be viewed from my website (it’s called BP PIR):

Battery powered PIR

The sketch is still under development; for instance, how much difference would it make if i change the DigitalRead() into a bitRead()? I’ll have to read more about that on JeeLabs … Other questions are: should i increase the heartbeat interval (currently 45 seconds) or the Motion report interval? Can i create some sort of battery power monitoring with the XBee? But that will all be investigated when i’ve finished building my second motion sensor based on JeeNode and XBee..

I wonder how Homeseer users deal with this..

Cause this is what you get when the batteries of a MS13 motion sensor are empty:

Yep.. last Saturday it happened again, around noon… one of my MS13 motion sensors had empty batteries, causing it to start sending rubbish all the time. Yes.. all the time! Side effect is that all other 433 MHz traffic is being jammed, causing a spike of more than 3600 unrecognized packets being received by my RFXCOM receivers. Fortunately i have 2 of those receivers, so not all data is lost. Otherwise my whole 433 MHz sensor network would have collapsed…

This time it was the motion sensor in the kitchen that had its batteries empty. Away with it! I removed the batteries and didn’t put new ones in. For me, the MS13 motion sensor is over and done with. No more!  This is the 3rd time in 2 years i had to go hunting for an MS13 that was jamming all other traffic. And of course, the faulty MS13 was the 3rd sensor of which i removed the batteries; so now i have to reprogram 2 of them again…Yuck!

I have better things to do… like finishing my own motion sensor, with heartbeat and no reprogramming needed when batteries are replaced… yeah!