Showing posts with label xBee. Show all posts
Showing posts with label xBee. Show all posts

Friday, May 8, 2015

XTension Smart Meter Reader Kit

I am pleased and proud to announce the XTension Smart Meter Reader Kit



The arduino IDE compatible board reads the calibration pulses available on many smart meter models and outputs to XTension the instantaneous usage, the peak usage, the wh used since the last packet and the wh elapsed since the last nightly reset of the counters.

Communications back to XTension is done via an xBee radio, any other “bee” device with the same pinout and power requirements or any other means you wish via the serial data pads on the board.

Kits are available for shipping now starting at $45USD without xBee radios. The included electric meter attachments are 3D printed to order.

Though this kit is designed to interface with the XTension for Macintosh home automation software and does not come with any kind of display system, you could certainly make that a second arduino receiver project if you wished to do it yourself. The firmware describing the data output is open and available on the MacHomeAutomation wiki linked to above.

Sunday, April 26, 2015

XTdb update and Lightning Sensor for XTension

Lots of work done recently on the day job over at XTension.

An updated version of the graphing and database add on to the program that provides motion reports and lovely graphs. I replaced the simple graphing engine with a commercial one that has already added several features like transparency and on/off graph zones. Very useful and a great update. Many more possibilities are coming in future builds. You can get the new version from the XTdb home page

Today I finished a tutotial for connecting a very nice Lightning sensor to XTension by way of an Arduino and an xBee radio. I’ve been enjoying the storm alerts from this on my phone for a long time now and am finally getting around to posting the tutorial for everyone. XTension Lightning Tutorial

UPDATE: 4/28/15 and digi liked the lightning tutorial so much they added it to their gallery site! http://gallery.digi.com/2015/04/28/lighting-sensor/

Sunday, September 14, 2014

xBee network hosted remotely off a Wiznet TCP/Serial board.

Wow, haven’t posted any projects since may 8th?! Most of my effort was spent in playing with the kids over the summer and in porting XTension to Cocoa. We’ve been a carbon app so long because we like to support older operating system versions, indeed we still supported PPC machines up until the most recent build. Thats just got to change, we’re never going to be in the app store or run properly in the sandbox if we don’t get around to leaving some of that behind. The PPC and pre-10.7 builds of XTension will continue to receive bug fixes but are basically done. I’ve been running my house on the cocoa version for almost a month now without difficulty and the ease of doing some important things is just wonderful. Even though the conversion was not at all painless it’s coming along nicely and the UI things I can do now alone make it worth while.

The last few days I’ve been fighting with an xBee breakout board and a Wiznet card trying to build a remotely hosted xBee network. Under most circumstances you can just add more xBee’s in between the area you need to cover and the host machine and connect it directly to the XTension machine, but that isn’t always feasible. So if you have any desire to host an xBee network with the xBee coordinator sitting on an ethernet network somewhere other than where you can reach with a USB cable from your XTension computer here’s the connections you’ll need to make.

Mac Home Automation - Hosting an xBee on a Wiznet card

Monday, August 19, 2013

xBee battery powered motion sensor, part the second.

This is a followup to an earlier post as came out in the comments you can't wake up an xBee directly with the output from the motion sensor, it's the wrong polarity. It connects to Vcc when motion is detected and floats when there is no motion. Just adding a pulldown and a transistor didn't work at all to connect it to ground and wake up the xBee. Too many timing issues.

So I decided to go with an ATTiny85 chip that can sleep most of the time and be woken up itself when the sensor goes high, and it can then handle the timing of waking up the xBee and having it sample it's pins and send the data. This actually worked lovely until I tried to add back in the motion sensor.

It turns out these motion sensors just dont work below 3v or so. They have an onboard voltage regulator for the 3.3v that they need to work so you really must power them with 5v to get them going. There is some talk on teh intertubes that you can just short across the regulator on the board. I think those instructions were written before they switched to all surface mount parts on these boards which makes it much more difficult. I did try doing that though and it did work then at 3.3v quite well.


