Expanding Home Automation

I’ve recently taken steps to expand the range of home automation devices supported by the WebCell web pages. The first new device is the RainBee16 irrigation controller from Smartenit. This is a 16-zone controller commanded wirelessly over ZigBee. At the head end, Smartenit’s ZBPLM (RJ-45 serial version) connects to the WebCell to provide the ZigBee interface. The ZBPLM also provides INSTEON control, so only one interface device is needed for both ZigBee and INSTEON.

I just installed this system, replacing a traditional irrigation controller. It was a real pleasure to be able to walk around the yard, iPhone in hand selecting an irrigation zone to check out. Even out of Wi-Fi range, the iPhone connected via cellular data and kept me in control. (I had to set up remote access with user name and password, as mentioned in my last post, for this to work.)

To get this going there was a fair amount of restructuring of the underlying web services used to communicate between the browser (on the iPhone or whatever) and the WebCell. Now that this is independent of control system, I hope to add more types of devices.

These new abilities have not yet been rolled out as update for WebCell. A little more testing and tweaking is needed.

Update to Self-Sufficiency

As presented on my company web site, the WebCell product line is sold as a programmable module that allows you to add a web interface to some existing project. Much is said about the CellScript Simulator for developing your own interface, while the included home automation interface is mentioned little more than in passing.

Since I myself use this device for home automation, I’ve decided to start shifting the emphasis in that direction. Toward that end, I’ve issued a major update to the WebCell firmware and home automation web pages. Once installed, this update allows the WebCell to be fully managed without the CellScript Simulator. This mainly means that the WebCell is now capable of checking for and installing updates for it’s own firmware and for the web pages. (If you already had a WebCell, installing this update would require the CellScript Simulator.) The bottom line is that from now on, an average end-user of the home automation pages will have no reason to ever use or even install the CellScript Simulator.

Another important feature of this update is that it now supports password-protected remote access. It allows you to create users that can access the WebCell from anywhere on the Internet. It also handles the nitty-gritty steps of opening a connection through your router to the Internet, using Universal Plug and Play (UPnP).

Finally, some of the home automation web pages have been spruced up. Managing and switching between multiple schedules has been greatly simplified. But the major overhaul I’d hoped for has not happened. My last post, over a year ago, talked about having a contractor lined up. That contractor was unable to deliver much, and the next one accomplished even less, so a year has been wasted on that front.

On Sale

Today the Paterson Technology web site was updated to take orders for the WebCell and Cell Development Kit. I’ve spent most of my time on the production process, from ordering parts to developing production programming software. (The actual assembly is handled by a nearby factory, Printed Circuits Assembly.) We now have both products in stock.

There has been some progress on the documentation, but there is still a long way to go. This will be a continuing emphasis for me.

The standard web pages for the WebCell are still as rough as ever. But I now have a contractor lined up to give them a beautiful new design.

The Unveiling

Today I rolled out a completely new Paterson Technology web site featuring the WebCell as a product “coming soon”. The WebCell documentation is skeletal at best and the pre-built web pages provided with it are pretty rough, so I don’t know when it will actually go on sale. But I felt I needed to get the obsolete products removed from the site and start talking about what’s coming up.

A Change of Schedule

Wow, it’s been a long time since my last update. I have continued to work on developing the WebCell into a product. I’ve used a few contractors from Elance.com to help with specific things, like make icons for the CellScript Simulator. But I’ve spent the most time on a total rewrite of the web pages for home automation.

The home automation web pages are no longer generated by running CellScript code on the WebCell. They create their content themselves with JavaScript by using a web service written in CellScript on the WebCell as the source of data. The web service provides an interface to the WebCell scheduler, which tracks things like thermostat settings and irrigation times.

With this rewrite I also recently completed a web page that for the first time provides access to a feature that the scheduler has had from the beginning – the ability to schedule a change of schedule. Here’s how I put it to use:

