Sunrise / sunset code based on location

rufessor · Post by **rufessor** » Tue Oct 02, 2012 10:47 am

No need for either actually... I calculate solar noon as basically the midpoint of the day (close enough) for the weather package. All it needs is rise and set... the rest happens. As for offset... yeah equatorial works best for corals... given the fact that they need some minimum amount of light.

I guess we could implement a minimum daylight period of say 12 hours and a max of say 15... Then when the distance between rise and set falls below that you just computationally add 1/2 that difference to set and subtract it from rise. Change the signs if its longer than 15... easy if loop- like 4 lines and were done.

That would enable world wide use of actual location and keep tanks alive.

Acclimation is more of a pain... I would guess that its better for people to do this manually (you only do it once after all). Else you need a programmable flag and then a time keeping element and then if it resets or looses power your kinda screwed. I would not advocate an acclimation feature just now.

If were going to do this, i.e. weather function... we should move this to the thread with the entire package published. So far as I can tell, its still bug free=- you have validated the port of the libraries and my handling on time and corrections to and fro from Unix to 2000 etc etc. My system has never had an issue with weather for a few months now. Although I am currently DOWN since one of my new fish decided to splash water all over hell and back and got it onto my dimming module board and shorted it out

So... eventually I will get a new board but most of what needs to be done is pretty simple.

Kurt-
If you seriously interested in putting this weather package into the libraries I can spend a bit of time working with you. Maybe PM me and if lnevo gets roberto's lights he can help test it. I know that the Reef Angel South Africa distribuitor is using the weather package and likes it... so they would help too and have offered to do so if needed.

The code is relatively compact for what it is... I can walk you though it. I have it kinda naturally split up into functions so porting it *may* be palatable but I am unsure as I have little experience here and you obviously have a format you need to stick to. Let me know. I am confident that those using the RA+ would probably try it.

Only issue is there are many options that may need to be delt with... many could be stripped out and simply used to create two or three set up configurations. Then hard coded from something like the wizard. That would be best... but is yet more work.

lnevo · Post by **lnevo** » Tue Oct 02, 2012 7:27 pm

I like the idea of min/max daylight time and adjusting the rise and set evenly...you could it in conjunction with the offset to customize perfectly.

As far as the acclimation schedule, we'd definitely need to store some things in memory, but I think it'd be worthwhile so you could say setup a 30 day schedule to adjust either your schedule or dimming from start to finish...

This is definitely not something doable manually with a controller, unless you are going to upload new code everyday.

As far as mem i think all you'd need to store number of days left in the program. Once it reaches 0, the program is done till you reset. Then you could use number of days remaining and total days in program to apply a percentage to your dimmer or an extra offset to the schedule... Come to think of it, it would be pretty straight forward.

What memory ranges are available for user based code/variables?

As far as rimai's offer... I'll have to pass unless it's a donation or close to it

there's a reason I want to DIY...if I'm gonna spend the cash, I want it my way or I'd just get a ready made unit. Also, id need to invest in the dimming module, my current ports are being used by my moonlights...I do appreciate the offer though. I guess I could always test out with the moonlights..

rufessor · Post by **rufessor** » Thu Oct 04, 2012 12:40 pm

With respect to acclimation... its actually easy to do with a controller... but you would need a simple PMW output percentage menu on the controller... which is of course available. But it just means you acclimate without the fancy stuff. Of course, anyone wishing to write in an acclimation program could do so, I just see lots of issues with power cycles (should they occur). There is essentially no way to account for that short of making it into a 2 headed hydra with a external database feeding it information about how far along its supposed to be. ANyhow, not worth discussing further unless or until Roberto or Kurt decide this should be integrated into the library.

Not trying to sell it, user demand would seemingly do that, and to be honest, so far as I can tell... there is basically none. Aside from your self and one other person (not counting me) i am not honestly aware of anyone running the weather package. Maybe not many dimming set ups actually exist.. maybe I made it to complex, maybe people are scared its not working (not the case, obviously)... who knows. But, I am happy with it and will probably implement the stuff I mentioned prior. If I do, I will post my version of how to do it (code) here so you can look at it. Not real hard

