Show Posts
Pages: 1 ... 46 47 [48] 49 50 ... 64
706  Using Arduino / Project Guidance / Re: Advice on Refrigerator Controller on: July 14, 2011, 07:16:06 pm
Thanks for the snippet, I didn't think of using state variables.  And, I was going to try exactly what you described for the freezer, glad you did it for me.  It never occurred to me that it would use more energy to suck the temperature down, however it did occur to me that opening the freezer during the peak period (to get a frozen fudge bar) could blow the entire experiment.  I think a little ice ballast might be a good idea though.

Any ideas on which transformer I could use for powering the devices?  I have limited wall plugs behind the appliances.
707  Using Arduino / Project Guidance / Advice on Refrigerator Controller on: July 14, 2011, 12:53:58 pm
I've been threatening to do this for several months and now I'm getting started.  I want to control my fridge during peak power usage.   I live out in the country so I have separate fridge and freezer (two different appliances) The shortcomings are:

It will run the compressor during peak periods
The stupid defrost timer on the freezer sometimes kicks on during peak periods
Both appliances kick on at the same time

My peak demand period is from noon to 7PM so, the defroster firing during that period is just silly, but I can't change the darn thing.  Setting them up such that they can't be on at the same time during peak period shouldn't cause any significant problems with temperature, and if it does, a backup temperature sensor that lets it run anyway shouldn't be too hard.

I already have an XBee network in the house and know how to work them so communication isn't a problem and I'm familiar with controlling power so I have no concerns there.  The idea is to measure the power actually used by the appliance and transmit it over the XBee network as well as grab the time of day from the same network.  I also have the total house power usage available on the XBee network so I can even shut them down during high loads if that becomes an option.  This thing could also monitor the internal temp of the appliances and alert me if they get too warm.

Where I would like y'all's help is in choosing a couple of transformers.  I will need two of them.  One is to actually supply power to the devices I add, and the other is to supply a voltage reference for power measurement.  They have to be separate devices because sucking current from the transformer affects the voltage measurement and closing a relay will do that (experience talking here).  I'd like this thing to be small with a plug on one end for 110V (US standard) and a socket on the other to plug the appliance into.  There should be a couple of relay outputs to hook the compressor and maybe something else into as well.

I just can't seem to get past the way they rate the transformers.  I'm stumbling around through the various choices on digi and mouser and it's a bit overwhelming.  The voltage sense transformer can be very low voltage and current since I'm only grabbing enough to measure the voltage, but the power supply one should be big enough to power an Ardweeny (the processor board I want to use for this) and a couple of relays with a low power XBee module for comm. 

I know there are tons of people on this board that can solve this kind of problem in seconds.

708  Topics / Home Automation and Networked Objects / Re: Xboard-Wireless Home Automation solution on: July 12, 2011, 12:26:17 pm
Correct me if I got the wrong impression.  What you've done is combine a mega328 with a wiz5100 on the same board that has an XBee socket.  Right?

And you're selling this for U$29?

This thing could be the perfect solution for people that want an arduino webserver without paying around $70 for just the ethernet board and arduino combination and have a XBee socket to play with for fun.  Or even an arduino with an XBee socket and still save $10 bucks or so.  Is there a proto board that will match it for separate circuitry to hold sensors and relays and such?
709  Development / Other Software Development / Re: Which GCC + avr-libc + arduino for mega2560 actually works? on: July 11, 2011, 01:33:10 pm
Actually, I don't know what the versions are internal to the IDE.  What I did was download iDE 21 and just use it on a windows machine.  It has worked pretty reliably in creating code that actually runs.  There were a couple of things that wouldn't compile early in my experimenting with it, but I've forgotten the details and I found work arounds pretty easily.  I've been afraid to experiment too much because of the problems other folk have reported with various changes.  Basically, I've got something that seems to work most of the time and I'm afraid to change it.

However, if you move this thread to the Installation and Troubleshooting area, it might (maybe) get more attention.  However, I can't prove that since my thread on the bootloader has been essentially ignored by the developers.  Also, if you need numbers from what I'm running, let me know what to look for and I'll get them for you.  However, I'm using windows so it may not be any help for you.
710  Development / Other Software Development / Re: Which GCC + avr-libc + arduino for mega2560 actually works? on: July 11, 2011, 11:35:40 am
Actually, I'm beginning to regret my 2560 board as well.  I have not had any trouble compiling.  Everything I try seems to work just fine using arduino IDE 21.  However, getting it on the board is an exercise in anger management.  Add to that the fact that simple changes to the watchdog timer code that were discovered and created years ago are not in the 2560 bootloader.

I realize that bugs happen and that sometimes it's a painful process to get fixes in place, but it's approaching a year ago that these shortcoming were discovered and there is nothing being talked about (other than my one little thread) fixing it.  I have indications that the code fixes for both of the items I have problems with have existed for months, MONTHS, and there is nothing out there for me to load on the board.

