Must-haves for EASY DIY controller?

[TheFishMan65]

Does the time chip we used have any nonvolatile RAM. IMHO NVR would be the best place to store user setting. Second place would be EEPROM, but NVR tend to have easier access. They make some that go on the IIC bus.

Start up is always the issue. I was going to write everything so it comes on in a safe mode. Lights would default to on. They might get a full 24 hours of light (if the glitch happens just after the off time), but would it matter for a day? Or wire it off and your power failure might have a really cloudy day go through. I guess the question (oh no more personal choice) what things really matter if they are left on on skipped for a day?

 

[terahz]

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?

In the firmware I'm using, all state is stored in EEPROM and read on boot. We can do the same with the alarms, but as you said, if the power comes back after the lights were supposed to be on, then the user will manually have to turn the lights on.

EDIT: Just get a $10 SLA 12V battery, that will run the hydra for quite a while

 

[ludnix]

Couldn't there be a listener of sorts that just checks if the time is inbetween the user set interval and corrects the relay settings to reflect current time. It seems like if this is a function in a the loop it wouldn't matter if the power went out or if the user changed the controller's time.

 

[TheFishMan65]

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.

#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)
    ;
}

 

[DustinB]

I'm going to go over all the advice given and the possible solutions over the holiday weekend and see what I can come up with. I'll have to wait til I can dig more into the time library, but I may just end up writing my own library or modifying this one to include support for power outages. I'm not sure this library suits the task at hand the best. Seems like a lot of fluff for something that should be relatively simple.

Might be best to get an example sketch going with the basic of what we've talked about and go from there.

 

[terahz]

Why don't we just add an on/off button on the remote for the lights? The pumps are wired on the normally closed loop of the relays so they will turn on by default. I don't see what else could require recovery after power resumes.

 

[TheFishMan65]

I tend to agree with terahz, and everybody could probably survive a day of darkness..

 

[DustinB]

The guitar center relay strip that a few of us are using is N/O only.

 

[der_wille_zur_macht]

I think it's worth noting that we basically have two control methods for state information:

1) Some things we'll be turning on/off based on time (lights)
2) Other things we'll be turning on/off based on conditions (i.e. turn a pump off if a float switch returns a certain value).

I don't think we need to be concerned about maintaining state for items in the second category as they will "sort themselves out" when power is restored.

 

[TheFishMan65]

+1

I asked the same thing earlier, "I guess the question (oh no more personal choice) what things really matter if they are left on on skipped for a day? "

So far lights

 

[der_wille_zur_macht]

See though, this is where I think we have to be very explicit in exactly how the controller functions.

Imagine if we write a generic scheduler that we model around turning lights on and off at certain times of the day. We don't think it's crucial that lights recover "properly" from a power outage, so we don't code anything to handle that. Or, we assume it's best practice to have the lights recover "on" or "off."

Now, someone comes along, and says "oh, a scheduler function! I'll use that to control my dosing pumps and automatic water change! And I'll use it to shut off my circulation pumps for 10 minutes every day when I feed!" If they don't correctly understand how this equipment will recover from a power outage, things could get ugly.

I guess my point is we should try to code the function to behave safely, and we should be very careful to explain that behavior.

 

[DustinB]

Exactly, the scheduler isn't(IMO) just for lights. I for one was planning on using it to control dosing.

The way I look at it is this is a custom controller with custom code. We shouldn't even have to think about "settling" for most things, especially lights off for a day.

 

[terahz]

The guitar center relay strip that a few of us are using is N/O only.

So you have to keep the relays energized all the time? What happens when you restart your controller, all your pumps and lights turn off until the system boots?

Regarding the recovery, I'm fine with whatever is decided. As long as we document what happens after power is restored, everyone can decide for themselves if they should schedule a given function.

Also, I don't see how is dosing concerned with recovery after power outage. I'm sure none of you want their controller to dump 3 days worth of CA, ALK and MG after a 2.5 day power outage?

For me, the best recovery after power outage is no recovery. That is, the controller does not try to fix anything on its own and everything is initialized in its default state, just like it is upon start. That + the ability to manually override the current state of an event (turn pump on/off, lights on/off, add a 1 time 1 minute dosing event etc.) should be more than enough to handle a power outage.

 

[DustinB]

