And here is the new cable (I replaced the six pin female header with a RJ11 crimp connector):

Onwards!

Hardware

The P1 port is a RJ11 port, using the following pin out:

I grabbed an old modem cable, with RJ11 plug and then I connected the appropriate pins to a modern devices USB-BUB. This device provides all the pins required. The request pin, as described above must be kept “HIGH” to retrieve data (i.e. provide 5V all the time). So I connected the request pin to the USb-BUB 5V. The other pins are DATA for the output, which I connected to the RX pin of the USB-BUB and GND which I obviously connected to the USB-BUB’s ground. This is a temporary solution until I get a proper 5V FTDI cable.

Note: to connect to the serial port, you need special port settings: 7 data bits (instead of the more regular 8) with even parity at 9600 baud.

Software

The P1 port uses a reversed serial protocol (1=0 and 0=1), to get this to work with a FTDI chip (this chip is used on the USB-BUB) you need to reverse the RX pin. Luckily FTDI provides a tool known as FT_PROG to do this. Thanks to Verkenner on the domoticaforum for figuring this one out. Here is a screenshot which shows you how to make the inverse RX setting in FT_PROG:

After programming you can also use the same cable under Linux, which is good because I run HouseAgent on Linux. Creating a plugin for HouseAgent was an easy task, it took me roughly 1.5 hours. For those of you interested in this plugin, you can find it’s source on Github.
And because of the built in graphing capabilities of HouseAgent (the screenshot is v0.2 btw :-) ), it was easy to create a graph of the current power usage (click for larger image):

One more thing I would like is bar charts of power usage over a longer period, but this requires some modifications in HouseAgent.
So there you have it, total insight on energy and gas usage!

Next we need to import the patch file into the vSphere Update Manager, the patch file is included into the downloaded zip file. It should be named: iomemory-vsl-2.3.9.54-offline_bundle-632012.zip. From the vSphere Update Manager click the “Import Patches” link:

Follow the steps in the wizard, after that the patch should be visible in the repository:

The next step is to create a baseline and assign the update to the baseline. From the baseline and groups tab, select “new baseline”:

Next, select “Host extension” as baseline type, this important because otherwise the update will never be applicable to any of your hosts.

In the next wizard step, include the Fusion IO driver:

Finish the wizard. Last but not least, we need to assign the baseline to the appropriate server, or cluster. Then scan the specific host or cluster and remediate the entry or entries. I have not included any screenshots of these steps because this is specific for your environment.

• 6 switchable and measurable sockets
• Overcurrent (10A fuse) -and surge protection
• 0.1W precision on load monitoring (energy measurement)

Here’s a picture of the device:

I was very curious whether this device would work with HouseAgent out of the box. After pairing the device (piece of cake, if you follow the manual) with my Aeon Labs z-stick, I tried to add the device to the HouseAgent database. This is what I got:

Hmm odd values, at that point I had no clue what values to expect. So, I decided to give Homeseer a go to so how it would recognize this device. After importing the device into Homeseer, this is what I got (a huge pile of devices/values!):

(click to enlarge)

Aha, so it’s a multi instance z-wave device! Notice the multiple instances underneath the root device (device 8). I suspect this is what causes the issue in HouseAgent/open-zwave, looking at the logfile of HouseAgent I noticed this log line:

2012-03-20 17:47:19:953 All endpoints in this device are the same as endpoint 1. Searching for the other endpoints...

It seems only the first instance is detected and the root device, I need to troubleshoot this a bit further.

I decided to play around a bit with the device from within Homeseer, all the functionality seems to work as advertised (the metering works, switching individual sockets works!). The nice thing is that all the sockets are measured individually, but also the power bar itself is measured and switchable as a whole. One minor drawback of this device is the fact that you need to poll it for it status (it doesn’t advertise it’s status on the z-wave network). Another point of attention is the fact that GreenWave doesn’t support this PowerNode without their own gateway product. Although it appears to work just fine, I take no responsibility if it doesn’t work for you!

Conclusion

This is a very nice device for it’s price, in fact it does all I expect of a power bar. This bar is going to be great for my TV setup! There’s some work to be done on the software side (HouseAgent), but I am pretty confident I can get it to work with some effort.

Further investigation in the Windows (application)eventlog showed me the following information:

A File Server Resource Manager Service email action could not be run.

Error-specific details:
Error: IFsrmEmailExternal::SendMail, 0x8004531c, Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send as this sender

As it turns out you need give send permissions to the computer running FSRM. You need set this send permission on the mailbox you specified in the “Default From e-mail address”. To do this, type the following command from the Exchange Management Shell:

Add-ADPermission -Identity "MailboxName" -User "DOMAIN\Computeraccount$" -ExtendedRights "Send-as"

After setting this send permission the error no longer occurred!

Motherboard: Intel Desktop Board DH55TC
CPU: Intel Core I3 530 2,93Ghz
Memory: OCZ Gold Low Voltage OCZ3G1333LV4GK (8GB)
Harddisk 1: Kingston SSDNow SNV425-S2BN/64GB
Harddisk 2: 500GB Western Digital Green

All of the hardware is housed in a small desktop enclosure (as shown on the picture)

