Friday, May 23, 2014

So, what does it look like when an A/C breaks? The graphs below tell the story.  I'm hoping I can use this data to write a script to detect this condition. I'll add more detail once I know what the actual breakage is.  Maybe it just iced up?  Those spikes are a little odd on the 1hr graph.

This is the AC trying to run, me giving up on it, and turning it to fan only.




Looks like it broke around midnight:
Now you can see below my vacation, returning, AC fires up as normal, and then clunk?
You can see the last working run, and then it starts to diverge

Here you can see vacation mode, and then the failure.




Monday, May 12, 2014

Why the Venstar T5900 is the answer to DIY HA thermostat needs

So, I recently picked up a Venstar T5900.  I've been looking for a good "high-end" thermostat for awhile now, that would work with DIY Home Automation.  I think the Venstar is about the only answer out there.

There is of course the 3M one from RadioThemostat, and yes, thats a pretty good choice.  It has an open API, and a few advanced features.  But it's not very pretty.  Old style LCD.  Meh.

Nest is cute, but they will probably never make an API.  Screw them.

The Venstar is color LCD, touch screen, tons of features, scheduling, has the web-connect interface stuff, easy to install, and best of all, a documented API.  They even did a pretty good job of documenting it.  Now admittedly, the API won't let you fiddle every single bit of the t-stat, but it's good enough for most HA uses.  It lets you fiddle the set-temps, and turn the unit on/off/auto/etc as you please.  It also lets you query the onboard sensors.

So what are the quirks?

1) The SSDP discovery routine is wonky.  It doesn't work to the spec.  Normally you send an SSDP query on the multicast, and get a direct response.  The venstar replies back to the multicast.  This can be worked around by just listening for the NOTIFY messages instead.

2) If you want to shut the unit OFF, you have to turn off the schedule first.  No big deal really.

3) If you send it too many queries too quickly it ignores them.  Just slow down your sends.

Which should you pick?

The T5800 is nice, but the T5900 is the one you should buy.  $10 more, and has a humidity sensor.  Even if you don't have a humidity system to control, for $10 you get one more sensor to read.  Yay data.  You definitely want the skyport wifi bit, without that, no API access for you.  Total cost shipped was about $225.  Took about 30 minutes to install, and 20 minutes to program locally.

The API is a simple JSOM interface for grabbing data, and a simple HTTP POST interface for changing settings.  No big deal to write code for at all. They even supply sample code in a few languages.


Tuesday, April 22, 2014

I've been playing with the API for the Irrigation Caddy lately, and I've discovered a few things not listed on the API page.

1) If you broadcast "Discovery: Who is out there?" to port 30303 UDP, all the irrigation caddies on the network will respond with hostname and macaddr.

2) Sending a stop=active will only stop the current zone, not the program.  So far the only way I've found to stop a program is to send a full stop then a full start.

3) The json requests are standard GET's, but all the zone fiddling, start/stop stuff is POST.

Just writing them down here for now so others can find them in the future.

Tuesday, July 9, 2013

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.

Saturday, June 29, 2013

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.