you can see my tiny little wire loop across the voltage regulator. Unfortunately at about 3v and lower it stops behaving at all which means that 2AA batteries are not going to power it for very long. And it also stops behaving above 4.5v which means that 4 batteries are a no go. The ATTiny has a good range of voltages in this area which makes it excellent for a long term battery operated product but the xBee is very sensitive to voltages above 3.3 volts. I wouldn't want to run it on 3 batteries without a regulator. Which means that would require a regulator which would waste a lot power and significantly reduce battery life.

I've looked around quite a bit, and there are some excellent canned solutions to motion sensing out there, including some fantastic chip/sensor combinations from Zilog (who also offer an SMT version of the Z80 CPU chip which somehow I find funny :) but they use too much current and still dont operate at a low enough voltage for a good battery operated project.

So we're left with separate power supplies for the sensor and the xBee or regulators or rolling it from scratch. I might experiment with a 3AA battery system where the sensor runs with it's regulator off 3 batteries and see what the current usage is and tap just 2 of the batteries to power the xBee. They will run down out of sync but that might still work and 3 batteries in the device isn't out of the question. Or it really might be time to start studying how these sensors work and roll one from scratch. The otherwise quite good except in radio range and reliability X10 motion sensors work for years on 2AAA batteries. I've glanced at their insides and I think they do a op amp comparitor thing between the 2 outputs of the motion sensor and then have a tiny PIC to make decisions on the output.

At least I understand why the newer ZWave motion sensors are so expensive and why the battery life in them sucks so badly overall.

But all this does mean that without the motion sensor the combination of an ATTiny and an xBee radio work great. So other sensors should be a piece of cake, something like a door/window contact closure device that might also sample temperature and light levels on a regular basis should be quite possible. I might concentrate on that for the moment and stew over the motion sensor problems a little longer.

Sunday, June 16, 2013

Arduino, xBee and PWM lighting with XTension

Back on Halloween Ben and I built him a gigantic lightup inflatable pumpkin costume that was a great deal of fun. In addition to the el wire face on it we also built him an electric t-shirt with LED strips attached to an arduino, some buttons for lighting effects and a little 12v battery pack to power them.

You can see them there under his costume, at night they put on a great show, flickering and fading in and out and flashing brightly when he pushed the button that let them accentuate his awesomeness while trick-or-treating.  We used these cool white LED strips from adafruit.com. After halloween I removed them from the t-shirt and saved them for future projects. A future project revealed itself shortly thereafter in the form of aquarium lighting for his new fish tank. We didn't do any fancy remote control or PWM on them for version 1. We just taped 2 of the 4 little strips to some shelf support material I had and powered them from a generic 12v wall wort.

They worked great for a while, but the constant splashing of water on them and the metal bars soon took it's toll. I think that the power supply may have been a bit high too for they rather quickly started to degrade and individual LED's started to go dim. Even so they lasted several months, but finally died and it was time to rebuild. We had 2 more strips left over from the costume and this time we decided to do it right. PWM to control the levels so it could be dimmed, an xBee radio so that it could be wired into the Home Automation System and some buttons so he could set the level there. I had just finished an arduino interface for XTension and so decided that this should be a demo project on how to bring some of these things together. 

Here you can see how far the old LED strips degraded. The metal shelf support is rusty, the LED strips have gone opaque and you can see where some coper was exposed and turned bright green.


Yuck... This time I would build something with proper heat sinking and proper protection from the elements. I used a  piece of aluminum extrusion U channel as the base for them. It's available at HD and others as a shelf support. It's meant to go over the long edge of a plywood or particle board shelf to keep it from bowing in the middle. It wasn't quite the perfect size for 2 LED strips, they were a tight fit, but I added some extra adhesive behind them as well. 


Also you can see one of the bezel pieces. I printed those on the MakerBot out of translucent PLA. They are actually less translucent that I had though and I might replace them with just cut pieces of plastic soon, but they work for now to protect the lights from the water.