I have thermostat schedules called “Home” and “Away”. The Home schedule changes the temperature setting each morning and evening; the Away schedule is basically set to turn the system off, with the heat set to 55° and the cooling set to 85°. I was leaving town for a week, but my son-in-law was staying at my house for an additional night, so I set the Away schedule to start at 8AM the next day. I also set the Home schedule to start in the morning on the day I get back. So now I get to save energy when nobody is in the house, but it will be a comfortable temperature when I return.

Is It a Product?

I recently made a revision to to the Development Kit PCB, and I’ve been testing out the revised prototypes. Everything is looking good so far. I didn’t need the circuit changes for my own use -– at worst, I could cut-and-jumper any of the PC boards I would want. This is the latest in a string of actions that only make sense if I turn the WebCell into a product.

Earlier in the summer I spent a fair amount of time creating simple web pages to demonstrate the I/O capabilities of the WebCell. Then I started writing a manual (a scary big project!). None of these things are stuff I would need to do just to keep using it around the house, but I could chalk it up to keeping myself occupied.

That changed when I decided to spend money on product development. Paying to have a new PCB fabricated and assembled is one example. I also upgraded my version of Help & Manual to make writing the documentation easier.

Yes, I would like to make the WebCell into a product if I can tackle all the hurdles. At this point I don’t know that I can, because what needs to be done isn’t what I’m good at. Writing documentation. Creating more web pages. Making the web pages I have look professional. Maybe I will find a contractor to help out (spending money again!).

It’s About Time

I happened to check the time on the WebCell the other day and noticed it was running about 4 minutes fast. Currently the WebCell clock only sets itself (using a network time server) when it powers on, so that error would have accumulated over the few months since the last winter power outage. I guess it’s time to change that.

Timekeeping on the WebCell originates with a 25 MHz crystal on the Ethernet chip. The Ethernet chip divides it by 4 to 6.25 MHz before sending it over to the AVR microcontroller.  The AVR multiplies it by 5 to 31.25 MHz, very close to its max clock speed of 32 MHz. A counter in the AVR divides this by 62,500 resulting in 500 Hz, which is then used for all internal timekeeping.

The crystal is supposed to be accurate to 50 parts per million, which can also viewed as one part per 20,000. Since there are 60 * 60 * 24 = 86,400 seconds per day, the crystal could have a max error of 86,400 / 20,000 = 4.32 seconds per day. Even resetting the time every day, that’s a little more error than I’d like to see.

The number 2^16 = 65536 is a bit special in programming, and I chose it as the interval in seconds between resetting the clock. This works out to about 18 hours. Not only that, but if the clock is off by one second or more when it gets reset, the counter that puts out the 500 Hz gets its divisor adjusted by one tick. So if the clock was running fast, the counter will be adjusted to divide by 62,501. If the clock continues to show an error at subsequent resets, the divisor will continue to be adjusted, one tick at a time. Given the accuracy of the crystal, this adjustment shouldn’t get larger than 3 or 4 ticks off the nominal 62,500, and I’ve set a limit of 20. This adjustment is maintained in the (non-volatile) EEPROM so it won’t be lost on power failure.

With that done, I decided to tackle another time issue that’s been bugging me. When I copy new web pages to the WebCell, the date/time stamp on the file is not copied with it. Instead, the new files are stamped with the current time. This can get pretty confusing when you look back and have to realize that a file time stamp on the WebCell that is after the file time stamp on the PC probably means they’re the same file.

Fixing this required hitting work items at several different levels. First, my implementation of the FAT file system did not yet support setting a file time stamp to an arbitrary date/time. Next, because these files are transferred using FTP, I had to implement the FTP extension MFMT, which sets the time stamp on a file. Finally, I had to have the FTP client in the CellScript simulator use that FTP extension when it copied files.

Fixing these time issues resolved all my immediate concerns for the WebCell itself, giving me some sense of completion.