PZEM-016: Another Chinese Power Monitor

I really like the PZEM-004 that I picked up just to see what it could do <link>, in fact I built the monitor and control system for my water heater with it <link>. This thing has really taught me a lot about water heaters and how much money my solar water heater actually saves me.

That led me to look at other devices available from China that could actually help out around the house. Well, the same manufacturer makes a different model, the PZEM-016 that does much the same, but even better for my purposes. This one does the measurements for me, but also has an RS485 serial interface so I can watch more than one of them.

OF COURSE I took it apart:

It's built extremely similarly to the 004 model I already wrote about. The big difference, of course, is that this one doesn't have any display. That's OK, I'll take care of that part. But first I have to actually talk to the darn thing. I've already worked with RS485 using an arduino when I put together my pool controller <link>, so it isn't too strange, but it still intimidates me a bit.

I dug around in my boxes of left over pieces and found an adapter to go from TTL serial to RS485 and combined it with an arduino and started working on getting it going.

Naturally, it was a pain in the bottom to talk to the device. I emailed the manufacturer when I first ordered the devices (yes, I got five of them) for as much documentation as they could provide. They sent me a manual that was actually pretty easy to read and understand. In it they said that the device was Modbus compatible, and that really impressed me. If you look up Modbus, it is an industrial protocol for machines. It can control a large number of devices in an industrial setting and should have code that I can leverage to get this working.

Right ! Things never ever work out that easily. I did find protocol libraries that I could use on the arduino, but have you ever looked at Modbus? I thought the documents for ZigBee were obtuse, these are where ZigBee learned how to do it.

Frankly, I chucked the idea of using a Modbus library down the tubes pretty quickly in favor of a much simpler approach. When I looked at the messages that the PZEM 016 actually used, there were only a few of them and the responses were pretty much canned and easy to work with. I just sat down and put together a message to read the data from the device and sent it to see what happened.

No, it didn't work first try. No, it didn't answer on the second or third try either. One has to understand that if you don't get the message exactly right, you'll never get a response from the device. In my case, I was messing up the checksum. Fortunately, in the last couple of years there have been many sample checksum implementations and online calculators implemented. I tried a couple with my data and hard coded the actual message I needed to send, that actually got me a response.

Then I spend a couple of afternoons working the kinks out of getting the response and using the checksum to validate the message. Once I could send and receive a single message reliably, I was ready to start adding code. Naturally, it encountered problems. It seems that short messages would cause checksum problems ... sometimes. So much for the idea that a computer does the same thing each time. I worked at this for quite a while without resolution. Here's a couple of screenshots of the arduino serial interface. The first one is using a message that requires a short response and the second is a longer message. The interesting thing is the accumulators I stuck in the code to count the checksum errors.

The short response has 34 checksum errors out of 100 tries while the second longer response has only one out of 100. Same code and timing in both cases...sigh.

For the rest of my experiments I used messages that required a long response. Eventually, I implemented code to handle reading the values from the device, changing the address of the device, resetting the energy (kWh) accumulator on the device, etc. I actually had it working pretty well.

Then I outfoxed myself and decided to modify the code to handle more than one device on a single pair of wires. This was actually easier than I thought it would be. The idea is that each device on an RS485 line has a different address, and you address the one you want to control or receive values from. In theory I could have several of these being read by a single arduino and monitor a lot of things around the house.

But, that would mean unique addresses and unusual delays and strange things happening. Gritting my teeth to the point of pain, I dug into it.

One of the initial problems I ran into was not knowing what would be coming after I sent a request out on the line. Sure, it should be predictable, but it never works out that way. When one does a serial read, you can get back something that is expected and just follow the bytes until you reach the end. We've all seen this: a protocol has a leading byte to tell you the beginning of the response, then a length to tell you how many bytes are to follow. You simply get the length and then read until the rest of them come in.

Suppose that is the last byte you see though. Or suppose there's a burst of noise on the twisted pair and you get about a thousand more? Obviously you can't rely on a length in the incoming characters until you can verify the integrity of the message by reading the checksum way out there at the end of the message. Let's make this problem even nastier, RS485 lines can ring. That means that you can get strange interference on the line that will mess up any message that is running around on it. You have to allow for settling times and such after messages fly around.

The problems are not insurmountable though, industry uses these protocols and devices every day. If they can make them work, I can get them to work well enough for my place. And, I think I did. Here's the code I came up with to read a message coming in:

int getit(){
  memset(rxbuf, 0, sizeof(rxbuf));
  int i = 0;
  if (digitalRead(debugPin)==LOW)
    Serial.println(F("Data from port:"));
  unsigned long startTime = millis();
  unsigned long lastChar;
  boolean startchecking = false;

  while(millis() - startTime < readTimeout){
    if(pMon.available() > 0){
      rxbuf[i++]=pMon.read();
      if (digitalRead(debugPin) == LOW){
        print8Bits(rxbuf[i-1]);
      }
      delay(1);
      lastChar = millis();
      startchecking = true;
    }
    if (startchecking && millis() - lastChar > 4)
      break;
  }
  if(i == 0){
    noResponse++;
    if (digitalRead(debugPin == LOW))
      Serial.println(F("NONE"));
    return(0);
  }
  if (digitalRead(debugPin) == LOW)
    Serial.println();
  uint16_t calcCrc = makeCrc(rxbuf, i-2);
  uint16_t rxcrc = word(rxbuf[i-2], rxbuf[i-1]);
  
  if (rxcrc != calcCrc){
    Serial.println(F("Checksum error"));
    if (digitalRead(debugPin) == LOW){
      Serial.print(F("Calculated "));
      print8Bits(highByte(calcCrc));
      print8Bits(lowByte(calcCrc));
      Serial.println();
      Serial.print(F("Received   "));
      print8Bits(highByte(rxcrc));
      print8Bits(lowByte(rxcrc));
      Serial.println();
    }
    checkSumErrors++;
    return(0);
  }
  return(i);
}

