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

DMF-028-2 with offset in weekly-schedule

Expand Messages
  • rene.quirighetti@siemens.com
    Hallo Dave, hallo LA-WG Studying your proposal on famous times I got over an issue if these famous times are combined with offsets in the weekly schedule as
    Message 1 of 4 , Feb 15, 2005
    • 0 Attachment
      Hallo Dave, hallo LA-WG
      Studying your proposal on "famous times" I got over an issue if these famous times are combined with offsets in the weekly schedule as proposed: 
       

      12.24.7.1 BACnetTimeValues in BACnetDailySchedules

       

      Each of the BACnetTimeValues in a BACnetDailySchedule may use one of three types of time values:

      a.       a simple time with constant hours, minutes, seconds and hundredths

      b.      an offset of ±0..720 minutes from a well-known BACnetFamousTimeKind

      c.       an offset of ±0..720 minutes from a time obtained from a BACnetObjectPropertyReference in a given index of the Time_References array property.

       
      The negative or positive offsets may lead to a resulting time one day earlier or later respectivly than the day the famous time is written in.
      Assume a schedule with binary PresentValue. The ScheduleDefault being : False, no entry at 00:00 am of the current day. At (BACnetFamousTimeKind(sunrise)- 240 minutes) the PresentValue shall become TRUE and remain there until  BACnetFamousTimeKind(sunset), i.e. only these two entries in this current day.
      This works well, until sunrise is before 4:00 am. The PresentValue will then be set to TRUE late in the day before our "current day" and reset to FALSE (the ScheduleDefautl) at 00:00 am the current day and remain FALSE until sunrise is again after 4:00 am!!!
       
      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?
       
      Regards
      Renö Quirighetti
       
       
       
    • 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 2 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 3 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 4 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.