A very simple yet effective way (for me) to get the sensor data where I want it (in my Domotica system) with minimal effort.

The JeeNode acts as a RF receiver and just echoes everything with a valid CRC to the Digi XBee; from there it eventually arrives at my Zigbee Coordinator with which I can communicate over TCP/IP.

The JeeNode runs a slightly modified version of the RF12Demo sketch made by Jean-Claude Wippler. I used the NewSoftSerial library to create an additional Serial port, and added a few print statements for the XBee port, right there where the RF12Demo Serial.println()’s the received RF data to the Serial port. Compile, Upload, setting the RF band,  group- and node ID and I’m done!

This JeeNode is powered by a 5V USB adapter and the XBee gets its power from the 3.3V JeeNode ports. The XBee uses a Zigbee End Device AT firmware (2864) with the Sleep Mode set to Pin Hibernate. But because pin 9 is wired to GND, this means that the XBee is permanently on.  Only 3 wires are needed to connect the XBee to the JeeNode: 3.3V, GND and a JeeNode digital pin to the XBee DOUT.

That’s it – moving on with where this all started with: understanding the flow of  heating energy in our house!

I changed some settings in the XBee and I added a wire to Pin 9, the Pin Sleep Control Line. The XBee is now in Sleep Mode 5 (Cyclic Sleep Pin-Awake), which means the XBee wakes on timer expiration or when Pin 9 changes from high to low state. The latter (Pin 9 change) is what the extra wire is for; it connects the output of the Hall-effect sensor to Pin 9, so that when the sensor output changes, the state of Pin 9 changes also.

Now the Xbee sends an IO Data Sample frame each 28 seconds based on the sleep settings, but also when the magnet is being moved towards the sensor – because the XBee Pin 9 becomes low, the XBee wakes up and starts to send an IO Data Sample Frame. Great! So now I know instantly when the magnet comes close to the sensor; exactly what I need.

But that’s only half of what I need of course, because when the magnet is being moved away from the sensor, the sensor output (and XBee pin 9) changes back to high, but that’s not triggering a wake up of the XBee… hmm.

So I started searching the net and read about all kinds of latches, NOT gates, flipflops, and saw more circuits than I’ve never seen before in my life. I haven’t found what I’m looking for yet – I don’t even know if it can be done – but I’ll continue my search for a way to shortly ground the XBee pin 9 whenever the sensor output changes from high to low or vice versa.

Yeah I know, an ATMega, duh.

It looks like it’s working, although I haven’t spent that much time on this yet. Yes, I do see incoming “IO Data Sample” packets, I see differences in the bits for “open” and “closed”, but I also see multiple packets (3, 5) where 1 packet would be perfect.

Another big issue is that in this setup the XBee is working in “No Sleep” mode, and that’s a no-go of course when this is going to be battery-powered. Do I want to use cyclic sleep and have IO samples sent at a regular interval? No!, that’s always too late…

Does the XBee Digital IO Change Detection work while it’s asleep? Probably not, although I haven’t tested that yet. But the manual doesn’t give any clue that this will work, so chances are small that it will.

Maybe I can do something with the “Cyclic Sleep Pin-Wake” Sleep mode? Never used that one before…

Or, use a different approach; use “a” circuit, triggered by the sensor, that will wake up the XBee, make the XBee send a IO Data Sample (this can be done with some specific XBee settings) and put it back to sleep after the XBee has finished sending the sample. That’s where I have used a JeeNode for so far .. ; but maybe there’s a simpler solution?

Time to find out!

But why not try it some time? It has been on the to-do list for some time, but never made it to the top-5. But when there was another question recently from someone for whom i gladly spend lots of time without any personal gain or interest, i decided to try some things to see if a first small step could be made. I put 1 of my spare XBee modules into a XBee adapter, loaded the firmware version 2864 (XB24-ZB End Device AT), set the preconfigured PAN id to 0 (which means the XBee will join any PAN it can find) and uploaded the new configuration.

Now there’s this small green LED on the adapter labeled as ‘ASC’, which tells you the associated state of the XBee. When it starts blinking rapidly, you know you’re going in the right direction … reading back the Operating PAN ID from the XBee showed me a value like D6F0000134567. Hey, where have i seen that value before? It looks like a Ember MAC address.. YES, it’s the MAC address of my Circle+ ! How odd…

OK, i know. This is just a very small step; i know the PAN ID of the Plugwise network now; duh. Next thing to figure out is the encryption key; it’s time to join forces on this project that is in the top-5 now and is there to stay!

Plugwise still sucks in some perspectives, but this is nice. And i have no idea if this will ever come to something useful. But that doesn’t matter, just as long as I’m having fun with what I’m doing

XBee Supply Voltage dropping fast!

Oops… the Supply Voltage on my motion sensor is already down to 3060 millivolts. Suddenly it’s dropping very fast; this sensor has been operational for more then 7 weeks now, with IIRC 2 new and 1 older rechargeable battery of a brand with which i’ve had bad experiences before. I hope that’s what is causing this, cause if not, i have some work to do

The other 2 battery powered sensors are still doing fine, BTW:

Supply Voltages (click to view the realtime values)

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!

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

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!

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!

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…