What I do is set a one second timer around the entire message and when a single character comes in, I set a intercharacter timer of four milliseconds for the next character. This way the most I can wait for a message is a second and then if it just stops mid message, I only waste four milliseconds before I give up and try again from the beginning. This works really well to cut the necessary time to read a message down as well as notice a failure quickly. I was pretty proud of this piece of code until a little later.

When I tried to send messages quickly, there were problems. One response would pile up on top of another from a different device. This required a delay between devices so things could quiesce a bit. Long painful experience has shown me that setting delays in code is just programming around a problem rather than solving it, but sometimes you just have to wait for other devices to stabilize before moving on. This is one of those cases because the devices on the line don't send you a ready message.

One other thing you'll notice in the code above is that I found a new debugging tool, an input pin. I use pin 3 on the arduino as a digital input pin and check to see if it is grounded before putting debugging messages out. If it's running and I see something I don't understand, just ground pin 3 and the debugging messages come out to the screen. I really wish I had thought of this about eight years ago.

The other pin I use for a special purpose is pin 2. If it's grounded I go into a special piece of code that allows me to change the address of a device. All the devices come addressed as one initially and I have to change them to something else to actually use them. So, if I add a device to the line, and boot the arduino, the first thing it does is check for a device at address one, and when it finds one, it tells me to change the address and hangs up in a hard loop.

I plug in a wire to pin 2 and then boot the arduino again. It senses the pin and goes into special code to allow me to readdress the device. This is also a good time to recompile and add another device to the device table. Yes, I took the cheap way out. I add a device in the code by changing a number and entering the default values as well. It just wasn't worth the time to come up with a more elegant solution for something that will happen six or seven times ... ever.

Basically, I'm done with being able to control and read this device, but that is the beginning of a greater project I've been thinking about for a long time. I'm going to put several of these in an enclosure and measure the power usage of my major appliances. The 2 AC air handlers and the 2 AC compressors are big users of power and I want to track their operation. The stinking dryer that has cost me so much money because people keep using it is another one <link>. I messed up though and only ordered five of the devices. I need one more for the kitchen stove. It'll be on order tomorrow probably.

Before the more astute of my readers comment on how an appliance that uses both 110 and 220 like a dryer or kitchen stove can't be measured with a single current transformer because one leg is referenced to neutral, go look at this post from quite a while back where I found a way <link>. Yes, Dorothy, there is a way to do it.

Here's a little sample of two of the devices monitoring my light that has two bulbs in it. I used the exact same setup when I worked on the 004 version.

I have the debugging pin grounded (that is so cool) and I'm reading the light with one bulb turned on. Notice the difference in the 'Energy' value? One of them has been recording usage longer than the other. They both read basically the same thing for the other measurements because they are hooked to the same thing.

Adding another monitor to the stuff is simple, Wire it in, ground pin 2, reboot, change the address to 4, change a value in he code, recompile and away it goes. Since this is one of those devices that will just run for a long time without changes, that should be fine.

Here's a picture of the setup I used to get it going.

The board in the upper left is the RS485 converter and the CTs are off on the right hand side.

Next, mount them in something, wire them up and hook the CTs around the power lines in the mains panel. I will add an XBee to the arduino and send messages back to the house monitor just like I did for the water heater. I fully expect to add at least one solid state relay (SSR) to the project to make sure the dryer is under my complete control. No more running the dryer during peak period for me.

Have fun.

Supercooling in the Desert: May 22, 2018 a day that will live in infamy !

This is the day I got clobbered by APS (my power company)

Look just before 8PM (20:00); see that bunch of spikes? My peak billing period lasts until 8, and something was sucking power before the period ended ! Let me expand the little piece that shows the problem:

That little period from about 7:24 to 8:00PM was the clothes dryer.

Yes, just a little before the end of my peak period a guest started the dryer to do some clothes. It wasn't their fault, they didn't know that the fascist power company would be watching to see if such a thing happened.

The peaks run as high as 7.4 kW, and it was doing this for a little over a half hour. The APS chart shows it like this:

And it was almost impossible to find. I looked for quite a while before I noticed it. I put the arrow on there to show you the tiny little green area that resulted. It shows up a little better on a single day chart:

That minor little slope up in the green area is where the meter saw the dryer running. It's recorded as "usage 3.18" during the 7-8PM hour. In theory, this should be my high 'demand' number that is calculated into my bill for the month.

I guess I should do a little calculating to see how this works to help me understand and avoid it even more stringently in the future. Let's look at the detail portion of my bill first:

So, the demand number wound up being 3.17 and is used as a multiplier in several items in billing. Here's the rate sheet for the plan I'm on:

So, my 'On-Peak Demand Charge' is 17.438 * 3.17 for $55.28. But, there's nothing on my bill that says that. Guess what? To make it more complicated and harder to understand, they actually split the $17 charge into two components and calculate them separately. From their tarif sheet again:

