Tag Archives: HVAC

Standard

Posted by

Posted on

October 12, 2012

Posted under

Digital Lifestyle, Home Automation

What have I been up to? (“Home Automation” edition)

Apologies for the dearth of updates.  The silent masses have been wailing my name incessantly as a result.  I hear you, your screams are defeaning.

(WTF?)

Things have been… different… this year.  That’s about as much as I can say at the moment.  The lack of a stable “all systems OK” comfort zone has basically meant that I’m in maintenance mode more than anything else.  Hence – little in the way of blog updates and other reckless indulgences 🙂

Anyhoo, on to the subject of this particular post.  And this will likely be quick.

You may recall that, to-date, the home automation system consists primarily of surveillance, hvac, and music.  Much hasn’t changed in that respect, but I have been able to make some changes that have increased the reliability, efficiency and usefulness of the system.

Surveillance first.  The most notable change here has been the inclusion of HTML5-compatible transcoded video.  For some time I’ve relied on Flash to allow for remote viewing of archived surveillance video – but having upgraded my phone to Jelly Bean and settled on Chrome as my browser of choice, Flash is no longer an option on that particular device.  To that end, the backend transcodes video into both Flash and x264 formats.  The format available to you is in the browser is determined automagically.

Other small changes have been the regular code cleaning that occurs when you realize that the way you did something a year ago makes absolutely no sense and – there – this makes much more sense.  For now.

The next notable change/improvement actually touches on HVAC as well, so it’s a good segue.  You may recall (but probably don’t) that the automation system is occupant-aware.  When we’re home, certain things happen – like telling the thermostat to target a comfortable temperature, or telling the surviellance system not to pepper me with event notifications.  Previously, occupant detection relied on Bluetooth and its rather short range.  And while I had dreams of hacking unsightly 2.4Ghz antennas onto cheap USB Bluetooth adapters, I woke up recently and decided to use WiFi for the same purpose – which also makes sense since our phones are connected to WiFi whenever we’re home.  Well, Shelly’s Nokia wasn’t always connected, by her loaner phone (my Desire Z) is as is my Galaxy S III.  It was just a matter of course before – no changes in usage or increased battery consumption.

This has simplified matters greatly, in addition to greatly increasing the reliability of the detection code.  The method is actually straightforward – check the wireless access point’s association table to see if particular MAC addresses are connected.  C’est tout.

Also within the spherical roundness of occupant-detection (???) is the news that the system can now get updates from the alarm system.  This is very useful, as it leads to very dependable home/away information that is actually more reliable (in some cases) than the wireless detection method.  The automation system is also configured to simulate motion/audio events on all cameras if the alarm notifies it of a perimeter breach.

Now over to HVAC.

Again – more code cleaning.  I spent a little bit of time thinking I could simplify the “Smart Logic” – the stuff that determines if the system should be off or on and what mode and when to run the fan and blah blah blah – but that turned out to be more painful than just leaving it the way it was so left it I did.  However, the system now has the ability to pre-condition the house if the next program calls for it.  This is one end of a multi-month effort that involved the automated collection of efficiency information.  The system keeps track of how long it takes to heat/cool the house – and currently maintains these statistics seperately for various absolute inside temperatures as well as inside/outside temperature differences – and if the next program calls for more heating or cooling, the system will start doing just that so that we hit the desired temperature just as the next program becomes active.

Admittedly this is not a novel concept.  Some thermostats have been doing this for years.  Something they can’t do is take the efficiency data and determine when to start pre-conditioning the house once it has been determined that occupants are on the way home.  And in the name of openness – my system can’t do this either.  But presently that has more to do with niggling concerns rather than a dearth of information or ability.  Any claims to the contrary would be blasphemy – you’ve been warned.

???

Anyhoo, the reality is that the current pre-conditioning only happens once a day – and perhaps twice a day in the cooling season.  Mostly this is due do the fact that I’ve “flattened” my thermostat’s programs, so that we basically have an overnight setpoint and a not-overnight setpoint (like I talked about here).  I’ve been able to do this because:

  1. the HVAC is much more efficient now than it was before (since we’ve moved)
  2. occupant detection can lower/raise the setpoint appropriately
  3. occupant prediction can target the “home” setpoint before we get home

We tend to keep a “cool” house when we’re asleep, but it absolutely sucks to wake up in the morning to cold floors and cold everything-else-too.  Otherwise, there’s really no need to program the thermostat when the pieces are in place to make more effective decisions automatically.

