After opening up the cable I noticed it used a “PL-2303HX” USB to serial chip. Searching Google appears it is made by Prolific. Unfortunately however the standard Prolific drivers do not work because the cable has a custom USB PID “1234″ instead of the standard Prolific PID of “2303″. Two possible solutions came to mind, either changing the chip back to the default PID such that Windows would recognise it as a standard Prolific serial adapter, or modifying the Windows driver to recognise the non standard Prolific PID.

I first tried reprogramming the chip. Appears it has been successful for someone using a T230 cable (EEPROM Writer link on that post is nolonger working however there is a copy at Megaupload via Jonathan Thomson’s Web Journal). I was however unable to get it to recognise the cable and looking on EDA Board appears a special “EEPROM programming cable” may be required.

I next tried modifying the Prolific driver, and was then able to install it however started getting a Windows error “This device cannot start” (and after rebooting I was unable to login – unplugging the USB adapter and rebooting again fixed the issue).

Next option I may try is either rewiring the adapter with another USB to serial chip that does have Windows 7 drivers or putting the SIM in a GSM modem / another phone that can be easily connected to a PC.

Parts were all from CCL for convenience as I was not placing the order myself, and they are competitively priced, however I have had a bad experience trying to return a faulty part to them a few years back.

I went with the following components:

Note: Cost excludes postage, I used some spare front and rear fans I already had.

I looked into various options such as services from AAISP who can deliver text messages to email, or a web form, which initially seemed perfect (they also have some good options for voice calls as well such as supporting multiple numbers on a single SIM both inbound and outbound, and VoIP termination) however then discovered that it is not possible to port a number to their service. I also found another similar company AQL who do support porting, but not for mobile numbers.

The option I came up with in the end to handle forwarding text messages was to write a C# application that can run on the PC desktop (in the task tray), connect to the phone over Bluetooth serial link (should also work with a regular serial / USB serial cable), poll it for unread text messages every few seconds, forward any found to a specified email address (which I can receive on my other phone), and delete them from the phone. Bluetooth is an ideal solution since it means the forwarding just works automatically whenever the phone is left at home by the computer.

Download: Source Code | Application

Notes:

• I was initially planning on using a Sony Ericsson DCU-11 sync cable however discovered it does not have any Windows 7 drivers available, and does not support charging.
• I found that Windows 7 by default did not seem to support connecting to my Sony Ericsson T610 over Bluetooth, therefore download the BlueSoleil Bluetooth stack which did.
• Application uses Stefan Mayr’s GSM library.

1. It is equipment using GSM, making use of various different phone networks, and cell towers that can not be easily replicated.
2. The issue only occurs on location in the field (i.e. live customers using the device).
3. It is an intermittent issue that can not be replicated on cue, ruling out simply going to the location for an hour setting up the relevant equipment and logging the issue.
4. Devices are in locations where it not particularly convenient / safe to setup and leave expensive testing equipment / laptops etc.
5. Testing equipment needs to run a Windows only application from a hardware manufacturer that needs “babysitting” (restarting if it stops logging).

I recently faced this issue. I tried a few options including blindly guessing at what the issue could be and implementing fixes for various possible issues, next tried working with the network operator (which got nowhere). Final solution I came up with was to build some custom / cheap (in comparison to the alternative) logging hardware to take the place of the hardware development board, Windows running laptop, hardware manufacturers software tool.

My first thoughts were that this could be done by using an Arduino with an SD Card data logging “shield” however after some further research I discovered the Spark Fun OpenLog. The OpenLog was a perfect fit since it:

1. Can be powered from 3.3V – 12V (could just piggy back it on the existing devices power supply).
2. Serial levels compatible with 2.8V CMOS levels of device.
3. Already setup to automatically log serial data to files on an SD Card.
4. Open source firmware that is freely available, meaning I could customise it to emulate the manufacturers software tool (eliminating the need for the extra hardware, and meaning I could deal with the reliability issues).
5. Development environment (see section “Compile Version 2″) that is simple / relatively straight forward to obtain / setup / use (Ardino IDE – even though it is not “Arduino” branded hardware as such).
6. Supports upto 16GB microSD cards (device outputs large logs).

There were a few steps involved in the process including, connecting the OpenLog to the device, building a programming cable for the OpenLog, and customising the OpenLog software to emulate the initialisation string of the Windows software tool.