Notice how the two numbers, $4.000 and $13.438 add up to the $17.438 they call the 'On-Peak Demand Charge'. OK, fine, I have a calculator and can punch in numbers like anyone else. 4.000 * 3.17 = 12.68 and 13.438 * 3.17 = 42.60, and they add up to the 55.28 I got above. So I should see:

Delivery On-Peak Charge 12.68
Generation On-Peak Charge 42.60

Or something similar on the bill, and indeed I do. Sort of:

Demand charge on-peak - delivery $12.40
Demand charge on-peak - generation $41.66

If you look at the bill, you'll see them on there. The sum of the two charges is $54.06 which is darn close to my initial $55.28. The reason for the difference is that APS made a mistake in the original rate change request and has to use the demand number to one significant digit and they can't round, so the actual demand number they get to use in this case is 3.1kW. That's on the bill also, so I don't even have to do the truncation itself:

Your billed on-peak demand in kW 3.1

That's a good thing because rounding would have put me up to 3.2 and would be paying even more.

Now, I got the cost all figured out, the dryer running cost me some amount, but how much extra based on past performance. To get that, I'm going to look at last month to see; taken from last month's bill:

Your billed on-peak demand in kW 1.5
Demand charge on-peak - delivery $6.00
Demand charge on-peak - generation $20.16

That stuff totals up to $26.16, so my dryer cost me $27.90 last month because I didn't keep it under control. It's actually a little bit higher because the rate per kW during peak is higher ($0.08683 vs $0.05230), but that's only 3 cents per kw, and the dryer only uses 7.5 kW at around a 50% duty cycle for 3.75 kW or $0.32 extra. I'm willing to ignore that.

Now is the appropriate time to talk about how APS gets that demand number. As I mentioned in another post, they average each hour and compare it to the maximum hour during the billing cycle. That gives me 5 vulnerable periods each day: 3-4, 4-5, 5-6, 6-7, 7-8. So, the dryer kicked on and sucked power in bursts like all electrical heating appliances and those bursts pulled 7.5 kW for a short period. The bursts were roughly half the time, so it worked out, on average, to the 3.17 kW number that APS measured. It would be too much to read if I did all the calculations, but you see what I mean. That 3.17 was the highest reading so far that month, so it kept it and continued to look for a higher hour; fortunately, it didn't find one, and that's how the month's bill came to be. Next post I'm going into how to read our smart meter so folk can actually see what is coming. Unless one goes to the trouble of doing what I've done, you can't catch it real time and stop it; you can only see the what's already happened.

This is not going to break me, but it does lose me some bragging rights. Because I didn't keep control, I'm out about 28 bucks. Be warned though, if the hot water heater had kicked on, and the stove was running, this would have been a monetary disaster. Thank goodness it was only the clothes dryer and that close to the end of peak !

There you are, an example of how power can get out of control no matter what you do and how much attention you pay to it. Something will slip in and get you from time to time. Overall though, keeping tabs on my power has saved me thousands over the years. This post is also good for folk that don't completely understand how that 'Demand Billing' stuff actually works, and how to tell if you're messing up.

The parts to prevent this from happening to me again are already on order.

Previous post in this series is <link> then next is <nothing yet>

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>

More on House Power Monitoring: Prebuilt Device

There's been a lot of new devices appearing on the market for monitoring power. I decided to get one and see what was actually going on. I prowled around Alibaba for a while and settled on this one, the PZEM-004:

The reason I picked this one is that it has a TTL serial output that I can play with as well as a display, and for a long time now I've wanted a display to put on the water heater to show me when it is actually using power. This might just fit the bill as well as giving me an output that I can use to record the actual power usage. Since the water heater is 240VAC, this should do the job. If it works.

Naturally, when it came in, I took it apart to see what was inside:

The power and CT inputs are on the right and a ttl serial port is on the left. The two big chips that do the work are: Atmel 24C02N a 2 wire serial eeprom <link> and SDIC RWTS SD3004 energy monitoring chip <link>. 

These 'energy monitoring chips' are a relatively recent thing. Manufacturers took the interest in smart meters and energy monitoring seriously and produced a whole lot of special purpose chips to sell. They're pretty nice, and for an industrial application, do a good job. Every smart meter out there has something similar inside it. The problem I see with them is that for a person like me, they're too darn complicated. They take a bunch of support circuitry and need special commands to do what you want. For the time being, my own devices will use the older methods I already understand, unless this device changes my mind.

The rest of the circuitry is power supply, serial interface, support for the displays and such. I can't recommend that people get one of these because there is no clear separation between the parts that can kill you and the rest of the board. They appear to be relatively safe, but missing are the board cuts and clear indications of where the high voltages run. For a beginner that wants to start monitoring devices, this could get them in trouble.

But, trouble seems to be my middle name.

My water heater is solar. I have a panel on the roof of the garage that heats water, and when the temperature in the heater is less than the temperature of the solar heater, it pumps water from the panel to a heat exchanger inside the water heater. The heat exchanger is necessary because the fluid used in the panel is partly ethelyene glycol to avoid the possibility of freezing up there on the roof. The heater tank is 80 gallons to hold enough hot water for a long time. There is a little 45W motor that moves the water around to do the heat exchange.

Additionally, there is a helper element inside the hot water tank. The helper element is activated whenever the water needs heating, including when the sun is out and the solar is working. They recommend that people put a timer on the helper element, instead I hooked it into the house controls <link>. So this device gives me the ability to use the serial output from the power monitor to record the energy used by the heating element of the water heater.