For the Arduino I went with a Fio. I'm not using the lipoly battery charging ability of it, just the fact that it's an arduino with an xBee socket built in. Both running at 3.3v so no other circuitry is required. Or so it seemed... The LED strips need to run at 12v, the Fio is rated at 12v input and initially booted and started up OK, when I had it wired in circuit and applied 12v the regulator on the board burst into bright flame or arcing or something. I removed the power with some alacrity thinking I had cooked the arduino and probably the xBee as well. Testing from USB power though showed them both to be just fine. Now thats impressive, a piece of gear that can actually catch fire and not break down! So instead of relying on the on board regulator I added a beefier external 3.3v regulator. That also released it's magic smoke upon startup. So at this point I took a step back and reviewed the rest of my wiring. Had I wired the mosfet backwards and was putting 12v into one of the input pins or something? Nope, everything looked good. So I broke out an anyvolt micro adjustable regulator and hooked that up instead. Adjusted it's output down to 3.3v and all was well. I guess 3.3v linear regulators just dont like an input as high as 12v. There are many dc/dc converters on the market now, and anyvolt also make a 3.3v version, but the adjustable was what I had on hand. Connecting that to the 3.3v input and bypassing the internal regulator completely brought it all happily back to life.



The mosfet in the picture makes PWM'ing high loads so very easy, no external parts required, not even a resister. This particular model is an N-channel power mosfet and I wired it according to adafruits excellent examples that are linked to from that store entry. Thats actually the same one that powered ben's halloween costume so it's still got some lumps of hot glue attached.  A $1.25 saved is a $1.25 earned ;) You can also see the LED strips powered up and running behind their makerbotted water protection. The plastic strips are just hot glued gently on top of the aluminum channel. I want to be able to replace them when they get a scuzzy from being in the water.


I mounted all three devices into a tiny plastic parts case with a hole drilled through the top/bottom for the xBee antenna. If you were using a lower output one with a chip antenna then even that wouldn't be necessary. 


The buttons in their final install position on the fish tank. Not very pretty, this end of the project will likely get a reworking.

The arduino interface for XTEnsion just provides a simple text based interface for sending values back and forth. basically just address=value with a return at the end. It can be extended of course ;) but for this that wasn't necessary. I opted to make the buttons and the light totally separate in the device itself, requiring the intervention of the computer in order to send back the light level in response to a button push. This means that you can't control the light if the computer if offline, but if the computer is offline I've got bigger problems than the fish tank lights. So in this code the buttons just send an ON when they are pushed (and no off, though I could do that easily enough if it's useful) and then the computer responds by sending a level for the lamp. There is a heartbeat delay between pushing a button and the response coming back, but this way I can set the levels in the computer without having to recompile the arduino code, or without having to write a lot of code to save the levels into the eeprom. So there are other solutions if you like that. You could also build this without any remote computer in the mix at all by just setting the lamp PWM value in the processButtons() handler. But this is an example of how to write arduino code that talks to XTension.


This is how the units are setup in XTension. The buttons receive the commands send from the arduino like:
  Serial.println( "button1=on");

and if you change the aquarium light units level it ends up sending a command like "LAMP=160"

XTension will also convert the address to be all caps, so keep that in mind in your arduino when comparing strings. In the code you'll see some commented out map commands as I was going to map the standard dim level in XTension, 0%=100% onto the range of PWM outputs available on the arduino, 0-255, but decided not to, just let us control it from here. In experimenting with it we discovered that 160 was plenty bright for the fish and the plants and struck a nice comprimise between light and heat output. Any more than that and the light bar started to border on hot rather than just warm. I want to keep these LED's for a long time so we are not going to let them overheat. And a value of just 4 is bright enough on the dim setting for Ben to use as a nightlight. It really does look like moonlight at that level and is quite pretty.

The computer control is important separate from the button control so that the lights can be turned on remotely when we are on vacation, or if he fails to turn them on in the morning. Since feeding the fish and turning on the light is part of his morning ritual he rarely forgets. But now I know when he last turned the lights on, and if it doesn't happen I can turn the lights on automatically and send me an alert so that I can feed the fish if he forgets. He's 8 and is really very good at taking care of them, but it does happen. 