I have never coded AVR C before however found it relatively straight forward to make the modifications I required to emulate the initialisation string of the Windows tool (primarily logging the string with Eltima Software’s Serial Port Monitor application, saving the data to a file on the SD Card and instructing OpenLog to read it back over the serial port, then drop back into logging mode.

A few issues I encountered along the way were:

1. OpenLog stops reading files if it encounters a NULL byte, however this should be fixed in the latest release.
2. Error trying to upload new software from the Arduino IDE to OpenLog due to the DTR pin needing to be connected to OpenLog to reset it just before programming. I substituted DTR for RTS (which my FTDI cable did have broken out).
3. Device I was logging data to was outputting [CTRL]+[Z] 3 times – the OpenLog escape sequence – I therefore modified the escape sequence to be 9 times rather than just 3.

Parst List

One Off

Per Logger

Build Instructions

Solder Headers

• Solder a x4 way header connector onto the logger GND, VCC, TXO, RXI (i.e. miss out the first pin labelled BLK, it is not required).
• Solder a x1 way header connector onto the logger for the GRN pin (I used a 2 way with the other pin overlapping off the end of the board as I could not easily obtain a 1 pin)
• Solder a x4 way housing connector onto the wires from the device (match up GND/VCC/TXO/RXI to appropriate pins on the device).

Note: A 5 or 6 way header soldered to all logger pins could just be used but I thought this approach best to avoid any mistakes (broken loggers) – that way there is a x4 way header to use when plugging into the printer and you are not left wondering which 4 pins should be connected.

FTDI Programming Cable

Modify the FTDI cable such that it has the following pinout (compatible with logger). Use a flat screw driver to release the pins from the existing socket.

Notes

• Arduino needs to be modified with a special version of HardwareSerial.cpp to work with OpenLog.
• If your SD Card did not come pre formatted you may need to use the FAT32 microSD optimised formatting tool from SD Association.

I went early morning and avoided the rain, was not too busy early on but became more crowded later on.

GPS Route Log:

View Larger Map

I was somewhat hoping the update would just appear on yum and happen automatically however looking into it I realise this was unlikely to happen:

Quote: “As with each other program in CentOS, the version numbers of released software will not change over the life time of a CentOS product.” — http://wiki.centos.org/FAQ/CentOS5

After Googling for a few options and not coming up with any I was particularly happy with (i.e. mostly using 3rd party repositories) I happened to run “yum list|grep php” and noticed a set of “php53*” packages. Appears it was decided at some point to make both versions of PHP available such that the user can choose which to install, but old installs would not be updated automatically to (most likely) limit the possibility of issues caused by incompatibilities.

I therefore ran the below commands and was upgraded to PHP 5.3 much quicker and with a lot less complication than I was expecting:

service httpd stop

service httpd start

The AXIS M1054 (purchased from Network Webcams) fit my requirements. It has a very fully featured web interface, with a number of potentially useful features such as:

• Uploading /sending files via HTTP/FTP/Email
• Video based motion detection
• PIR based motion detection
• Triggering events via GPIO on camera
• Event notification via custom TCP socket protocol
• Pre/post event buffers (capture images from before/after the actual event is triggered)
• Motion JPEG, H.264 support, single image frame capture (JPEG)

I initially attempted to use the PIR to trigger an event (image upload to server) however the PIR has a limited range/does not work well through a glass window, I therefore switched to using the video motion detection. At first I found the motion detection to be somewhat unreliable however after spending time tweaking it, and a firmware update the situation improved, however not to a level where it was usable as a primary trigger (I found it would falsely trigger if too much changed in the image, e.g. shadows from sunlight). I therefore decided to setup the camera to upload images to a server on motion detection, and use a doorbell press event from my existing Synapse home automation mesh network to trigger a PC popup with the latest camera image. The combination of the camera motion detection, and doorbell event works well since it means I can obtain a single image of the caller (rather than relying on taking the last 5 images from the buffer – where depending on their walking speed any one / none of the images will have their image) and using the doorbell even eliminates the false positives of the cameras motion detection.

On the server end I had some difficulties receiving the images in PHP, however after some trial and error worked out that they could be read In the slightly non standard way of using “php://input” rather than “$_FILES”:

<?php
file_put_contents('camera_photo.jpg', file_get_contents('php://input'));
?>

In terms of the physical hardware, I was fairly impressed, it is a well constructed unit, supports POE, and supports a traditional wall based mount, or a clamp based mount (both or which are supplied in the box). It has a swivel arm with a large range of movement for finer adjustment. At 720p HD resolution the image quality is also quite reasonable, and with the motion JPEG support there are a number of apps that support the camera on the iPhone, such as the free NetcamViewer.

The camera comes with the AXIS Camera Station PC software. As far as I can see the main benefit of using the software is the ability to manage video recordings play/record (manually or motion captured – since the web interface only allows JPEG images). I had some problems with the server side component seemingly crashing/not responding to client connections, but not really needing this functionality it was not something I looked into any further (may have been a memory issue on the server).

In the future I may look into integrating it into with a SparkPad “open platform digital display” picture frame to popup the callers image in other rooms that do not have a PC.

Download: Camera Viewer Popup C#

Further Resources:

• Product Comparison: Axis M1104 vs. Panasonic WV-SP105 vs. Sony SNC-CH110
• Evaluation: Axis M1054 IP Camera

Features:

• Two channel (heating and hot water) support.
• Temporary Override (ignore schedule for 30 min – 1 day), both overriding on, but also off.
• Permanent Override (ignore schedule).
• Web based interface for changing schedule / override settings.
• Schedule support for any combination of weekdays.
• Schedule support for one off custom schedules on specific dates only.
• Setting date/time via NTP (with automatic support for time zones, and daylight savings – built into Linux server).
• Support for override control via Cisco 7960 phones (already located around house / managed by Asterisk).
• Wireless from control unit to programmer (linked to network).
• Self contained system – does not require separate PC server running 24/7.

Hardware

In terms of hardware the system is comprised of:

1. A relay box containing two opto-isolated 230V 3A relays with CMOS level control.
2. A control box with Synapse RF Engine installed in Synapse Evaluation board connected to several lights/switches allowing for local control over on/off, override settings, and visual indication of on/off status (evaluation board is connected directly to relay box).
3. An ACME System Fox G20 Board (Atmel ARM processor, running Debian Linux), linked to another Synapse RF Engine, the controller behind the whole system, connected to wired network.

I chose to install the relay box it in parallel with the existing timer clock. During normal use the existing timer will be turned to its ‘permanent override: off’ setting, this means that if the custom system were to fail it’s a simple case of powering it down, and going back to using the regular programmer.

Relay Box

In terms of mounting the relay PCB in the box I chose to use to use some nuts and bolts, hot gluing the bolt to the base. I also put some small rubber feet on the board to keep it more secure. This allows the relay board to still be removed from the box if required at a later stage.

I secured cables going into the boxes with cable ties (one on the outside and one on the inside), not the most professional solution but having used various cable grips before none of which seemed particularly secure (prone to popping out again), and being time consuming to fit therefore this time I opted for a simpler solution.

Control Box

The control box had limited space this meant things fit nicely without moving but I also used some stick on cable holders to hold the PCB steady, and placed a blank PCB in the box to separate the switches from the Synapse Evaluation board preventing the possibility of shorts.

I used a standard labeller with stick on labels for marking controls on the box, this did not lead to as professional a finish as I would have liked however I could not immediately think of a better options without paying out for a possibly costly custom enclosure.

In terms of wiring in the control box, it is fairly straight forward, a TS7809 [pinouts] to regulate the 12V PSU to 9V, switches connected directly from ground to GPIO pins (for pinouts see Python file), LEDs each connected to GPIOs via transistors [wiring diagram].

Software

Fox G20

The Fox G20 runs a PHP schedule application which sends signals to the control box LEDs / relays, and also receives button press events for override support. It does this via a serial / wireless link (using Synapse modules) to the control box.

The Fox G20 was chosen since it offers (in software terms) something very similar to a regular Linux PC – support for web server, PHP, Cron jobs, RTC (with backup battery), serial ports, Ethernet, hard drive (memory card) all in a small form factor (web server, PHP, cron support were even already installed on the purchased memory card), meaning that time consuming / fiddly cross compiling etc was not required as they might with other hardware.

Getting the Fox G20 out of the box I was immediately very impressed with it and was able to get up and running within minutes, only thing that was not immediately clear was the root password (netusg20) but this was quickly located after a search of the wiki.

[Download: PHP Schedule Application inc. Cron service]

Fox G20 – Synapse RF Engine

The Python script on the Synapse RF Engine simple connects the serial port to the transparent wireless connection.

[Download: Python Software]

Control Box – Synapse RF Engine

The Python script on the Synapse RF Engine mounted in the control box is responsible for sending out message over wireless serial when buttons are pressed, and processing messages turning them into GPIO on/off events to control the relays/LEDs.

[Download: Python Software]

Custom Build

A few of the decisions to build my own system include:

• Cost of commercial solution.
• Easily extendable as required (ability to just code new features in PHP).
• Support for control via Cisco 7960 phones (at any location in the house) – phones that support XML browser via “services” menu.
• Implementation of all existing features of current system easing user adoption (for other members of the household).
• Ability to make system wireless, but also separate from existing servers (independent system).
• Network support for NTP / timezones / daylight savings time.
• Key components that may be damaged by heat (unavoidable due to location) easily replaceable (e.g. just slot in new Synapse Module, purchase new power adapter).
• Easy to make remotely accessible (just code authentication support).

Implementation Notes

• PHP was not particularly designed to be used as a long running process (which is how it is necessarily used on the Fox G20 to receive data from the serial port. For that reason I wrote a separate script called by Cron to check it is running, or if not start it back up again. This causes a slight usability issue with the physical control box in that it may be unresponsive for up to 60 seconds (if the PHP process stops, and is pending a restart) however in practice this seems to happen only once every 5 hours, and the control box is rarely used anyway so it would be unlucky for a user to try and use it during that time. It does not cause any issues with the schedule since any on/off events that happened when it was not running will be processed when it starts back up again.
• I could have simplified things by having the Fox G20 board with WiFi module directly in the control box (removing the need for the Synapse modules) however did not do this due to possible issues with heat (cost of replacement), ease of access, and ease of hardware / software implementation (there does not seem to be a particularly simple/optimal way of supporting momentary push buttons in an event driven way, with the Fox G20 whereas there is with the Synapse).
• I chose to implement support for permanent overrides on the control box via momentary/non locking toggle switches. These are not ideal as they do not offer the user any feedback on the current state directly, however it seemed like the best option due to already using up most of the GPIOs on the Synapse Engine, and increased built time, especially when they are a rarely used feature. I chose to use non locking switches such that the permanent override setting could be changed via the web interface, but another option may have been to use locking toggle switches and remove permanent override control from the web interface.
• The Fox G20 PSU is supplied with a Euro plug, even if ordered in the UK, I therefore purchased a Euro to UK plug adapter, but another option would have been ordering a new 5V 1A PSU.
• Currently the system is still relying on the existing hard wired thermostat. Synapse recently brought out a new motion/light/temperature sensor which I may add in support for in the future. The motion sensor could potentially be used to automatically turn off the system (disregarding the schedule) if no one is in the house resulting in cost savings. To switch over I would simply set the existing thermostat to a high temperature such that it is always on, allowing the Synapse sensor to have priority.
• I only tested the blue LEDs initially which was a mistake since after implementation I found that the green LEDs were barely visible (I did not realise the greens require greater current), this meant the addition of some extra lower value resistors on the PCB that I had not originally planned for. Even so the green LEDs still ended up being significantly less bright than the blues however measuring current with a meter any lower resistor values (leading to a higher current) may have been out of spec possibly damaging / reducing the life of the LED. The reduced brightness is not ideal from a user point of view however is acceptable as the box is mounted inside a darkened cabinet.

Parts List

FOX G20 / Synapse – Pinouts

Further Information: FOX G20 – serial ports, FOX G20 – pinout

The FOX G20 has a 3.3V output that can be used to directly power the Synapse Module.

Further Resources

• Dean Smith – Comfort System
• Steve Jones – HomeVisionPro
• Keith Doxey – HomeVisionPro
• Honey Cottage – TOM10/xAP

Update 2011-07-06: The Synapse “motion/light/temperature sensor” is part of the “closed” SNAP-Lighting.com system, it can not be independently controlled via Python.

The unit operates from two AA batteries and features:

• 1 Red LED
• 2 Green LEDs
• 1 Buzzer
• 2 Push switches
• 2 Toggle switches

Apart from the toggle power switch all LEDs/switches are software controllable via GPIO pins.

If the doorbell is rung, the bell sends a multicast RPC call which is picked up by the unit. One of the green LEDs is then turned on. Depending on the status of the (non power) toggle switch the buzzer is then turned on as well (the non power toggle switch is used to enable/disable the buzzer). One push button is used to reset the unit (turn back off the LED/buzzer). The red LED is used to indicate the power on/off status. The remaining extra push switch/LED are currently not used but built in for possible future functionality.

Parts List

Note: The DC plug/socket shown in one of the photos was later removed due to lack of space inside the box.

Download: Python Software