and if you like the idea go ahead and do it... I need a new dimming module and not ordering yet as my funds are tied into another project currently.

lnevo · Post by **lnevo** » Thu Oct 04, 2012 4:24 pm

Just saw someone post on manhattan reefs who is using the weather and sunrise/sunset, so probably more than you think...

As far as acclimation, I will attempt something soon... If I use a variable in memory it would persist in memory I believe...although I think I have a bad battery so I can't really test that. Roberto can you comment on that? Also what variables can I use to store stuff like that? I think it's a good feature...apparently so does Ectotech Marine

rimai · Post by **rimai** » Thu Oct 04, 2012 7:03 pm

Memory settings are stored in non-volatile type. It doesn't get erased.

lnevo · Post by **lnevo** » Thu Oct 04, 2012 7:21 pm

Perfect...I just need a memory location to store the number of days counting down to 0 now to know where we are at. I will start a new thread once I get some code together.

lnevo · Post by **lnevo** » Sun Oct 21, 2012 5:22 pm

I've added a function so I can update the memory locations instead of just keeping the values we learn in memory.

Code: Select all

void SunLocation::SetLightTimes()
{
  byte MinuteOffset=InternalMemory.ActinicOffset_read();

  int onTime=NumMins(InternalMemory.StdLightsOnHour_read(),InternalMemory.StdLightsOnMinute_read());
  int offTime=NumMins(InternalMemory.StdLightsOffHour_read(),InternalMemory.StdLightsOffMinute_read());
  int riseTime=NumMins(m_SunriseHour,m_SunriseMin)+MinuteOffset;
  int setTime=NumMins(m_SunsetHour,m_SunsetMin)-MinuteOffset;

  if (riseTime/60!=onTime/60) InternalMemory.StdLightsOnHour_write(riseTime/60);
  if (riseTime%60!=onTime%60) InternalMemory.StdLightsOnMinute_write(riseTime%60);
  if (setTime/60!=onTime/60) InternalMemory.StdLightsOffHour_write(setTime/60);
  if (setTime%60!=onTime%60) InternalMemory.StdLightsOffMinute_write(setTime%60);
}

I added this function to the CheckAndUpdate() function so it would only be run once and allow me to override if needed.

I'm attaching the new cpp file since I also had to add some includes for InternalMemory and NumMins to work. Let me know if any questions. So far this class has been working great and no issues.

jerkyjunky · Post by **jerkyjunky** » Fri Nov 16, 2012 2:17 pm

Looking over this code, it doesn't look like it plays well with DST. Am I right? Looks pretty good though, when I first saw the thread I thought you would be syncing info off a website. Was shocked to see it computes it!

Have to try to make it work for my setup!

lnevo · Post by **lnevo** » Fri Nov 16, 2012 4:04 pm

Twice a year, you will need to sync your reefangel regardless...the computations won't be affected...

Let me know if you have any questions.

rufessor · Post by **rufessor** » Mon Nov 19, 2012 3:55 pm

So far as I can see you have not implemented any day light savings algorithim in your code. Therefore since the Arduino now() function is without regard to DST rules- there is no need to sync your controller, ever- at least not to correct for the arbitrary rules of DST in the USA. The arduino processor (in fact I believe all processors) do not use DST or any artifical constructs for time. It is very strictly the elapsed seconds since 1970 or in some processors since 2000- period. Thus, they can be thought of as running on "GMT" time, in that they all *think* they are basically set to GMT time - which is why the code you grabbed is working. I had spent a lot of time trying to implement DST rules, but two things happened. When people around the world started to try it, I had to flag it to be optional since many regions do NOT even use any correction at all, and for sure no one follows the USA rules but for the USA and maybe a few other places on the globe, so its a huge mess.