So ya, that’s HVAC.  Last (and perhaps least?), Music.

Admittedly there hasn’t been much development there.  Not to say that I/we don’t use the system – in fact I used it this past Thanksgiving when we entertained family.  I just haven’t had occassion to spend oodles of time on it.  As it is now, it Just Works(tm).

What I have done, though, is to bring some HTML5 usefulness to the streaming aspect of the system.  As with video in the surviellance system, there has been a browser-embedded solution for some time to stream music via a Flash player.  Got the job done, but again – Flash’s days seem numbered and are basically done and done in the mobile world.

To that end I added HTML5 Audio, and it gets regular use when I’m at work.  Not so much in the car (also known as “not at all in the car”) but that’s because Chrome (and perhaps others) will not allow for background HTML5 audio.  If the screen turns off or the browser is pushed to the background: sayonara streaming audio.  So I still rely on a bonafied SHOUTcast client for streaming in the car, and truthfully I’d love to be able to run the browser-only solution as it requires much less in the way of security concessions.

Aaaaaaand….

….that’s it!

Standard

Posted by

Posted on

February 1, 2012

Posted under

Digital Lifestyle, Home Automation

Server upgrade? [update: 2012-02-17]

Ah, the life of a consummate hardware tinkerer.

Blog devotees will know that my “Home” server is the guy whose job is to run the house – in-so-much as the house can be run by a computer, that is.  More commonly noted in these journals as “Home Automation”, the Home server is primarily responsible for surveillance, HVAC, Whole Home Audio, TV show transcoding, and a host of other support services.

Said server has had a long history of service, although the only original parts are probably the case, power supply, and some hard drives(!).  And after just over 3 years with its current hardware configuration, it would seem that a significant shift is about to occur.

So significant, in fact, that I’ve had to come up with a new “P”-prefixed name for said server.  Yes, *all* of my computers are named with a “P” as the first character…

Anyhoo, this started about a week ago when I noticed some “previous system shutdown was unexpected” messages in the event log.  And some quick investigating led me to conclude that hardware was – again – the cause of the problem.

I was left with three choices:

  1. Retire the Home server and move all functionality to the remaining (“Internet”) server.
  2. Troubleshoot the problem and replace the failing component.
  3. Start from scratch with a new server

My “best practices” principles ruled out option #1.  And with time at a premium these days – and given that the Home server is based on technology that’s over a decade old – I decided to take the $$$ plunge and build a new system utilizing modern(ish) technologies.  Some things I’ve wanted for some time – like RAID1 drive redundancy – and other things I’ve had no experience with and wanted to have at least some passing familiarity (like SATA… yes, *all* of my drives are PATA!!!)

I also decided that I wanted to go with an Intel motherboard and processor solution.  In all of my professional and personal years dealing with computer hardware, I can’t recall one time that an Intel product has failed (especially motherboards).  I may be unique in this experience, but I decided to pay the extra money and go Genuine Intel.

Unfortunately I may have been too presumptuous during my decision-making process, as I opted for any old Intel board that had the hardware features I wanted (among them, 3 PCI slots) and didn’t spend too much time worrying about the “***DESKTOP***” branding that graced the packaging and product designation.  So it was that I came home, spent an untold amount of time putting the hardware together, and found myself unable to install my server software due to driver issues – all of which were arbitrary on Intel’s part, wanting their DESKTOP boards to have no business running SERVER software.

So it took a few nights and early mornings to finally get Windows Server 2003 installed and recognizing the DZ68DB board’s many features.  Thanks to Google and these pages for the invaluable assistance.

That was the first hurdle, and I knew that the software setup would be a multi-day affair.  Unfortunately I’ve run into another (temporary) roadblock, which is that the act of promoting this Windows 2003 Server to a Domain Controller has been foiled by Exchange 2000-related issues in my Windows 2000 AD schema.  Argh.  And while I value the learning experience, at this point I just want to get to the point where I can start moving services to this new “Home” server from the old “Home” server.  I’m really looking forward to the significant increase in speed that this server should bring, particularly with respect to show transcoding and database operations.

So I’ll update this post when I have more to report.

[update 2012-02-17]

