Building A Web Accessible Heating / Hot Water Programmer (Home Automation)
I recently got round to completing a central heating / hot water automation project I had been meaning to do for a few years but previously issues over cabling, heat (i.e. possible damage to electronics), hardware choice, and various other installation issues had caused me not to do it until now.
- 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.
- A relay box containing two opto-isolated 230V 3A relays with CMOS level control.
- 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).
- 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.
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.
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].
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
[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]
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).
- 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.
|x2||Momentary Toggle Switch||FH03D|
|x1||ABS Box (Control)||LH22Y|
|x2||Green LED Momentary Push Switch||N08AR|
|x2||Blue LED Momentary Push Switch||N09AR|
|x1||12V DC PSU||N12GN|
|x1||9V Regulator (TS7809CZ)||N37CA|
|x1||ABS Box (Relays)||N59FK|
|x3||2 Core 3A Mains Cable||XR47B|
|x2||4 Core Alarm White||XR89W|
|x1||FOX Board G20 Starter Kit||COMBO-2|
|x2||Synapse RF150 Module||RF150PC6|
|x1||Synapse Evaluation Board||SN171GG-NR|
|x1||Euro to UK plug adapter||Pulsat|
FOX G20 / Synapse – Pinouts
|Synapse Pin||G20 Pin|
|5 (UART 0 RX)||J6.5 (USART 1 TX)|
|6 (UART 0 TX)||J6.4 (USART 1 RX)|
|21 (VCC)||J6.1 (3.3V)|
|24 (GND)||J6.40 (GND)|
The FOX G20 has a 3.3V output that can be used to directly power the Synapse Module.
- Dean Smith – Comfort System
- Steve Jones – HomeVisionPro
- Keith Doxey – HomeVisionPro
- Honey Cottage – TOM10/xAP