Since the arduino has plenty of inputs and outputs available we have plenty of room available for future expansion. I think a water temperature sensor is in the near future, that will be easy. Perhaps some UV or deep blue LED's to make his fluorescent fish light up at night too. We're also starting to think about an automatic feeder that we would design and print on the makerbot and control from this same arduino.

Setting up xBee radios to work with XTension needs an entry of it's own as well. That will come shortly. Here is the source code free and open use it as you wish. download the arduino project

/*

  Ben's aquarium light 
  
  using an xBee to talk to XTension

  June 10 2013  james@sentman.com
  
  In this example, the 3 buttons send their ON to XTension when they are pushed, and XTension replies
  with the proper change to the light level. They do not directly control the level of the lamp.
  the lamp is only controlled from XTension by way of scripting from the button units.

*/


//input and output pin definitions
const int lampPin = 3;
const int upButton = 8;
const int midButton = 7;
const int downButton = 12;
const int ledPin = 13;

//these globals are used by the serial interface for talking to and getting commands
//from XTension via the Arduino interface. All commands are sent as NAME=value pairs with a 
//carriage return at the end. Set your buffer sizes to be at least as big as the longest command
//you expect to receive. These are oversized as only a single value is sent.

const int commandBufferSize = 19;
const int valueBufferSize = 22;
char commandBuffer[ commandBufferSize + 1];
int commandBufferIndex = 0;
char valueBuffer[ valueBufferSize + 1];
int valueBufferIndex = 0;
boolean gotCommand = false;


//debounce necessities
unsigned long lastButtonMillis = 0;
unsigned long currentMillis = 0;
int currentButtonPushed = -1;




void setup(){
  
 //make sure xBee is set to same serial speed. Could use faster of course 
 Serial.begin( 9600);

 //set the pinmodes for in or out as appropriate
 pinMode( lampPin, OUTPUT);
 pinMode( upButton, INPUT);
 pinMode( midButton, INPUT);
 pinMode( downButton, INPUT);
 pinMode( ledPin, OUTPUT); 
 //turnon the pullup resisters
 //to simplify the wiring I'm using internal pullup resisters for the buttons
 //that way I only have to connect them to ground.
 digitalWrite( upButton, HIGH);
 digitalWrite( midButton, HIGH);
 digitalWrite( downButton, HIGH);
 //make sure we startup off 
 analogWrite( lampPin, 0);
 //could always save the current value of the light to the eeprom 
 //and retrieve it at startup so that a power outage for a few seconds 
 //wouldn't result in the light being off.
 //give the led a flash
 digitalWrite( ledPin, HIGH);
 delay( 500);
 digitalWrite( ledPin, LOW);
 //write to XTension that the system is ready.
 Serial.println( "log=Aquarium Ready");

 //and update it's unit so that it knows that it's not on
 Serial.println( "LAMP=0");
  
  
  
}


void loop(){
  
   //currentMillis is used in the button processing in several places
   //so instead of constantly calling to millis() just do it once and put it
   //in this variable.
   currentMillis = millis();
   //check the serial buffer for any waiting command data and process it
   //if there is any
   processSerialCommands();
  
   //check for any button state changes
   processButtons(); 

  
  
}

/*
  this is part of the Arduino interface to XTension
  it can easily be reused in future projects.
  this just manages the command and value buffers and reading of data
  from the port. Any actual received commands will be passed to the next
  processCommand() method. Add any other incoming value handlers or special
  commands there. This handler shoulnd't need to be changed for most things
*/