Second, if your calculating rise and set based upon geometry of the planetary system as we are, there is absolutely no effect in using DST, in fact you need to cancel out the DST change before you even send the time to the algorithm... so

No need to sync controller, unless you wrote in a DST correction routine in your own PDE I am nearly certain that the reef angel libraries have no such function that is generally implemented. Controller time is simply local time in the units of unix time (seconds since 1970).

With respect to using the straight unix time (seconds since 1970) to feed the algorithm you really should be correcting to year 2000 elapsed seconds as it does in fact result in an introduced error to use the 1970 date as the start date for those calculations. Its minor, but you will get better results using the real Y2K elapsed seconds, so if in bundling this to a library distribution that got left out- it should be restored. Was not clear to me what finally was decided.

I will be posting code to account for the desire to ahve a minimum and maximum lights on period and correct the true rise and set times to account for that (during the solstice region depending on your location) so that the lights are actually on for a minimum period every day, or not on longer than a max period. I am hard coding it to avoid variables... Pretty simple, should have somehting up soon. I have not been developing for many months as I had been working on other projects but finished them and its back to reef angel for a while.

lnevo · Post by **lnevo** » Mon Nov 19, 2012 4:25 pm

You are correct. There is no code or any modification for DST...simply resend your controller time when you adjust your other "normal" clocks...it's one click from the portal

As far as y2k...it's your code I modified. The only issue that came up regarding that was reverting the newday variable back to normal 1970 based epoch. However after the calculation with this code newday is never used again, so it's irrelevant...I forget how I left it..

I'm curious to see how you do the minimum light per day as I may use that to implement my coral acclimation schedule...

you'll like it when it's done...I promise

rufessor · Post by **rufessor** » Mon Nov 19, 2012 5:37 pm

I am very happy to see you running with this! And to find others also interested in what your doing.

In terms of minimum day length its not going to be fancy but it brings up a question I was pondering.

of the following options... what do you think is best (please any one reading this chime it)

NOTE... this is an example not a suggested light period for coral... just math.

Assume this is the calculated rise and set time

rise 6:45 am
set 5:10 pm

which yields roughly 10 hours of light but you want 14 hour for your coral so you need to add 4

a) split it evenly and the tank lights up at 4:45 am and sets at 7:10 pm

b) Add it all to the end of the day so the tank lights on at 6:45 am and sets at 9:10 pm

c) make up some distribution function that splits it to fulfill a light period you program in.
e.g. say create two variables E and L that sum to 1.0
Then the distribution could be weighted according to your preference, e.g. if your a morning person you set E to 0.7 and L to 0.3 and the math is such that 0.7*4=2.8 hours is the offset subtracted from the calculated rise time and the remaining time (4-2.8=1.2) 1.2 hours is added to the set point.

Option C is tunable to personal preference which makes sense and is no more work to code (all of these are completely trivial 30 minute projects)

Thoughts?

lnevo · Post by **lnevo** » Mon Nov 19, 2012 5:58 pm

Well i currently switched my code to use internal memory for my light functions which allow me to see the calculated times in the portal but also allow me to modify then ad-hoc if i want to. I like that flexibility... Anyway to facilitate this i am also using the portal variable actinic offset to start my blues before and after my whites... I say if you are going to stretch/shorten the time window do it evenly with one variable to make it easier, if you want to finer tune we already have rise and set offsets to play with and i think most people who are hard coding the times will be adjusting other light with hard coded variables a well...

Just my opinion..

rufessor · Post by **rufessor** » Tue Nov 20, 2012 9:06 am

I agree- sort of....

I guess its really a matter of where you live or what coords you choose to use for your location. I am in Salt Lake City UT currently and sunset is 5 pm rise is just barely 6 am. So, two things are going on for me. My tank is getting 11 hours of light without offsets... and I only extend the blues or UV with offsets as I choose to have the white light follow the sun and because I really want to run this and forget it, and if I add offsets to the whites, in July the sun is rising at 5 or something and setting after 9 so now the tank is "naturally" getting 17 hours of light which is enough to cause bleaching (I know this cause I have been through a summer). So if I run offsets to fix the winter light cycle I bake the tank in the summer.