Correct, if the controller restarts, everything restarts. I have a custom delay in my sketch to start the skimmer after a certain delay in order to allow the sump water level to drop, return and powerheads come on right after boot.

What I meant by recovery was a way to parse which actions are scheduled. As it stands now, if power is lost the scheduled events disappear right? I was suggesting focusing on a way to store these events in EEPROM such as index, start time, stop time; then have the scheduler continue to check for these events. In the case of the lights, simply check for the lights start/stop times, compare to current time, then act appropriately.

This way I don't see a possibility of having days worth of anything dosed. Everything should resume when power restores and everything will happen normally, other than things that should have happened while power was off of course. You may miss a scheduled dose or only get half a dose depending on when and how long the power was off, which IMO is perfectly acceptable.

I think we are roughly on the same page, I wasn't suggesting to try and correct for anything that was missed, just bring us back to current operating status.

 

[terahz]

Dustin, I wouldn't do the relays the way you have them. You put the life of your tank in the hands of the controller. If the controller crashes/dies/burns etc, you can potentially kill all power to your tank.
Don't forget that some of the components on the Hydra are rated for quite short life (like 1000 hours at 85C) which is something else I wanted to talk about...


Scheduling: That makes complete sense. I definitely misunderstood the point. What you are describing must be part of the controller anyway, I never thought that we'll have to reset all events every time the controller restarts so that's why I didn't realize you are talking about that.

The EEPROM is probably the best place to store the state. In my firmware I have generic write/read templated methods that can store anything, so in theory we can make the timelarms library store the entire struct in EEPROM and read it when the constructor is called as long as we have space.

For a moment I thought you guys want the controller to "make up" for the down time

BTW, Happy Thanks Giving to everyone! Thanks to all that have contributed to the project and DWZM especially for starting it!

 

[5ft24]

If power is lost, can the code check to see the state of the outputs, and if they don't match what they should be in that time frame, toggle them?
Also, to keep the time set, maybe a small routine on the 2nd arduino that sets the RTC via NNTP over ethernet??? Have the time zone set as a variable stored in the sketch...
Just random brain farts here LOL

Happy thanksgiving!

 

[der_wille_zur_macht]

Also, to keep the time set, maybe a small routine on the 2nd arduino that sets the RTC via NNTP over ethernet??? Have the time zone set as a variable stored in the sketch...
!

The RTC has a backup battery. The only time it needs setting is when you first build the hardware. After that, the only time you'd need to adjust would be if the backup battery dies (not likely, the size we're using should provide years of power-off memory retention) or if you move to a different timezone.

 

[DustinB]

That is something that had crossed my mind, the rather short life of some of the components. We could start looking at caps rated to 10k hours.

I know what you mean about the relays, it is really disappointing not having the option of N/C. I'd rather have it N/O considering the heater than the other way around. As far as the coils go in the strip, given the small 12v load, I don't see those failing. The question is, what is a possible solution to a board failure under these conditions?

Would it be best to upgrade components and hope for the best? Create some sort of monitoring board? Try to modify the relay strip with SS relays?

I know ideally you want the return and/or powerheads to be running all the time either off the relay control or through a N/C failsafe, but I really want to keep my feeding mode button!

 

[der_wille_zur_macht]

Since we're building a relay control board anyways, it should be easy to build into that board an option to invert the function of the relay. Of course this wouldn't work if the relay breakout board failed but it would work if the hydra failed.

 

[der_wille_zur_macht]

Speaking of component life, I'm guessing you guys are talking about the electrolytic capacitors. I did some research back when I was working on the first DIY LED driver and my fears were calmed for a few reasons:

1) The lifetimes are usually specified at some arbitrary high temperature. I've seen an often repeated rule of thumb that you get double the lifetime for every 10 degrees C below that nominal temperature. So if a cap is rated for 1000 hours at 85 C and we're running at 45 C then we'd see 16,000 hours lifetime.
2) The lifetimes are specified under some nominal ripple current, which is likely not as bad as the caps are seeing on our board.
3) The lifetimes also typically are specified until a certain drop in capacitance, not until failure. Most of the electrolytics on the board are bigger than they need to be so this shouldn't be an issue.

So yeah, we can and should probably spec better components anyways, but in the end I'm not terribly worried about it.