What the heck? 

Currently, my recommendation to folks is to avoid the entire UNO line and stick with the older or clone stuff.  I'm sure I could have used the previous mega board just fine.  And frankly, I'll wait at least a year before I even try version 1.0
711  Development / Other Software Development / Re: bug in the timealarm library on: July 06, 2011, 07:06:29 pm
I've had it going in a random fashion from a couple of years back to 5 years forward, starting over when it goes past the upper.  Both timers and alarms have been working fine.  I also ran it once to failure in the future and no problem came up.

I suggest publishing it and let other folk play with it as much as they want to.
712  Using Arduino / Installation & Troubleshooting / Re: Mega 2560 bootloader revised? on: July 06, 2011, 10:16:28 am
I promised to keep this thread updated as this progresses.  Just got another note from the developer regarding the bootloader. 

Quote
I will have it done in another week. and it will go into the release.

Not really sure when we'll have a module to load on the board, but we'll see in a week.
713  Development / Other Software Development / Re: bug in the timealarm library on: July 05, 2011, 04:59:07 pm
Oh, nevermind, found it.
714  Development / Other Software Development / Re: bug in the timealarm library on: July 05, 2011, 04:54:31 pm
Uh, kinda make it hard to test

Code:
TimeAlarmsTest.cpp: In function 'void onAlarm()':
TimeAlarmsTest:37: error: 'class TimeAlarmsClass' has no member named 'getTriggeredAlarmId'
TimeAlarmsTest:51: error: 'class TimeAlarmsClass' has no member named 'free'
TimeAlarmsTest.cpp: In function 'void loop()':
TimeAlarmsTest:137: error: 'class TimeAlarmsClass' has no member named 'getNextTrigger'
715  Development / Other Software Development / Re: bug in the timealarm library on: July 04, 2011, 03:29:37 pm
Actually, I've run both.  The tests that exceeded the upper limits were the just before trigger time ones.  I haven't gotten past 2014 on the 55 second tests.   I haven't done any real time testing since it takes so darn long.  I have it running right now in a real device, but the first alarm is not for several hours.  The timers seem to work fine in it though, I have a lot of them running in it.

Regarding complexity, I can't disagree, but it would be sad to lose working changes that other's might need and subsequently have to reinvent.

Y'know, if you were to post a note in the forum under 'project guidance' I bet a bunch of people would chime in for opinions.  Those folks don't seem reluctant to sound off.  However, they can be unkind as well at times.
716  Development / Other Software Development / Re: bug in the timealarm library on: July 04, 2011, 02:34:41 pm
A define to turn them on is a reasonable idea IMHO.  Especially since anyone using very many alarms will be editing the max number anyway.  And, a small number of 'default' capabilities that are available without doing anything is reasonable also.  What I guess I'm asking is not to lose any of the features that have come about because someone needed them.  Sheltering them behind a define is a pretty good idea to keep complications down and not lose any inventiveness that has gone before.  That makes it especially easy for someone, once they get past a certain point in the learning curve, to go augment away.

By the way, I still haven't been able to break it.  The only failure so far was when it rolled over 2106 a couple of times.  I may be putting this latest code in something that is running for real just to push the envelope.
717  Development / Other Software Development / Re: bug in the timealarm library on: July 04, 2011, 12:22:33 pm
Back when I was looking at how to control things around the house I got most of my ideas from devices available at the store.  The more expensive drip water controllers had days of the week and a couple of alarms allotted to each day.  So, a total of 14 alarms that I could program for any start time and duration.  Others had more alarms per day and multiple outputs.  They were all the same type and I couldn't change them to be something else.  The price on these things went from around U$20 for one alarm a day up to well over a hundred for more control.  None of them was remotely programmable nor reported what they were doing.  That's one reason why I started looking for something I could program to do exactly what I want.

I like the simple interface of create it, let it expire and then create another one.  But, that makes it hard to actually use because there is no central place to change it, you have to change the code tor create another one as well.  So, a repeat alarm is good.  Now some folks need to be able to cancel a current one (maybe it rained), but allow it to repeat again day after tomorrow.  Other folks want to do other things that I haven't even suspected were possible.  So, there is probably no end to the possible uses of alarms.  Timers are different in that you set it and it expires and does something.  The idea of a repeat is a good one so the programmer doesn't have to keep resetting it.  The ability to cancel it is good also so failsafe alarms can be created. 

And vicnet has a really good point that he was the one that found the initial problem with the daily alarm.  I would have run into it during a future phase of my work, but I was using a daily alarmOnce and recreating it in the callback because I might not have wanted it to go off next time exactly the same way.  Alarms and timers can be used as program flow control tools as well as turning on relays.  However, this means that few people used AlarmRepeat in a daily fashion and actually tested the code, including me.