So- since I don't want to have to reload and edit a program, its supposed to do this on its own- its the reason I even started to write this... hands off running is the goal. Thus, no offsets will be edited manually to fix this maybe I could edit the ChOffset array instead of editing the rise and set times.... I had written most of the code to do it by asymmetrically shifting the day to conform to a minimum length and I am almost done with the other half of the code- I decided to actually reduce set point intensity as a function of the percent over a max day length.... so if your 10% longer than a desired max, your intensity is reduced by 10% for the day... but I need to look up the intensity v.s. PWM current curve and see what it looks like.

I can see editing the ChOffset array evenly (or asymmetrically) to add light across all channels.... maybe that would work fine for the winter, but I would rather see the tank rise and set with the sun in the summer, otherwise the whole point of working on this to get the Lat/Lon coordinate based rise and set times is basically useless cause It would be edited out for a very large portion of the year for me... so I would rather play with intensity to counteract the summer bleaching I was seeing (I edited intensity down manually when I noticed it but have been thinking about this for a while).

I will post the code I wrote on the .INO forum for my code... you can look at it at least to see what I was doing. I may look into internal memory but do not use the portal just now, but I am not using those locations for anything else so I might as well write to them if for no other reason than to have the capability to grab it later. Less interested in editing them from the portal but I suppose I could use that to turn on the lights at night if I needed to.

More thoughts?

rufessor · Post by **rufessor** » Tue Dec 11, 2012 1:37 pm

posted code that I will be running this evening... on my thread. If your interested it compensates for day length variation throughout the year to get even PAR over the tank... *I think*

Oh... if your really bored... can you look at the calculation of fracInt in the first bit (its a float) to see if you think this will work and then the last for loop in Insolation... concerned (maybe unsure is better term) that I may have a truncation issue in the math

lnevo · Post by **lnevo** » Wed Dec 12, 2012 1:41 pm

I will look at integrating the minimum daylight time into the code, but I'm currently not doing anything with intensity or PWM so it will be difficult for conversion into the smaller codeset. It would be nice if we could abstract it and maybe would be helpful if you can use the class code published to make the coordination easier. For instance, we don't have any insolation. From jerkeyjunky, who was using this code, there are some more functions and things we can make accessible from the class, so that might even make your code easier to abstract. I need to make some time to look at it...

On another note, the current code uses GBR as a default timezone. Here are some results throughout the year when I compiled the sunrsie/sunset code into a standalone UNIX executable...

Jan 21, 2013 5:59 18:57
Feb 21, 2013 6:14 18:47
Mar 21, 2013 6:21 18:27
Apr 21, 2013 6:27 18:04
May 21, 2013 6:35 17:51
Jun 21, 2013 6:45 17:52
Jul 21, 2013 6:46 18:01
Aug 21, 2013 6:32 18:09
Sep 21, 2013 6:08 18:13
Oct 21, 2013 5:45 18:18
Nov 21, 2013 5:34 18:32
Dec 21, 2013 5:41 18:49

In December, the longest day of the year for Southern Hemisphere, there are 13hours 8 minutes of daylight.
In June, the shortest day of the year for the Southern Hemisphere, there are 11hours 7 minutes of daylight.

So with GBR we are only getting a 2 hour swing vs Utah's 6 hour swing....

Overall, I do like the idea of setting a desired day length and adjusting it so that you don't adjust too much and I think it may be a handy way to deal with my planned coral acclimation code when I ever get around to writing it..

rufessor · Post by **rufessor** » Mon Dec 17, 2012 1:50 pm

