Log in

HomEvenT

Intro

«HomEvenT» is a contraction of "home event", plus funky capitalization.

The download site is my gitweb page; if you want to hack on it (you should …), use git to download it from here.

There'll be a separate homepage for HomEvenT soon, including a Trac setup. I'm just too busy to do it right now.

Rationale

I wrote HomEvenT because, while playing around with some home automation stuff, I found that none of the free systems out there fit my needs particularly well, plus they are not talking to each other.

In my home, I really need a heterogenous infrastructure: some switches need to be wireless, in others existing wired switches need to survive; some devices can only be controlled by infrared, some are in places where nothing except stringing some wire would work.

Devices

The components I'm mostly concerned with are:

This is a German wireless system operating in the 868-MHz range. It's not at all secure and generally doesn't use two-way handshakes. Wall switches cost €15, a heating controller is €40, so it's not too bad.

There's a FS20 controller for USB, which I'm currently using. Alternately, you can buy a sender and a receiver, and connect them to your computer directly. Somehow. I plan to use an USB sound interface for that, because I want to control the heating system directly, and the commercial controller doesn't let you do that.

That controller is supported by a large and well-maintained server written in Perl. The main problem I have with it is that I do not like Perl :-/ the other is that it's 100% synchronous code, which does not integrate at all well with the 1wire bus.

You can download a preliminary wiring diagram; everything else is in the git archive.

The microcontroller wants TTL-level serial signals. These days, you get those most easily from an FTDI usb-to-serial converter. Hobbyists who don't want to solder SMD parts, much less SSOP28 chips, might want to google for "usb ttl-232" cables. Don't pay more than $20 for one.

This is a two-wire bus system -- one of these wires is Ground, so apparently it doesn't count. ☺ In practice, you do need a separate power supply. Personally, I use a cheap shielded four-wire cable (LIYCY).

The bus can be connected rather haphazardly if your wires are not that long, or you can use special branch controllers if you need to be more careful. It works admirably well in my house.

The system is not that fast. In practice, you can poll a simple on/off sensor 250 times a second, so the limit with cheap sensors is 40 switches on a bus — 100, if you get somewhat-more-expensive "event counter" chips instead of dumb sensors. You can also connect a variety of sensors and A/D converters to that bus, but not at the same time because doing so will block the bus for up to a second. :-/

On the plus side: the peripherals, including voltage and (calibrated!) temperature sensors, are really cheap, and a little bit of electronics knowledge goes a long way. (Who needs "when's sunrise" code, when you can add a real daylight sensor to your system for less than €5?) There are also inexpensive LCD panels for remote status displays which don't warrant their own control computer.

Linux support for 1-wire comes either as an incomplete kernel module, or a user-space daemon (<http://owfs.sourceforge.net>) with support for networking and multiple scripting languages. I'm using the latter.

I use infrared to control the window blinds. Good motors cost around €110 wholesale (or €210 retail ☹).

LIRC is a reasonably integral part of most modern Linux distributions, so the idea to use it as a simple way to control a couple of Linux programs ("if I turn off the room lights in my living room at night, please pause Rhythmbox and/or Totem, turn off power to the stereo, and let the computer hibernate") has a lot of appeal... and if the lights are not controlled centrally, see above for the cheap light sensor.

Other systems and projects

Really large. Not my kettle of fish: writing my own system is bound to be quicker than figuring out how to hook 1-wire sensors into this beast of hundreds of C++ classes.

Looks interesting, but frankly I hate Perl. Writing a home automation configuration in Perl is not what I want to do.

Focuses on FS20. Might be OK as a front-end. Again, too much Perl.

This protocol tries to be both high-level enough to serve as a generic home control infrastructure and low-level enough to be understandable in dumb devices. My take is that a high-level protocol needs to be more structured (dare I say XML?) and low-level devices are better handled by an adapter — the protocol is too verbose for slow interfaces.

The available software is somewhat Windows-centric. The Python module for it (100% written in C, one wonders why) is one of the most ugly pieces of code I've ever seen.

Writing a front-end adapter might work, and there are some good ideas in the data structures it models.