OT: Evap cooler algorithms

This is a different problem, but it's an example of an HVAC fallback strategy.

I have a gas furnace that normally has a data bus to the wall thermostat and heat pump. However, for heating only, it also has a fallback mode that can be accessed from a small keypad and LCD in the furnace. The only choice you get is a duty cycle: 10%, 20%, 30%, 40%, 50%. It runs on medium blower and medium gas valve at that duty cycle until you tell it to stop.

I've never tried it, but the directions imply that this mode works even without the wall thermostat or heat pump (outside unit) connected. The intended use case is apparently a building under construction in the winter; once it is enclosed and has gas and electricity, the builders can run the furnace and get warm, even if the final ductwork and thermostat are not yet installed. It also might help if you have a thermostat failure, or a data bus failure - like somebody weed-whacks the outside wire or puts a nail through the inside wire.

If you're in fallback mode but you still have Internets, maybe pulling the METAR for a nearby airport will give you some "close enough" data about the outside temperature and humidity. Unless it's a huge airport, this data only gets updated once an hour.

Matt Roberds

Cool! I could do something like that as well -- *if* the (remote) temperature sensor was "unavailable" (highly unlikely as it is tethered directly to the controller). Even semi-recent history could help

*pick* an open-loop duty cycle! (though the fallback condition I'm trying to address assumes I know *nothing* -- not even time of day!)

Yes. This is the one "node" in the house that is capable of operating independent of the rest of the control system (though it relies on mains power being available -- as the HVAC kit wouldn't run without it!) It has its own little user interface (which isn't very accessible) which could conceivably have been part of a "wall mounted thermostat" (we don't have anything *on* the walls, here)

The heat and (ACbrrr) cooling are a lot easier to relate to in this sense as you are directly affecting the controlled variable. The cooler gets a bit squishier to control as you don't really have any idea what the moisture is/isn't doing to the interior environment without more detailed information (e.g., outside temperature, moisture content of air, wind speed and direction, etc.)

Again, I'm looking at "when I have *nothing* to draw on"... i.e., I can't even get the current time of day nor talk to the database that has the recent records of the HVAC's actions (i.e., repeat what you did yesterday and hope for the best!) or environmental data.

In that way, I'm essentially asking: "What's the best a COTS swamp cooler controller *could* do (given that they undoubtedly do NOT have access to the resources I potentially have available)?"

For example, once you reach 100% duty cycle, it may be better to step

*back* to "low blower speed". I.e., just keep the blower running to ensure positive pressure in the building and prevent hot air blowing in through windows, etc. At the same time, avoiding the deliberate act of trying to moisten/cool that air IN LARGE VOLUMES to replace the air that is already *cooler* (because you've already exceeded 100% duty cycle) inside the building! [i.e., will continuing to operate the blower on HIGH just accelerate the building's tracking of the exterior temperature? if you COULD button up the windows and shut the cooler off, would that *slow* the interior's response to the external conditions? etc.]

(sigh) Questions that are far more interesting/challenging than picking a gain for an amplifier stage! :>

I hope you're doing this explicitly as a state machine. Also it's pretty hard to get good test coverage when you have a lot of infrequently-used paths.

Given that the pipes won't freeze if the swamp cooler quits or the occupants misunderstandmisunderstand it, I'd just have the fallback be the old fashioned 7-position rotary switch.

Cheers

Phil Hobbs

I have developed some delightfully elegant "state machine frameworks" over the past 35 years. They make *most* algorithms a lot easier to code and debug by allowing me to focus on "what do I need to deal with,

*here* and how did I *get* here". They've evolved to the point where I've actually got a little "state machine language" that I can use to concisely encode the FSM itself (tables, transitions, etc.).

In this case, there are several different machines that coexist. Which machine is operative depends on the resources available to the algorithm. E.g., if it can't know local weather conditions, then the machine that takes those into account is useless so it transitions (on "!LOCAL_CONDITIONS") to a machine that doesn't rely on them.

E.g., Matt's duty-cycle algorithm is just a tiny two-state machine that corresponds to "blower on" and "blower off" with transitions between the two states signaled by "elapsed_time_in_this_state". A *common* set of conditions (i.e., checked by each state) allows the machine to transition to a more "full featured" machine when/if additional resources come on-line (e.g., connectivity reestablished with the weather station; temperature sensor operative; etc.).

Solve several *little* problems instead of trying to solve all of them in a big mess of code.

Fallback doesn't have to be *stupid*. E.g., getting the indoor RH up to

90% can be as bad as letting the occupants "be a bit warm". (Our first year here saw us fighting "swollen" doors, mold, etc.)

As I said, the problem is finding the right operating conditions for each of the various machines so they each know how to gracefully deal with the failures they may have to encounter (and loss of signal).

A big red light that says "call for service" isn't a solution -- it's just another "problem"!

Well, you could decouple the problem by using the swamp to control temperature and the A/C to control humidity.

Cheers

Phil Hobbs

Have to deal with folks who don't have AC.

Well, you could detect whether a window was open using the Helmholtz resonance. It's like blowing across the mouth of a beer bottle--the air near the orifice is a mass, and the compressibility of the rest of the air is the spring.

Cheers

Phil Hobbs

I rely on the alarm system to tell me the state of "openings". But, in fallback mode, I can't *get* that information. So, assume "enough" vent is available and run cooler (opt for low blower speed on the ASSUMPTION that external conditions won't be able to counteract this positive pressure if the windows aren't "overly wide open"). Or, assume they are *closed* and don't run cooler.

OTOH, if I have access to temp and indoor RH, I can make some better guesses based on observations.

"Simple" problem with an annoyingly complex set of caveats! This is why COTS controllers just deal with temperature (*at* the controller) and leave the rest to the user to sort out!

"Gee, it feels awfully SOUPY in here!"

"Where's that hot dry air coming from?"

etc.