This was partly because, at the time I started working on that project, there was practically no mention of TimeAlarm in the playground.  This really surprised me because things like sprinkler timers and Christmas lights would have this as a central component.  Much of the stuff we do around the house for real applications is alarm based.  And, most notably, almost everyone makes an arduino clock as one of their first projects.  I was concerned that the library was out of date and even posted a thread that only got two responses since I could have easily googled for it here.  The responders didn't realize I was trying to make sure that the library was valid and that I had read almost everything on the darn internet about it already. 

Net, the ability to create, modify and delete a daily alarm is necessary.  Additionally, being able to count and list them would make it versatile for people that want to create a sophisticated control system.  For example, if a user wants a menu interface to the alarms they create for something like a sprinkler controller, they will need to know how many there are, when they expire and what kind to put up a nice display.  The guy that did his controller for a dish washer could have easily used this kind of capability.

Please don't misunderstand, I realize that a line has to be drawn somewhere, features can't just be added forever.  But a recurring daily alarm is so darn nice to build into real-life control systems that some complexity is not only warranted, it's downright wonderful.  And, some of us (well, maybe only me) are using these little devices to do real life stuff.  Heck, I'm working on building one into my refrigerator to control it to my tastes instead of what the manufacturer thinks I need. 

So, put the primitive features at the top of the list of capabilities and lower down, the more sophisticated ones.  The people using it will read it and figure out what they need as they build the devices.  Keeping it simple will help the beginner, but people don't stay beginners for very long.  Simple is nice, but we out grow it pretty quickly.

Honestly, I've been keeping myself under control.  Automatic setback thermostats have a weekday vs weekend alarm.  Real expensive ones have holidays built in and are programmable (my power company has these available for a price).  Birthday alarms are really fun.  Monthly alarms are great for paying the power bill.  Odd vs even days make for a nice cycle in some projects.  Alarms that calculate sunrise and sunset are great for outdoor lights.  Should I go on.
718  Development / Other Software Development / Re: bug in the timealarm library on: July 03, 2011, 07:34:40 pm
Well, I can't break it.  I'm still running tests, but nothing I've tried is failing.   All the capabilities I use work fine.  Right now I have about 20 total timers and alarms running from as short as a second to a second less than a day and it just keeps on working.  I intend to run this some more and try some random timers to see there may be something hiding, but looks good.
719  Development / Other Software Development / Re: bug in the timealarm library on: July 03, 2011, 02:06:57 am
OK, I have no life.   I admit it.  However, I put this little bit of code in the test sketch and am running it now.  I'll let this go on and off until something else is ready to test.  I think I can modify this to work with timers too and add them in as well.  An extended run of random timers and alarms with vicnet's trick to speed up time should beat the heck out of the code.  Sure, it isn't perfect, but it'll test it more than a room full of monkeys and typewriters (do they still exist?  typewriters that is).

Code:
if (id == randomAlarmID){
    if(weekday(tnow) != rday || hour(tnow) != rhour ||
         (rmin-1 > minute(tnow) && minute(tnow) > rmin+1)){
      sprintf(buf,"Random Failure, parameters %d, %d, %d, %d ",
              (timeDayOfWeek_t)rday, rhour, rmin, rsec);
      Serial.println(buf);
      showMe("Failed at", tnow);
    }
    else {
     showMe("Random", tnow);
    }
    Alarm.reset(id);           //reset it so I can make it again
    rday = random(1,8);
    rhour = random(0,24);
    rmin = random(0,60);
    rsec = random(0,60);
    randomAlarmID = Alarm.alarmRepeat((timeDayOfWeek_t)rday,rhour,rmin,rsec,onAlarm);
  }
720  Topics / Home Automation and Networked Objects / Re: Measuring phase angle and power on: July 02, 2011, 10:09:05 pm
Some folks don't realize those things actually get hot.  I guess it isn't intuitive because it came as a surprise to me.  To give you some idea, just two days ago I was helping my neighbor spread some asphalt for a new driveway.  We had a lot of trouble because it melted and was sticking to everything, the tires on my tractor were covered with about an inch of the stuff.  We finally gave up and waited until the next morning.  During this process one of the pins from the scraper blade on the tractor fell off and I had to find it.  When I picked it up, it burned my hand and I just popped the blister it raised on my left index finger.  High temperature today, 116F, but it's expected to be cooler tomorrow, around 113F.  By 0900 it was over 100F.  However, you do get used to it, I keep my swimming pool at 94F during the summer so I don't freeze when I get in it.

So, you can see why something that gets hot on its own isn't something that we want to put in a closed metal box outside.  Good old contactors.   In your neck of the woods though, it could have worked fine, even as suggested, mounted to the hot water heater.

But, I don't get much snow, and the girls don't wear much. smiley-red
Pages: 1 ... 46 47 [48] 49 50 ... 64