Re: [mh] Newbie Question on HVAC

[Gregg L. <gr...@li...>]

Hi Eric,

Quoting Eric Bauer (9/20/06 9:25 PM):

> Could someone please recommend which of the HVAC and/or iButton scripts
> I should be playing with as a newbie to MH and Perl??  Any advice would
> be greatly appreciated.  I have two iButton temp sensors that I can read
> using the Digitemp software, so it's time to move to working w/ MH.  I'd
> like to move in small steps from simply  being able to read the
> sensors(and maybe graph them), to turning a fan on and off based on a
> temp setpoint, and then on to move sophisticated control.

I'm working on 3 pieces that might help you.  I hope to get them to a
sufficient state of initial completion to make available by this
weekend.  They are:

1) OneWire xAP Connector (oxc).  Currently, it only connects to
digitemp.  It runs separate from mh and therefore can poll sensors w/o
impact to mh performance at user definable rates and report at less
frequent rates and w/ optional delta change.  In the future, it will be
possible to schedule differing rates so that fluctuating sensors or ones
that you want to react to quickly if a change occurs can be sampled more
frequently than others.  All sensor reports are communicated via xAP.
Depending on work that Jim D. is doing w/ owfs, I may decide to
incorporate support for owfs as well.  If owfs is supported, then oxc
will also be able to receive xAP messages to control onewire devices
(e.g., LCDs, etc.)

2) OneWire_xAP.pm - the mh utility library the monitors sensor reports
from oxc and populates Analog_Item objects to reflect the sensor updates.

3) Analog_Item - currently a class embedded in OneWire_xAP.pm (that will
likely be moved if used by other libs/code).  Its purpose is to hold the
current sensor value as well as provided a limited time history.  In
addition, it will provide utility methods for getting derivative data
like rate of change and average rate of change.  It also has a utility
class to map it's sensor data to a Weather hash item.  I'm also working
on a mechanism for "tie-ing" usercode to a user-definable condition.
One example of a possible implementation is:

$house_temp->tie_condition(\&turn_off_heat, "$current > 72");

sub turn_off_heat {
   $heater->set(OFF);
}

Note that the first argument is to some piece of user code and the
second argument is an evaluated condition.  The implication is that
there would be a number of preset "tokens" like "current" that would be
available for use.  I am thinking that something other than the concept
of "current" sensor value is needed to support hysteresis.  As you can
probably tell, I've not yet implemented the tie_condition method not
identified all of the tokens that should be available.  My intention is
to attempt to keep the tokens somewhat device-agnostic (i.e., not
dependent upon the sensor being temp, humidity, barometric pressure,
etc.).  But that may be unrealistic.  If you or others have
requests/recommendations, please forward them to me.


I currently have all of the above working (for the exception of the
tie_condition part) in my production environment.

The following bit of usercode reflects my current usage pattern:

------------- cut ------------

$onewire_xap = new OneWire_xAP;

$temp_inside = new AnalogSensor_Item('familyrm-t', 'temp');
$humid_inside = new AnalogSensor_Item('familyrm-h', 'humid');

# tell the xap conduit which sensors to update
$onewire_xap->add($temp_inside);
$onewire_xap->add($humid_inside);

# noloop=start

# map sensors to weather hash
$temp_inside->map_to_weather('TempIndoor');
$humid_inside->map_to_weather('HumidIndoor');

# compensate for miscalibrated temp sensor - partly due to heating
inside case
$temp_inside->apply_offset(-3.5);

# noloop=stop


# and, for those that stare at their consoles continuously:
if (new_minute 1) {
        print "inside temp = " . $temp_inside->measurement . "F\n";
        print "inside humid = " . $humid_inside->measurement . "%\n";
}

-----------------------------

Gregg