Home AMX User Forum AMXForums Archive Threads AMX Applications and Solutions

ASTRO_CLOCK vs. TimeManager, sunrise/set

I'm getting incorrect sunrise and sunset times from the Astro_Clock function. Using TimeManager I get the correct sunrise & sunset times. Both using same timeserver, same latitude & longitude.

Tech support suggests not using Astro_Clock.

I'm curious....anyone else encountered this before?

Thanks
«1

Comments

  • DHawthorneDHawthorne Posts: 4,584
    I've been using i!-TimeManager since it was released, and never even tried ASTRO_CLOCK.
  • truetrue Posts: 307
    The offset is weird.

    To use ASTRO_CLOCK, check when sunrise and sunset are supposed to be, then adjust your offset that you pass to ASTRO_CLOCK to make them match. Offset seems to +16 from local time for us out here (PST/PDT).
  • viningvining Posts: 4,368
    Try this thread if your not confused enough already:

    http://www.amxforums.com/showthread.php?t=6681&highlight=astro
  • Joe HebertJoe Hebert Posts: 2,159
    ASTRO_CLOCK
    Rich Abel wrote: »
    I'm getting incorrect sunrise and sunset times from the Astro_Clock function. Using TimeManager I get the correct sunrise & sunset times. Both using same timeserver, same latitude & longitude.

    Tech support suggests not using Astro_Clock.

    I'm curious....anyone else encountered this before?

    Thanks
    There is nothing wrong with ASTRO_CLOCK. I?ve been using it for years without issue. You?ll have to add an hour if DST is true.

    Are you using the correct value for GMT? For example here in my neck of the woods in the Midwest it?s -6.

    Post your code if you want and we?ll figure out the problem.
    true wrote: »
    The offset is weird.

    To use ASTRO_CLOCK, check when sunrise and sunset are supposed to be, then adjust your offset that you pass to ASTRO_CLOCK to make them match. Offset seems to +16 from local time for us out here (PST/PDT).
    Nothing weird about it, no need to fudge the numbers. The function works correctly. I never heard of a +16 hour offset, you sure it?s not -8? Although rolling over into the next day will get you to the same place timewise.
  • glr-ftiglr-fti Posts: 286
    I agree there is nothing wrong with the ASTRO_CLOCK function but .....

    the question then is how do you know when DST is active? CLock Manger only tells you if you have or have not enabled DST not whether it is ACTIVE.
  • viningvining Posts: 4,368
    There's always this: nTimeMngr_DST = CLKMGR_IS_DAYLIGHTSAVINGS_ON() ;
    CLKMGR_IS_DAYLIGHTSAVINGS_ON
    Returns FALSE/0 or TRUE/1.
    
    The default setting is FALSE/0.
    

    I would assume the DST rules are built it otherwise what's the purpose of this query? But are the rules universal for all that observe it? Hmmm...
  • viningvining Posts: 4,368
    Hmmm, I guess we have to set these values ourself.

    CLKMGR_SET_START_DAYLIGHTSAVINGS_RULE
    CLKMGR_SET_END_DAYLIGHTSAVINGS_RULE
    CLKMGR_SET_DAYLIGHTSAVINGS_MODE
    CLKMGR_SET_DAYLIGHTSAVINGS_OFFSET

    I would assume if you set these astro_clock settings it will return the correct time so you won't need to -+ an hour for DST. You could also just create your own DST flag when DST begins and ends and do the math based on your flag.
  • truetrue Posts: 307
    Joe Hebert wrote: »
    Nothing weird about it, no need to fudge the numbers. The function works correctly. I never heard of a +16 hour offset, you sure it?s not -8? Although rolling over into the next day will get you to the same place timewise.

    We are -8/-7DST. I tried -8 first. Did not function as expected - hour was way off. I had to apply a 16 hour offset from local time (basically, +8/+9DST) in order to get correct values. Time was set and the proper timezone was selected on the master.
  • Joe HebertJoe Hebert Posts: 2,159
    true wrote: »
    We are -8/-7DST. I tried -8 first. Did not function as expected - hour was way off. I had to apply a 16 hour offset from local time (basically, +8/+9DST) in order to get correct values. Time was set and the proper timezone was selected on the master.
    I just tried San Diego California and it works just fine:

    Latitude = 32.72
    Longitude = -117.16
    GMT = -8

    Adding an hour for DST and I get:

    Sunrise = 06:28
    Sunset = 19:11

    You must have something else going on that’s not correct. Are you using DOUBLEs for Lat, Long, and GMT? Is your Longitude negative?

    The time on the master should have nothing to do with the results. It's just a formula. Obviously the date has to be correct.
  • truetrue Posts: 307
    Joe Hebert wrote: »
    You must have something else going on that?s not correct. Are you using DOUBLEs for Lat, Long, and GMT? Is your Longitude negative?
    It is used as specified (so yes, doubles are used) - and yes, longitude is negative. After applying the gross offset, the values are correct.
    Joe Hebert wrote: »
    The time on the master should have nothing to do with the results.
    Thinking about it now, no, it shouldn't. I can't describe why I have this problem, but I don't really care much, since it worked in the end.
  • glr-ftiglr-fti Posts: 286
    So why do I have to waste time dealing with this, whatever this is......to get what other manufacturer's already have written to get a simple correct time and whether sunset or sunrise has occurred and whether DST is active from my control system? Is it Astro_Clock, i! Time Manager, i! Scheduler, Clock Manager? How about a complete document that clearly shows the steps required and what not to replicate?
    What am I missing? Is there a document somewhere I have missed?
  • truetrue Posts: 307
    Re: ASTRO_CLOCK, it's documented in help.
    Re: other stuff, they have some documentation but I don't use them.

    I'll write some sample code with ASTRO_CLOCK() (using clkmgr with an assumed +1h DST offset, although you can pull this from the master too). All you need to do is include this and you'll have working sunrise/sunset.
    /* variables */
    define_variable
    volatile double		ss_coords[2] = {0.0, 0.0}	// set these to target lat/long
    volatile double		ss_gmt_offset
    volatile char		ss_sunrise[8]
    volatile char		ss_sunset[8]
    
    
    /* start */
    define_start
      // use this function to determine if DST is on or not
    if (clkmgr_is_daylightsavings_on()) {
    	// startup code when DST is on goes here
    	wait (200) send_string 0, 'DST is active'
    } else {
    	// startup code when DST is not on goes here
    	wait (200) send_string 0, 'DST is not active'
    }
    
    
    /* mainline */
    define_program
    wait (600) {
    	astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(),
    		LDATE, ss_sunrise, ss_sunset)
    	
    	// send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset"
    	
    	if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) {
    		// code for when sunrise occurs goes here
    		send_string 0, 'SUNRISE OCCURRED'
    	}
    	
    	if (left_string(ss_sunset, 5) == left_string(TIME, 5)) {
    		// code for when sunset occurs goes here
    		send_string 0, 'SUNSET OCCURRED'
    	}
    }
    

    Set ss_coords and ss_gmt_offset. Every minute, ss_sunrise and ss_sunset will be updated, and instructions will be executed depending on if the current time matches.. Check these by debugging to make sure they're right. I haven't tested it. It should work. Point out issues if you see them, please.

    EDIT: fixed obvious bug.
    EDIT 2: As indicated by Joe Hebert below, the DST stuff likely doesn't work properly. I'll update this later with an implementation for you, glr-fti.
  • Joe HebertJoe Hebert Posts: 2,159
    I see your problem true.
    volatile double	ss_gmt_offset 
    

    You need to set the GMT value just like you need to set lat and long. Check out the help file. In your case for the west coast it should be -8. Do that and you should be fine. No fudging needed.
      // use this function to determine if DST is on or not
    if (clkmgr_is_daylightsavings_on()) {
    

    Unless things have changed I believe that will only tell you if DST is observed or not. It doesn?t tell you if it?s active at the moment which is what Gary (glr-fti) is talking about.

    This has been brought up on the forum previously and I sure hope AMX gives us the flag in the future. Or maybe we have it and I just don?t know about it.



    true wrote: »
    Re: ASTRO_CLOCK, it's documented in help.
    Re: other stuff, they have some documentation but I don't use them.

    I'll write some sample code with ASTRO_CLOCK() (using clkmgr with an assumed +1h DST offset, although you can pull this from the master too). All you need to do is include this and you'll have working sunrise/sunset.
    /* variables */
    define_variable
    volatile double		ss_coords[2] = {0.0, 0.0}	// set these to target lat/long
    volatile double		ss_gmt_offset
    volatile char		ss_sunrise[8]
    volatile char		ss_sunset[8]
    
    
    /* start */
    define_start
      // use this function to determine if DST is on or not
    if (clkmgr_is_daylightsavings_on()) {
    	// startup code when DST is on goes here
    	wait (200) send_string 0, 'DST is active'
    } else {
    	// startup code when DST is not on goes here
    	wait (200) send_string 0, 'DST is not active'
    }
    
    
    /* mainline */
    define_program
    wait (600) {
    	astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(),
    		LDATE, ss_sunrise, ss_sunset)
    	
    	// send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset"
    	
    	if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) {
    		// code for when sunrise occurs goes here
    		send_string 0, 'SUNRISE OCCURED'
    	}
    	
    	if (left_string(ss_sunset, 5) == left_string(TIME, 5)) {
    		// code for when sunset occurs goes here
    		send_string 0, 'SUNSET OCCURED'
    	}
    }
    

    Set ss_coords and ss_gmt_offset. Every minute, ss_sunrise and ss_sunset will be updated, and instructions will be executed depending on if the current time matches.. Check these by debugging to make sure they're right. I haven't tested it. It should work. Point out issues if you see them, please.

    EDIT: fixed obvious bug.
  • truetrue Posts: 307
    Joe Hebert wrote: »
    I see your problem true.

    ...(no problem)...

    You need to set the GMT value just like you need to set lat and long. Check out the help file. In your case for the west coast it should be -8. Do that and you should be fine. No fudging needed.
    that isn't my "problem" - I wrote this in 5 minutes from bed as a demo for this guy, and even stated below the code that it needs to be set if this code is to be used. A proper offset was used in my production code. Otherwise, how do you think I figured a +16hour offset to local time?
    Joe Hebert wrote: »
      // use this function to determine if DST is on or not
    if (clkmgr_is_daylightsavings_on()) {
    
    Unless things have changed I believe that will only tell you if DST is observed or not. It doesn?t tell you if it?s active at the moment which is what Gary (glr-fti) is talking about.
    I assumed DST would turn on / off - so the switch is to turn observance on, rather than currently being observed on? I didn't test this thoroughly. That's kind of backwards thinking or bad function naming - especially since documentation for clkmgr stuff is pretty bad. It's something I'll look at closer, thanks. (Which means it's trivial but not simple to get DST being observed now, as you now need to calculate based on current rules...sigh.) I'll probably write a function we can all use (clkmgr_is_currently_dst()?)
  • Joe HebertJoe Hebert Posts: 2,159
    true wrote:
    that isn't my "problem" - I wrote this in 5 minutes from bed as a demo for this guy, and even stated below the code that it needs to be set if this code is to be used.

    Easy there big fella, no need to get your feathers ruffled. :) I read your comments by the variable declarations and missed the part down below.
    true wrote:
    A proper offset was used in my production code. Otherwise, how do you think I figured a +16hour offset to local time?
    The ?proper? offset for the west coast is -8 GMT. It?s easy enough to look up on a time zone map like the one built into Windoze. There is no such thing as +16 GMT. But as I stated before since we?re dealing with a 24 hour clock +16 rolls over into the next day and ends up the same as -8 the next day.

    If I use your code with the correct offset of -8 GMT then I get the correct value for sunrise and sunset.

    ASTRO_CLOCK works fine with the correct values. Nothing weird about it.
    true wrote:
    I assumed DST would turn on / off - so the switch is to turn observance on, rather than currently being observed on?
    Yes, I believe that?s the case. Sucks I know. I hope I?m wrong.

    Peace.
  • truetrue Posts: 307
    Joe Hebert wrote: »
    The ?proper? offset for the west coast is -8 GMT. It?s easy enough to look up on a time zone map like the one built into Windoze. There is no such thing as +16 GMT.
    As I've said a few times now, my offset is +16h from local time, not from GMT. You even quoted me on that. This would be an offset of +8 or +9 passed to the "GMT" parameter for PST or PDT, respectively.
    Joe Hebert wrote: »
    If I use your code with the correct offset of -8 GMT then I get the correct value for sunrise and sunset.
    ASTRO_CLOCK works fine with the correct values. Nothing weird about it.
    I get the wrong value unless I pass +8 or +9. Only had to use ASTRO_CLOCK() once so far (had to do it a lot with C restron customers but never had the request until recently with an AMX customer). I tried it on my NI with the same results. I'll probably be hacking away at stuff this weekend so I'll try to figure out where the bug lies.
  • Joe HebertJoe Hebert Posts: 2,159
    true wrote: »
    As I've said a few times now, my offset is +16h from local time, not from GMT. You even quoted me on that. This would be an offset of +8 or +9 passed to the "GMT" parameter for PST or PDT, respectively.
    The function calls for GMT. GMT for the west coast is negative 8. Forget the whole local time thing.
    true wrote: »
    I get the wrong value unless I pass +8 or +9. Only had to use ASTRO_CLOCK() once so far (had to do it a lot with C restron customers but never had the request until recently with an AMX customer). I tried it on my NI with the same results. I'll probably be hacking away at stuff this weekend so I'll try to figure out where the bug lies.

    Using your code with the correct value for GMT (-8) I get then correct values for sunrise/sunset for San Diego (ignoring the whole DST thing) as shown below:
    define_variable _
    volatile double	ss_coords[2] = {32.72, -117.16}	// set these to target lat/long
    [b]volatile double	ss_gmt_offset = -8[/b]
    volatile char		ss_sunrise[8]
    volatile char		ss_sunset[8]
    
    
    /* start */
    define_start
      // use this function to determine if DST is on or not
    if (clkmgr_is_daylightsavings_on()) {
    	// startup code when DST is on goes here
    	wait (200) send_string 0, 'DST is active'
    } else {
    	// startup code when DST is not on goes here
    	wait (200) send_string 0, 'DST is not active'
    }
    
    
    /* mainline */
    define_program
    wait (600) {
    	astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(),
    		LDATE, ss_sunrise, ss_sunset)
    	
    	send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset"
    	
    	if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) {
    		// code for when sunrise occurs goes here
    		send_string 0, 'SUNRISE OCCURED'
    	}
    	
    	if (left_string(ss_sunset, 5) == left_string(TIME, 5)) {
    		// code for when sunset occurs goes here
    		send_string 0, 'SUNSET OCCURED'
    	}
    }
    
    

    And the output:
    Line     51 :: Sunrise is at 05:25:00; sunset is at 18:15:00 - 01:45:34
    

    There?s no bug in your code or ASTRO_CLOCK. Where?s the problem?
  • Joe HebertJoe Hebert Posts: 2,159
    GMT

    Here is a snapshot showing the value for your GMT true:
  • truetrue Posts: 307
    Joe Hebert wrote: »
    The function calls for GMT. GMT for the west coast is negative 8. Forget the whole local time thing.
    I understand this completely. What I am trying to tell you is that in Pacific Time Zone, I had to pass +8/+9 (which happens to be +16h of local time; it's completely 100% equivalent and means the same exact thing as saying +8/+9GMT) depending on whether daylight savings time is active or not to get the proper values. To clarify, because I'm not sure you're getting it, when I pass -8 in the "GMT" parameter I get values like 22:30 for sunrise. My sun doesn't rise some time just before midnight.

    I don't think you're getting it, and won't really continue - I experienced this offset problem and continue to, others don't, so obviously there is a problem somewhere and as I said, I'll try to figure it out.
    Joe Hebert wrote: »
    codestuff
    I explicitly wrote that I haven't tested this code. Works for you? Great. Maybe my other code has some bug this doesn't, I don't know. I'll test it when I get time but I'm not going to argue with you over semantics (+16h local to PST and +8/+9GMT means the same exact thing! last time I'm writing it!) and try to drive my point yet again when I've written my experience numerous times already.
  • Joe HebertJoe Hebert Posts: 2,159
    true wrote: »
    I understand this completely. What I am trying to tell you is that in Pacific Time Zone, I had to pass +8/+9 (which happens to be +16h of local time; it's completely 100% equivalent and means the same exact thing as saying +8/+9GMT) depending on whether daylight savings time is active or not to get the proper values. To clarify, because I'm not sure you're getting it, when I pass -8 in the "GMT" parameter I get values like 22:30 for sunrise. My sun doesn't rise some time just before midnight.
    I?ve got no desire to get into a wienie war with you true.

    One last time. If you use the correct value for GMT as the function calls for which is -8 for pacific time (as the picture above shows) then you?ll get the correct value.

    I took the time to test your code and showed you the output. Your code is fine, ASTRO_CLOCK is fine. What else can I do? It?s all there in black and white with a picture.

    I don?t care about the local time +/- whatever argument (or parameter as Hedberg might call it. :) ) It?s irrelevant as it has nothing to do with ASTRO_CLOCK.
  • glr-ftiglr-fti Posts: 286
    True,

    I previously stated that ASTRO_CLOCK works. I know where the documentation is as well. I also know where the documentation is for i!Schedule, i!Time Manager, and Clock Manager. The problem is that none does what is needed in the scenario described. I've been testing i!Time Manager and changing code the last few days, after talking with TS, to see if I could nail this issue. Just when I think I have it something weird happens and changes my offset back to non DST.

    As has been pointed out clkmgr_is_daylightsavings_on() only returns whether it has been enabled not whether it is active. Yes we need another that says clkmgr_is_daylightsavings_ACTIVE() then we can all go back to bed.
  • truetrue Posts: 307
    glr-fti wrote: »
    True,

    I previously stated that ASTRO_CLOCK works. I know where the documentation is as well. I also know where the documentation is for i!Schedule, i!Time Manager, and Clock Manager. The problem is that none does what is needed in the scenario described. I've been testing i!Time Manager and changing code the last few days, after talking with TS, to see if I could nail this issue. Just when I think I have it something weird happens and changes my offset back to non DST.

    As has been pointed out clkmgr_is_daylightsavings_on() only returns whether it has been enabled not whether it is active. Yes we need another that says clkmgr_is_daylightsavings_ACTIVE() then we can all go back to bed.

    I'll write something later (likely this weekend) that uses clkmgr to check if you are in DST or not.
  • Rich AbelRich Abel Posts: 104
    astro clock, time manager, clock manager.....

    wow, I really got a discussion going on this....sorry to post a message and not be able to respond until now.

    Anyway - an update. I'm going to be doing a bunch of time related stuff on an upcoming job so I wanted to bring myself up to date on the various time and astronomical clock functions in Netlinx and the current generation of firmware.

    Toward that end, I wrote a program that attempts to use both the TimeManager module and the built-in clock manager and astro_clock routines.

    I'm running this code on a NI2000 running master FW v3.50.430.

    What is puzzling is that I seem to be getting 4 minutes difference between the Sunrise and Sunset times from Timemanager and astro_clock.

    Since I don't have a touch panel handy, my code runs a timeline to generate a timeline event every minute. I call the ASTRO_CLOCK function to get its Sunrise & Sunset for my Seattle location.

    I'm running timemanager using the same lat and long values. The system is set to use an external time server. I'm getting a 4 minute difference between the sunrise and sunset times between ASTRO_CLOCK and TimeManager. For example for today 4/13/10 astroclock gives me sunrise of 06:28:00 (which is +4 minutes from the correct time) and timemanager gives me 06:24:00, the correct sunrise time.

    As someone else noted, it seems like the numbers ought to be dead on the same. Maybe I have a typo that I'm missing. Here is my source......
    DEFINE_DEVICE
    dvDEBUG								=	0:0:2
    dvMASTER								=	0:1:2
    vdvTP										= 33002:1:2
    dvTMTIMESYNC						=	0:3:2
    vdvTMEVENTS						=	33001:1:2
    
    //******************************************************************************
    //	CONSTANT DEFINITIONS
    //******************************************************************************
    DEFINE_CONSTANT
    // TIME SERVER CONSTANTS
    (* TIMESERVER PROTOCOLS *)
    nProtoNone        		= 0
    nProtoDaytime     		= 1
    nProtoTime        		= 2
    nProtoSNTP        		= 3
    nProtoSNTPBCast   		= 4
    
    (* TIME SERVER CHANNELS *)
    nTmSunriseChannel     = 1
    nTmSunsetChannel      = 2
    nTmDstChannel         = 3
    nTmTimeChangeChannel  = 4
    
    (* TIME SERVER LEVELS *)
    nTmGmtEffLevel        = 1
    nTmGmtLevel           = 2
    nTmLongLevel          = 3
    nTmLatLevel           = 4
    
    //******************************************************************************
    //	DATA TYPE DEFINITIONS
    //******************************************************************************
    DEFINE_TYPE
    
    //******************************************************************************
    //	VARIABLE DEFINITIONS
    //******************************************************************************
    DEFINE_VARIABLE
    // TIME SERVER & TIME RELATED VARIABLES
    //VOLATILE CHAR 				cTIMESTRSUNRISE[50]
    //VOLATILE CHAR 				cTIMESTRSUNSET[50]
    //VOLATILE SINTEGER 	sSUNRISEHOUR
    //VOLATILE SINTEGER 	sSUNSETHOUR
    //VOLATILE SINTEGER 	sSUNRISEMINUTE
    //VOLATILE SINTEGER 	sSUNSETMINUTE
    VOLATILE CHAR 				cTMSUNRISE[10]
    VOLATILE CHAR 				cTMSUNSET[10]
    
    (* TIMEZONE *)
    VOLATILE CHAR    		cTMTZNAME[100]
    VOLATILE CHAR    		cTMTZDESC[10]
    VOLATILE DOUBLE  		dTMTZGMTOFFSET
    VOLATILE CHAR    		cTMTZDSTRULES[1000]
    
    (* LOCATION *)
    VOLATILE CHAR    		cTMLOCNAME[100]
    VOLATILE DOUBLE  		dTMLOCLONG
    VOLATILE DOUBLE  		dTMLOCLAT
    
    (* TIMESERVER *)
    VOLATILE INTEGER 		nTMTSPROTOCOL
    VOLATILE INTEGER 		nTMTSCHECKTIME
    VOLATILE CHAR				cTMTSSERVER[100]
    
    CLKMGR_TIMESERVER_STRUCT TS									// TO HOLD CURRENT TIMESERVER INFO
    CLKMGR_TIMEOFFSET_STRUCT DST_OFFSET
    
    VOLATILE CHAR				cDST_START_RULE[35]
    VOLATILE CHAR				cDST_END_RULE[35]
    VOLATILE INTEGER		nRESYNCH_PERIOD						// MINUTES
    VOLATILE INTEGER		bDST_ON
    
    VOLATILE SINTEGER		sRET_CODE
    VOLATILE CHAR				cTZ_STRING[25]
    VOLATILE DOUBLE			dHRS_TO_UTC								// CURRENT HRS FROM GMT OR UTC
    
    CONSTANT LONG				lONE_MIN_TL		=	1					// TL ID
    VOLATILE LONG				ONE_MIN[]			= {60000}		// 60,000/1,000 = 60 SEC
    VOLATILE INTEGER 		nTL_RET										// TIMELINE_CREATE RETURN VALUE
    VOLATILE DOUBLE 		dLATITUDE			=   47.6350	// NORTH LATITUDE FOR OLIN PLACE
    VOLATILE DOUBLE 		dLONGITUDE		= -122.3129	// WEST LONGITUDE FOR OLIN PLACE
    VOLATILE CHAR 				cSUNRISE[10]
    VOLATILE CHAR 				cSUNSET[10]
    
    //******************************************************************************
    //	INCLUDE FILES
    //******************************************************************************
    
    //******************************************************************************
    //	LATCHING DEFINITIONS
    //******************************************************************************
    DEFINE_LATCHING
    
    //******************************************************************************
    //	MUTUALLY EXCLUSIVE DEFINITIONS
    //******************************************************************************
    DEFINE_MUTUALLY_EXCLUSIVE
    
    //******************************************************************************
    //	SUBROUTINE AND FUNCTION DEFINITIONS
    //******************************************************************************
    
    //******************************************************************************
    //	STARTUP
    //******************************************************************************
    DEFINE_START
    (***********************************************************)
    (* STEP 1 - CONFIGURE THE TIMEZONE:                        *)
    (***********************************************************)
    
    // CONFIGURE TIMEZONE
    // PARAMETER 1: TIMEZONE NAME.  EX: "EASTERN"
    // PARAMETER 2: TIMEZONE DESCRIPTION.  EX: "E%ST"
    // PARAMETER 3: TIMEZONE GMT OFFSET IN HOURS.  EX: -5.0
    cTMTZNAME					= 'Pacific'
    cTMTZDESC					= 'PD%sT'
    dTMTZGMTOFFSET		= -8.0
    
    // CONFIGURE TIMEZONE RULES
    // PARAMETER 1: DAYLIGHT SAVINGS STRING.  EX: "NONE", "US" OR CUSTOM.
    // CUSTOM STRING: "MONTH" "DAYDESCRIPTION" "TIME" "OFFSET FROM STD" "DESCRPTION"
    //                "MONTH":          MONTH NAME EX: "APR"
    //                "TIME"            TIME TO ACTIVATE (HH:MM:SS, 24 HOUR).  EX: "02:00:00"
    //                "OFFSET FROM STD" TIME TO OFFSET FROM GMT (HH:MM:SS, 24 HOUR).  EX: "01:00:00"
    //                "DESCRIPTION"     STRING TO REPLACE "%S" WITH IN TIMEZONE DESCRIPTION.  EX: 'D'
    //                "DAYDESCRIPTION"  DAY DESCRIPTION. FIXED DATE, LAST DAY OF WEEK OR
    //                                  FIRST DAY OF WEEK BEFORE/AFTER DATE
    //                                  FIXED EX: "15"
    //                                  LAST DAY OF WEEK EX: "LASTSUNDAY"
    //                                  FIRST DAY OF WEEK BEFORER DATE-EX: "SUN<=24"
    //                                  FIRST DAY OF WEEK AFTER DATE-EX: "SUN>=1"
    cTMTZDSTRULES 		= 'US'
    
    (***********************************************************)
    (* STEP 2 - CONFIGURE PHYSICAL LOCATION:                   *)
    (***********************************************************)
    
    // CONFIGURE PHYSICAL LOCATION
    // PARAMETER 1: LOCATION NAME.  EX: 'SEATTLE'
    // PARAMETER 2: LOCATION LONGITUDE.  EX: -122.33 (>0 == EAST, < 0 == WEST)
    // PARAMETER 3: LOCATION LATITUDE.  EX: 47.6 (>0 == NORTH, < 0 == SOUTH)
    cTMLOCNAME   			= 'Seattle'
    dTMLOCLONG 				= -122.3129 
    dTMLOCLAT 				=   47.6350
    
    (***********************************************************)
    (* STEP 3 - CONFIGURE TIME SERVERS:                        *)
    (***********************************************************)
    
    // CONFIGURE TIME SERVERS
    // PARAMETER 1: PROTOCOL, 0=DISBALED, 1=DAYTIME(13/UDP, 13/TCP), 2=TIME(37/UDP, 37/TCP), 3=SNTP(123/UDP), 4=SNTP BROADCAST (137/UDP).  EX: 2
    // PARAMETER 3: DEFAULT SERVER.  EX: 'MYTIMESERVER.MYDOMAIN.COM'.  LEAVE BLANK TO READ FROM TIME SEVRER FILE (TIME/NIST_SVR.LST)
    // PARAMETER 2: CHECK TIME INTERVAL IN SECONDS.  USE 0 FOR DEFAULT (2 HOURS).  EX: 3600
    // PARAMETER 4: PREFERED INDEX OF TIMESERVERS IN LIST.  EX: 2
    // NOTES:       IF PARAMETERS 3 IS SUPPLIED, PARAMETER 4 IS IGNORED
    //              IF PARAMATER 3 IS AN EMPTY STRING AND PARAMETER 4 IS 0, A DEFAULT WILL BE PICKED FROM THE LIST IS POSSIBLE
    // CONSTANTS-
    //	nProtoNone       = 0
    //	nProtoDaytime    = 1
    //	nProtoTime       = 2
    //	nProtoSNTP       = 3
    //	nProtoSNTPBCast  = 4
    
    nTMTSPROTOCOL   	= nProtoSNTP
    nTMTSCHECKTIME  	= 0
    cTMTSSERVER   		= ''
    
    (***********************************************************)
    (* ALTERNATE MANUAL TIMEZONE CONFIGURATIONS:               *)
    (***********************************************************)
    
    // THESE ARE SHOWN FOR EXAMPLE PURPOSES AND REPRESENT INFORMATION THAT IS NOT GUARANTEED TO BE CORRECT!
    
    // HERE IS AN EXMAPLE CONFIGURATION FOR SANTIAGO, CHILE WHICH IS -4 HOURS BEHIND GMT AND OBSERVES DAYLIGHT SAVINGS STARTING
    // ON THE SATURDAY ON OR AFTER OCTOBER 9TH AT MIDNIGHT (JUMP AHEAD 1 HOUR) AND THE SATURDAY ON OR AFTER THE 9TH OF MARCH AT MIDNIGHT (JUMP BACK 1 HOUR)
    // AND DESCRIBES THE TIME AS "HH:MM:SS CST" OR "HH:MM:SS CDT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "33S27, 70W40":
    //
    //		cTMTZNAME				= 'Santiago'
    //		cTMTZDESC				= 'C%sT'
    //		dTMTZGMTOFFSET	= -4.0
    //		cTMTZDSTRULES		= "'Oct Sat>=9 00:00:00 01:00:00 D',$FF,'Mar Sat>=9 00:00:00 00:00:00 S'"
    //
    // AND
    //
    //		cTMLOCNAME			= 'Santiago'
    //		dTMLOCLONG			= -70.67
    //		dTMLOCLAT				= -33.45
    
    // HERE IS AN EXMAPLE CONFIGURATION FOR SYDNEY, AUSTRALIA WHICH IS +10 HOURS AHEAD OF GMT AND OBSERVES DAYLIGHT SAVINGS STARTING
    // ON THE LAST SUNDAY IN OCTOBER 2:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN MARCH AT 3:00 AM (JUMP BACK 1 HOUR)
    // AND DESCRIBES THE TIME AS "HH:MM:SS EST" REGARDLESS OF DAYLIGHT SAVINGS AND IS LOCATED AT "33S52, 151E13":
    //
    //		cTMTZNAME				= 'Sydney'
    //		cTMTZDESC				= 'EST'
    //		dTMTZGMTOFFSET	= 10.0
    //		cTMTZDSTRULES		= "'Oct LastSun 02:00:00 01:00:00 X',$FF,'Mar LastSun 03:00:00 00:00:00 X'"
    //
    // AND
    //
    //		cTMLOCNAME			= 'Sydney'
    //		dTMLOCLONG			= 151.22
    //		dTMLOCLAT				= -33.86
    
    // HERE IS THE EXAMPLE CONFIGURATION FOR LONDON, ENGLAND WHICH USES GMT AND OBSERVES DAYLIGHT SAVINGS STARTING
    // ON THE LAST SUNDAY IN MARCH AT 1:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN OCTOBER AT 2:00 AM (JUMP BACK 1 HOUR)
    // AND DESCRIBES THE TIME AS "HH:MM:SS BST" OR "HH:MM:SS GMT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "51N30, 0W10":
    //
    //		cTMTZNAME				= 'London'
    //		cTMTZDESC				= '%s'
    //		dTMTZGMTOFFSET	= 0.0
    //		cTMTZDSTRULES		= "'Mar LastSun 01:00:00 01:00:00 BST',$FF,'Oct LastSun 02:00:00 00:00:00 GMT'"
    //
    // AND
    //
    //		cTMLOCNAME			= 'London'
    //		dTMLOCLONG			= -0.16
    //		dTMLOCLAT				= 51.50
    
    // TIMELINES....
    nTL_RET = TIMELINE_CREATE(lONE_MIN_TL,ONE_MIN,LENGTH_ARRAY(ONE_MIN),TIMELINE_ABSOLUTE,TIMELINE_REPEAT)
    
    SWITCH(nTL_RET)
    {
    	CASE 0:
    	{
    		SEND_STRING dvDEBUG,"'TL lONE_MIN_TL SUCCESSFULLY STARTED.',$0D"
    	}
    	
    	CASE 1:
    	{
    		SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIMELINE ID ALREADY IN USE.',$0D"
    	}
    	
    	CASE 2:
    	{
    		SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIME ARARY NOT ARRAY OF LONGS.',$0D"	
    	}
    	
    	CASE 3:
    	{
    		SEND_STRING dvDEBUG,"'TIMELINE_CREATE: LENGTH SPECIFIED GREATER THAN LENGTH OF PASSED TIME ARRAY.',$0D"	
    	}
    	
    	CASE 4:
    	{
    		SEND_STRING dvDEBUG,"'TIMELINE_CREATE: OUT OF MEMORY.',$0D"	
    	}
    }	// END OF SWITCH ON TIMELINE RETURN
    	
    DEFINE_MODULE 'i!-TimeManagerMod' mdlTM(vdvTMEVENTS,
                                            dvTMTIMESYNC,
                                            (* TIMEZONE *)
                                            cTMTZNAME,
                                            cTMTZDESC,
                                            dTMTZGMTOFFSET,
                                            cTMTZDSTRULES,
                                            (* LOCATION *)
                                            cTMLOCNAME,
                                            dTMLOCLONG,
                                            dTMLOCLAT,
                                            (* TIMESERVER *)      
                                            nTMTSPROTOCOL,
                                            nTMTSCHECKTIME,
                                            cTMTSSERVER)
    
    //******************************************************************************
    //	EVENTS
    //******************************************************************************
    DEFINE_EVENT
    
    TIMELINE_EVENT[lONE_MIN_TL]
    {	
    	cTZ_STRING = CLKMGR_GET_TIMEZONE()
    	SEND_STRING dvDEBUG,"$0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A"	// PUT SOME SPACE BETWEEN REPORTS
    	SEND_STRING dvDEBUG,"'CLKMGR CURRENT TIMEZONE IS: ',cTZ_STRING,$0D"
    
    	IF(FIND_STRING(cTZ_STRING,'UTC',1))
    	{
    		REMOVE_STRING(cTZ_STRING,'UTC',1)
    		cTZ_STRING = LEFT_STRING(cTZ_STRING,(FIND_STRING(cTZ_STRING,':',1))-1)
    		SEND_STRING dvDEBUG,"'CLKMGR cTZ_STRING= ',cTZ_STRING,$0D"
    	}
    	ELSE
    		SEND_STRING dvDEBUG,"'UTC NOT FOUND IN CLKMGR cTZ_STRING!',$0D"
    	
    	IF(bDST_ON)
    		dHRS_TO_UTC = -7.0
    	ELSE
    		dHRS_TO_UTC = -8.0
    	
    	sRET_CODE = ASTRO_CLOCK(dLONGITUDE,dLATITUDE,dHRS_TO_UTC,DATE,cSUNRISE,cSUNSET)
    	
    	SWITCH(sRET_CODE)
    	{
    		CASE 0:	{ SEND_STRING dvDEBUG,"'ASTRO_CLOCK FUNCTION EXECUTED OK',$0D"	}
    		CASE 1:	{ SEND_STRING dvDEBUG,"'ASTRO_CLOCK LATITUDE ENTRY ERROR',$0D"	}
    		CASE 2:	{ SEND_STRING dvDEBUG,"'ASTRO_CLOCK LONGITUDE ENTRY ERROR',$0D"	}
    		CASE 3:	{ SEND_STRING dvDEBUG,"'ASTRO_CLOCK HOURS ENTRY ERROR',$0D"			}
    		CASE 4:	{ SEND_STRING dvDEBUG,"'ASTRO_CLOCK DATE ENTRY ERROR',$0D"			}
    	}	// END OF SWITCH ON RETURN CODE
    	
    	
    	IF(CLKMGR_IS_NETWORK_SOURCED())
    		SEND_STRING dvDEBUG,"'CLOCK MANAGER IS NETWORKED SOURCED',$0D"
    	ELSE
    		SEND_STRING dvDEBUG,"'CLOCK MANAGER IS STAND ALONE',$0D"
    			
    	CLKMGR_GET_ACTIVE_TIMESERVER(TS)
    	CLKMGR_GET_DAYLIGHTSAVINGS_OFFSET(DST_OFFSET)
    	cDST_START_RULE = CLKMGR_GET_START_DAYLIGHTSAVINGS_RULE()
    	cDST_END_RULE = CLKMGR_GET_END_DAYLIGHTSAVINGS_RULE()
    	nRESYNCH_PERIOD = CLKMGR_GET_RESYNC_PERIOD()
    	bDST_ON = CLKMGR_IS_DAYLIGHTSAVINGS_ON()
    	
    	IF(TS.IS_SELECTED)
    		SEND_STRING dvDEBUG,"TS.URL_STRING,', ',TS.LOCATION_STRING,' IS CURRENTLY SELECTED TIMESERVER.',$0D"
    	ELSE
    		SEND_STRING dvDEBUG,"'CLKMGR TIMESERVER IS NOT CURRENTLY SELECTED',$0D"
    		
    	
    	
    	SEND_STRING dvDEBUG,"'CURRENT TIME IS ',TIME,$0D"
    	SEND_STRING dvDEBUG,"'DATE IS ',DATE,$0D"
    	SEND_STRING dvDEBUG,"'SUNRISE TODAY AT ',cSUNRISE,$0D"
    	SEND_STRING dvDEBUG,"'SUNSET TODAY AT ',cSUNSET,$0D"
    
    }	// END OF TIMELINE_EVENT[lONE_MIN_TL]
    
    DATA_EVENT[vdvTMEVENTS]
    (***********************************************************)
    (* DATA_EVENT:   STRINGS FOR SUNRISE/SUNSET                *)
    (* PURPOSE:      PARSE STRINGS FOR SUNRISE AND SUNSET      *)
    (***********************************************************)
    {
      STRING:
      {
        STACK_VAR CHAR cUPPER[30]
        STACK_VAR CHAR cTEMP[30]
        STACK_VAR CHAR cTRASH[30]
        
        cUPPER = UPPER_STRING(DATA.TEXT)
        cTEMP = DATA.TEXT
        cTRASH = REMOVE_STRING(cTEMP,'-',1)
    		
        SELECT
        {
          ACTIVE (FIND_STRING(cUPPER,'SUNRISE-',1)): 
          {
            SEND_STRING dvDEBUG,"'i!TimeManager Sunrise Time = ',cTEMP" 
            cTMSUNRISE = cTEMP
          }
            
          ACTIVE (FIND_STRING(cUPPER,'SUNSET-',1)):
          {
            SEND_STRING dvDEBUG,"'i!TimeManager Sunset Time = ',cTEMP" 
            cTMSUNSET = cTEMP
          }
    				
          ACTIVE (FIND_STRING(cUPPER,'TIMEZONE-',1)):
    			{
            SEND_STRING dvDEBUG,"'i!TimeManager Timezone = ',cTEMP"
    			}
    				
          ACTIVE (FIND_STRING(cUPPER,'TIMEDESC-',1)):
    			{
            SEND_STRING dvDEBUG,"'i!TimeManager Time Description = ',cTEMP"
          }
    			
          ACTIVE (FIND_STRING(cUPPER,'LOCATION-',1)):
    			{
            SEND_STRING dvDEBUG,"'i!TimeManager: Location = ',cTEMP"
    			}
        }	// END OF SELECT-ACTIVE
      }	// END OF STRING DATA_EVENT
    }	// END OF vdvTMEVENTS DATA_EVENT
    
    BUTTON_EVENT[vdvTMEVENTS,nTmSunriseChannel]
    (***********************************************************)
    (* BUTTON_EVENT: SUNRISE CHANNEL                           *)
    (* PURPOSE:      CHANNEL IS PUSHED (AND TURNED ON) WHEN    *)
    (*               THE SUNRISE OCCURS                        *)
    (***********************************************************)
    {
      PUSH:
      {
        SEND_STRING dvDEBUG,"'i!TimeManager: Sunrise occured at ',TIME"
      }
    }
    
    BUTTON_EVENT[vdvTMEVENTS,nTmSunsetChannel]
    (***********************************************************)
    (* BUTTON_EVENT: SUNSET CHANNEL                            *)
    (* PURPOSE:      CHANNEL IS PUSHED (AND TURNED ON) WHEN    *)
    (*               THE SUNSET OCCURS                         *)
    (***********************************************************)
    {
      PUSH:
      {
        SEND_STRING dvDEBUG,"'i!TimeManager: Sunset occured at ',TIME"
      }
    }
    
    BUTTON_EVENT[vdvTMEVENTS,nTmDstChannel]
    (***********************************************************)
    (* BUTTON_EVENT: DST ACTIVITY CHANNEL                      *)
    (* PURPOSE:      CHANNEL IS PUSHED (AND TURNED ON) WHEN    *)
    (*               THE DST RULES AFFECT A TIME CHANGE WITH   *)
    (*               A NON-ZERO TIME OFFSET (DST ACTIVE)       *)
    (*               CHANNEL IS RELEASE (AND TURNED OFF) WHEN  *)
    (*               THE DST RULES AFFECT A TIME CHANGE WITH   *)
    (*               A ZERO TIME OFFSET (DST INACTIVE)         *)
    (***********************************************************)
    {
      PUSH:
      {
        SEND_STRING dvDEBUG,"'i!TimeManager: DST is now active: ',TIME"
      }
      RELEASE:
      {
        SEND_STRING dvDEBUG,"'i!TimeManager: DST is now inactive: ',TIME"
      }
    }
    
    BUTTON_EVENT[vdvTMEVENTS,nTmTimeChangeChannel]
    (***********************************************************)
    (* BUTTON_EVENT: TIME CHANGE CHANNEL                       *)
    (* PURPOSE:      CHANNEL IS PUSHED (AND PULSED) WHEN       *)
    (*               THE TIME IS CHANGED BY A COMMUNICATION    *)
    (*               WITH A TIME SERVER.                       *)
    (***********************************************************)
    {
      PUSH:
      {
        SEND_STRING dvDEBUG,"'i!TimeManager: Time adjusted by time server.  New Time is ',TIME"
      }
    }
    
    LEVEL_EVENT[vdvTMEVENTS,nTmGmtEffLevel]
    (***********************************************************)
    (* LEVEL_EVENT:  EFFECTIVE GMT OFFSET                      *)
    (* PURPOSE:      LEVEL IS SENT WHENEVER THE EFFECTIVE GMT  *)
    (*               OFFSET IS CHANGED.  THE EFFECTIVE OFFSET  *)
    (*               IS THE REAL GMT OFFSET WITH DLS CORRECTION*)
    (***********************************************************)
    {
      SEND_STRING dvDEBUG,"'i!TimeManager: Effective GMT Offset = ',FTOA(LEVEL.VALUE)"
    }
    
    LEVEL_EVENT[vdvTMEVENTS,nTmGmtLevel]
    (***********************************************************)
    (* LEVEL_EVENT:  GMT OFFSET                                *)
    (* PURPOSE:      LEVEL IS SENT WHENEVER THE GMT            *)
    (*               OFFSET IS CHANGED.                        *)
    (***********************************************************)
    {
      SEND_STRING dvDEBUG,"'i!TimeManager: GMT Offset = ',FTOA(LEVEL.VALUE)"
    }
    
    LEVEL_EVENT[vdvTMEVENTS,nTmLongLevel]
    (***********************************************************)
    (* LEVEL_EVENT:  LONGITUDE                                 *)
    (* PURPOSE:      LEVEL IS SENT WHENEVER THE LONGITUDE IS   *)
    (*               CHANGED.                                  *)
    (***********************************************************)
    {
      SEND_STRING dvDEBUG,"'i!TimeManager: Longitude = ',FTOA(LEVEL.VALUE)"
    }
    
    LEVEL_EVENT[vdvTMEVENTS,nTmLatLevel]
    (***********************************************************)
    (* LEVEL_EVENT:  LATITUDE                                  *)
    (* PURPOSE:      LEVEL IS SENT WHENEVER THE LATITUDE IS    *)
    (*               CHANGED.                                  *)
    (***********************************************************)
    {
      SEND_STRING dvDEBUG,"'i!TimeManager: Latitude = ',FTOA(LEVEL.VALUE)"
    }
    
    //******************************************************************************
    //	MAINLINE PROGRAM
    //******************************************************************************
    DEFINE_PROGRAM
    
    //******************************************************************************
    //	END
    //******************************************************************************
    //******************************************************************************
    

    Regardless, I'm going to just use TimeManager and get on with things.....but I am curious where my error lies.

    thanks (and take a deep breath),

    Rich
  • Joe HebertJoe Hebert Posts: 2,159
    Rich Abel wrote: »
    What is puzzling is that I seem to be getting 4 minutes difference between the Sunrise and Sunset times from Timemanager and astro_clock.
    ASTRO_CLOCK(dLONGITUDE,dLATITUDE,dHRS_TO_UTC,DATE,cSUNRISE,cSUNSET)
    

    Instead of DATE try LDATE and I believe that should resolve the difference you are seeing.

    ASTRO_CLOCK calls for the mm/dd/yyyy format.

    DATE returns mm/dd/yy and LDATE returns mm/dd/yyyy

    Have fun.
  • Rich AbelRich Abel Posts: 104
    Bingo!

    Thanks Joe! That was it.

    Rich
  • Joe HebertJoe Hebert Posts: 2,159
    Sure thing Rich.
    Always happy to help.
    Long live ASTRO_CLOCK. :)
  • viningvining Posts: 4,368
    Since this thread made me realize my switch from !iTimeManager to using the Astro_Clock function left me with errors that I wasn't aware of I decided to change its implimentation and create an dedicated include file for time and date stuff. This is an .axi file not a .axs. I change the file extention just to upload it to the forums.

    BTW I only changed to astro_clock because of an error the ZigBee Pro firmware update caused on a job that showed up in my daily log files. To minimize the errors plus being informed that astro_clock runs regardless and since there may be possible negative affects if !iTimemamger is running at the same time I decided to switch to the astro_function since I can control it somewhat and minimize the errors. So I pulled out Timemanager and changed to the astro clock. Of course I didn't pay attention and I didn't impliment it properly which this thread made me aware of.

    This is a useful include file and can be easily plugged into your code in it's entirety or in parts. Some functions aren't completely tested but seem to work so if you find something that doesn't work properly feel free to fix it and let me know so I can fix mine. It will chcek to see if DST is in affect or not based on the start and stop dates. I don't do anything with that info since I haven't seen any problems with what the astro_clock function returns but you can use it to display on your TP.

    There's some other time functions in here that aren't needed for the code in this include but are used elsewhere in my code and since they are time related I decided to store them in the time include so they would be easier for me to find.

    Since this is an .axi there are parts that this file needs that isn't in this file. If you find you can't figure it out on your own and need the missing parts just let me know. A few things may make you scratch your head and yes 8 space indents, camel case w/ hungarian notations and braces where no real programmer would ever put them so deal with it.

    If anybody wants to improve the get_holiday function (add holidays) feel free but post your additions.
  • truetrue Posts: 307
    Sorry about the delay - within the week I'll have beginnings of date/time common functions, including stuff that should be clkmgr functions but aren't, such as determining if daylight savings is currently active. I have a function written for that now, but hopefully I'll have other things. These will be part of the NetLinx Common Libraries.
  • John GonzalesJohn Gonzales Posts: 609
    Joe Hebert wrote: »
    I don?t care about the local time +/- whatever argument (or parameter as Hedberg might call it. :)
    haha, that still cracks me up. :)
    --John
  • Joe HebertJoe Hebert Posts: 2,159
    haha, that still cracks me up. :)
    --John
    Yup, I would definitely nominate Hedberg?s quip as a forum classic and something only a geek would enjoy.
Sign In or Register to comment.