MA70Snowman
New member
Wow, I get stuck at work for 48 hrs and this board exploads. I can't remember all 2 pages and I had so many posts highlighted for response but I'll hit the big topics off the top of my head.
First off since I keep seeing it thrown around and I didn't get an answer and please forgive the bolds, but i'm totally lost in the sauce
What is ATO? (currently in my line of work it stands for Authority to Operate lol so forgive me when that term is thrown around and I'm going cross eyed.
Umm.. I had addressed this with my sketch. Please look at the void setup () during the initialization of the hydra it will do an INDEPTH check of the alarms to see what the exact state is. After it gets past the initialization it goes into simple mode (has x time passed) So I'm a little miffed that we're still debating this when I've tossed it out there. It's not a hard concept.. power is lost on the hydra, it shuts down.. when power is finally regained, it will automatically default to the state it SHOULD be in given that time of day. This will work for heaters/lights etc. If yo'uve got something that is a measured dosage, don't implement that type of alarm for that I/O pin.
the code is simple, it doesn't account for if your OFF time is before your on time.
For exe. ON TIME: 1700 OFF TIME:0800
your if/else statement will ALWAYS return an OFF. Yes it's all well and good if you have a NORMAL alarm, but we need to account for those instances where users want that functionality, (I.E Moonlight)
It seems there's alot of good ideas for the functionality of the schedualing, and I do feel this should be implemented in the Core code. (or even offloaded to the slave) I'm going to spend some time playing w/ that new library that was addressed.
as far as multiple controls. I think it would be pretty easy to set an array with a number of alarms and call them depending on a variable that corresponds to your port. (Alarm_ON[5] = GPIO5 ) That's ultimately what I will be going for i'm just addressing the general problems, of power outages, and inverted alarms, and time wraping (going from 2359 -001)
I know I'm forgetting somethings. and I apologize if th is comes across scatted, i've been up for 48 hrs and am ready for bed.
First off since I keep seeing it thrown around and I didn't get an answer and please forgive the bolds, but i'm totally lost in the sauce
What is ATO? (currently in my line of work it stands for Authority to Operate lol so forgive me when that term is thrown around and I'm going cross eyed.
PS - I agree, with various combinations of the four included functions, we should be able to cover just about all of the "scheduler" situations described in the last few days. The only problem I can think of is if power goes out - you aren't guaranteed that things will restart in the correct state.
For instance, if you use the alarmRepeat function to turn lights on at 8 AM, and use another instance of it to turn lights off at 5 PM, imagine if your power goes out at noon. When power resumes, the lights will be off (I'm assuming that default status for relay control will be "off").
Actually, this raises a bigger question. How are we storing state information when the power goes out? How are we storing user-configured settings when the power goes out?
Umm.. I had addressed this with my sketch. Please look at the void setup () during the initialization of the hydra it will do an INDEPTH check of the alarms to see what the exact state is. After it gets past the initialization it goes into simple mode (has x time passed) So I'm a little miffed that we're still debating this when I've tossed it out there. It's not a hard concept.. power is lost on the hydra, it shuts down.. when power is finally regained, it will automatically default to the state it SHOULD be in given that time of day. This will work for heaters/lights etc. If yo'uve got something that is a measured dosage, don't implement that type of alarm for that I/O pin.
Then you have a two things controlling the relays your loop and the alarm - it may get awkward for debugging.
This might work rather than have alarms that turn the light on and off. Create a new function that takes the start time and the stop time. It would then create both alarms which use the same function and then calls the procedure to update the lights.
PHP:#define START_TIME 8,30,0 #define STOP_TIME 17,45,0 LightsOnOff(void) { if ((CurrentTime > Start) && (CurrentTime < Stop)) lightson else lightsoff } SetAnOnOffAlarm(StartA, StartB. SarttC, StopA, StopB, StopC, function) { Alarm.alarmRepeat(StartA,StartB,StartC, function); Alarm.alarmRepeat(StopA,StopB,StopC,function); function(); } main { SetAnOnOffAlarm(START_TIME,STOP_TIME,LightsOnOff) while(1) ; }
the code is simple, it doesn't account for if your OFF time is before your on time.
For exe. ON TIME: 1700 OFF TIME:0800
your if/else statement will ALWAYS return an OFF. Yes it's all well and good if you have a NORMAL alarm, but we need to account for those instances where users want that functionality, (I.E Moonlight)
It seems there's alot of good ideas for the functionality of the schedualing, and I do feel this should be implemented in the Core code. (or even offloaded to the slave) I'm going to spend some time playing w/ that new library that was addressed.
as far as multiple controls. I think it would be pretty easy to set an array with a number of alarms and call them depending on a variable that corresponds to your port. (Alarm_ON[5] = GPIO5 ) That's ultimately what I will be going for i'm just addressing the general problems, of power outages, and inverted alarms, and time wraping (going from 2359 -001)
I know I'm forgetting somethings. and I apologize if th is comes across scatted, i've been up for 48 hrs and am ready for bed.