Loading ...
Sorry, an error occurred while loading the content.

Re: [BACnetLighting] DMF-028-2 with offset in weekly-schedule

Expand Messages
  • Steve Karg
    Hi Rene, ... There is also the case where sunrise or sunset returns 00:00 (i.e. no sunrise or sunset) because the device is located in Alaska or another area
    Message 1 of 4 , Feb 16, 2005
    • 0 Attachment
      Hi Rene,

      > There should probably be additional rules, e.g. that the time can't be
      > shifted with offest outside the "current day"....
      >
      > What do you think about that?

      There is also the case where sunrise or sunset returns 00:00 (i.e. no
      sunrise or sunset) because the device is located in Alaska or another
      area of the world where it is sunny or dark 24 hours a day for part of
      the year, and there is an offset.

      I agree that additional rules, rather than error responses or leaving it
      a local matter, would be a good idea. Making it part of the standard
      would keep implementations from configuration problems.

      Best Regards,

      Steve
      --
      http://www.kargs.net/
    • Stuart.Donaldson@alerton.com
      Hello Rene, Steve, and other innocent bystanders... Rene identified an important issue, but I am concerned that we will limit the usefulness if we do not come
      Message 2 of 4 , Feb 16, 2005
      • 0 Attachment
        Hello Rene, Steve, and other innocent bystanders...

        Rene identified an important issue, but I am concerned that we will limit the usefulness if we do not come up with a mechanism to support offsets that span the midnight boundary.

        In the real world, time is a linear thing, and offsetting something by 4 hours is offsetting it by 4 hours, and the fact that 4 hours earlier happens to be the day before has no bearing whatsoever on the real world.

        -Stuart-




        Steve Karg <steve@...>

        2005-02-16 12:42 PM
        Please respond to BACnetLighting

               
                To:        BACnetLighting@yahoogroups.com
                cc:        
                Subject:        Re: [BACnetLighting] DMF-028-2 with offset in weekly-schedule



        Hi Rene,

        > There should probably be additional rules, e.g. that the time can't be
        > shifted with offest outside the "current day"....
        >  
        > What do you think about that?

        There is also the case where sunrise or sunset returns 00:00 (i.e. no
        sunrise or sunset) because the device is located in Alaska or another
        area of the world where it is sunny or dark 24 hours a day for part of
        the year, and there is an offset.

        I agree that additional rules, rather than error responses or leaving it
        a local matter, would be a good idea.  Making it part of the standard
        would keep implementations from configuration problems.

        Best Regards,

        Steve
        --

        http://www.kargs.net/



        ======================================================
        To view the message archive, set user options, or view
        files in our archive, visit the following web page:

           
        http://www.yahoogroups.com/group/BACnetLighting/

        To subscribe to this group, send an email to:

           BACnetLighting-subscribe@yahoogroups.com


        Yahoo! Groups Sponsor
        ADVERTISEMENT




        Yahoo! Groups Links
        ______________________________________________________________________
        This email has been scanned by the MessageLabs Email Security System.
        For more information please visit http://www.messagelabs.com/email
        ______________________________________________________________________
      • Dave Robin
        Absolutely. The fact that current BACnet schedules cannot cross midnight is a glaring omission. Is is common for real people to want to make schedules that
        Message 3 of 4 , Feb 17, 2005
        • 0 Attachment
          Absolutely.   The fact that current BACnet schedules cannot cross midnight is a glaring omission.   Is is common for real people to want to make schedules that cross midnight, and clever workstations have to split that desire into two schedules (one ending at 23:59:59.99 and one starting at 00:00:00.00) and hope to goodness that the target device crosses midnight without a bump.   This is not pretty.   All future changes to the schedule object should handle crossing midnight seamlessly.

          Stuart.Donaldson@... wrote:
          Hello Rene, Steve, and other innocent bystanders...
          
          Rene identified an important issue, but I am concerned that we will limit 
          the usefulness if we do not come up with a mechanism to support offsets 
          that span the midnight boundary.
          
          In the real world, time is a linear thing, and offsetting something by 4 
          hours is offsetting it by 4 hours, and the fact that 4 hours earlier 
          happens to be the day before has no bearing whatsoever on the real world.
          
          -Stuart-
          
          
          
          
          
          
          Steve Karg <steve@...>
          2005-02-16 12:42 PM
          Please respond to BACnetLighting
          
           
                  To:     BACnetLighting@yahoogroups.com
                  cc: 
                  Subject:        Re: [BACnetLighting] DMF-028-2 with offset in weekly-schedule
          
          
          Hi Rene,
          
            
          There should probably be additional rules, e.g. that the time can't be 
          shifted with offest outside the "current day"....
          
          What do you think about that?
              
          There is also the case where sunrise or sunset returns 00:00 (i.e. no 
          sunrise or sunset) because the device is located in Alaska or another 
          area of the world where it is sunny or dark 24 hours a day for part of 
          the year, and there is an offset.
          
          I agree that additional rules, rather than error responses or leaving it 
          a local matter, would be a good idea.  Making it part of the standard 
          would keep implementations from configuration problems.
          
          Best Regards,
          
          Steve
            


          -- 
          Dave Robin, Automated Logic Corporation
          phone: (770)795-4888  
          fax:   (770)795-3588
          email: drobin@...
          icbm:  34°00'17.42"N, 84°35'04.91"W
          
        Your message has been successfully submitted and would be delivered to recipients shortly.