void processSerialCommands(){
   int workByte;
  
    //if no data available then just return, nothing to do this cycle through loop
    if (Serial.available() == 0){
     return;
    }
   //read a byte
   workByte = Serial.read();

   //since all data is sent and received as name=value pairs
   //initial data is added to the command buffer. When a 61 or "=" is recieved
   //we finalize the end of the commandBuffer with a nul and start adding future characters
   //to the value buffer.
   if (workByte == 61){
      commandBuffer[ commandBufferIndex] = 0;
      commandBufferIndex = 0;
      gotCommand = true;
      return;
   }
   
   
   //this is looking for the carriage return at the end of the command line
   //if it finds the return then it finalizes the value buffer with a nul and 
   //resets the buffer indexes to get them all ready for the next command
   // and finally passes the most recently received command=value pair to the process command
   if (workByte == 13){
     valueBuffer[ valueBufferIndex]=0;
     valueBufferIndex = 0;
     commandBufferIndex = 0;
     gotCommand = false;
     processCommand();
     return;
   }
   
   
   //if we haven't finalized the command yet (or address as it's now called in XTension)
   //then we add the byte to the commandBuffer and increment the index to wait for the next one
  if (!gotCommand){
    commandBuffer[ commandBufferIndex] = workByte;
    commandBufferIndex++;
    
    //make sure that we dont overrun the buffer though and reset it if we're receiving garbage
    if (commandBufferIndex > commandBufferSize + 1){
      commandBufferIndex = 0;
      return;
    }
    
  } else {
    
    //we've already got the command because gotCommand has been set to true by the
    //check above for a 61 value or "="
    //so now add instead to the value buffer, increment it's counter and continue
    valueBuffer[ valueBufferIndex] = workByte;
    valueBufferIndex++;
    
    //make sure that the value buffer doesn't overflow and if so then
    //reset both the command and value buffer due to garbage on the line.
    if (valueBufferIndex > valueBufferSize + 1){
      commandBufferIndex = 0;
      valueBufferIndex = 0;
      return;
    }
  }
  
}

//XTENSION here is where you will receive incoming commands use the string objects to manage your response
//  add as many addresses as you need.

void processCommand(){
  String theCommand = String( commandBuffer);
  String theValue = String( valueBuffer);
  
  if (theCommand == "LAMP"){
    
    if (theValue == "on"){
      setLampLevel( 100);
    } else if (theValue == "off"){
      setLampLevel( 0);
    } else {
      setLampLevel( theValue.toInt());
    }
    
    return;
  }
  
  //add as many more comparisons for theCommmand as you need to for your application
  //XTension will always send address=value pairs if it's a change to a unit, though
  //any data may be sent with the "send data" verb including commands that have no value
  //though in that case you should still send the = and then immediately the return. like
  //reboot=/13 do not omit the equal sign.
}


void setLampLevel( int newLevel){
 //int adjustedLevel;
 //level from XTension is 0 to 100, map it so that we never go to all on 
 //adjustedLevel = map(newLevel, 0, 100, 0, 210); //keep it from going all on as that burns out the LED's
 //Serial.print( "log=level is ");
 //Serial.println( adjustedLevel);
 analogWrite( lampPin, newLevel);
  
  
}


void processButtons(){
  boolean debounceTimeout;
  
  if ((currentMillis - lastButtonMillis) > 100){
    debounceTimeout = true;
  } else {
    debounceTimeout = false;
  }
  
  
  if (digitalRead( upButton) == LOW){
    //upbutton is pushed
    if ((debounceTimeout) && (currentButtonPushed != upButton)){
      currentButtonPushed = upButton;
      lastButtonMillis = currentMillis;
      Serial.println( "button1=on");
      return;
    }
  } else if (currentButtonPushed == upButton){
      //the button is up but the last button pushed was ours so we can reset it
      if (debounceTimeout){
        lastButtonMillis = currentMillis;
        currentButtonPushed = -1;
      }
  }

    
 if (digitalRead( midButton) == LOW){
    //midButton is pushed
    if ((debounceTimeout) && (currentButtonPushed != midButton)){
      currentButtonPushed = midButton;
      lastButtonMillis = currentMillis;
      Serial.println( "button2=on");
      return;
    }
  } else if (currentButtonPushed == midButton){
      //the button is up but the last button pushed was ours so we can reset it
      if (debounceTimeout){
        lastButtonMillis = currentMillis;
        currentButtonPushed = -1;
      }
    }
    
  if (digitalRead( downButton) == LOW){
    //upbutton is pushed
    if ((debounceTimeout) && (currentButtonPushed != downButton)){
      currentButtonPushed = downButton;
      lastButtonMillis = currentMillis;
      Serial.println( "button3=on");
      return;
    }
  } else if (currentButtonPushed == downButton){
      //the button is up but the last button pushed was ours so we can reset it
      if (debounceTimeout){
        lastButtonMillis = currentMillis;
        currentButtonPushed = -1;
      }
  }
}

