The 24-Volt Insurgency: Why Desert Packrats Are Mocking Your Peppermint Oil

There is a specific, primal horror to waking up in the middle of an Arizona summer night in a pool of your own sweat, checking the thermostat, and seeing a crisp 89 degrees staring back at you.

It’s even worse when you grab a flashlight, walk out into the hot, dark, pre-dawn desert air to inspect your air conditioner, and find that a furry, four-legged demolition specialist has systematically snipped your 24-volt control line, converting your life-saving air conditioner into a heater.

If this happens once, it’s an annoyance. If it happens three nights in a row, it’s a battlefield between the primal forces of nature and civilization as we know it.

What was going on?

For the last week, my northern AC unit became the epicenter of a tactical showdown between human engineering and rodent persistence. A huge inconvenience to me, but after a few midnight flashlight repairs and some serious crime-scene analysis, I’ve cracked the code on why they do it, why the internet’s favorite DIY remedies are absolute garbage, and most importantly, how to build a defense grid that actually works.

Add to that the safety factor. The default factor in home AC heat pumps is to heat. It seems better to be awakened to the heater running unexpectedly instead of the cooling. The engineers seem to think that uncomfortable heat is better than freezing to death in the winter from a rat breaking the 24-volt circuit. Living in Arizona, I might argue that, but my relatives in the Northeast would object.

The Soy-Plastic Myth vs. The "Perfect Toothpick" Reality

If you spend ten minutes on automotive or HVAC forums, you will run into the classic urban legend: "The government forced manufacturers to change the insulation to soy-based plastics, and now the wires taste like food!"

Let's set the record straight. While it’s true that modern car manufacturers did switch to soy-based bioplastics over the last decade (creating a multi-thousand-dollar buffet under modern truck hoods), it wasn't due to US regulations. It was companies pandering to environmental concerns.

This new insulation will, over time and exposure, decay—unlike petrochemicals that last forever. It’s lighter, easier to form, weighs less, and fills that niche of environmental awareness that sells so well to city dwellers who seldom actually see, much less live in, the environment they talk so much about preserving. The unintended consequence of this corporate virtue signaling? Your expensive vehicle or outdoor equipment has been converted into a gourmet snack.

However, before you go blaming a corporate marketing department for your broken AC unit, there’s a twist: your standard residential air conditioner thermostat wire isn't soy. It's still old-school, petroleum-based Polyvinyl Chloride (PVC). It smells like chemical garbage, not dinner.

So why did the rats keep coming back to my north unit to slice the exact same wire?

During day three of my investigation, I noticed something critical: The rats completely ignored the thick outer cable sheath. They only attacked the thin, individual 18-gauge colored wires after the sheath had been peeled back for the connections. "But why?" one asks.

It turns out it's a matter of biological imperatives. A rodent’s incisors grow continuously—up to five inches a year. If they don't constantly gnaw on things to file them down, their teeth will literally grow through their own jaws. This provides some clues to why, but also some cautions.

The thick outer jacket of an AC cable is too wide and smooth; they can't get a jaw around it. But an individual 18-gauge strand? That is the exact diameter of a small root or a piece of desert scrub. It fits perfectly into the sweet spot of their jaw mechanics. It's not dinner—it's a precision-engineered toothpick. Something to gnaw on to help grind down their teeth, and a low enough voltage not to roast them into a carbon footprint. 

Why Internet Remedies Fail: The Evaporation Trap 

Before we talk about what works, let’s talk about the absolute sales BS cluttering up the internet. In my time fighting the desert wire-eaters, I have systematically tested the "feel-good" remedies. Here is the field report:

• Peppermint Oil: I once sprayed a literal quart of high-concentration peppermint oil around the engine compartment of my truck. The result? I had the best-smelling, mintiest rodent hotel in Arizona. Once the initial vapor shock wears off in a few hours, the rat’s drive to chew completely overrides any objection the rat has to the smell. Trusting that home remedy cost me $2400 at the dealer having wiring harnesses replaced.

• Bitter Sprays: Products designed to stop dogs from chewing work for about 48 hours. In our brutal desert environment, the intense sun, heat, and ambient dust cause the bitter compounds to volatilize and vanish. Also, remember, the rat has to chew enough of it to taste the bitters. Our own experience with canine bitters has mixed results; some dogs react to it, and others ignore it and still chew off our baseboards and chair legs. How well would we expect it to work on a rodent that eats cactus (thorns and all), chews the bark off our fruit trees, gathers dried dog poop and uses it as a front door to its home, and leaves trails of its scat under our BBQ?

• Predator Urine: Buying fox or coyote urine sounds tactical, but rodents are highly adaptable. A desert packrat has no evolutionary memory of a European Red Fox. Even if you use local coyote scent, if the smell just sits there day after day without a physical coyote ever showing up, the rats figure out within 48 hours that it’s a ghost threat. Renewing the dosage only helps the rat to learn that the smell is not left by a predator simply because the threat never materializes. 

The Real Culprit: The Oasis Effect

While inspecting the unit on day four, I finally found the smoking gun. I noticed a distinct, wet patch of condensation pooling right on the base tray of the compressor housing. Look closely at the dust, and you can see the tiny, muddy footprints.

In the middle of a scorching summer, a guaranteed, daily source of fresh, dripping water is worth more than gold. The copper pipe carrying cold refrigerant into the air handler inside the house condensed the limited humidity of our desert air and dripped into that little reservoir at the bottom of the compressor casing. My AC unit wasn't just a hardware store; it was a five-star desert oasis. The rats were stopping by for a cool drink of AC sweat to beat the heat and then deciding to utilize the local 24-volt toothpicks while relaxing by the pool.

Before your environmental instincts kick in and you comment on how bad for the environment rat poison is, I had been three nights without sleep in a sweltering puddle of sweat, listening to complaints about the AC continuing to fail. What exactly would you have done? Cut me some slack here. Plus, this is some of the incredibly expensive rodenticide that only kills once. 

Even worse? Those green poison pellets I threw down were sitting completely untouched right in the puddle. The rats literally marinated their poison while ignoring it to chew on my wiring.

The Counter-Insurgency Playbook

To win a war, you have to change the environment. Here is the two-phase strategy I used to take back the north wall.

Phase 1: The Tactical Retreat to the High Ground (The Free Fix)

The rats were successful because the 24V lines were sitting on a low-level "lounge deck" right at chest height for a sitting rodent.

The service access to the AC compressor

Close up of the wiring area after two

repair attempts. 

I pulled the thin AC control lines completely out of that bottom open shelf. Then I rerouted the multi-conductor line from the house upward and fed it directly into the side knockout of the upper, enclosed high-voltage metal service area.