Which code class... when I wrote this none of this was being done in this way so i kinda went off in a corner and started it avoiding any conflict with anything that had existed previously... if its now being used in a wider way I have not been made aware of this asside from the short conversation above- which appears to have been left hanging... nor have I really looked at the library in quite a while.

lnevo · Post by **lnevo** » Mon Dec 17, 2012 2:34 pm

Binder turned it into a class, thats the code I'm currently on and plan to support as a standalone. I thought it was this thread. When i get a chance I'll update this post with the link.

It's not yet in the libraries, not sure if it will be or not..

binder · Post by **binder** » Mon Dec 17, 2012 3:45 pm

it is in this thread. it starts on page 5 at the bottom with my first version of it. the lnevo updated a few bugs on page 6 & 7. so flip back to those pages and snag the code in use.

lnevo · Post by **lnevo** » Wed Dec 26, 2012 2:43 pm

So I had to make some modifications to the class to support my Coral Acclimation code...

The reason for this may be that I'm having some issues on Linux and for some reason larger ints or maybe because they are signed were not working properly. I had a similar issue with the WaterLevel sensor....

Anyway, for the acclimation, I'm setting a memory location with the number of days. Each day at midnight I decrease the acclimation countdown. Now in using the SunLocation class, I moved the SetOffset function from my setup() function to inside the loop() function, right before we calculate the days' rise and set times.

So, now I can set the variable I'm using from the wifi which will decrease 4 minutes per day in the AM and 2 minutes per day in the PM. So if I start with a 30 day schedule, I'm making the sunrise 2 hours later, and sunset 1 hour earlier. Each day the counter is dropped one until it reaches 0, and the schedule is modified nice and smoothly. Using the memory location ensures that if the controller is reset, it will pick up in the same spot. The variable is published to the portal so I can monitor it remotely. The same principle can be used to reduce the dimming percentage if you have a dimmable fixture.

Here's the code I used:

in defines.

Code: Select all

int riseOffset=472; // these numbers were calculated to correct errors I saw in the overall calculations. 
int setOffset=506; // these numbers were calculated to correct errors I saw in the overall calculations. 
byte acclTime=0;
SunLocation sl;
#define Mem_B_AcclTime    102

in loop().

Code: Select all

    acclTime=InternalMemory.read( Mem_B_AcclTime );
    ReefAngel.CustomVar[4]=acclTime;
    if (acclTime > 0) { 
      if ( (hour()==0) && (minute()==0) && (second()==0)) {
        acclTime--;
        InternalMemory.write( Mem_B_AcclTime, acclTime );
      } 
    }

    sl.SetOffset(-9,riseOffset+(acclTime*240),-9,setOffset-(acclTime*120)); // 9 hour difference
    sl.CheckAndUpdate();

Here's the current class files I am using now.

lnevo · Post by **lnevo** » Thu Dec 27, 2012 8:30 am

Ok, my daily decrease on the counter executed 4 times in the one second that I am doing the check so it went from 15 to 11 last night.

I need a better way to trigger the daily countdown... roberto do you have any recommendations for that? I don't want to have to make a flag variable that it's set and unset...

rimai · Post by **rimai** » Thu Dec 27, 2012 9:53 am

This won't work:

Code: Select all

      if ( (hour()==0) && (minute()==0) && (second()==0)) {
        acclTime--;
        InternalMemory.write( Mem_B_AcclTime, acclTime );
      }

The controller executes this more than once per second.
You will need to have a boolean variable to control it so it only does it once.
Something like this:

Code: Select all

      static boolean acclCounterReady=false;
      if ( acclCounterReady && now()%86400==0) {
        acclTime--;
        acclCounterReady=false;
        InternalMemory.write( Mem_B_AcclTime, acclTime );
      } 
     if ( now()%86400!=0 ) acclCounterReady=true;

lnevo · Post by **lnevo** » Thu Dec 27, 2012 11:41 am

Thanks, was hoping there was a trick and not having to use another variable, but that's fine. I'm ok with what works