Wednesday, May 22, 2013

xBee Motion Sensor testing

I've been meaning to do some battery tests with these things for a long time. An xBee can sleep at nearly no power use until it gets a wakeup signal. I'm not sure what the power usage of the PIR sensor is, but we'll find out.

In full on mode it works fine, but that will run the battery down fairly quickly. I'd like to set a periodic wakeup once an hour or so to just report in battery voltage or at least to give a ping that it's still there and of course it needs to wakeup whenever the PIR fires.

So now off to study the sleep settings.


Tuesday, May 21, 2013

Thermostat Prototype Stage

This is a continuation of work started in part one

I've finished a usable version of the firmware and have gone ahead and installed the prototype thermostat. It's ugly as sin with all it's interconnects and it's enormous makerbotted case, but it's working. It has a much longer cycle time than the old thermostat which was really short cycling. I'm not sure if I like it better like this or the old way. I think that to be completely accurate it's going to need to anticipate the temperature drop or rise and actually cut out before it reaches the goal temperature. I think the array that I use to average several temp readings over time will need to be adjustable in size too.



There you can see the various parts, the LCD display in back with it's IC2 backpack both from adafruit.com, the diavolino board from evilmadscience.com is my favorite arduino platform for such things, and you can't beat the price either if you're willing to do a little soldering. To the right are the xBee for comm and below that the temp/humidity sensor. That one is the parallax board purchased from adafruit and I'm not wedded to that form factor though I suppose the pins on it would make it easier to include it on a custom board. the analog board below is working great.

I need to add some fail safe logic in the arduino code that make sure that multiple relays aren't on at the same time, it shouldn't happen, but it will be easy to verify.

All the wiring is such a mess, it needs to be all on one board and this will be my excuse to really learn to use some of the open source schematic and board layout tools. I'm not looking forward to that actually as they all look like a nightmare, though some folks seem to do very good work with them. The diavolino was designed with them so I should be able to learn to use them too. 



There it is installed, looking like a total hack on the wall, but it's a prototype and I've done far worse to the house in the name of science ;) The oregon sensor is for temperature verification. I graph the 2 of them together in the computer to make sure that I'm actually measuring the temperature.

The connection software so that it can get it's info from and send data to XTension is all done. It's a very simple human readable protocol. The thermostat doesn't try to do any scheduling or setback by itself, that will all be handled by scripts in the computer so it's own software isn't concerned with such things as what time it is. The clock display is updated from the computer with a regular update that is only for display. If you dont send a clock update for 2 minutes that display changes to tell you there has been a loss of communications to let you know something is up. So far that hasn't happened, the xBee is working perfectly.

The bottom line in the display there showing the outside temp is just a text line message that can display anything. The computer can send any kind of alert to display there. At the moment I'm only sending the outside temp, but it could show anything useful there. 



The web interface through XTension is working great too. I now have 5 thermostats connected to the computer in 2 separate physical locations. The "Beach" one is at Nana's place near the beach and is connected over the internet. I have 2 wifi thermostats from radiothermostat.com, an omnistat, an aprilair communicating thermostat and until the last lightening storm an RCS RS485 model that I loved sadly it died and is now replaced with a home made one. XTension supports all these kinds now and if anyone wants to use another kind let me know, as long as it has a documented protocol. The latest honeywell wifi thermostats that home depot is carrying now are locked down and they seem to have no interest in interacting with any other systems at all, so dont buy those.


The backlight level is not automatic yet, I just control it from a unit in XTension. So when I go to bed it dims it down and when we get up in the morning it turns it up for easier viewing. I'm also tracking free memory in the arduino and sending that as a unit update. In the above example it's 0 because it's never actually sent a change since the first few minutes. There are a lot of variables and the array of floats to average for temperature so I was concerned that it would stop working after time if I had bugs in the code. With each loop through the main code it checks it's available memory and if it changes it will report it up to XTension. So far doing it's thing for several days now the available memory hasn't changed at all which is a good thing.