So I’ve surmounted most (all?) of my AD-related issues, and the server is chugging along quite happily.  Girder gave me some issues – particularly in the area of launching processes – but this was resolved by changing the window parameter from “hide” to “show”.  Had to do it for both the open process and kill process (this is more a note to myself for future reference…)  I was also pulling my hair out over mixer issues until it dawned on me that the references to the hardware on the old server were probably causing Girder to get mired in some thick mud.

Anyhow I can say that services are smoking fast; DivX transcoding is limited by the speed of the network transfer from the PVR machine (which is currently the Internet server but will soon become the Home server).  The responsiveness of the whole-home audio interface is likewise much improved, as is the whole set of intranet pages (particularly noticeable when looking at archived HVAC and surveillance data).

I’m still in the process of moving my network-stored movie images from a local disk on the old Home server to a local disk on the new server.  This task’s painfulness is exacerbated by the insistence of the old server to spontaneously reboot whenever I try to initiate such a file transfer over the network – which certainly would seem to mimic the original problem which started this whole process in the first place.  The question still remains as to why this causes a server reboot.

Anyhow, I’m using the external 1TB drive (thanks Mark!) to sneaker-net the files from the old server.  However, we’re talking about something like 40GB of data (or is it 80GB?), which is very slow to transfer using the old server’s USB 1.1 ports…

Other than that, I’ve finally got full data redundancy thanks to Second Copy (thanks Daniel!) and that very same 1TB drive.  NTBackup is backing up the system and data drives on both servers, saving said backups to the external drive; and Second Copy is doing one-way replication to the external drive of all media on a nightly basis.  To Centered Systems – the cheque will soon be in the mail 🙂

Standard

Posted by

Posted on

September 7, 2011

Posted under

Home Automation, Software Development

Comments

1 Comment

OAuth 2.0 and Latitude API [update: it works!]

So my smart thermostat has been doing its homework and keeping itself abreast of new developments.  I’ve been tweaking the automation code and adding bits of logic to accommodate my particular nuances.

You may recall that one of the most important features of my setup is an ability for the system to automatically determine home/away status.  This is based on Bluetooth detection; and while I’ve still to add a large antenna to extend the detection range, I’m also acutely aware that this method of determining home/away status will always be reactionary vs. predictive.

As usual, the Wifey Factor(tm) is playing a critical role here.  A comment was made recently – well, a question actually – as to whether the HVAC system knows when we’re on the way home so that it can start heating/cooling the house automatically.

Admittedly, such a usage of the system leans more on the side of comfort than efficiency.  And I’ve already made a concession to comfort by setting a small(er) offset between home/away temps.  (IIRC, it’s something like 1C in cooling mode and 1.5C in heating mode).  I’ve also approximated a “should be getting home soon” decision process by setting evening programs which differ from the daytime programs; ideally, you’d really only need an overnight program and a not-overnight program, and the occupant detection would determine the home/away offset.

