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!

A boxed PIR13

Two PIR13’s arrived yesterday. I immediately unpacked them to see if they would fit in the enclosure I want to use for them. It fits, but there’s not much room for error.

The lens is larger than the one on the previous PIR I used; this one requires a 13 mm hole, the previous was 10 mm. And the PIR13 lens sticks out more then the Panasonic version. But still, i prefer this much more than the X10-RF motion sensors i used in my former life πŸ™‚

The PIR13 PCB is glued to the top plate with hot glue. As you can see there’s not much tolerance along the long sides of the PCB; if the hole through the top plate is a bit excentric, you’ll have a hard time to make it all fit right. So pay attention there!

One nasty thing happened to me while preparing the 1st PIR13 to fit in the box; i decided it was wise to get rid of the 3 headers that are sticking out of the PCB; they were much to long! So i took my soldering iron and tried to get those things out. Normally, when you remove the plastic piece of the header and hold the soldering iron against a pin, they automatically fall out, sometimes with a bit of help, or they stick to the soldering iron. This time it was different; as if the pins were rammed into the PCB with a hammer! So i used a pair of pliers to gently pull the pin out; and while doing that, i damaged the PCB in a way that can’t be repaired anymore; aarggh!! First a voltage regulator blown up, now this.. what is this??

With the 2nd PIR13, i just cut off half of the pin length…

I foresee a “battle” for my spare time, between the LED strips and this new motion sensor… πŸ™‚

Trying to get a date with Plugwise

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 πŸ™‚

Motion sensor v2 built and in use

Two motion sensors v2 are in use right now, yippee!

I upgraded an existing v1 sensor to a v2 and built a new one. The v2 sensor specs are very different from the v1 but much more promising, yet all i needed to do to was soldering the digital output of the PIR to another JeeNode port (namely ATmega INT1) and use a different digital port for serial I/O with the XBee. Oh, and upload a new sketch of course. Now i have 2 identical v2 sensors:

v1 upgraded to v2

Looking back at how this motion sensor evolved i am wondering, why didn’t i think of interrupts in the first place… not very smart actually..

Or maybe i did think about interrupts but unconsciously thought it would be to hard for me to handle already, cause that’s what you read all the time: interrupts are a tough subject! Maybe it is, but i didn’t notice that yet! πŸ™‚

So now I’ve got 2 motion sensors with the following features:

  • powered by 3 * 1.2V, 2000 mAh rechargeable batteries;
  • PIR with digital output, 100Β΅A standby power usage and 5m detection range;
  • a JeeNode that’s effectively running only a total of about 180 seconds per day (0.2 %), even with 350-400 motion reports and lots of heartbeats. The rest of the time the JeeNode is in power down mode;
  • it’s ZigBee based which is better than 433 MHz in my opinion, especially when you’ve got a lot of sensors;
  • relatively small sensor housing compared to commercial (mostly big and ugly) products;
  • completely DIY so everything is how i want it to be;
  • interrupt-based, the best you can get I’d say;
  • need i go on?Β  πŸ™‚

I’m gonna monitor this sensor very closely in the coming months and learn from it. Here you see one of the sensors being used in the kitchen:

Motion v2 in the kitchen

Finished? Almost; some loose ends in the sketch. Maybe it can be made even smaller/faster/less energy consuming. But I’ll look into that when the 3rd sensor is built.

Update 2010-09-16:

The sketch that’s currently running on these sensors can be found here; the Sleep library i currently use can be found here .

ZigBee Coordinator relocated

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

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

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

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

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…

New motion sensor in use

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

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

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..

Motion sensor in next stage

This weekend i spent some time to make the experimental PIR sensor setup i made some time ago, a bit more permanent. Ingredients:

Enclosure modified with hobby knifeThe enclosure i used this time is a bit different from the enclosure i used on a previous occasion. This one lacks the inner ribs and opening and closing is a bit harder: for opening the enclosure you need to put a screwdriver between the 2 halves and twist it to get the enclosure open.Β  The first thing i did was making my life easier by removing the ribs that keep the 2 halves together on one side of the enclosure. Some more modifications here and there now make it possible to open the enclosure without any additional tools, but still will not open by accident.

PIR enclosurePIR enclosure

I drilled a 10 mm hole into the PIR enclosure so that the PIR fitted nicely through the top plate; a drop of super glue on the inside did the rest. There was plenty of room for the 100k pull-down resistor inside the PIR enclosure so i soldered it to the PIR there. An extra hole of 4 mm and a cable tie for the wire completed the PIR box.

JeeNode, XBee

JeeNode, XBee

This being my first motion sensor built this way, i added a LED to be able to see what the XBee radio is doing; is it still transmitting or not, when, how often, etc. ? Maybe this is overkill, but when this sensor is placed somewhere in the house with no computer screen nearby, it can be very handy to see if the sensor is still functioning instead of running to and from the nearest screen…
If the flickering of the LED is to visible or annoying in the future, i can always disable it or make it invisible by a piece of tape over it; but for now, this LED seemed like a good idea to have. The LED lights up when the XBee is on and from the duration that the LED stays on i can see what’s happening; whether it’s transmitting (very short durations) or having PAN trouble (long).

The software part of this sensor will be the most time consuming of it all i guess. Since i want it to be battery powered, i’ll have to consider what is relevant information for my Domotica system, and when it is. In fact, the only thing that really matters is one single thing: fast motion detection! All the rest is less important.
Cause what do we Domoticans use this motion detection for? To turn things ON… not OFF; at least, i don’t.

Further more, a quick look in my events history tells me that from 01-04-2010 till today i missed (my 433 MHz RFXCOM receivers, i mean) a total 869 ‘OFF’ transmissions (meaning “no motion”) from my 10 MS13 motion detectors. That’s way to much to be called reliable! So my system already has the capability to deal with this situation of missing ‘OFF’ transmissions; when a MS13 hasn’t reported neither an ‘ON’ nor an ‘OFF’ for a specific time interval, i set the motion sensor back to ‘OFF’ in software.

So.. i could as well do without this ‘OFF’ completely; i don’t use it as a trigger, so why send this non-information anyway?

What i do want to have is a heartbeat, every 90 seconds or so. And i would like to have an ‘ON’ being sent with a specific interval when motion is detected continuously. That’s what I’ll be working on in the coming week.

To be continued.