Go Down

Topic: bug in the timealarm library (Read 11 times) previous topic - next topic

viknet

#75
Jul 04, 2011, 09:57 am Last Edit: Jul 04, 2011, 10:03 am by viknet Reason: 1
Quote
Yes, I can see that the new structure could need an enhanced write that takes the dtAlarmPeriod_t but I am not sure how it would actually be used.

Can you explain the use case for changing the tick handler callback?

And also can you explain the use case where the period type would be  changed?


Well I am building a weekly programmer like this one: except having many output and instead of having display and button it will have a serial connection (connected to a wifi computer handling php pages)

Using serial I need to set and reset alarm to the user desire :=) all handler are identical and I have a structure which give me information for each alarmid (which input to turn on or off) which sprinkler to enable for  how long......

beeing able to get/set the periodicity enable me to change on the fly alarm, at this moment I only can free an alarm and create a new one.

In this case I can only determine the id after the creation so if a user want to modify the periodicity of alarmid=3,
I have to free alarmid=3  then create anotherone having all parameter (zones/durations) identical except periodicity and give the new id to the user.

Concerning the handler, beeing able to get/write would enable me to have two different tye of program with different logic behind, some program would be simpleon/off the other sprinkler program, If I need to display the program to the user I need to have access to the handler information. at this moment as said before, all program do the same and the program has a type with a big if at the beginning.

on a different subject, the fact that now weelky and daily cannot be set the same way I had to put something like this:

Code: [Select]
if (day==0)
 Alarm.alarmRepeat(H,M,S,handler);
else
 Alarm.alarmRepeat(day,H,M,S,handler);


when before I was only doing
Code: [Select]
Alarm.alarmRepeat(day,H,M,S,handler);

I made the "if" to test your lib but I am not that happy with it, it leads to unnecessarly cumbersome code. I don't know what would be the best, expose the create function to the outside or check if the day is 0 and then create a daily alarm.

best regards

viknet






mem

Viknet, thanks for the information.

In your application where the user can create or change any alarm type and period on any alarm, I  prefer an approach that rather than allowing any value to be written to any timer, restricting the input to the current alarm type. If the user needs to change the alarm type then he would need to delete the old alarm and create a new one of the required type. This allows some detection if invalid commands are received.

The code is open source so there is nothing stopping you changing your copy of the library to suit your application, but I prefer that the public version provides more error checking capability on changes applied to a timer than you want for your app.

As I mentioned in post #47, the new code differs from the playground version in that it returns an error if time values greater a day are given to the method to create daily alarms.
I think having separate  methods for daily and weekly alarms with error checking if the arguments are out of range is worth the extra if statement that may be needed in a sketch.
I would be interested in hearing views on this point from anyone using the current Timealarm library. I suspect that viknet and draythomp are not typical users and they would have no problem adjusting their code to suit, but I wonder if this would be a problem for others?

Michael

viknet

michael,

I understand your point of view concerning alarms, but if the write(AlarmID_t ID, time_t value) exist then the write(AlarmID_t ID, time_t value,dtAlarmPeriod_t period) needd to exist, I can understand both way of thinking (also I prefer the last),

But beeing able to read/write the periodicity is a must if you can read/write the value, that was my major fear when you proposed the migration.

Of course I understand the fact that this is opensource and I fully understand that what I need is not necessarly what most programmers need (and don't worry If I need to change the lib I will do it),
your call for comment is the good way of doing it, but seeing that that I was the fisrt to discover the bug concerning Dow, I think that there is not that much people using this feature.
maybe your request for comment, need to be open in another to gain visibility.

regards

Viknet


best regards
 

mem

Viknet, rest assured that you will be able to have the functionality you need even if its not in the playground version.

I am keen to keep the playground version  simple and safe. But I recognise that there are useful capabilities for testing or specialist applications that go beyond this scope and  you may have noticed that the alpha code I posted here yesterday had the write, read, readType,  free, count and getNextTrigger as private methods unless a #define was used to expose them.
My intention is to hide all of those functions in the standard distribution and discourage their use with sketches that are indented for public distribution.  I doubt any of these functions are needed for the kinds of applications that the typical arduino user is making.  Experienced  users such as yourself can find the #define to turn these on but I would discourage the publishing of sketches that require these methods as I think its very easy for  inexperienced users to get into trouble  if they play around with this low level alarm logic.
I feel strongly that in the Arduino world its better to provide robust but simple capabilities that address 90% of the likely applications rather than something highly flexible but easy to abuse.
Perhaps there is room for two libraries, one limited to the public methods I have proposed and another with a different name that includes low level functions.
I would be interested to hear comments on this.

Michael

draythomp

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.
Trying to keep my house under control http://www.desert-home.com/

Go Up