But, why is that important to me since I have a solar water heater. Firstly, because I can. Secondly, it would be good information to know what a water heater actually uses in energy for my purposes. Heating a bunch of water is an efficient task since the element is actually submerged in there, but it still uses a heck of a lot of power. I want to understand this.

The very first thing I encountered was hooking the darn thing up in some kind of test bed. I really didn't want a bunch of jumpers carrying 220 hanging off my water heater, so I cut up an old extension cord and built a test bed for a 110VAC light that had two bulbs. That way I could change the bulbs and see different values as a kind of calibration test. I made darn sure the wires weren't exposed so I wouldn't rest my arm on them. The meter worked fine and actually gave a reasonable reading first try.

Next I went looking for how to hook up the serial port to my laptop. The USB to ttl serial cable that came with it had a fake chip in it and wouldn't work. I chased down the correct drivers for the chip and got the serial working, but couldn't find the proper baud rate anywhere in the (slim) documentation that came with it. That got me to searching the web for information.

Really fortuitous problem. There are a lot of sites out there that have messed with this device and put up examples. I even ran across a library to support it in github <link> so I wouldn't have to do everything from scratch. By the way, the baud rate is 9600!

So, I added a little arduino to my test setup and started to peck away.

Yes, I know it's not the safest setup in the world, but as long as I remember to pull the plug before grabbing that metal screwdriver, I should be OK.

As you can see, the monitor worked first try and all the displays worked. The picture missing some things is an artifact of the pulsed display. I didn't have as much luck with the software I found though. It took me a bit to figure out what 'yield();' was that was keeping me from compiling, but it turns out that that is simply a delay(0) for the esp8266. I added a stub for that.

Everything worked from then on Here's the serial results as it came out of the box:

The power, voltage and stuff was right on the money when I compared it to other devices I have around the house. The current transformer they supply is one of those that you have to remove the wires to use. You can see it in the picture above. In some places you can't get the wire loose for various reasons, so I tried a SCT-013 that can be found all over the place and I happened to have. The results were not as pleasant:

If I need to use one of those, I'll have to hunt down and change the burden resistor since I can't get to the calibration. The displays shows one bulb at first and two about half way down; roughly half what it should be. There are no markings on the supplied CT, but I bet it has half the windings of the SCT-013.