So whats next? I dont really like the display, I think that version 2 might have a graphical display for fancier display. I used an expensive temp/humidity module that is very accurate, but I had to make an offset parameter anyway so whats the point, there are much cheaper modules that are easier to use that I will investigate too. 

Since it's going to be an xBee socket the final product will be able to use any of the xBee's out there so you should be able to connect through a zigbee network the way I do or with a "bluetooth bee" directly as a serial port to the computer or via wifi with the wifi bees that can be placed in the same sockets. Though the setup for those will be more complicated.

Wednesday, March 20, 2013

Arduino Thermostat part 1

We took a very close lightning hit here a month ago. I didn't lose anything plugged into the wall, I have good surge protection on each electric panel, but I lost several things connected to long serial cables including my very fancy RS485 serial thermostat from HAI. I've replaced the other components and added surge protection to their long serial lines to prevent future problems from induced current but I've decided to roll my own thermostat.

I've been supporting communicating thermostats in XTension for some years now. There are 4 models that I've implemented the protocols to and there are more lined up should they ever choose to document what those protocols are. (and if you have one, or have a favorite you think should be supported please let me know) so it's not like I have a lack of good thermostats laying around here that I could install. But I'm drawn to dangerous DIY like this.

I've decided that it should not do very much in the thermostat at all. Since it's going to be connected to XTension through an xBee radio link I really have no need of schedules or setbacks or anything, I can do that all in the logic of the computer. Since I've basically disabled that functionality of every thermostat I've ever installed and just run it from the computer anyway it seems like a lot of added complexity in them that I never use. I've been using those xBee radios for some time in lots of projects around the house and they are just awesome. XTension lets you control their pins, or read their analog inputs or use their remote serial ports for just about anything.

This device I"m making wont be a one size fits all for everyone, but then anybody considering doing this should have some info on what they are doing since getting this wrong could potentially ruin your house in the form of frozen pipes or destroy thousands of dollars worth of compressors in your AC or worse. So I'm not going to sell a kit or anything, but it's been interesting me for some time.

Here's the power board completed. It has the connections for the thermostat wiring, 3 solid state relays and the half wave bridge rectifier and smoothing capacitor to make the DC prior to feeding it into the arduino power supply. Since the furnace here is simple, only single stage only 3 are necessary. The fan relay, call for heat and call for cooling.