The 24VAC wires are on the bottom

And the 240VAC wires are on top.

By making all the wire-nut connections inside a sealed metal box, the target wires were protected. The only thing left downstairs near the concrete pad is a smooth, unbroken stretch of factory cable jacket. They showed up the next night, drank their water, and realized the wire playground was locked and went off to some other rat playground. We are currently four nights in with zero outages.

Phase 2: The Permanent Armor (The Parts List)

Once the immediate crisis is averted, it's time to build a maintenance-free fortress. Because we are dealing with a whole desert ecosystem—from tiny mice to heavy-jawed gophers, ground squirrels, and don't forget, rabbits—your best bet is to armor-plate the entire run from the wall to the chassis.

1. Mechanical Armor (Techflex F6 Heavy Wall Braided Sleeving: Instead of tearing your fresh wiring apart to slide a tube over it, use a split braided sleeve. The heavy-wall version has a built-in lateral overlap that snaps shut around the existing wire. A rat's teeth slide right through the slick woven matrix rather than grabbing and cutting it. Plus, the wire sticks them in their mouth, making it unpleasant enough to leave alone. 
   
   

   
   I've used this on my pool for months. 

2. Chemical Deterrence (Genuine Honda Rodent Tape) This stuff is the gold standard for a reason. Honda bakes micro-capsules of pure capsaicin (chili pepper extract) directly into the vinyl substrate. It doesn't wash away or evaporate in the sun like a spray. When a rodent punctures it, the capsules burst directly into their mucous membranes. It's true that the rodent has to actually chew on the tape to get the burst of capsaicin, but that's what rats do, chew.
   
   

   Safety Note: Always wear heavy gloves when handling the spicy tape, and for the love of God, do not rub your eyes, scratch your privates, or pick your nose afterward. You might also warn a repairman, but that's your choice.

End Result

Here's a picture of the AC unit after I finished it up. It has (so far) held up against the wandering rodents seeking cover and water. 

All the points where wires might get exposed are wrapped with rodent tape and  all the wiring is inside the wire sheath. Yes, those are stainless steel zipties; plastic doesn't last long here. I suspect this will hold up for a long time, but I'll keep an eye on it just in case of sun deterioration. 

Final Lessons from the Desert

If you live out in the rural desert, nature is always trying to reclaim your assets. If you park a vehicle outside, leave the hood up. Rats hate open spaces where hawks can see them, and they hate the sun. I've had reasonable luck with flashing lights; get some flashing Christmas tree lights and toss them under your vehicle to chase rodents away. This method does run the risk of the extension cord from the vehicle to the outlet getting chewed up though. For vehicles I use a combination of open hood and flashing lights that has worked well.

If your AC goes down, look for the water source, move your connections into protected areas, and armor the gaps. Let the neighbors deal with the mint sprays and the ghost coyote urine—stick to solid mechanical engineering and really spicy unexpected treats.

Wrapping Up The Water Heater Monitor (and control)

For the present, I'm going to claim that (as the British say) the water heater monitor is, "All done and dusted." There's a few tiny items I'll mention that I may do in the future to make is a little easier for other folk to understand, but it does what I set out to do with it.

It monitors the temperature at the top and bottom of the tank, the power usage of the entire system and controls the power applied to the internal heating element. I save the data on my house data base and can chart anything I want. It has been a cool project that I got to use new things on and implement some software that I haven't dealt with yet.

To measure the temperature I made a couple of sensors out of discrete 18B20 temperature sensors and installed them under the insulation against the tank at the top and bottom. No, I wasn't going to drill into the tank to install them, and I wasn't going to tap into the existing sensors that drive the tank. Tapping into the existing sensors might break them and drilling into the tank would have been a disaster. I want this thing to be capable of working if the new electronics ever fail.

Here's one of the sensors:

I thought about using one of the 18B20 sensors that are enclosed in a waterproof stainless steel enclosure, but I wanted as much sensitivity as possible and jamming the sensor up against the tank and securing it with metal tape seemed like the best way to do it.  It was a bit of a pain getting through the insulation to the tank, and the tank itself was covered with a high density insulation as well. I didn't dig into the tank coating; I just secured the sensor to the top of it. This made my reading low as compared to the temperature of the water inside, but if necessary in the future, I can correct for that by adding a little to the reading in the code.

With two sensors, the PZEM-004 power monitor, power supply and control wire for 220VAC power to the heating element, I ran into a little problem with available connectors for power ground and the sensors. After considering electrical tape, hot glue, shrink tubing and such, I just soldered some more power, ground and sensor connectors on the XBee shield I used.

Those three vertical black things are where I tap off and supply the various power and signals. I'm going to have to remember this trick in the future. It turned out to be a really convenient way to get extra connections. I even put the pull up resistor that one-wire devices need in there. You can barely see the 4.7K resistor in there between the rows of connections.

But, you ask, what did you discover after all this work? Well, I discovered how annoying working on a step stool over the top of a working solar hot water system is. Up, down, dropping things, wires too short to reach, taking it apart, putting it back together, all were inconvenient. It probably added several hours of pure frustration to the process, but all of us folk that do this around the house should be used to that ... right?

Here's a chart of actual operation that I pulled today:

In this the solar is running at around 80 watts and then reaches temperature and shuts off. The top of the tank was at 129F and the bottom at 118F for a differential of 11 degrees over the height of the tank. The actual water temperature measured at a nearby faucet was 138F, so it looks like the tank coating was keeping 9F of temperature away. To me, that's OK since I understand what is going on.

I also caught this where I turned on the dishwasher after the sun went down:

You can clearly see where I turned on the dishwasher and the cold (well tepid) water came into the bottom of the tank. Then a little later the rinse cycles of the dishwasher removed some more hot water from the tank. The temperature at the top of the tank didn't drop that much though, only down to 127F. It wasn't even enough to turn on the heating element (it was dark outside). Here's the entire chart for the same period:

Ok, it's a mess. That's because the power being used is only 3-10 watts and that auto expands to cover most of the chart. But, you can see that it isn't using 80 watts circulating the solar or over 4000 watts running the heating element, and that the grid power was available by the green line at the bottom.

That means that I ran the dishwasher a full cycle with hot water and didn't pay anything for heating the water since it was still hot from the solar cycle during the day. I've seen this several times now; the dishwasher, shower, various faucets, don't use enough to cause the heating element to turn on. Especially since the incoming water is probably close to 100F already during the day.  Hang on a minute, I'll go measure the water temperature coming into the house right now.

It was 89.6F. So, the incoming water is 90F and the solar will take it up to 138 making the differential only 48 degrees or so. It will show up as 129 on the graph due to the loss I described above, but that's a known thing. As a matter of fact, the heating element hasn't come on at all in the last 72 hours. I can't show you a graph to prove it because I've had the thing taken apart too many times. I may post an update later after a few days of operation. But, as a consolation, let's take a look at the cooling rate of the water heater:

Here is a period between cycles of the solar heat running. The bottom temperature is affected by the solar running, so it is higher than the incoming water temperature; the heat transfer coils are at the bottom. That makes the bottom temperature drop at the beginning. The top temperature  drifts down over time at a reasonable rate of about a degree every hour that decreases to less than a degree every two hours when it gets around 125F or so. This thing will keep 80 gallons of hot water all night this time of year. I'll have to wait a few months to see what it does in colder weather. If it gets too cold, the heating element will turn on and raise it back up anyway.

Which brings up a point I didn't realize until I did this. The temperature for solar heated water is 138 degrees. I set that back when I got the heater and it is controlled by a differential controller separate from all the other stuff. The electrical heater is set lower; how much lower I don't know yet. I'll experiment a bit to find out, but I suspect it's about 10 degrees or so. That's why the mains power isn't used much. The solar keeps the water above the temperature where the heating element kicks in. I don't know where that control is, but it's worth looking for at some point.

Software wise, it wasn't particularly hard to put together. I used the arduino library for one-wire sensors like I did for my room temperature sensor project. What I did was to read the sensors, then read the power, then send the data using timers. Since the water isn't changing very fast due to the nature of water and the mass of 80 gallons, I only read it every minute. I read the power every 15 seconds. The report is sent every 30 seconds right now, but that may change in the future when the new wears off the project. In the remaining CPU cycles, I watch the XBee for incoming items.

I only respond to the time signal and a command to turn on the mains power. The mains power was easy, I just picked a digital pin on the arduino and set it high to turn on the 100 amp solid state relay in the box. I watch the time for obvious reasons, I turn off the mains power at noon (soon to be 3 PM) to avoid the peak period charges. It doesn't get to turn back on until 8PM.

I used the timeAlarm library for the arduino to handle both timers and alarms. Timers control the readings and report while alarms turn the mains power on and off.

See how previous projects where I used time and various libraries are paying off? As one works with this stuff it gets easier to put things together and create something new.

It didn't work first try though. Most of it did, but the darn thing quit sending data every day at noon when it turned off the mains power to the heater. The problem turned out to be that 'on' has one less letter than 'off', and I was overflowing the buffer that I build the JSON report string in. That simple little problem took almost a day to isolate. I kept trying to blame it on the pin controlling the SSR.

There you are, the most comprehensive water heater controller I've ever seen. Probably more than I'll ever actually need.

But, exactly what I wanted.

Edit: I just put the code in Github so you can take a look if you want to.

Monitoring Water Heater Power

Well, I can now monitor my hot water heater power usage. The step-down transformer I got <link> worked just fine and I managed to put together all the pieces and now have it out there running just fine. I mounted the transformer on the lower right of the picture below. I used exactly the same technique that was used in the power converter it came out of, high adhesion two sided tape.

What I did was to spread some silicon grease on the bottom of the transformer then put the tape on one side. I pressed the grease down on the enclosure and slid the transformer back until the tape adhered to the back of the enclosure. This way I used the entire steel enclosure as a heat sink for the transformer. I used the same idea for the three phase solid state relay (SSR) that actually controls the power to the water heater.

In case some of you haven't worked with power transformers, they get hot. It seems like no matter how high the rating, they generate more heat than expected, and can cause problems over time. That's why I was careful about giving the heat generated somewhere to go.

Just to the left of the transformer is an Arduino with an XBee shield on top, and just left of that is a AC to 5VDC switching power supply.

This little power supply is really nice:

I got it from itead.com a while back because I knew I would need a small power supply in the future and wanted to try one out. Unfortunately, they retired this model and I only have one left. I guess I'll have to hunt down another one sometime in the future.

I took the easy way out in mounting both the Arduino and the power supply, hot glue. It just wasn't worth the effort to build something special to hold them in place, so I grabbed a piece of plywood and mounted them to it. Worked fine, and they'll still be easy to get to if I want to change something or fix it in the future.

The enclosure is from Home Depot and I've had it for a while now. It's been the enclosure for the big SSR in the middle of the box for years, I'm just now adding more circuitry to it.

I'm interested in monitoring the power right now, so I haven't moved the code to control the SSR over to this Arduino yet, but that will come in a few days. That control is still part of my garage controller that also controls the garage doors. As a matter of fact I had power applied to the water heater when I took this picture; you can tell because the LED on the SSR is on. The control for that comes through the small wire on the top and connects to the left side of the SSR.

I was a bit worried about how far the little XBee would reach since it would be inside a grounded metal box once I put the lid on, but it worked well enough that it got to another XBee and the network took care of the store forward part I needed to get away with this.

It looks pretty good up there on the wall above the water heater:

Now I can glance up at the display and tell immediately if the solar pump is working, the mains power is being used or nothing is going on. To measure the power used by the solar pump and temperature controller I used the transformer mentioned above to reduce the power from 240 to 120 and put a plug on the front of the enclosure.

Notice that the solar pump is running when I took the picture. It uses about 80 watts to circulate the fluid from the collector on the roof through the heat exchanger inside the water heater. It has to run a long time to heat the water up inside, but at 80 watts, I don't even notice the power usage.

Now that I can see all the power data for the water heater, I can pretty much write it off as a large factor in my power bill.

Above is a chart of the last 24 hours of all the power usage by my solar water heater. Notice that there is one peak of main usage around 10AM and some light usage at other times. The large peak is too short in duration to cause a problem with the 'demand' billing and the light usage is around 80 watts from the solar pump.

Here's a chart of just the solar pump running:

The gap just to the left of middle is me installing stuff. Yes, I turned off the breaker; I have a healthy respect for 240VAC directly from the mains panel. All the jagged readings on the lines are the circuitry doing measurements and sending them off through the XBee. I have blinking lights on the Arduino and displays of the PZEM-0400 that are constantly changing. Makes for an interesting display.

Now before the more astute readers out there start picking on me for parasitic power usage, here's a chart of the power usage when nothing is heating at all:

The usage when nothing is heating varies between 3 and 10 watts, that will take a long time to add up to a full kilowatt and even show up on my bill. If you look up above at the first chart, you'll see that this is the condition that the water heater is in most of the time.

Actually, when I looked at parasitic power a few years ago, it just wasn't a problem. I have a baseline of roughly 500 watts that is used all the time. Things like ceiling fans, necessary appliances, phone chargers and such do add up, but what are you going to do about it? You have to keep the food cold and a 10 watt device running just isn't worth bothering with. All the hype about this just doesn't add up.

So, I did all this just to find out that my water heater is doing a really good job of saving me money. To heat the 80 gallons of water in my heater using the rule of thumb number of 0.166 kWh per gallon (60 degree F increase) for 80 gallons is 13kWh of power. I get it for a few hours of 80 watts in full sun. And, sunny days are not something in short supply around here.

I'll use the charts and power control to find a happy medium between using sunshine and mains power for keeping the power bill under control. I'm sure I can fine tune this over time. Plus, for the rare cloudy day, I can always crank on the power during off-peak periods to handle my hot water needs. I have special web code to do that from anywhere <link>.

I'm not quite done with the water heater yet though. I want to put a couple of thermometers up against the tank one at the top and one at the bottom to measure the actual temperature of the water. I also want to move the code that controls the SSR over to the new device so I have all the water heater code in one place.

But this little exercise has opened the doors to another possibility. All of my 240 volt appliances should have monitoring like this. I can get several of the power monitors and install them for the AC compressors, AC air handlers, dryer, and maybe even the microwave. Heck, I could monitor the kitchen oven as well. Hmmm, I could use another SSR and keep the darn clothes dryer from messing with my power bill, that has happened twice now. Someone needs clothes dried and they turn on the dryer during the peak period. I can actually put a stop to that by doing what I've done with the water heater.

How come every project leads to another?

PZEM-004: Now to actually use it for something

Literally hundreds of these energy monitors have been sold, but judging from the various articles I've run across, not too many of them have actually been used to meaningfully monitor power around the house. I'm going to install one of them on a troublesome device and actually use it to help understand my power usage. My current victim is my hot water heater.

I've described it before <link>, it's a solar hot water heater with a helper element in it for times when the sun isn't shining. Basically every day here in the desert I'm supplied with unlimited heating for water, but how often do I need the heater element? The element is designed to turn on any time the temperature drops below a certain temperature, but I have no idea what temperature that is. I have the solar heating set for 138F, and since it is an 80 gallon heater, this supplies my needs quite well. Nevertheless, I still want to understand the device and how it uses power.

The first thing I need to do is both read the serial output from the power monitor and be able to transmit it to my house controller so I can save the readings over time. This turned out to be a problem because an arduino only has one hardware serial port. It is possible using software to get another one, but having two software ports is a problem.

The SoftwareSerial library allows for two serial ports, but you can only work with one at a time. Each time you switch ports, the input buffer for the other one is cleared. When I tried it, that meant that the buffers were wiped such that I couldn't actually get enough data from either the XBee or the power monitor to construct a usable packet. I want the serial port for debugging and commands, so I had to work out another method.

What I did was set up a timer that fires off every 15 seconds to interrogate the power monitor, saving the data in global variables. Every 30 seconds another timer fires and sends a report of whatever the variables happen to hold at that time over the XBee network. This way I have reasonably fresh data to send every thirty seconds and only use the two software ports one at a time.

The exception is that in the main loop of the code I check for incoming data from the XBee network at every iteration. Basically in the idle periods between gathering and reporting, I check the network. To prevent the arduino startup from sending bad data from the variables that aren't filled in yet, I read the power monitor before I do anything else. Then I wait for a time message from my house clock, set the two timers and let it run.

It seemed to work pretty well.

Now, how the heck am I going to attach this mess to the water heater? I'm dealing with mains voltages here, I can't just stuff it in a cardboard box and hang it by its USB cord on a nail. This will take some consideration. Additionally, since there is no neutral line to the water heater, everything needs to work from a 220VAC source. Yes, I know, most of the world already has this to deal with; for me, it's a new experience.

Being impatient, I took a big rag and insulated (if you can call it that) the top of the water heater and hooked the power monitor to the high power solid state relay that I use to control the power to the water heater. Then I draped the USB cord over to a wall plug for 5VDC power to the arduino and XBee combination. This way I could actually watch the water heater power usage real time and work on the software to add the data to my Graphana display.

I had some foresight though, I put in plugs for the connections to the CT, 240VAC voltage monitor and serial input so I wouldn't have to flip the breaker when I did something, and it worked like a charm after some programming to save the data I had gathered and a little work in the charting software:

Granted, it's not much to look at. The heater only turned on three times, and even then, it was only for a minute. Slow day around here, but notice that the spikes are 4500 watts. This thing can really pull the power; remember, the solar is running also.

What is happening is that using hot water causes the temperature in the tank to drop and both the solar and the helper element kick on. This heated the water back up in a hurry. Or, maybe I have a bug I haven't discovered yet. Over the next few days I intend to look at how hot water is used for showers and general use around the house. I won't get good data on how this thing is working until I can also monitor the small solar pump as well, but that will take some thought, and probably, some more parts and pieces. Keep in mind that the small pump is 120VAC and I'm working with 240 at this point. A transformer maybe??

My data gathering will be impacted by the fact that the water here doesn't get cold enough to need much of it. This time of year, the rest of summer and early fall, one can take a shower with nothing but the cold water turned on. The best we get for cold water is tepid, and maybe use a tiny bit of water from the hot side. Not that way in the winter though, then hot water usage is much higher.

I'm starting to like the PZEM-004; when this project is running, I want to look around at other similar devices. It's hard to beat less than $15 for a device like this. I certainly can't build an equivalent for less.

I'll put the code for this on github when it is a little farther along. There may be too many bugs right now.

Previous post on PZEM-004 <link>

Adventures With My Freezer (the one in the house)

Over the years I've been doing modifications to the freezer in my kitchen. It all started way back in 2014 when I decided to not only measure the power usage of this device <link>, but to also control when the defroster runs <link>.

A tiny bit of background for folk that haven't been following my silliness for very long: I'm trying to lower my electricity bills here in the Arizona desert, and have a power company that offers a lower rate during off hours. What I do is try to keep all my major usage in the non-peak hours, and having the defroster run whenever it wants to sometimes leads to defrosting in the middle of the peak period. Also, I bought this freezer because it is simple, really simple. There's no huge electronic package in there that is designed to save power, hook to the internet, take pictures, call my Mom, etc. It's just the basic freezer, albeit a high capability, and repairable model that looks really good.

I also added the ability to monitor the temperature inside the freezer <link> after my 'wonderful' defrost controller crapped out. While I was fixing that I decided to combine the two relays on the Arduino shield I was using to parallel the contacts, hoping to extend the life of the relays.

Don't ever do that !!

I totally forgot that doubling the number of components also doubles the possibility of failure, as well as doubling the ways they can fail. This is a great story of doing the wrong thing, so I'm going to teach you a bit about the defrost cycle on a freezer so you understand what I got myself into. Since I have the ability to chart the actual action of my freezer, you get to have real examples of my (seemingly infinite) ability to screw up.

This is what a normal defrost cycle looks like when you can observe both temperature and power usage.

Ignore point A, that's the icemaker running to dump ice in the tray, and the tiny bump next to it is the lights in there when I open the door.

Point B is the start of the defrost cycle, this happens on a timer that closed a SPDT set of contacts that shuts off the compressor and kicks on a heater that is actually attached to the evaporator at the bottom of my fridge.

Point C is where the heater is running, and it will run until a temperature sensor (also mounted on the evaporator) reaches a built-in temperature that the manufacturer thinks is the best to clear the frost away. In my particular case this thermostat is 37F.

Point D is where the heater shut off and the freezer just sits there until the timer runs out after 30 minutes. This is to allow the water to drain out the bottom into an evaporation tray and away from the freezing area of the freezer.

Point E is where the compressor kicks back on, the spike is the usual one you get from the run capacitor letting a lot of power through to get things going.

Point F is the normal compressor run cycle. It runs until the Freezer gets to operating temperature and then shuts off. On freezers the compressor runs a long time, but that's OK because these things only use around 100W. In the days before LED lights in appliances, the lights used a lot more power than the compressor did.

So, the heater pulls around 400W, but should only run for around 15 minutes, however once in a while it because of high local humidity, someone holding the door open too long, trying to freeze a gallon of hot water, or something like that, the heater will run the entire 30 minute cycle time. When this happens, the next defrost cycle will take care of the left over buildup.

Unless something is broken, or you've got someone in the house that messed things up.

I noticed that the temperature in my freezer was gradually rising and the compressor seemed to be running too long. Here's a chart of what I saw when I looked at it:

Once again, the sharp peaks are the icemaker doing its thing, but let me step through the other parts I pointed out:

A is where the defrost heater started. This part appears perfectly normal.

B is where the defrost heater should have leveled off at around 400 watts. Notice it's up around six hundred and climbs after that.

C is the defrost heater shutting off after the full thirty minutes of time allowed by the timer. It didn't shut off early and coast.

D the big spike of power should have shown up, it didn't. The spike there is the ice maker dumping ice.

What was happening? After a bunch of troubleshooting and scratching of my head, I figured it out; one of the relays had a frozen up contact and the compressor was running during the defrost cycle. The other relay was working just fine, but it couldn't stop the compressor with the other one bad.

I gutted the relays to double check (sorry I forgot to get a picture) and one of them had the contacts welded together and was the culprit in this mystery. I pulled it loose and let it go. About two days later, the remaining relay gave up the ghost as well. So much for those relays. I've got my eyes on one of the 30 amp relays now and have an order off for a circuit board that will hold it and an XBEE in my own designed Arduino shield.

Yes, I feel a bit stupid. But, isn't the ability to chart the performance of my freezer cool? Looking at the database of freezer data I was able to tell exactly which day it happened and how much the temperature rose over time as the defroster competed unsuccessfully with the compressor. Even the fancy internet connected freezers can't do that.

Right now, the freezer has the old mechanical defrost control in it that has had to be replaced twice because the mechanical clock in it doesn't hold up over time, and the defroster turns on whenever it feels like it. I had to get out the heat gun and melt the frost off of the evaporator by hand to give it a head start, that wasn't hard, but it did let the ice cream get soft.

More later, I'm not giving up on this.

Battery Operated Temperature Sensor: The Batteries Died

The previous entry on this project is here <link>.

I worked on this project earlier this year and put it into daily service back in April. The batteries died last night (this morning) at 4:00 AM, earlier than expected. They lasted 5.5 months and had the same rapid decline to 2.7 volts that I saw when I was running it in accelerated mode to understand how to do this.

Basically they coasted along dropping a little over time and then just dived, relatively speaking over a couple of weeks to a level where it wouldn't work anymore. This seems to be the normal behavior of alkaline batteries, so nothing new.

I am disappointed that it took less than six months to die though, but it died two days after my TV remote control died and I changed those batteries around the same time as this device. I remember because of the coincidence of having the remote need batteries around the same time as I started the long term test on the sensor. Could be the life of the cheap batteries I'm using.

The device was set for 115 seconds off and 5 seconds on and I can easily change that to a much longer off period if I need to, but I'm not sure I want to. Having the temperature available at two minute intervals is nice and fits with my longer term plans for temperature control in the house.

On the reliability front, this thing has worked day after day without a hiccup. I use it to turn off the bedroom and outside lights when I go to bed every day and sometimes just to show it off. Never gave me a problem unless the controller it talks to was having problems because I changed something there. It's still a bunch of components on a proto board though. I couldn't find an enclosure to fit it that I liked and decided to wait until I could buy a 3D printer to make something for it.

My tractor and the terraforming work around the house ate up the money I was setting aside for the printer and that has been postponed until I finish that stuff. Keeping flood water out of my house and repairing ruts in the driveway will always take precedence.

I put some more of the exact same batteries in it, and it's beside the bed again doing exactly what it's supposed to. I'll check on it from time to time and see what develops over the next six months or so.

Maybe by then I'll have an enclosure for it.

Arduino, Raspberry Pi, Pool Controller and Another Guest Speaker

Let me introduce Mike He's another one of us folk that wanted automation, but didn't want to pay unreasonable prices or be locked into the control of some system 'out there.' He's been working on a project that I want to get into deeply at some point (when I get sorta caught up), and he's way ahead of me on it. Go ahead Mike:

The initial project...

   Several years ago, I was trying to think of a way to extend my swimming season without breaking the bank. I have a heat pump on the pool but they aren't very cost effective to operate. As I live in Florida,  we have plenty of sun so solar was an obvious choice.  Problem is that I didn't want my roof covered with plastic pool panels as I intend to install PV electric panels there and since they tend to develop leaks, i didn't want salt water on the roof. I already heat my hot water with solar so I started looking into using the same concept for the pool.

   I located a pair of glazed DHW panels and set them up with a titanium heat exchanger so that I wasn't running corrosive salt water through the panels. Here's a picture of the panel...

   I used a circulation pump to pump the water in the closed solar loop and quickly discovered I could gain 5 to 6 degrees a day in pool temperature in March. I was losing 2 to 3 degrees at night but the idea was successful as I was still gaining heat. Since I didn't want to heat the pool past a certain point and I didn't want to have to manually control it, I needed a contoller. I was already  toying with my first Arduino (a Uno) so it was an obvious choice.

   I began to research temperature sensors and ran across the "Differduino" project. All I had to do was modify the hell out of it and I had my basic controller! I added an ethernet shield so that I could send data to an external site now known as Xively.

   The controller monitors the pool temperature and the panel temperature and turns the circulation pump on and off on a differential provided the pool temperature is below the setpoint. This part of the project has not changed, much....

The evolution begins...

   Then one day, I stumbled across the "Desert Home" page. Don't remember what I was looking for but this crazy fool was doing things I had thought about but hadn't figured out how to do practically. As he had put up all of his code and wanted people to see it and benefit from it, I decided to do so. Dave was (and still is) very helpful in getting things up and running and I soon had a Raspberry Pi to play with.

   The Ethernet interface on the pool controller was replaced with an XBEE radio and the data was being magically sent through the air to the RPI where it was being stored to do with as I chose. This led to a Web interface that can be seen at myeager.no-ip.biz that allowed me to see the data in real time. I added a temperature and humidity sensor so I knew what was going on outside. Here's a picture of the controller about this time..

The house controller...

   The heart of the project has actually shifted from the pool controller to the house controller. This creation started out as Dave's, 100%! As it was written in Python, it was a learning curve. My programming experience was mostly C++. As I came to figure out more of Dave's code, it became more natural to read and much easier to learn from. Once again, Dave would prod me along rather than hand me the answers. Kudos to Dave for that...

   As I was collecting more data from the pool controller and have built a few other devices as well, data was getting tedious to process. I ran across a library called ArduinoJSON and spent a weekend in the woods figuring out how it best suited my needs. I'd like to think I turned Dave on to that little treasure but he may have been exploring JSON already. If you haven't looked at JSON, I suggest doing so. I learned quickly that only so much will fit on an Uno...

Reboot!!!

   I got hold of a Mega 2560 and loaded the code to it. I had a ton of memory now (and 3 extra hardware serial ports). The SoftwareSerial library I was using could now go away but I didn't do that until I realized that it didn't work well with two way communication on the Mega. I added and GPS module I scavenged from Streets and Trips. Now I had Dave's house clock as well so I could set up timers for the pool. A Timezone library even correctly handled the time change twice a year. This has come in handy on a few other devices. I intend to add a pH probe to monitor the pool and an acid pump to keep the pH at a certain point but I haven't done it yet. I have added two way communication with the pool controller and several things are now adjustable from the Web interface.

   The pool controller and all other devices I've built so far operate entirely on their own and continue to do their thing even if the house controller is offline. I recently had to replace my pool pump motor and chose to get a Hayward variable speed unit instead. Best decision possible in my opinion. Much quieter and the energy efficiency is a big benefit.  Electric bill went down almost $60! I'm now using the timer that I programmed to run the pool pump to run the chlorine generator and the timers on the pump to vary the pump speed. I let it run at a low speed overnight instead of turning it off.

   The house controller also now incorporates ZWAVE and controls several lights and doors. It's function grows almost every time I look at it. The power of these inexpensive machines is impressive.

What's next?

   The pH monitor and acid pump are still on the list. I need to get my panels finished up, right now I'm operating on just one, and I need to get them permanently mounted. I'm working on replacing my DHW controller with one that integrates into this system and I've got an LED sign that displays weather data and pool information all over the XBEE network.  I'm also looking into adding an FPH system from Hotspot. I'll do my own controller rather than using theirs but between it and the solar, I should be able to swim almost year round. We don't get much of a winter....

This is Dave again. Nice job Mike, and thanks for chiming in. See people, you're not the only one that does this kind of thing.

Have fun.

Arduino Controlled Sprinklers, and A Guest Speaker

Yes, I have a guest speaker for this post. Glenn lives in the part of Texas where they got about a ton (per square inch) of rain recently. Since he couldn't play outside, he decided to play inside with ... yes, a sprinkler system. I asked him to write about it because it is a novel and really, really cool setup. It uses those valves that latch into place and take zero current to run saving power and allowing for the possibility of battery operation. I'll shut up now and let Glenn take over:

Lately I have been working on my baler between rain storms. However, during the rain storms I have continued to work on my vineyard irrigation controller. Not that the grapes are going to need watering any time soon. But there will come a time and I must get this moved forward.

I have a large aluminum panel mounted to my steel pipe fence with a water hydrant next to it. I have my three zones of irrigation pipes running up to this panel (just underneath it). I have purchased a three zone manifold valve system from Orbit and equipped it with two 24VDC solenoids. The black object on top of the green valves is the solenoid. The 24VAC ones have two black wires. The 24VDC solenoids have one red and one black wire. The red goes to the set screw terminal and the black goes to the reset terminal of the zone. This is a really easy thing to do. The manifold will be mounted on the lower left of the panel just above the zone pipes. There is no need for me to put these in the ground as it is more of an industrial installation. The aluminum panel faces north so nothing will get direct sunlight, which here in East Texas is intense. Currently the aluminium panel has just a water filter mounted on it. I welded Unistrut ( this is the funny C channel electricians use) to the pipe fence then bolted the panel to the Unistrut. It makes taking the whole panel off really easy should it be necessary.

Back to the controller. Just above the valves I will be mounting a 4X4X2 inch plastic electrical box. I got this box from Home Depot. I comes with a waterproof cover and mounting tabs on each side. This is a shot of it open with the cover reattached backwards.

As you can see from the above photo I will be mounting my ardweeny and support shields to the cover of the box, not inside the box. There will be one or two access holes in the bottom with water tight entry fittings through which the wires will got to the valves as shown in the first picture. There will be three shields to the system. Ardweeny, XBee and Valve controller, all stacked as shown.

The really key thing here is that everything will mount to the cover, not inside the box.
I have several reasons for this. All fall under the category of convenience.
When I open the box and reverse the cover as shown, everything is readily available. I can access the usb port without problem. I can remove any or all of the boards conveniently. I can work with the enclosed wiring without having the shields also in the box getting in the way.
If I need to I can remove the entire controller just by disconnecting a few wires and take it away. The entire box stays mounted in place. Oh and by the way, since there are no screws on the back the box will site flat on the surface of the aluminium plate.

The box cover will also have a key pad mounted on the front for manually turning the irrigation zones off and on:

The Orbit manifold I purchased from Lowe's. They usually have them in stock. They come with everything you need including 24V AC solenoids. I think I paid $54.00 for it. I bought two 24V DC solenoids off Amazon that were "used" actually only the packaging was used for $7.00 each. The third I will buy from Lowe's locally as they are in stock and only cost about $10.00. They simply unscrew. My 24V DC solenoids came with a little gray adapter that has to be removed and then screw it into the manifold. I can take some pix and send them if you like to describe it.

Rain protection. None required. This stuff is meant to be in the ground. It gets wet. Everything will be mounted on a vertical plate of aluminium. If one wanted you could simply add a little roof shelter at the top of the aluminium, but I do not plan to. The 4X4X2 box is water tight. The connections coming in from the bottom mean rain can't enter unless it rains uphill.
I mentioned water proof connectors on the bottom will also prevent wasps, and other critters from getting at the circuitry.
I may put a little roof cover above the keypad like they do for gate openers that you drive up to. I will seal any entry points such as the keyboard cable entry with silicon sealant.

I plan on powering this with either a 9volt battery or a combination of 9volt and three AA's. This way I won't need to have a regulator. I plan on having it shut down through software much the same way as your remote temperature sensor works. The jury is still out just yet on this. I plan to liberally and unashamedly steel Dave's software......Hee Hee Hee. He's done a great job and created a voluminous library of functions that will save me from reinventing the wheel.

I chose to go with Ardweeny because there is a nice little shield for it that fits the Arduino form factor. I can do all my testing and code development with the regular Arduino and then simply replace it with the programmed Ardweeny. No other special mouning requirements. I have the shield on order and as soon as it arrives I can drill the holes.

I plan on a next issue of this showing how I will use insert nuts that have a built in standoff of about a 1/4 of an inch to mount the Ardweeny shield to the cover and gluing up of the finished numeric pad. There will also be more discussion on powering. I am thinking of a second box that could house a small motorcycle battery. I found one for $25.00. The big thing on this to remember is that this only will run through the summer months so I could conceivably charge the motorcycle battery once a year and run it all summer. More to come on this note.

Still a few things to think about with this yet. I'm not sure about a led in the outside of the cover plate that will illuminate when you push the button. I'm thinking that the clicking sound of the solenoid plus the rush sound of the water in the pipes might just be enough. Needs to pass the "wife" test though.

So there you have it. The main theme of the blog is really "Don't forget the cover" and the benefits it affords for mounting options.

Comments?

This is Dave again, I have a comment, AWESOME. I've been using those waterproof boxes from Home Depot for quite a while for various projects and it never, ever occurred to me to mount everything to the lid <link>. Simple idea that I should have thought of.

Yes, I'll be stealing that idea and others from him.

Battery Operated Temperature Sensor: OK, Let's Build This Thing

The previous post in this series is here <link>.

Well, I've been testing, trying new ideas and even added a button to this thing for the last several weeks. I don't think I'm going to learn anything new in the short term, so I decided to solder everything down and turn it into a package that I can actually use.

I got some of these:

Those of you that have been following this project understand now why I wanted to confine the parts to half a breadboard. I can put all the parts on this and then have something I can put in some kind of enclosure. I stripped all the parts off the breadboard and put them on the new board.

Yep, I got the regulator, XBee, Arduino Mini Pro, sensor, and a push button on there. I mounted the active components in sockets so they'd be easy to change if I needed to. I also put a plug on the battery pack so I can unplug it if needed. I still have the monitor circuit for watching the battery level, that way I can tell when the batteries are starting to go flat.

It's a nice little package, even if I do have to say so myself. If I put the battery underneath the board, it is pretty compact as well:

I think I'll put it in a travel container for a bar of soap to play with it around the house for a few months. Here's the schematic for the final result:

I'm going to the 3V version of the MCP1700 as soon as they come in from Mouser. Those little devices are perfect for battery applications. The 3V version (opposed to the 3.3V) worked well with this combination of components because the battery drops to just under 2.9V before it shuts off. That way I've dropped the batteries down to a volt each, and there's essentially nothing left in there.

Notice the voltage divider on the battery input? That combination of values works well to monitor the battery voltage, but I had to calibrate it in the code. It's pretty easy, get your meter, measure the battery voltage and then adjust the code until you get the same reading ... done. This will hold essentially forever, but if you want to check it yearly or so, it's easy.

This particular device (there WILL be others) is going beside my bed. I'll have the temperature of my bedroom as well as a button to turn the light off eliminating the X10 controller I have there now. Remember, this is a smart device, I can program it to do other things over time, and probably will. I think having one in the guest room with a door sensor attached would be fun. I may put one in the attic to monitor the heat up there, and one hooked to a moisture sensor out in the garage would be great for keeping track of the water heater.

How long will the batteries last? I don't know exactly, but it should be many months, a little less than a year. I can't measure the power usage, it's too low for anything I have. I removed the led from the Arduino board and feed the power behind the power regulator, so I have no losses there. I suspect it's using around 10 micro amps when asleep and not much when it's running. I'm going to set it to 5 seconds awake and 115 seconds asleep which will cut the drain in half compared to the level I ran it at in testing. If it runs down too soon, there's still several things I can do, but they won't actually gain me very much. Slower clock speed, mosfet switch for the power to the sensor and XBee, that kind of thing. The one thing that will really increase the time between battery changes is to simply use four batteries. The regulator I used can take it and it's not much more space. I'll try the three battery setup for as long as it runs to get a feel for what's going on.

My new NAS came in and is installed, so I guess I'll move on to something on it now. I'll build more of these as time permits, I have enough XBees for a bunch.

The next entry on this project is here <link>

Battery Powered Temperature Sensor: Remote Control Added

The previous post in this series is here <link>.

So, I crawled into bed the other night and reached over to turn off the light and it didn't work. Poked the X10 control button several times and nothing. Crap! I had to get out of bed, go to another room and turn off the light from there. The next morning I replaced the button battery in the control and everything was fine again.

But this got me to thinking; this is the only X10 device I have left from years ago and it's time to think about doing something different. X10 failed completely in my house except for the room farthest away from everything else and it has been flaky for some time now. But, how would I implement a remote control that can just hang on the wall for months and get used maybe once a day?

Put a button on my battery operated temperature sensor! It's still in testing, but it appears to be working great, All I'd need to do is put a button on it and cause an XBee message to be sent to my house controller and then I can choose some switch device to put on the light circuit and have my button beside the bed. It would measure the temperature periodically and just wait for a button press to send the signal.

Sure, I could use my cell phone with the (brand spanking new) app I made for the house, A tablet, or a web browser. I could even call my neighbor and tell them to turn the light off for me, but I want a simple button on the nightstand that I can press without any hassle and turn the silly light off. But, how to do it without draining the battery?

Interrupts, yes, that's the ticket.

Remember from the previous (ton) of posts on this device, I put the device to sleep for 55 seconds at a time and wake it up for 5 seconds to transmit the battery level and temperature, all I should have to do is to hook a button to an interrupt pin and add some code to send a message to the house controller. At the controller I can add some code to do anything I have a controller for. I could open the garage door with it if I want to.

So, a few hours later after about 25 false starts, I got it working. I connected a little switch between pin 2 and ground of the Arduino board I'm using and it causes an interrupt which breaks the arduino out of sleep and then I just send the normal temperature message which now includes a new field to indicate that the button was pushed. At the house controller, I parse out the field, look at the value and do whatever I program in.

The reason it took several tries to get it working was because I was making it too hard. I thought I'd have to have a lot of special code to support the interrupt and proceeded down that path. It turned out the JeeLab routine I'm using for sleep already supports other interrupts, and all I had to do was check a variable and add a simple interrupt handler and everything worked ... well mostly.  Here's a code fragment showing how I sensed that the button had been pressed:

 if (millis() - savedmillis > AWAKETIME){
    Serial.print("was awake for ");
    Serial.println(millis() - savedmillis);
    delay(100); // delay to allow the characters to get out
    savedmillis = millis();
    digitalWrite(xbeeSleepReq, SLEEP); // put the XBee to sleep
    while (digitalRead(xbeeCTS) != SLEEP){} // Wait 'til it actually goes to sleep
    unsigned long timeSlept = 0;
    int result = 1;
    while (timeSlept < SLEEPTIME){
      attachInterrupt(0, buttonThing, LOW);
      result = Sleepy::loseSomeTime((unsigned int)7000);
      if (result == 0) // this is something other than a watchdog
        break;
      timeSlept = (millis() - savedmillis);
    }
    Serial.print("was asleep for ");
    Serial.println(millis() - savedmillis);
    savedmillis = millis();
    if (result == 0)
      Serial.println("Woke up on a button press");
    digitalWrite(xbeeSleepReq, AWAKE); // wake that boy up now
    sendStatusXbee();
  }

I simply look at the return value from loseSomeTime() and if it's 0, then some interrupt other than the watchdog timer happened. I print a message for debugging and go to the XBee send code. The trick is in the interrupt handler:

// This is for the remote control buttons
void buttonThing(){
  sleep_disable();
  buttonPressed = true;
  detachInterrupt(0);
}

The variable 'buttonPressed' is simply a global variable that I set to true and look at in the XBee send routine. If the variable is true, I set a new field in the mesage to say so, if it's false, I say 'nothing' in the field. I'll eventually work out what would be the best thing to put in the message, but that parts easy once you get it working. Notice that I attachInterrupt() for interrupt zero, which means button two on the Arduino, just before going to sleep, and detach it after the button is pressed. That prevents multiple interrupts from button bounce. The disadvantage to doing it this way is that it won't respond to a button press during the 5 seconds the board is awake. I don't currently consider this a problem, but that might change if I want to use it for something else.

So, now if I push the button, it gets an interrupt on pin 2, breaks out of sleep, sends the temperature and an indicator that the button was pushed to the house controller. The house controller records the temperature, then looks at the new field and does whatever I want.

The Xbee send code looks like this

void sendStatusXbee(){
  xbeeReadyWait(); // Make sure the XBee is ready

  char *command;
  if (buttonPressed)
    command = "toggle";
  else
    command = "nothing";
  buttonPressed = false;
  sprintf(Dbuf, "{\"%s\":{\"name\":\"%s\",\"temperature\":\"%s\",\"command\":\"%s\",\"voltage\":\"%s\"}}\n", 
            deviceType, // this happens to be a temperature sensor
            deviceName, // originally read from the XBee
            dtostrf(readTemp(), 4, 1, t),
            command,
            dtostrf(readVcc(), 5, 3, v) // This is a text conversion of a float
            );
  Serial.print(Dbuf); // notice this is only for the serial port
  sendXbee(Dbuf);     // out to the XBee
  Serial.println("Message sent");
}

Not much to it, just a field called 'command' in the JSON string that I can look at when the message comes in. Currently I'm sending the word 'toggle' if the button was pressed and 'nothing' if it wasn't; I love being able to read the messages, so that was descriptive enough for me.

There's another interrupt pin on the Arduino, pin 3, and I can use that also for two buttons. Maybe an on-off toggle. I could also multiplex it by putting a keypad on there. First button wakes up the Arduino and then watch for letters, digits, whatever and compose a more complex command. For now, It's just a button that turns off my bedside lights. 

Tomorrow though, it'll be a button that turns off the bedside light, turns off the outside lights, sets the thermostat to the temperature I use at night, closes the garage doors (if left open), and maybe turns off the water heater power. Call it my 'going to bed now' button.

Now, a bit about the sensor testing. I had to put in a voltage divider to measure the input power because it was driving me nuts monitoring the power after the regulator. To do this, use really high value resistors for the divider and then a .1 cap on the analog pin to ground to lower the impedance. The arduino has an input impedance of around 10K on the input pins, and if your external circuitry is too high, it will give the wrong readings. The easiest way to overcome this problem and still not use very much power is to use a cap. I used 10 Meg and 1 Meg, which put my quiescent current below a micro amp, that should be fine.

So watching it run on the almost dead batteries I installed, it started failing at around 3.6 volts. The regulator on the Pro Mini I'm using was junk. First, it didn't regulate well, the voltage wandered around 3.9 V and eventually dropped off to nothing when the supply went to 3.6. This is not what the spec sheet says. Fine, I have a solution to that, I'll just put a MCP1700 regulator in place and started it back up. Take a look at the specs for the MCP1700, it's a totally awesome low current, low dropout regulator designed for this kind of thing.The new regulator worked great and I've been running with 'dead' batteries for several days now.

I did kind of mess up though. I should have ordered a different MCP1700. I chose the 3.3V version, and I think I should have gone for a lower voltage. Fortunately, they cost me 37 cents each, so I haven't lost much money if I decide to go lower. I'll know more when I hit the cut off point on the 3.3V and how it performs when I bottom out the batteries.

Just for giggles, here's a picture of it right now:

I thought it was a mess of wires a few weeks ago, now you can't see some of the components for the wires connecting things. I haven't tried to condense it yet, I'll get to that later. The new switch is between the batteries and the other stuff so I can get to it. I plan on actually using it for a while to be sure it will do the job for me.

Overall though, this little bundle of wires has really performed well. This learning curve has actually been fun and gave me ideas for other things I can build around the house. Remember, it currently senses temperature, it could easily sense anything else you want to throw at it. Suppose you put a pressure pad in front of the driveway, you could tell when someone pulled in. A light sensor to tell you if the lights in the shed were left on. A moisture sensor beneath the water heater to tell you if it started leaking. An air flow sensor in one of the ducts running through the ceiling. All of these things could be at my beck and call.

One more step in my quest to conquer the world.

The next post in this series is here <link>.