lnevo · Post by **lnevo** » Fri Dec 28, 2012 7:04 pm

Ok, I did some updating to the SunLocation class. I cleaned up a little bit in CalSun() and also wrote some functions to return the actual time_t of rise/set for those that would rather work with that variable type. I also added 2 functions that would allow someone to pass in a time_t variable for another day (say like tomorrow...) and get the rise/set time_t back.

So we now have the following functions:

Code: Select all

        inline unsigned long GetSunRise() { return m_rise; }
        inline unsigned long GetSunSet() { return m_set; }

        char CalcSunRise(unsigned long *when);
        char CalcSunSet(unsigned long *when);

So if you want the rise time in a time_t format you can do this:

Code: Select all

time_t rise=sl.GetSunRise();

If you would like to get the sunrise for tomorrow...you could do the following:

Code: Select all

   //Get time of midnight, add 1 day, then run it through the sunrise calc
   time_t timeTemp = now(), timeTomorrow;
   timeTomorrow = timeTemp-(timeTemp%SECS_PER_DAY)+SECS_PER_DAY; 
   sl.CalcSunRise(&timeTomorrow);

I have not tested these new functions, but they should work fine. If anyone wants to test these, please let me know the results.

I also added a boolean to UseMemory which is currently the default. This will update the Memory fields for Standard Lights and respect the ActinicOffset variable as well so you can view and modify the calculated results on the portal / phone apps. If you are using the memory fields for something else or you would prefer not to update these fields, you can disable memory, just like the RF module.

Code: Select all

sl.UseMemory=false;

Please let me know if you have any issues with this version. For now I've done all the modifications I plan on, unless someone comes up with more.

I would like to thank rufessor for everything he contributed to get the base for this class and binder for objectifying it for us. I think this is a very nice piece of code which can easily integrate into your PDE with very little modification and with great ease of use.

Thanks,
Lee

lnevo · Post by **lnevo** » Fri Dec 28, 2012 7:05 pm

Here is the latest code with the additions mentioned above. At this point, it should be feature complete and has been running for a while with no issues.

Installation: Just unzip the attached zip file into your libraries folder. To use in your code all you need to do is the following:

Code: Select all

// Add to includes
#include <SunLocation.h>

// Declare the object
SunLocation sl;

// In loop()
sl.CheckAndUpdate();

If you want to change the default coordinates from GBR:

Code: Select all

// In setup
sl.Init(latitude, longitude) // In decimal numbers (i.e. -18.285833, 147.699722)

If you want to set your offsets:

Code: Select all

sl.SetOffset(-9,0,-9,0); // rise_hour, rise_seconds, set_hour, set_seconds

If you use the default memory locations, you just need to declare the port for your Standard and Actinic lights as follows and the times will be set automatically

Code: Select all

ReefAngel.StandardLights( Port1 );
ReefAngel.ActinicLights( Port2 );

If you are hard coding or using the variables for other functions you can get the calculated results with the following functions

Code: Select all

sl.GetRiseHour();
sl.GetRiseMinute();
sl.GetSetHour();
sl.GetSetMinute();

Any questions on usage or improvements, feel free to discuss

binder · Post by **binder** » Sat Dec 29, 2012 8:24 am

Nice write up. Seems pretty straight forward. Good job!

TanksNStuff · Post by **TanksNStuff** » Thu Jan 03, 2013 10:15 am

Wow, great job with this everyone! I've been periodically checking this thread and waiting for a complete working package that I can add the code to my RA+ (in lieu of the dimming module as rufessor first designed this to do)... mostly so I can monitor and/or control it via the android app instead of just having it work independently of the RA+ controller.

It seems like with this new class created (with the combined effort of rufessor, Lee, and Curt, and obviously the necessary work from Mike Rice)... that the sun rise/set function will be very easy to include and customize into your custom code.

However, I've been using the parabola function for my LED on/off/dimming and using internal memory locs and offsets... and I'm very happy with how that's working as is. Sure, it's a continuous pattern every day, but it seems to be working for me and my tank.

