Show Posts
Pages: 1 ... 46 47 [48] 49 50 ... 64
706  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'
707  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.
708  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.
709  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.
710  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.
711  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);
  }
712  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
713  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 02:24:05 pm
I threw this one together and modify it as necessary to try various items.

Code:
#include <Time.h>
#include <TimeAlarms.h>

AlarmID_t morningAlarmID=99, afternoonAlarmID=99, eveningAlarmID=99;
AlarmID_t tuesdayAlarmID=99, wednesdayAlarmID=99, thursdayAlarmID=99,
          fridayAlarmID=99, saturdayAlarmID=99, sundayAlarmID=99;
char buf[100];

void setup()
{
  Serial.begin(57600);
  Serial.println("Initializing...");
  delay(2000);
  setTime(0,0,0,1,1,1971);
//  morningAlarmID   = Alarm.alarmRepeat(8,30,0, onAlarm);
//  afternoonAlarmID = Alarm.alarmRepeat(13,25,0,onAlarm);
//  eveningAlarmID   = Alarm.alarmRepeat(17,45,0,onAlarm);
//  tuesdayAlarmID   = Alarm.alarmRepeat(dowTuesday,17,45,0,onAlarm);
//  wednesdayAlarmID = Alarm.alarmRepeat(dowWednesday,17,45,0,onAlarm);
//  thursdayAlarmID = Alarm.alarmRepeat(dowThursday,17,45,0,onAlarm);
//  fridayAlarmID    = Alarm.alarmRepeat(dowFriday,17,45,0,onAlarm);
//  sundayAlarmID    = Alarm.alarmRepeat(dowSunday,17,45,0,onAlarm);
  saturdayAlarmID  = Alarm.alarmRepeat(dowSaturday,17,45,0,onAlarm);
  pinMode(13, OUTPUT);     
  Serial.println("Begin test...");
}

void onAlarm()
{
  // alarm callback function
  AlarmId id = Alarm.getTriggeredAlarmId();
  time_t tnow = now();

  if (id == tuesdayAlarmID){
    if(weekday(tnow) != dowTuesday || hour(tnow) != 17 || minute(tnow) != 45){
      showMe("Tuesday error", tnow);
    }
    else{
 //     showMe("Tuesday OK", tnow);
    }
  }
  if (id == wednesdayAlarmID){
    if(weekday(tnow) != dowWednesday || hour(tnow) != 17 || minute(tnow) != 45){
 //     showMe("Wednesday error", tnow);
    }
     else{
//      showMe("Wednesday OK", tnow);
    }
 }
  if (id == thursdayAlarmID){
    if(weekday(tnow) != dowThursday || hour(tnow) != 17 || minute(tnow) != 45){
      showMe("Thursday error", tnow);
    }
    else{
//      showMe("Thursday OK", tnow);
    }
  }
  if (id == fridayAlarmID){
     if(weekday(tnow) != dowFriday || hour(tnow) != 17 || minute(tnow) != 45){
      showMe("Friday error", tnow);
    }
    else{
 //     showMe("Friday OK", tnow);
    }
  }
  if (id == saturdayAlarmID){
    if(weekday(tnow) != dowSaturday || hour(tnow) != 17 || minute(tnow) != 45){
      showMe("Saturday error", tnow);
    }
    else{
      showMe("Saturday OK", tnow);
    }
  }
  if (id == sundayAlarmID){
    if(weekday(tnow) != dowSunday || hour(tnow) != 17 || minute(tnow) != 45){
      showMe("Sunday error", tnow);
    }
    else{
//      showMe("Sunday OK", tnow);
    }
  }
  if (id >= dtNBR_ALARMS){
    showMe("Creepy ID", tnow);
  }
  if (id == dtINVALID_ALARM_ID) {
    showMe("Invalid Alarm ID", tnow);
  }
}

void showMe(char* type, time_t tnow){
  sprintf(buf,"%s alarm %s, %d:%d:%d %d/%d/%d",type,dayStr(weekday(tnow)),
       hour(tnow),minute(tnow),second(tnow),month(tnow),day(tnow),year(tnow));
  Serial.println(buf);
}


int savedMonth = 0;
int savedDay = 0;

void loop()
{
  if(savedDay != day()){  //just to let me know it's alive
    savedDay = day();
    digitalWrite(13, digitalRead(13)==HIGH?LOW:HIGH);   // flip the led
  }
  if(savedMonth != month()){  // how far it's gotten
    savedMonth = month();
    sprintf(buf,"Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),day(),month(),year());
    Serial.println(buf);
  }

  Alarm.delay(0);
  adjustTime(55);
//  sprintf(buf,"Time %d:%d:%d %d/%d/%d", hour(),minute(),second(),day(),month(),year());
//  Serial.println(buf);
 
}
714  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 01:00:45 pm
That's actually a pretty good question, but like you said one is easy from the other.  So, it would be a teeny bit better to return the remaining number IMHO.  This is not a hard and fast recommendation at all, just a guess.  Perhaps it would be better to name it something like countersleft, remaining, not used or something.  Count implies used and blows my argument about using the remaining number.

flip a coin???

Just to help you understand how I and one neighbor use the timers dynamically.  He has a drip watering system that senses the moisture level in the soil a couple of inches below grade.  When it gets dry enough, he turns on the drips, but he wants to limit how long they run because he doesn't want to drain the water tank and have the wives (I share the tank, he's not Mormon) mad because they can't make iced tea.  So he turns on the drip and sets a timer for 1 hour from now to turn it off then sets another timer to check tomorrow for dryness.  You can't sample the tank because it's buried up to the very top to keep it from getting hot.  Maybe an ultra sonic from the lid, but that's another project.  But meanwhile, the little arduino is doing a ton of other stuff of a similar nature.  The ability to set a timer then just forget about it until it fires leaving the arduino free to do something else makes really cool control systems easy.  There's hardware out there that is so complex that you really can't predict what it will do next so, you check it; an alarm that fires daily and then decides when to fire again based on the data is really useful.  I don't have a clue why people don't do more of this.  Heck a standing light that turns on when a coyote comes in range of the chicken coop then sets a timer to turn off in five minutes is dynamic, multiply that times one light at each corner and you start to see something of the situation.  Of course, you want the lights independent, it confused the coyotes more.

