gnhast 0.2.3 released.

New release of gnhast-0.2.3 today.  Changelog posted below.   Available at:
http://sourceforge.net/projects/gnhast/files/gnhast-0.2.3.tar.gz/download

0.2.3 - Release 7/9/13
    Added Collectors:
        wupwscoll
        wmr918coll
    Added Handlers:
        nightlight
        switchon
        switchoff
    New features:
        Make gnhastd aware of the unit that data is stored in.  Now a collector tells
gnhast what scale it is feeding data in (ex, Celcius). When requesting data, you can
request it in a different scale, and the server will auto-caclulate.
        Add a wupwscoll collector.  This collector will publish weather data to
weather underground, and pwsweather.com.
        Add wmr918coll collector.  Collects data from oregon scientific weather stations.
Works on wx200's wmr918's, and can also connect to a running wx200d instance and
gather data from that.
        Insteon i2cs code now tested and working fully.
        Added basic handlers for a nightlight routine, and switching devices on and off.
        Add a modify command to gnhastd, so you can edit the config file on the fly by
sending it simple commands.  This allows you to add a handler or tweak names/watermarks
on a running instance.
        Port to Linux.

Insteon I2CS notes.

Turns out, the i2cs protocol is slightly more annoying than I was led to believe.  At first glance of the available docs out there, you would think that the only difference is everything gets sent with an extended command.  That is where you would be wrong. It turns out *some* commands are extended, and some are still std.

I recently purchased a pair of the outdoor modules, which are the new i2cs protocol.  Doing the ALDB stuff, and the initial setup was easy, just send all extended commands.  Send it fast on/off, on/off, (as extended) everything works great.  Send it 0x19, for status, and it just ignores it.  Turns out, the status command has to be sent as std, or it ignores it completely.

Sigh.

Power usage

Yesterday, we had a bit of a scorcher.  117F.  The day before was 110, so a difference of 7 degrees.  Look at the difference in power usage.  It's absolutely nuts.

7 degrees translated into 2kw of power.  That's crazy.  Today will be even hotter, I'm sure it will be even nuttier.

Helpful Links

While writing all this automation code, I found tons of useful information out there.  I'll try to keep this post updated with some of the things I found that we especially useful.

Insteon Command Reference
AD2USB Forums (vista alarm panel interface)
One Wire FS
LibConfuse Documentation
LibEvent Documentation
BrulTech
Bitfield decoder
http://marc.merlins.org/perso/linuxha/
http://homewireless.org/wp/2010/03/insteon-commands/
http://irrigationcaddy.com/blog/
WMR968 Serial Protocol
http://hobby-boards.com/store/

Playing with sensors:

I've been goofing around lately with some one-wire sensors.  I have RJ45 jacks all over the house, and I've been wiring them into the one-wire hub, and getting temperature data on all the rooms.  The problem is, I purchased a bag of 25 raw DS18B20 chips, so I've been soldering the things onto little stub wires, and then crimping them onto rj45's and it takes forever.

Then I had the idea of just crimping the chip right into the RJ45.  It actually fits perfectly.  But I was worried that the data would be messed up, because it would basically be measuring the temperature of the wall, not the room.

So I crimped one stub, one 4" wire, and put them right next to eachother for awhile, and recorded the results:

 

The long wire is much more sensitive.  The way it jumps up and down, is actually the air conditioner going off repeatedly.  The stub seems to smooth the results out more.  It does seem however, that the stub is consistently about .5 degrees higher on average, so I guess that's the effect of the wall holding heat.  Based on these results, unless I need actual detail, these stubs will be fine, and are much easier to make.

This will eventually be the home of my journey through building a home automation system, from scratch.  I am DIY'ing everything, from the installation of all the hardware, right down to writing the software for it from scratch.

This week I've released the initial beta version of gnhast - Garbled's NetBSD Home Automation Scripting Tools.  Download it here.

About gnhast:

A collection of daemons that work together to build an event-based home automation system. The core set of daemons is written in C, however, any event (such as a light being turned on) can be handled by an external script or program. These programs can be written in any language, and the central daemon handles all the intercommunication. It is designed to be easily extensible for new device types and protocols.

The core system is BSD Licensed (3-clause), however scripts or additional data collectors may be written under any acceptable lic.

While the primary development environment for this is NetBSD, it can be used on other UNIX variants, such as Linux, or other BSD's.

gnhast wiki (in progress)

The initial version has support for one-wire sensors (temp, humidity, lux, lightning strike, general counters), Brultech GEM's, and Insteon v2 switches and dimmers.  Support is planned for NuTech AD2USB devices, and a few other things, as I buy and install them in my house. The general plan is to co-develop the system as I physically install devices, so more support will be added as my wallet allows.

Tim