What I'm really hoping to get out of all of your hard work is a simplified way to include the weather functions in my main code (which will likely depend upon the SunLocation class code) so that I can have random/automatic clouds and lightning affects that happen (based on seasonal averages for tropical climates or a preset % chance.) I'd also really like to be able to demo them (on-demand) via the android app if at all possible.

Given that this part is complete, would anyone be able to help me with the simplest way to add the weather functions too? I think Curt mentioned that he might be able to add the weather function as a separate class at some point too. Any idea if/when that might happen?

Thanks for all the hard work everyone! I really love this community.

binder · Post by **binder** » Thu Jan 03, 2013 12:19 pm

TanksNStuff wrote:Wow, great job with this everyone! I've been periodically checking this thread and waiting for a complete working package that I can add the code to my RA+ (in lieu of the dimming module as rufessor first designed this to do)... mostly so I can monitor and/or control it via the android app instead of just having it work independently of the RA+ controller.

It seems like with this new class created (with the combined effort of rufessor, Lee, and Curt, and obviously the necessary work from Mike Rice)... that the sun rise/set function will be very easy to include and customize into your custom code.

However, I've been using the parabola function for my LED on/off/dimming and using internal memory locs and offsets... and I'm very happy with how that's working as is. Sure, it's a continuous pattern every day, but it seems to be working for me and my tank.

What I'm really hoping to get out of all of your hard work is a simplified way to include the weather functions in my main code (which will likely depend upon the SunLocation class code) so that I can have random/automatic clouds and lightning affects that happen (based on seasonal averages for tropical climates or a preset % chance.) I'd also really like to be able to demo them (on-demand) via the android app if at all possible.

Given that this part is complete, would anyone be able to help me with the simplest way to add the weather functions too? I think Curt mentioned that he might be able to add the weather function as a separate class at some point too. Any idea if/when that might happen?

Thanks for all the hard work everyone! I really love this community.

Triggering from the app could be simple. The idea I would think of would be based on a memory location value. Then depending on the value, you can trigger different effects. ie. 1- thunderstorm, 2- clouds, etc

I can help with turning functions into an easily included class. Here is what I will need from you:

start a new topic/thread
list of the functions that you would use (or a list of all the weather functions)
any configurations that you would need or use for the functions. ie, cloud percent chance, days in a month or days in the range for not repeating or whatever (i have no idea here. i'm just guessing and making up stuff).

This is by no means all of things needed but it's a start. Oh and lastly, you would need to be willing to test things for me to make sure it's functioning like it is supposed to. I will obviously test that the logic and code compiles but I will need help with the fine tuned stuff (and i don't have lights that can do that stuff here). I know this sounds like a lot but it really isn't and i'm sure you will have no problems getting this stuff. Just let me know.

lnevo · Post by **lnevo** » Thu Jan 03, 2013 12:47 pm

Definitely should start a new thread. The ONLY thing that the Sunrise/Sunset code does is calculate time of day for Sunrise and Sunset based on location. It has no functionality as-is to do any cloud or storm effects. Would be great to see this as a class, I saw some simple code that was done for cloud affects in another PDE (jedimasterben's) that should be easy enough to encapsulate, but that doesn't do storms, etc.

This code is mean to enhance your current parabola calls by using the calculated rise/set for the parameters that go into your function. Anything else has to be done somewhere else

lnevo · Post by **lnevo** » Thu Jan 03, 2013 1:10 pm

Curt,

Here's the original thread with the cloud/storm/weather functions. http://forum.reefangel.com/viewtopic.php?f=14&t=288

I don't think much needs to be modified here except that currently the triggers are all based on #defines. I wouldn't mind seeing this turned into a class though, similar to what we have here, but the usage would be the tricky part.

I think roberto's code for this is pretty straight forward. I think all Tank's needs to do is have the way to trigger the effect.

Lee

Reef Angel Forum