But I digress. In an effort to solve this little problem while also furthering my understanding of web-based technologies (ie, the Cross-Pollination(tm) effect, search the blog 🙂 I decided that the answer may lie in utiliizing the Google Latitude API.

We already use Latitude for tracking purposes, so the privacy concerns have been addressed already.  The premise, then, is simple – my automation system polls Google, gets our locations as reported by Latitude, and then does some calculations to determine if we’re on the way home.

Simple in practice, yes.  More difficult in execution, but only marginally.  One of the unknowns here was OAuth, which serves as Google’s (and many web services’) API authentication/authorization method.  I’d heard about OAuth, but never had a need to look into it – either for work or personal means.

And that’s a shame, really. Anyhoo, OAuth is done and done and now I’ve got my automation system pinging Latitude, calculating distances, and producing raw-ish data that I’ll later analyze to determine the most suitable “peeps are on the way home” algorithm.  I may even use it to supplement the Bluetooth detection method, which is sometimes hit-or-miss in lieu of that big antenna…

One of the more challenging aspects has been deciding what to do with outlier data points.  Latitude has this habit of sending you off 100’s of kilometers in some random direction for no apparent reason; we certainly don’t want the automation system going bonkers by thinking we’re flying in at Mach 5 from some random city in the US. And while I’m sure that there are many statistical methods that one can use to clean a data-set, such an endeavour would be secondary to the purpose of this project.

So to that end I’m currently using a “line of best-fit” (aka the Least Square Method) to fit a straight line to my Latitude data points.  It doesn’t completely solve the outlier problem, but it lessens the impact somewhat.  Anyhow I’ll pore over the resultant distance calcs over the next few days and…

… I’ll post back when I’ve got useful performance data.

[update 2011/09/15] Seems to be working well!  Check out the thermostat post for info.

Standard

Posted by

Posted on

April 26, 2011

Posted under

Home Automation

Comments

6 Comments

Adding a smart thermostat to the mix [update 2011/12/29: versatile]

So you may or may not know that I’ve got this Whole Home Audio system and networked surveillance system; both are combinations of off-the-shelf hardware and custom software.  Together, they’ve been carrying the torch for my fledgling home automation aspirations.

A full-fledged home automation system can do all sorts of cool things – control lights, sprinklers, link to the alarm system, interface with voicemail, play mood music, etc.  In general, you’re talking Entertainment/Convenience, Security, and Comfort.

I’ve finally added Comfort to the mix, by way of a WiFi-enabled thermostat.

I’ve had my eye on this category for some time, having read about X-10 and ZigBee and any number of other communication protocols.  And while I may agree that a large abode can benefit greatly from complex automation, I always considered a smart thermostat to be the first order of business.

First, some clarification.  I’ve been running programmable thermostats for years, as I’m sure most of you have.  There are real energy savings to be found by setting your furnace to drop a few degrees at night or during the day when you’re not at home.  And if you work a 9-5, then the thermostat’s schedule-based program is likely sufficient.

I do work a 9-5, but my weekend schedule is often up in the air, and there’s no real guarantee that my life will adhere to my thermostat’s schedule.  If you happen to forget to hit the “away” button when you run to the mall, then the real answer is that your home is being heated unnecessarily until you get back.  And if you err on the side of being miserly, then you may find yourself a little chilly (or hot) on the weekend because you forgot to set a comfortable temperature.

My forays into occupant awareness, then, were necessary prerequisites to a smart thermostat.  The next prerequisite was cost, and Radio Thermostat Company of America has ticked that box with their US$99 CT-30 thermostat.

The thermostat connects to your home wifi network, just as your laptop would, and once connected it talks “to the cloud” so that you can access your thermostat using a web browser or smartphone app.  This is great – but the real usefulness for me lies in the Application Programming Interface, which means that my custom-built home-automation system can talk to the thermostat.

As such, the thermostat’s typical 7-day/4-program schedule is set to maintain acceptable at-home temperatures, while the home-automation system – being occupant aware – can override the thermostat and set a lower (or higher) temperature when nobody is home.

So can I expect to save $99 on my gas/hydro bill with this solution vs. a typical programmable thermostat?  Maybe.  Does this solution check all of the right boxes as a hobby project with real-world usefulness?  Most definitely 🙂

I’ve only recently finished the coding that controls the thermostat, so I’ll keep an eye on it over the next few days to see how it performs.  After that I’ll add some logging (to see when the hvac system is actually on and for how long) as well as the requisite intranet webpages for feedback/control.

[update 2011/04/29] While I haven’t had any real problems with the thermostat and the home-automation integration, I decided rather quickly that it needed to be even smarter.

I’ve moved from a fixed “away” temperature to an offset method, where the system sets the “away” temp as an offset of the program temp.  This is to handle the situation where the house is uncomfortably cold/hot when you arrive.  Instead, it will now be about 2C off of the program temp, which will still result in acceptable savings.

Right now I’m struggling with a complex matrix of situations involving overriding the automation system.  I think I’ve got something but I’ve run out of time right now, so more later.

[update 2011/06/01] So this setup has been working pretty well.  But I decided that I wanted more variables.

They say that no man is an island.  Well, so it is that no HVAC system is an island either.  In this case, the surroundings – external temperature – play into the efficiency and performance of the HVAC system.

So I added some code to make some decisions based on external temperature (which may include windchill or humidex).  As it stands now, the automation system will actually set the HVAC system to an “off” state if it determines that external temperatures don’t warrant consuming resources to heat/cool the house.  The thinking is that you can open a window and let nature do the work instead.  This will occur even if temperatures are higher/lower than the desired setpoint, which would normally result in the HVAC running.

The method is extensible, so if I need to get really exotic then I can look at cloud conditions and windspeed as factors which can influence the decision.

[update 2011/06/13] Here’s a screenshot of the work-in-progress webpage that provides current state and historical information about the thermostat.  The graph also represents my first foray into the HTML5 canvas tag.

The graph actually shows quite a bit of information.  The bars show interior temperature, the line shows exterior temperature, and the dots show the desired interior temperature (the “setpoint”).  Both the setpoint and the interior temperature can be any of three colours each: grey, blue, or red, signifying the hvac mode and state (off, cool, or heat).  So the red bars in the graph at the left show that the hvac was heating the house at that point in time, while the red dots indicate that the thermostat was in heat mode.

Notice that the setpoint eventually goes grey; this is related to the upward trend in the exterior temperature, represented by the solid line.  That’s putting the “smart” in smart thermostat 🙂

Also worth noting here is that I’m using JSON for the first time to pass this information from the backend to the webpage.  Nifty stuff.  I fully expect that I’ll be porting my knowledge to projects at the 9-5; I’m particular amped about using <canvas> to bring some improved visuals to our main web-based app.

[update 2011/09/15] Occupant prediction is active and working well.  So far the crystal ball can’t see too far out in the future, by virtue of the fact that normal commutes are too short for any meaningful trending data to become obvious.  For my commute the system seems to be averaging 15-20 minutes of foresight, while Shelly’s commute garnered an impressive 40+ minutes today.  Not bad.

With this level of performance I’ll probably end up increasing the “away” heating offset to something like 2.5-3C from its current 2C.  The cooling offset is a little trickier, as the hvac seems to have a harder time lowering the temps in the house.

[update 2011/10/05] So the system proved its merit the other day, doing exactly what I intended it to do re: occupant prediction.  The conditions were such that this particular instance represented the first time the system exhibited practical usefulness due to the prediction code.

See the graph below:

Occupant prediction in action

A: at 5:00PM, the thermostat switched to a new program.  This program calls for a temperature of 22C.  Since nobody was home, the automation system called for a temperature of (22C – 2.5C = ) 19.5C.  The HVAC was not turned on as the measured temp was higher than 19.5C, however the system was “armed” (set to heat mode) as the measured temp was within a predetermined range of the desired temp.

B: at roughly 5:35PM the system determined that occupants were on their way home.  Looking at the logs I believe it estimated an arrival time of 5:55PM, but that’s not important; what’s important is that, at 5:35PM, the automation system told the thermostat to remove the offset so that the thermostat would now target the program temperature of 22C.  Notice that the thermostat turned on the HVAC at this point, since the measured temperature was below 22C.  Also note that the bars representing the measured temp are a light red, indicating that the system was heating while nobody was home.

C: at roughly 6:05PM the automation system detected at least one occupant.  The bar for measured temp appears as a darker red to reflect this new occupant state, and to indicate that the HVAC was still heating the house. At the next polling cycle (5 minutes later) the HVAC had reached the desired target of 22C and therefore switched off.

The result? The house was cozy warm when I got home, due solely to the fact that the automation system knew I was on the way home.  Good news!

[update 2011/10/15] I just came across this post which details another project which talks about HVACs and occupancy prediction – albeit a project operating under the umbrella of a well-known corporate entity.  The project calls itself PreHeat, and while both approaches (mine and theirs) depend on occupant detection, they differ in that the PreHeat method uses historical occupancy data to predict future trends – whereas mine uses actual occupant-location data.  One could argue that, on the face of it, my approach would offer more accurate predictions.  However, PreHeat doesn’t rely on an external service API and is able to derive all of its data simply on the basis of actual bodies being home.

Regardless, I thought it cool that there are other people working on solving the same “problems” as I am 🙂

[update 2011/12/29] Evolution of the code continues.  The latest addition is a post-heat fan circulation feature, which runs the fan for a few minutes after a heat-cycle in order to help equalize temperatures throughout the house.  This is a feature that some thermostats come with out-of-the-box, and it’s quite useful.  My thermostat doesn’t have this feature built-in, but the home automation system is capable enough that I can add these sorts of features myself.  Along the same lines I had also previously added a window condensation-reduction mode, which runs the fan periodically for 30 minutes or so overnight if external temperatures are low enough and a heat cycle hasn’t occurred in some time.  And when the system is in cooling mode, the automation system will start running the fan if internal temperatures are rising and approaching the desired setpoint – the idea being to mix the warmer air on the upper floors with the cooler air in the basement.

It’s just nice to have that amount of control and versatility.