Hypervisor/Virtualization
With the initial setup of my home server I started with a Windows 2008 R2 installation, with Hyper-V on top.
After running on this system for about 2 months, I really couldn’t overcome the lack of USB passthrough in Hyper-V. A lot of domotica interfaces use USB, so I couldn’t use them within virtual machines.
I could off course still run my home automation software on the host (Windows 2008 R2), but this has a downside on the flexibility side. I just want my home automation software within a VM so it can be easily moved around to different hardware in case my server crashes.
This is where VMware ESXi comes to the rescue! ESXi does offer USB passthrough, it works very convenient. You can just plugin USB devices to the host and then add them to a Virtual Machine as hardware.
Here’s an example of a few interfaces connected to my home automation VM:

VMware ESXi (5.0) is offered for free with a few limitations:

- You can use a maximum of 32GB
- You can use only one processor (with unlimited amount of cores)

Both limitations are not a big problem for my home server setup. More information about VMware ESXi editions can be found here.

Virtual machines

I run quite a few VM’s on my home server, here’s a list:

- One Linux (Debian 6.0) machine running my home automation software (HouseAgent).
- One OSX Lion machine, for testing purposes (basically to test HouseAgent on OSX)
- Two Windows servers for general purpose (file sharing etc.)
- One Windows 7 Virtual Machine for general purpose and testing
- I also have some VM’s that are in the “Off” state but are sometimes powered on for testing, such a System Center Operations Manager (SCOM) test environment.

I hear you asking, OSX on ESXi? But isn’t that unsupported? Yes, it’s indeed unsupported but thanks to the ESXi unlocker for OSX this is now possible. The unlocker can be downloaded here. It runs very smooth with VMware tools installed.

So there you have it: three platforms (Linux, Windows and OSX) on one single server! Something I was looking for, for quite a while..

Disk layout
All VM’s use more or less the same disk layout. The OS disks are created on the SSD disk, whereas the data disks are created on the Western Digital disk.
My home automation is entirely created on the SSD, for optimal performance.

Performance
So what about performance? Well, even with 5 VM’s located on this hardware it still runs very smooth. Most of the time the VM’s are idle anyway.
CPU usage is around 15% on average. Memory usage is 7GB out of 8GB.

This concludes the first part of these blog series, I hope you enjoyed it so far. In the next post we’ll dive into the backup methods I use for my home server.

I think his/her spambot had to a pick a random word from those lists, but somehow it failed :-)
So, here’s a lesson.. if you do things like this, do them right and properly!

- 8Kb flash (yes, space does matter!)
- 0.5Kb SRAM
- Maximum operating frequency (20Mhz, using an external crystal)

Here’s a picture of this MCU:

To program this MCU you have to use an ISP (In System Programmer) programmer. I own an USBTinyISP produced by Adafruit, which is perfect for this job. There is a minor drawback though: the ATtiny chips are not supported out of the box within the Arduino IDE. However, there is a perfect open source library by the name of arduino-tiny available to support this MCU within the Arduino IDE.

Here’s a picture of my test setup with the USBTinyISP (on the right) connected:

The pins are connected as follows:

• ATtiny Pin 2 to USBTinyISP SCK
• ATtiny Pin 1 to USBTinyISP MISO
• ATtiny Pin 0 to USBTinyISP MOSI
• ATtiny RST pin to USBTinyISP RESET

After getting the connections right, I started my first programming attempt. The test sketch blink, which is the “hello world” for MCU’s compiled correctly but then:

Hmm, nasty java exception there. After some digging around I figured out the incorrect programmer was getting addressed in the boards.txt file coming with the arduino-tiny project. This file is located under in the Arduino hardware/tiny/ folder. In order to make it work with the USBTinyISP, you have to change the following line for each target board (the ATtiny85 at 1mhz is illustrated here):

attiny85at1.upload.using=pololu

Into the following:

attiny85at1.upload.using=arduino:usbtinyisp

After restarting the IDE, I was able to program the sketch!

Debugging

For standard Arduino’s, you can use a built in serial interface to debug. There is no such thing available for ATtiny chips. However, the arduino-tiny library does offer a debug interface. I used the USB-BUB from Modern Device to setup a debug interface. For the ATtiny85 the standard arduino-tiny debug interface is tied to PB3 of the ATtiny.
Once setup, you can use the regular Serial.begin() and Serial.print/println() functions. I connected PB3 to the RX pin of the USB-bub, off course there’s also a ground connection required so I connected the GND of the USB-BUB to the GND of my ATtiny. After that I was ready to start debugging…

So, here we go.. ready to start tinkering!

Looking for alternatives ZeroMQ caught my eye. A major difference is that ZeroMQ uses a brokerless design whereas RabbitMQ uses a broker based design.
Let’s have a look at both designs:

As you can see, there is a major change in architecture. However because we use a central “coordinator” already, that coordinator took over the role of “broker” role as well.
This way the change to ZeroMQ has minimal impact on plugins, or the way HouseAgent works in general. This architecture leaves some space for future high availability/failover scenarios, by implementing a second “coordinator”. I don’t want this post to become a RabbitMQ vs ZeroMQ comparison (just Google if you are looking for that), but I did want to point out this essential change.

So let’s look at the size of ZeroMQ. The size of ZeroMQ is a lot less (being c/c++), the shared library is 1.6MB and can probably be stripped down quite a bit by removing unused features. 70MB-1.6MB = 68,4MB space saving!

The code to implement ZeroMQ is available on Github right now, in the branch “zeromq”. In an upcoming blog post I will post a developers update, to adjust existing plugins so they work with the new system (the changes are minimal, promised!)

Feedback on the new architecture and code is greatly appreciated!