(Edit: I looked up the various datasheets, the SCT-013 has a ratio of 1:1800 and the split core version of the included CT is 1:1000. Not quite half, but close. There is a split core CT that will work with this, the PZCT-02, that costs about five bucks and has a 30 day delivery. I'd still like to be able to use the SCT one though)

So, now I'm at a decision point. Do I add this to the water heater setup or not? If I do, do I use a separate system from the garage device. The garage is currently handled by an Arduino that controls the water heater and the garage doors. This device could be for the water heater like I have one for the freezer and such.

Decisions, decisions.

Continuing with this device <link>

OK, Now I Have a Question I Need Help With

I ran across a forum discussion that got me to thinking <link>.  I was researching (again) measuring power with some non intrusive method when I ran into a typical snarky set of responses to a person showing a possible solution.  The author of the post showed this picture of a clamp current meter and some wiring:

Granted, it looks like it won't measure anything since both lines go through the current clamp, but I'm here to tell you this works.

Yep, if the direction is reversed using a loop in the wire it will measure total current through the two lines.  I actually tried it with a current clamp and some 14 gauge wires to a 220V light bulb in an Edison socket.  As further proof, here's a picture of the wiring inside my smart meter:

Look closely, you can zoom if you need to, but notice how one of the power legs goes through the current transformer in the opposite direction?  Here's another picture of the wires removed from the meter:

One current transformer and two wires to measure the total current being used by my house.  I asked the guy from the power company why they didn't just put the current transformer around the neutral and he said people could avoid part of the bill by referencing to ground avoiding the neutral path.  That actually makes sense in a very unsafe fashion.  There's a number of things you can do with current transformers that I hadn't thought of until now.  You can run both wires through in the same direction and tell if there is current to ground; that's how the GFCI you have in the bathroom works.  You can loop a wire around the transformer and double the voltage out to measure smaller currents.  Heck, there's a bunch of configurations that can help us measure things if we learn how they work.

My question is, how the heck does this work?  I know it does, I've done it, and the meter manufacturer has also.  I just can't get my head around the physics of it.

This also points out how folk on the web jump on someone who is correct and belittle them.  I guess we've all been there some time or other.  The author of the picture showed a heck of a lot more restraint than I would have in the same circumstances.

Arduino, XBee, and a Freezer Defroster

I have an upright freezer.  Living a ways from town and the climate make this necessary.  I load a cooler in the car, go to the store get my frozen goods and some ice, pack the food in the cooler with the ice and come home.  When it's over 114F outside, you have to take some special precautions to keep the food from becoming a puddle in the back of the car.

A while back I discusssed how my freezer uses power; it's relatively efficient except for one item, the defroster <link>.  A freezer's defroster is a combination of a timer, a heater, and a thermostat to monitor the temperature of the evaporator.  What bothered me was the timing of the defrost cycle.  Every 11 hours or so, it would defrost, and this meant that the heater would be on during peak usage period.  Since I pay a lot for peak usage it would be nice to have better control of the timing of the defrost cycle.  So, an examination of the defrost circuitry showed a clear opportunity for an accurate timer and a simple SPDT relay as a replacement for the conventional method.

So, since I had a couple of arduinos that weren't doing anything, I got one of these:

This shield has both the relays and the XBee socket I wanted to use, perfect.  I have a few XBees that I picked up, so I configured one and plugged it in.  A little code later I was reading my house clock transmissions and setting off a timer every 12 hours.  I chose 08:15 and 20:15, times that are outside the peak period, now all I had to do was wire it in and test it.  Here's an image of the schematic of the circuitry:

I circled the defrost timer to make it obvious.  Notice that it simply switches between the compressor circuitry and the defrost heating assembly.  This makes it simple to wire into the circuitry, so I took out the timer and used the plug that went to it to wire into the relay of the arduino shield.  It was ready to test, and I hooked up a wall wart power supply and plugged the arduino into the same power monitor that I use on the freezer.  It worked like a charm.  Now my freezer goes into a defrost cycle at the programmed times and runs for 30 minutes.  I checked the evaporator pretty often to make sure it was running the heater long enough and everything seems fine.

While I was programming the device I threw in some code to allow me to set off the defrost cycle any time I want to as well as having it report through the XBee the status of the defroster.  This leaves a clear opportunity for installing a temperature sensor, compressor sensor, door sensor, etc.  Over time I may well do some of these things.  I could go nuts and use the arduino to control the entire freezer; these appliances are relatively simple devices and a little arduino and some relays could take over the entire operation.  I'm not sure there's any real point to that since it works well already, but I may get bored some hot summer day.

A temperature sensor would be pretty nice though.  I could send the temp to my house controller <link> and set up a piece of code to check for the temperature getting too high.  A too-high situation could easily send me mail or light up an LED somewhere to alert me to a problem.  Or both.   

Here's a chart of my freezer power usage over a 24 hour period:

The freezer is the black line.  Notice the two humps, one at 08:15 and the other at 20:15?  That's the increased power usage from the heating units (one on the evaporator and the other on the drain tube).  Now I have this power using mode scheduled for the lower rate periods.  With the new LED lights I installed in the freezer to replace the incandescent ones, this device is getting cheaper to run all the time.

Before you tell me that the wall wart and arduino probably use 5 watts continuously, remember my goal was to move the higher usage away from peak billing periods.  I'd rather have 5 watts continuous than 400 watts for thirty minutes during peak.  Peak usage is really expensive in my area.

No, it's not a major savings, but every little bit helps.  Heck, I'll probably get back the money I spent on the shield and arduino in ... what ... 10 years or so.

Cell Phone Charging and Power Usage.

One of the comments on this blog made me start wondering about the little parasitic devices we have all over the house.  I've always assumed that they drew so little power they wouldn't matter when compared to to the kilowatt guzzling motors and heating elements we have in the larger appliances.  One little device that annoys me is the cell phone charger.  Every time the phone gets to a full charge it tells me to unplug the charger to save energy.  Sheesh, leave me alone, let me worry about how much power I'm using.

However, the commenter said his measuring device recorded 15 watts for several of his devices.  If I can confirm that, I may have to think about doing something since I have a bunch of them around the house.  So, I'll take on an annoyance and see what the power usage really is for my cell phone charger.

This little phone sucks 12 watts when it first starts out, so I need a really good wall wart that can supply over two amps to get the quickest charge.  Since I used the 'genuine' Samsung charger for this test, I let the phone drain down to (approximately) the same point and tried one of those 'Samsung' chargers that are available on Ebay.

Don't let the scale confuse you, this charger never gets over 1 watt.  Since my granularity (using this monitor device) is 1 watt, it could have gone a little higher or lower and still read this way, so I plugged in an amp meter in series and watched a while and it didn't ever go over 500 mA.  It doesn't have the stair steps of the real Samsung charger and took much longer ( less than an hour compared to over 2.5).  It looks like buying a real brand name may result in much, much better performance.  However, how the heck do you tell if it's really from the manufacturer?  Both of them are labeled 'Samsung' and they are the same form factor.  The ratings on the side are the same, so how do us folk out here in the world tell the difference?

I don't have an answer to this, and I'm certainly not going to buy a few hundred different ones and try them out.  I'm seriously thinking about making a load to test these things before I try to depend on them for anything.  If they fail the test, I'll do some serious complaining to the supplier.  The other thing I'm thinking about is putting together a power supply that will give me 5V at three amps reliably.  This would be useful to see how the charge characteristics of the phone look when it has enough current available.

Just for fun, I weighed each of them.  The real Samsung charger weighed 37 grams and the other one came in at 25 grams.  The real one has 12 grams more stuff in it, or thicker plastic.  Since I plan on using the fake for other things, I'm not going to dismantle it ... yet.  But here's a picture of the two of them:

The fake is the black one.  

Just to let you folk know though, there are two differences between them. 1. The real one has a UL certification on it, the fake doesn't.  That's really easy to overcome, they simply add another certification stamp to it.  2. The fake says 5.0 volt at 2 amp, and the real one says 5.3 volt at 2 amp.  Once again, that's easy to overcome.  I've already mentioned the weight, but no supplier tells you the weight of the device.

Anyway, I started this as an investigation into parasitic power and wound up researching chargers and their capabilities.  Sigh.  At any rate, let the buyer beware.

I Got My Smart Meter - North of Phoenix, AZ

Yep, today I got my smart meter.  I called the power company yesterday and asked them the questions I had and guess what ... they didn't have the answers.  Are you surprised (not!)?  No, I'm not a health nut; I realize that the frequency of the transmissions is non ionizing, and that the intensity decreases with the square of the distance, so this tiny radio on the side of my garage is about 1/1000th as dangerous as a wayward Lego on the floor.

No, what I wanted to know is:

Is it Zigbee?  No, they chose another transmission and protocol method.  I don't know what, because the tech didn't either, however it is a store forward mesh network that can use other nearby meters to forward the data to a central collector.

What frequency range does it use: It's in the 900mHz band.

How often does it report? The tech was unclear on that, but the total time is only seconds a day which leads me to believe that it's on an hourly basis.

Who made it?  The meter is the common Elster REX2.  Which negated a whole series of questions about what technique was used to measure the power coming into the house.  I'll talk more about this a little further down.

Were they any  good? He thought they were accurate and seemed to be holding up well in the heat, but the cover tended to glaze over from the sun and there seemed to be a higher replacement rate for not reporting than the old meter.  This is a little strange though since the old meter didn't report at all; they had to come out and actually read it.  I suspect he was talking about a seemingly unusual rate of not reporting for the meters he had installed.

Where was the collector for the meters?  It's down the road and around the corner roughly a mile from my house.  The meters are rated for six miles on their own, so the data may not have to be relayed at all if the range claims are true.

How does the data get to APS (the power company)?  At the collector it is forwarded to Verizon and uses their facilities to get it to the power company data center.  Apparently, they use both cellular and wired depending on where the collector is and what facilities are available.  Out where I am, they use cellular links to forward the data.

Did it have a pulse output? NO DARN IT.  I was looking forward to setting up hardware to read the pulses to see how accurate my measurements are over the long haul.  This was disappointing, but since I already measure the power myself, I don't have much to complain about.

So, I didn't gain much with the new meter.  However the power company will collect data by usage time and I can prowl around their data and compare it to mine.  If they show a significant difference, I might have to talk to them about it.  Although, if they record less than I read, they won't be hearing from me.

What's fun though is that people have taken these meters apart and looked inside <link>.  This article is absolutely great because it matches my meter exactly.  I stole a couple of pictures from the article because I can't be sure it won't disappear at some point and I want to point out a couple of things:

This is the bottom plate of the meter.  Notice the large wires to connect the supply to my house, they have a current transformer wrapped around them.  This is almost exactly the way I measure power with my power monitor <link>  The big difference is that I had to use two CTs to measure the power since the wires were too far apart to get one CT to go around them both.  Nice to have some validation after so long.  I've had to explain this a thousand times to various folk.  Here's a picture of the CT with the wires after the author removed them from the housing:

Clever weren't they?  The CT leads into a circuit board that measures the current and voltage to calculate the power usage.  Darn, this is really starting to sound familiar.

There's a ton of conspiracy folk out there that see smart meters as a threat.  They could become one at some point given an unrestricted power company and shoddy government oversight, but I'm not worried about that.  I'm excited about the technology.  This little guy can measure my power and send it up to APS (my power company) once it's there, I can grab it and do comparisons against my own measurements.

Heck, I'm using my power company as another cloud storage.

My Freezer and the Iris Smart Switch, Measuring Power

I went to Lowe's Home Improvement the other day to get supplies for jobs around the house that need to be done, you know caulk needing replacement, some spray foam, wire brush, the things we all have to get from time to time, but somehow, I wound up in front of the Iris display.  Shame on me.

When I got home with the stuff I needed, and my new Iris smart (which was NOT on the list) I decided to hook it to my freezer so I can monitor both big appliances in the kitchen.  Since I was lazy the last time I played with these devices, I had to modify the code to support more than one switch.  That wasn't too hard.  The switch connected first try and started reporting.  I was a bit surprised at what I got out:

I labeled a couple of interesting things; remember I have separate refrigerator and freezer, this is the freezer only.

The spike and drop at point A is the automatic defrost running.  The way these things work is there is an actual heating element on the evaporator in the freezer, and a timer runs it a couple or more times a day.  The timer kicks on and the heater brings the evaporator up to 40°F when a thermostat on the evaporator coil opens and turns off the heater.  The rest of the defrost cycle runs and control goes back to the temperature control system.  Which usually means the compressor kicks on.  This period of time allows the water to drain away into a pan where a fan evaporates it.  My defrost cycle falls in the 'Peak' period of billing, so that's not good.  The timer also runs on a little less than a 24 hour cycle, so it doesn't kick in at the same time each day.

This all means that I have a heater kicking on during the peak period that could be run some other time.  Fortunately, there's a little slot on the defrost timer that allows it to be advanced such that the defrost time can be moved, but since it will eventually move back into the peak period, I'll have to readjust it from time to time.  Notice it runs twice a day, that'll just complicate matters a bit.  This little timer may be a good place to put an Arduino synced up to my house time for absolute control of the defrost cycle.  No, I'm not getting too anal about this ...

Point B is the lights inside the darn thing.  This freezer has 8 stinking lights in it; four on the top, and four on the bottom.  Time to see if I can get a deal on led lights to replace these incandescents along with the ones in the fridge.  I mean the lights actually use more power while they're on than the compressor does.  Granted, they aren't on very often or for very long, but crap, close to 300 watts to light up the freezer?

Point C is the automatic ice maker.  When ice is low, this thing kicks on periodically to roll the new cubes into the tray and opens a valve to let water in for more.  This seemingly simple operation uses over 150 watts.  This is also short lived, so it can be tolerated.

What surprised me was how long the compressor runs.  I was worried that there may be something wrong since low coolant pressure or an air leak can cause the compressor to run too much.  I went to the GE site and looked up their explanation of the compressor cycle and what I'm seeing is perfectly normal.  The compressor on a freezer can run from 75 to 90 percent of the time under normal operation.  This seems excessive, but the motor is designed to take this much use.  It only uses 130 watts, so that's not too bad, and it does cycle somewhat, especially in the late evening early morning period.

What's becoming more apparent over time is the insignificance of parasitic power devices.  Little things like cell phone chargers that are left plugged in, televisions that look for remote control signals, wireless phones, etc.  I'll start checking on these devices, but it appears that all of them are roughly equivalent to a 60 watt light bulb.  You'll get a lot of bang on the power bill by paying attention to the lights and ignoring the small devices around the house.

Now, I have to get the caulk gun and get back to what I'm supposed to be doing.

Apple's Big Home Automation Announcement

A couple of days ago I ran across an article that said Apple was going to announce a movement into home automation. Every time Apple coughs, the news services go orgasmic and start showing everything they can, the tech copycat articles start popping up using text they stole from some other site, and the news aggregators (huffington and the like) duplicate the articles all over the place.  I knew this was going to be fun.  Here's a link to the article I ran into <link>

So, today was the day that Apple was going to make their earth-shattering announcement.  The home automation part of it didn't really get out there until several hours latter, the copycats were too busy talking about the Beats purchase and maybe some new changes to iOS.  But, I found one here <link>, I'll bet the audience of Appleophiles were going all big eyed at what was possible.  Why, you can shut your garage door, set your thermostats, turn the lights on ... I actually laughed out loud.

For goodness sake, folks like me have been doing this for years now.  We control our pool, measure the weather (inside and out), and even measure the level of our septic tanks; we mix and match devices, services, and web pages to our hearts content.  We don't pay monthly subscriptions and are not at the mercy of a single supplier.

We are free to handle our house the way we want to.

I think it's a good thing that they are doing this because it won't be long before one of us hacks into the various devices and makes them work for us.  This means more devices we can play with, more things we can automate, more of Apple's research we can leverage to our own ends.  I don't think they think like I do though; they'll want a monthly fee for web services and get even richer.  I'll be chuckling as I take apart their devices to see how they work.

Another good thing, Apple's announcement will open people's eyes to what is possible.  Much more so than my little blog and the hundreds of others out there that do the same kind of thing.  There's a whole lot of us that are doing it ourselves, and this may enlist more of us.  Sure, we're outnumbered by the folk that just buy a solution, but where's the fun and satisfaction in that?

Meanwhile, I got a notice today that I'm going to get a smart meter on the house.  Finally, the powers-that-be are moving technology out into my neck of the cactus plants.  Now, I may have to build up a device to read the pulses from the meter and get power readings that are as accurate as theirs, but much more current than what they provide.  I suspect I won't be able to crack into their monitoring signal, but I don't really need that.  However, you know I'm going to try.

Smoking Meat and Power Usage

I have an electric smoker.  Why electric?  Well, I got tired of running out of fuel during long smokes and decided to just break with tradition and increase the technology.   But, I've wondered for a long time how much power these things use.  Sure there's a label on them, and they're almost always wrong in my experience.

Wait though, I have this cool Iris switch that measures power, and I have charting tools, and I have cloud storage.  Let's take a look:

It uses around 800 watts when it's on and nothing when it's off.  After a start up period of about 20 minutes it settles into a regular cycle that varies around three minutes on and three off that expands to longer off times as the food inside rises in temperature.  If I had run it longer, I suspect the off times would have stabilized to periods approaching 10 minutes.

So, the device doesn't use a lot of power for something that keeps wood smoldering to cook and flavor food, but it could be death on my 'Demand' number for the month.  An extra 800 Watts added to my base usage during this time of year would probably push me up over 2kW and cost around $15 more on my power bill (I usually run around 1.6 kW this time of year).

For you folk that don't have demand billing, this looks like it would be .45 kW for each hour of usage on average if you ran it for 4 hours or more.  Not too bad for smoking food, your dryer uses a heck of a lot more than that.  Just to illustrate how this can combine with normal house electrical usage, take a look at my overall usage during this same period:

This makes it look like I'm a total power hog.  My usage tops out around 17 kW and jumps over 10kW several times during the morning.  That's what happens when you're doing laundry; the dryer is chewing up almost 8kW by itself when the element is on, the washing machine motor eats it fair share, the swimming pool filter is running on high, and the smoker is stinking up the area.  This is life though, we have to figure out how to deal with it and not let the power company take away our savings.

Notice that everything shuts off at noon?  Yep, I carefully shut things down to prevent the demand billing system from eating me alive.  Actually, that's what this site was started for; back before I wandered off into anti-siphon faucets, rattlesnakes, acid handling, battery maintenance and such.  Funny how things take on a life of their own.

It looks like smoking will be reserved for nights and weekends.

Hooking HighCharts Into My House

If you prowl around this blog very long you'll run into a bunch of charts.  I've experimented with several cloud services for storing data and shown examples of my own data using their charting provisions.  All of them are cool, but some of them leave a little bit to be desired.  For example, Xively uses Rickshaw <link>, and it's a nice package, but the Xively implementation is too darn complex for my taste.  If you look at the various cloud providers, they all have their favorites.

Up until now I've been using the Google graph API for my own stuff, but the problem is that Google Graph uses Flash.  Cell phones don't like Flash very much.  That means my home graphs don't work on my phone.  I absolutely can't let that continue any longer, and since my favorite cloud provider, Grovestreams <link>, uses HighCharts <link>, I stole their example and developed my own graph using the same library.

Hey, they stole my idea for the SteelSeries gauges, turn about is only fair play.

But, as usual, it was an exercise in patience.  The documentation on HighCharts is voluminous; it goes on forever and ever with tons of examples and links into JFiddle <link> so the ideas and stuff can be experimented with; talk about information overload.  It's also tough to figure out how the set the various properties in the right place to get things done, and none of the examples did exactly what I needed.  That's why patience was required.  I didn't want to get disgusted with it and just give up.

I finally got one working.  If you put your pointer inside the chart, you can get the actual reading of any point.  If you click, drag across the chart, you can zoom in and see it closer.  If you have a touch screen, you can use the 'pinch' and 'expand' to zoom in and out; when your zoomed in, you can slide the chart right and left to see the data.  By clicking on the labels at the bottom, you can turn off one of the series to make the remaining one more clear.  I could put up a lot of things to examine and choose which one by turning the others off.  I'm not sure I like the colors yet, but they're easy to change.

The beauty of this chart is that it's totally javascript.  That means it works on the phone, so I can add it to the Android app I have:

OK, the chart looks silly.  But look what happens when you turn the phone into portrait mode:

Is that slick or what?  Using the touchscreen I can zoom around it and select points to my hearts content.

The data shown is taken from my legacy feed on Xively and was reasonably easy to grab.  The only real problems I had getting it going was prowling through the documentation on HighCharts; it was all there, but like finding a needle in a haystack.

If you want to steal my example and modify it for your own use, it's on GitHub, drop a comment here and I'll post the link.

Raspberry Pi Home Controller; In service and working

I finally made the plunge yesterday and brought my Rasberry Pi online and disconnected my old controller.  The Pi is now doing all the functions of the controller and presenting a web interface for monitoring control.  It was quite the learning experience.

In this post <link> I described the architecture I chose for the new device; I extended that to handle scheduled events such as turning the pool light on for an hour at 8PM to attract bats.  Bats are fun to watch when they swoop over the pool catching bugs.  Eventually I'll have a number of events because I intend to hook my drip watering system up to the network as well as a number of lights around the house.

I also added the three cloud services I update data to: Pachube (legacy Xively), the new Xively <link>, emoncms <link>, and ThingSpeak <link>.  They fit right in the architecture without changing much at all.  Over time I expect to extend it a bit more and have a tablet based application that can control the house like a remote control.  The hooks are all there to add things over time.

Wow, was there a lot to think about.  I had to make the processes restart after a power failure, which meant taking on the init process of linux.  I upgraded the init process to use upstart.  This piece of code is much friendlier than the older init process, but was a scary piece of work.  See, if I screwed that one up I would have to start all over because it would have made my little Pi fail to boot up.  So, I backed up the operating system image before I started and several times during the process.  Fortunately, I did it right and the system came right up and worked.  Now, all the processes start on boot up and are restarted whenever they die.  This makes it cool because I can make a few changes, kill the old process, and the new one takes off and does whatever job I added to it.

I also added an update process for dyndns.  When you get a controller like this working, it just makes sense to put it on the internet so it can be monitored from anywhere.  Services like dyndns make this possible for us regular folk that have normal consumer DSL service.  Our ip addresses change from time to time and we have to keep the internet name servers up to date.  To do this, I had to take on the mysteries of the cron process.  What a pain in the behind that was.  No, the documentation out there is correct, but it's so easy to make a mistake, and so hard to find it that I spent almost a day messing around with that piece alone.

But I got it working.  Here's a block diagram of the process architecture as it exists right this minute:

Notice how the cloud update services Xively, ThingSpeak, and emoncms just read from the database to update over the internet.  Using this technique, I can try out other cloud services without making any changes at all to the ones that already exist.  The event handler communicates with the House Monitor directly, it doesn't need to mess with any other processes to do its job.  The Web Server has interfaces to the controls and database to keep the internet away.  I'm trying to keep my neighbors from playing with my garage doors.

It's strange to imagine that a little arduino 2560 did most of this stuff for a couple of years.  When you think about it though, the arduino was written in c++ and hand tailored to handle stuff over a long period of development.  I only added the things I knew it could handle.  Now, I can add capabilities that the arduino just couldn't do, which also means that I can off load some of the work that is handled automatically by other network devices if I need to in the future.

One of the great things I haven't experimented with yet is the web interface.  I can easily edit new pages off the one I have now to show graphs, pictures, etc.  This could get to be fun and offer a platform for other folks to get ideas from (that I would then steal and put in mine).

Later today I hope to massively update my page on the House Controller (see the tabs at the top of the page) so that I can share the code and ideas that are currently running.  It'll be a bit bittersweet though, since I put so much time into the care and feeding of the old controller.  But, I'm sure I'll find a use for the parts in some future expansion of the system.

You can see the web page here <link> be kind though, it's a Raspberry Pi, not a giant web server.