Oh, so far, the testing has been working perfectly.  I still have a few things to try out, but it has stepped through a few years of daily alarms with them all firing at the right time.  I have not checked to see if any of them have missed, just that when they fire they fire on time.  More later.  And don't worry, if you change something and it needs to be tried, I'll crank up the little piece of code I'm using and do it again.

Besides, I have a vested interest in this because I use this library a lot for drip watering, pool control, blinking lights, etc.  The arduino makes an incredible timer when you need one. 
715  Topics / Home Automation and Networked Objects / Re: Measuring phase angle and power on: July 02, 2011, 11:47:24 am
Just a quick interjection that might (maybe) help you avoid a problem.  I tried solid state relays for a high current project, a water heater controller.  It was a 240V thing that was optoisolated.  Worked great, got hot.  It had to have a heat sink and airflow to keep cool enough to touch and couldn't be mounted in a box outside where I live (desert) because the ambient temperature and afternoon sun would destroy it.  I switched to an old fashioned contactor controlled by a little bitty relay off a 5V digital pin.  This was because an A/C contactor was easily available and ran off 24VAC.  It runs nice and cool and has been cycling now for over two years.  At first the noise was offensive, now its comforting because I know it's working.

Now, I know it may have been the particular device I got stuck with and your mileage may vary, but keep this in mind when choosing the device.  In my case, old school worked best.
716  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 11:34:38 am
I want my count function.  Of course, it doesn't need to be called count, but for me and others that will do something similar I think it will be useful.

C'mon, trying to set a timer and having it fail because you have dynamic code that can't track of how many are used kinda sucks.  if you create a timer and it returns BAD, what do you do?  Hang up in a loop until one comes free to the exclusion of draining the septic tank?  The count function could be tied to a bell that rings because you added one too many timers and overdid it.  It would also be useful to measure how loaded your device is becoming.

With the clear, reset, whatever routine one could keep assigning timers until one ran out and then clear them all out to get the count, but that's the only way outside the library to tell how many are currently being used.  That seems a little silly when it is so easy to do in the library.  Looking at the index value doesn't meet with the idea of libraries controlling their data, otherwise, once could just get the id and start poking at the alarm itself.

How many of us have implemented something to tell us how close we've gotten to the end of memory because our arrays and such have put us a hundred bytes from oblivion.  Heck, if you're using streams you can run out and have exactly zero indication that there's a problem except for the burst of garbage on the serial output as you over write the stack.

If vicnet hadn't put in the free, he would have wanted a count, especially if he couldn't use the id as an index indicator.

You see, I envision a controller with sixty or seventy timers or alarms.  They check on devices periodically, take actions, then retry in a few seconds if it didn't happen, measure ph in the pool and time HCl injectors over a period of days, pan cameras toward the neighbor lady that sunbathes in the afternoon on Tuesdays when the sun is out.  It would be very bad if that alarm failed because it ran out.
717  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 10:34:03 am
vicnet, your modules update worked, at least so far.  Saturday no longer fires every time through the loop.  I'll run some tests now that include saturday and such to see how it goes.
718  Development / Other Software Development / Re: bug in the timealarm library on: July 02, 2011, 10:22:34 am
vicnet, I'll be glad to give your pieces a try.  Get to it in a bit.

mem, first, let me bring up that the usefulness of daily alarms is huge.  I'm not sure why people aren't using the heck out of them and why this particular problem hasn't cropped up before except in my case where I reset the daily alarm each time the previous one triggered.  But household timers: alarm clocks, thermostats, pool controllers, chicken feeders, light controllers, etc all want daily alarms.  So, given that, I think a small change of philosophy is a good thing.  

And, frankly, it doesn't make much sense to me to set a daily alarm in any fashion other than alarmRepeat( everyDarnMonday, 10:00AM,etc)
because that reads well in the code except in the instances where the daily time is calculated.  In my experience there are extremely few instances where a daily time is calculated, sensors for sunrise, sunset, ph, drainage valves etc, prevail.

Net, having to use the calls with the day of week to set a daily alarm is not a problem, and not being able to use time_t shouldn't bother anyone.  I can't imagine how one would use that reasonably anyway.

Also, I don't see a problem having to set the time before using the alarms.  It's one silly call with easy to type parameters and one already has to have the time library included.  No big deal.
719  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 10:27:03 pm
OK, testing again.  Daily alarms seem to work except for Saturday

the call  - saturdayAlarmID  = Alarm.alarmRepeat(dowSaturday,17,45,0,onAlarm);  will fire every time through the loop.  I have all the latest changes in place.  The next time you post a change, try to put the entire module in the box, my editing can cause errors.

There are a lot more tests to run though.  I haven't tried jumping by hours to see how far it will run and I haven't made sure it doesn't miss any.  Additionally, tests on a future date, like Feb 4, 2013 need to be tested.  However, right now the saturday thing is messing me up.
720  Development / Other Software Development / Re: bug in the timealarm library on: July 01, 2011, 08:16:13 pm
I think I have the source mixed up somehow.  Regrouping.....
Pages: 1 ... 46 47 [48] 49 50 ... 64