Tag Archives: Xbee

RF to Zigbee gateway

  By Robert Hekkers | December 2, 2011 - 18:00 |
9 Comments

The last piece of missing hardware is finished. The picture below shows the 2nd RF to Zigbee gateway I had to make to be able to receive all the Hydronic balancing sensors I made earlier this week. One of those sensors just couldn’t make it through 3 walls all day long, so I created  a temporary solution on a breadboard to solve this.

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!

Half-way there?

  By Robert Hekkers | December 19, 2010 - 21:51 |
Comments Off

Today I changed some things on my previous setup, after testing & concluding that XBee IO Change detection doesn’t work during sleep, which I already anticipated.

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.

MCU-less experiments

  By Robert Hekkers | December 16, 2010 - 22:27 |
1 Comment

Some days ago I was reminded of the fact that the Hall-effect sensor I’m currently testing, could very well do without a JeeNode; a combination of this sensor with a XBee could maybe suffice as a wireless sensor. Right; so I made this breadboard setup:

A3214 sensor with XBee

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!

Lamp replaced by “DIY Ambilight”

  By Robert Hekkers | September 19, 2010 - 19:15 |
1 Comment

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!

Trying to get a date with Plugwise

  By Robert Hekkers | August 12, 2010 - 21:46 |
Comments Off

Having Plugwise in my house since December 2008, playing around with Digi Series 2 XBee modules for some time, knowing both are Ember EM250 based; nice ingredients for some fooling around with those two. I’ve already been asked a few times if I could ‘see’ any Plugwise traffic or other signs of the Plugwise network. No, i did not. Cause that would be wrong, if those would interfere that easily. And to tell you the truth, i wasn’t really interested enough to spend much time on this.

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 :-)

Dropping fast…

  By Robert Hekkers | July 24, 2010 - 00:01 |
Comments Off

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)

ZigBee Coordinator relocated

  By Robert Hekkers | July 20, 2010 - 16:03 |
Comments Off

This is how my ZigBee Coordinator has been on my desk since the beginning:

ZigBee Coordinator

Not a good idea to keep it this way forever. So it was time to give it a nice enclosure and move it to the meter cabinet. I found an enclosure in which there’s plenty of room for the XBee Explorer board. Some sawing, drilling and adjusting resulted in the following.

Zigbee CoordinatorCoordinator

That looks much better! It doesn’t bring any new functionality, but it does make things look more “complete”…one of those things i often forget, because the next thing is already waiting to get started… :-)

XBee Configuration

  By Robert Hekkers | July 9, 2010 - 19:36 |
2 Comments

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

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!

ZigBee Network monitoring

  By Robert Hekkers | July 5, 2010 - 18:07 |
Comments Off

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

X-CTU tool

XBee Supply Voltage monitoring (3)

  By Robert Hekkers | June 26, 2010 - 22:45 |
Comments Off

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:

RC Cars

Batteries are being charged! :-)