I debated how to switch the lines to the furnace. I could have used cheap relays, but they use not insignificant power that can cause heating inside the case and false readings (but you can get around this like more commercial thermostats do by putting the relays at the top of the case and the sensor at the bottom and using the heat to create a chimney effect of room air past the sensor making it read actually better) but it can also cause problems with voltage fluctuations causing false readings from analog temp sensors and other things. (this wont be a problem since I've decided to go with a digital temp sensor) Plus you can hear them click and that is just so last decade... The problem is that you're switching AC power, so just a single mosfet isn't going to work. You can use 2 wired in opposite directions to do it or an SCR or any number of other ways, but these SSR's are not expensive (I think I paid around $5 each for them from allelectronics.com) and I had them around. Additionally they provide complete isolation between the logic and the current being switched.

The capacitor is overkill by 3 or 4 times, but it's what I had around and it mostly fit on the board there. There are 2 diodes on the board wired in series. I used what I had, those are fancy fast acting low voltage drop schottky diodes which are totally overkill for this power supply too, but I had a bunch of them left over from switching LED power supply experiments. They are rated for an amp of power which is good, but only for 20 volts, so 2 in series are necessary to safely rectify the 24v from the furnace. I used a simple half wave bridge here because the output from a full wave bridge would have been more DC voltage than the switching regulator I've ordered for the arduino side is rated for on input.

Apart from just following good coding practices when I start writing the code, and making it as simple as possible I will be implementing a ping and response system between this and XTension so I can tell if it goes away or gets hung up. I've done a lot of smaller projects with Arduinos and I know they can run for extended periods without problems. Even so, this being a one off project I need a way to reset the thing automatically if it goes down. My first thought was to use one of the many unused pins on the xBee connected through a transistor to the arduinos reset pin. Then I can reset it from the XTension computer if I lose the ping. Though I am beginning to think a local circuit with some timer or capacitor that needs to be regularly restarted by a pulse from the arduino and will cause a reset if it doesn't get that pulse might be good too. A kind of local watchdog timer too. We shall see what happens.

Shortly I'll be connecting this board to the power from the furnace and measuring the output and making sure that all works even though there is no control logic yet.

Today I'll be putting together the arduino and hopefully the fancy temp/humidity sensor I ordered will arrive and I can begin that side of the project.


Wednesday, May 2, 2012

Metering The Smart Meter: part, the 4th

I’ve made some significant progress in measuring those pulses from the smart meter that I talked about in previous blog entries. The IR remote receiver was a total fail in reliably receiving them as they weren’t modulated that way, or in any way to make their reception reliable or easy to manage. It’s just on/off once for each watt hour used.

So i built a new sensor to velcro over the LED on the meter. This one has just a phototransistor and some resisters, the values of which I failed to record and cannot remember. So i’ll have to sort that back out again before I can make more of them. I did some math to decide what they should be but have cleaned up the lab since then and the notes are gone... Need a notebook rather than scratch paper I think.

I’ll post the software when it’s all working. The problem with a phototransistor is that you have to measure the output on an analog pin. You can’t just get a nice pulse of digital on/off. So that means sampling in a loop and comparing the values. Though that phototransistor is in a black casing which reduces it’s sensitivity to regular light it still changes it’s values significantly when the sun is shining on the meter.

This makes it difficult to just pick 2 readings and call one the ON threshold and the other the OFF threshold for the LED. What I finally did was to save each loops reading into a buffer of an arbitrary size calculated that even for the lowest power use it will always contain samples from on and off. Then I walk that array and take the min/max of the values. Finally I create an ON threshold at a quarter of that difference above the min, and the OFF at a quarter below the max.  These numbers adjust during the day as the light levels change and make sure that it can always tell the difference between an on and an off.

I still get the rare oddball pulse. It’s so reliable in it’s timing that it’s either real coming from the meter or that is the shortest time frame that can be calculated with the arduino that I’m using. I’ve added code to ignore a pulse if the calculated power usage is more than 150 amps. It is possible that this might actually ignore a real peak power usage starting up a large AC unit with a hard start kit on it or something like that, but thats probably an unlikely occurrence that wont change the overall calculations that much.

Once doing that I am now reporting to XTension a value for the last reporting period, at least 5 seconds between reports, the number of pulses counted for a more accurate overall usage than adding the calculated values together and lastly the average power usage for the period and the peak usage for the period. All together making a very nice graph inside XTension.



thats just the AC cycling on and off the other morning. Interesting the compressor profile there where it uses a lot of power initially (though no big startup spike) which drops off and then as it comes up to full operating pressure returns almost to the starting load. Does it every time too.


This one is me cooking dinner the other day and you can see the electric stove elements cycling on and off and the spikes they generated when they first turned on. The graphing software needs some help there calculating the x axis lines ;) Dont know why that is so bad looking, but I never tested it with such a wide range of values.

This reports up to XTension through the serial port of an xBee, the next project will be to get it working with the wifi version of the xBee which I just received a couple of from Digi and will start messing around with shortly. Adding support for those and the traditional xbee radios to XTension really opens up a lot of possibilities. Here’s the Wifi one:



.code { background:#f5f8fa; background-repeat:no-repeat; border: solid #5C7B90; border-width: 1px 1px 1px 20px; color: #000000; font: 13px 'Courier New', Courier, monospace; line-height: 16px; margin: 10px 0 10px 10px; max-height: 200px; min-height: 16px; overflow: auto; padding: 28px 10px 10px; width: 90%; } .code:hover { background-repeat:no-repeat; }