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

Add 135-2008i PPR4 Draft 5

Expand Messages
  • polars15213
    This doc contains revisions based on Atlanta discussions. ... Some of you had asserted that there can be multiple outstanding relinquish timers in effect, now
    Message 1 of 6 , Nov 11, 2009
    • 0 Attachment
      This doc contains revisions based on Atlanta discussions.
      In particular:
      >New RELINQUISH-FADETO, RELINQUISH-RAMPTO commands allowing fade/rate using post relinquish most important guy's level

      >COV on blink warn is now a local matter

      >add priority field to LightingCommand

      >DONT AGREE SEE PURPLE HIGHLIGHT
      Some of you had asserted that there can be multiple outstanding
      relinquish timers in effect, now potentially even at different
      priority levels. After studying the existing language, I don't
      agree that this is possible or desirable. See the purple highlighted
      section of the PPR4 Draft 5. I have not changed this language.
    • Steve Karg
      Hi Dave, ... Thank you for the hard work preparing this document, and keeping our discussions on track during our meeting discussions yesterday! I noticed that
      Message 2 of 6 , Nov 11, 2009
      • 0 Attachment
        Hi Dave,

        > This doc contains revisions based on Atlanta discussions.

        Thank you for the hard work preparing this document, and keeping our
        discussions on track during our meeting discussions yesterday!

        I noticed that in one case some new language ought to be more specific:

        12.X.17 Step_Increment
        ...
        Writes to Step_Increment shall always be greater than the value in the
        Resolution property. Lower values shall return errors.

        Possible new text could be:

        Lower values shall cause a Result(-) to be returned with an error
        class of PROPERTY and an error code of VALUE_OUT_OF_RANGE.

        > >DONT AGREE SEE PURPLE HIGHLIGHT
        > Some of you had asserted that there can be multiple outstanding
        > relinquish timers in effect, now potentially even at different
        > priority levels. After studying the existing language, I don't
        > agree that this is possible or desirable. See the purple highlighted
        > section of the PPR4 Draft 5. I have not changed this language.

        Although the existing language doesn't take into account multiple
        duration timers in effect, that is not necessarily a good thing.

        The use case is a control device (i.e. wall switch) that could specify
        a duration so that it's priority slot can timeout after a period of
        time (i.e. after hours timeout). If another control entitiy uses a
        duration option at a different priority slot, then the original
        control device priority slot is orphaned in a non-null state, causing
        lights to remain on or off when they were not intended to do so.

        We should be able to still provide the option for Lighting Output
        objects to be lightweight (i.e. without multiple priority slot
        timers), while giving others the ability to implement them. An
        implementer would have the option to implement multiple priority slot
        timers to handle multiple durations (automatic relinquish at every
        priority slot), or only a single duration timer.

        Possible language for this option could be:

        An implementation may choose to have one duration timer or sixteen
        duration timers (one duration timer for each priority slot). If only
        one timer is implemented, and a priority field and a duration field
        are specified together, then a Result(-) shall be returned with an
        error class of PROPERTY and an error code of
        OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

        The purple highlighted language should be modified to deal with the
        possibility of multiple priority slot duration timers. Perhaps:

        If a duration is specified and is greater than zero, it shall reset
        any previously specified duration that is currently in effect for that
        priority slot. If a duration of zero is specified, it shall stop any
        duration currently in effect for that priority slot, canceling the
        automatic relinquish.

        Best Regards,

        Steve
        --
        http://steve.kargs.net/
      • David Ritter
        Regarding the issue with multiple relinquish timers I have two thoughts: 1. The purple highlighted section is applicable (and would still apply) when a
        Message 3 of 6 , Nov 11, 2009
        • 0 Attachment

          Regarding the issue with multiple relinquish timers I have two thoughts:

           

          1.       The purple highlighted section is applicable (and would still apply) when a lighting command is written at the same priority as a previous lighting command. In this case it should completely cancel out, including the auto relinquish, the previous lighting command. I agree with the wording changes as proposed by Steve.

          2.       If you allow writing lighting commands at any priority and you allow auto relinquish it would be inappropriate to reject an auto relinquish command if there is already one active. Imagine the confusion when a write from a wall switch works today, because it was the first to issue an auto relinquish command, but doesn’t work tomorrow because another device wrote an auto relinquish command ahead of him. In my opinion the only way to handle this is to either allow auto relinquish on every priority or not support the Duration field and therefore not support auto relinquish. There is really no way to make this light weight unless we disallow auto relinquish or restrict the lighting command to one priority.

           

          One other thing we should do is add a definition of “Blink Warn” to section 3.2.

           

           

          David Ritter M.Sc.

          Delta Controls Inc.

          17850 56th Ave

          Surrey, BC

          V3S 1C7

          604.574-8492 (direct)

          604.574.9444 (office)

          604.837-1330 (cellphone)

           

          From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Steve Karg
          Sent: Wednesday, November 11, 2009 10:08 AM
          To: BACnetLighting@yahoogroups.com
          Subject: Re: [BACnetLighting] Add 135-2008i PPR4 Draft 5

           

           

          Hi Dave,

          > This doc contains revisions based on Atlanta discussions.

          Thank you for the hard work preparing this document, and keeping our
          discussions on track during our meeting discussions yesterday!

          I noticed that in one case some new language ought to be more specific:

          12.X.17 Step_Increment
          ...
          Writes to Step_Increment shall always be greater than the value in the
          Resolution property. Lower values shall return errors.

          Possible new text could be:

          Lower values shall cause a Result(-) to be returned with an error
          class of PROPERTY and an error code of VALUE_OUT_OF_RANGE.

          > >DONT AGREE SEE PURPLE HIGHLIGHT
          > Some of you had asserted that there can be multiple outstanding
          > relinquish timers in effect, now potentially even at different
          > priority levels. After studying the existing language, I don't
          > agree that this is possible or desirable. See the purple highlighted
          > section of the PPR4 Draft 5. I have not changed this language.

          Although the existing language doesn't take into account multiple
          duration timers in effect, that is not necessarily a good thing.

          The use case is a control device (i.e. wall switch) that could specify
          a duration so that it's priority slot can timeout after a period of
          time (i.e. after hours timeout). If another control entitiy uses a
          duration option at a different priority slot, then the original
          control device priority slot is orphaned in a non-null state, causing
          lights to remain on or off when they were not intended to do so.

          We should be able to still provide the option for Lighting Output
          objects to be lightweight (i.e. without multiple priority slot
          timers), while giving others the ability to implement them. An
          implementer would have the option to implement multiple priority slot
          timers to handle multiple durations (automatic relinquish at every
          priority slot), or only a single duration timer.

          Possible language for this option could be:

          An implementation may choose to have one duration timer or sixteen
          duration timers (one duration timer for each priority slot). If only
          one timer is implemented, and a priority field and a duration field
          are specified together, then a Result(-) shall be returned with an
          error class of PROPERTY and an error code of
          OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

          The purple highlighted language should be modified to deal with the
          possibility of multiple priority slot duration timers. Perhaps:

          If a duration is specified and is greater than zero, it shall reset
          any previously specified duration that is currently in effect for that
          priority slot. If a duration of zero is specified, it shall stop any
          duration currently in effect for that priority slot, canceling the
          automatic relinquish.

          Best Regards,

          Steve
          --
          http://steve.kargs.net/

        • David Fisher
          Steve & Dave, Thanks for these suggestions. I have revised the draft and posted a new version that incorporates my interpretation of these changes. David
          Message 4 of 6 , Nov 11, 2009
          • 0 Attachment

            Steve & Dave,

            Thanks for these suggestions. I have revised the draft and posted a new

            version that incorporates my interpretation of these changes.

             

            David Fisher

            PolarSoft® Inc.

            914 South Aiken Ave

            Pittsburgh PA 15232-2212

            dfisher@...

            www.polarsoft.biz

            412-683-2018

            412-683-5228 fax

             


            From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Steve Karg
            Sent: Wednesday, November 11, 2009 10:08 AM
            To: BACnetLighting@yahoogroups.com
            Subject: Re: [BACnetLighting] Add 135-2008i PPR4 Draft 5

             

             

            Hi Dave,

            > This doc contains revisions based on Atlanta
            discussions.

            Thank you for the hard work preparing this document, and keeping our
            discussions on track during our meeting discussions yesterday!

            I noticed that in one case some new language ought to be more specific:

            12.X.17 Step_Increment
            ...
            Writes to Step_Increment shall always be greater than the value in the
            Resolution property. Lower values shall return errors.

            Possible new text could be:

            Lower values shall cause a Result(-) to be returned with an error
            class of PROPERTY and an error code of VALUE_OUT_OF_ RANGE.

            > >DONT AGREE SEE PURPLE HIGHLIGHT
            > Some of you had asserted that there can be multiple outstanding
            > relinquish timers in effect, now potentially even at different
            > priority levels. After studying the existing language, I don't
            > agree that this is possible or desirable. See the purple highlighted
            > section of the PPR4 Draft 5. I have not changed this language.

            Although the existing language doesn't take into account multiple
            duration timers in effect, that is not necessarily a good thing.

            The use case is a control device (i.e. wall switch) that could specify
            a duration so that it's priority slot can timeout after a period of
            time (i.e. after hours timeout). If another control entitiy uses a
            duration option at a different priority slot, then the original
            control device priority slot is orphaned in a non-null state, causing
            lights to remain on or off when they were not intended to do so.

            We should be able to still provide the option for Lighting Output
            objects to be lightweight (i.e. without multiple priority slot
            timers), while giving others the ability to implement them. An
            implementer would have the option to implement multiple priority slot
            timers to handle multiple durations (automatic relinquish at every
            priority slot), or only a single duration timer.

            Possible language for this option could be:

            An implementation may choose to have one duration timer or sixteen
            duration timers (one duration timer for each priority slot). If only
            one timer is implemented, and a priority field and a duration field
            are specified together, then a Result(-) shall be returned with an
            error class of PROPERTY and an error code of
            OPTIONAL_FUNCTIONAL ITY_NOT_SUPPORTE D.

            The purple highlighted language should be modified to deal with the
            possibility of multiple priority slot duration timers. Perhaps:

            If a duration is specified and is greater than zero, it shall reset
            any previously specified duration that is currently in effect for that
            priority slot. If a duration of zero is specified, it shall stop any
            duration currently in effect for that priority slot, canceling the
            automatic relinquish.

            Best Regards,

            Steve
            --
            http://steve. kargs.net/

          • David Ritter
            The changes in the Lighting Command property allow the implementation to use one timer but allowing Lighting Commands at any priority. As Steve pointed out in
            Message 5 of 6 , Nov 11, 2009
            • 0 Attachment

              The changes in the Lighting Command property allow the implementation to use one timer but allowing Lighting Commands at any priority. As Steve pointed out in his previous email, this can result in an orphaned Lighting Command which was written with a time duration but will never be auto relinquished because a subsequent Lighting Command with a non-zero duration was sent at a different priority. The writer of the original Lighting Command assumes the command will be auto relinquished (because he wrote it with a duration) so he will never come back to relinquish it.

               

              I believe the principle should be:

              1.       If you only support one timer then you must only support writing a Lighting Command at the priority specified in the Lighting Command Priority property.

              2.       If you support writing at any priority then you must support concurrent auto-relinquish on each of those priorities (i.e., multiple timers)

               

              David Ritter M.Sc.

              Delta Controls Inc.

              17850 56th Ave

              Surrey, BC

              V3S 1C7

              604.574-8492 (direct)

              604.574.9444 (office)

              604.837-1330 (cellphone)

               

              From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of David Fisher
              Sent: Wednesday, November 11, 2009 1:11 PM
              To: BACnetLighting@yahoogroups.com
              Subject: RE: [BACnetLighting] Add 135-2008i PPR4 Draft 5

               

               

              Steve & Dave,

              Thanks for these suggestions. I have revised the draft and posted a new

              version that incorporates my interpretation of these changes.

               

              David Fisher

              PolarSoft® Inc.

              914 South Aiken Ave

              Pittsburgh PA 15232-2212

              dfisher@...

              www.polarsoft.biz

              412-683-2018

              412-683-5228 fax

               


              From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Steve Karg
              Sent: Wednesday, November 11, 2009 10:08 AM
              To: BACnetLighting@yahoogroups.com
              Subject: Re: [BACnetLighting] Add 135-2008i PPR4 Draft 5

               

               

              Hi Dave,

              > This doc contains revisions based on Atlanta discussions.

              Thank you for the hard work preparing this document, and keeping our
              discussions on track during our meeting discussions yesterday!

              I noticed that in one case some new language ought to be more specific:

              12.X.17 Step_Increment
              ...
              Writes to Step_Increment shall always be greater than the value in the
              Resolution property. Lower values shall return errors.

              Possible new text could be:

              Lower values shall cause a Result(-) to be returned with an error
              class of PROPERTY and an error code of VALUE_OUT_OF_RANGE.

              > >DONT AGREE SEE PURPLE HIGHLIGHT
              > Some of you had asserted that there can be multiple outstanding
              > relinquish timers in effect, now potentially even at different
              > priority levels. After studying the existing language, I don't
              > agree that this is possible or desirable. See the purple highlighted
              > section of the PPR4 Draft 5. I have not changed this language.

              Although the existing language doesn't take into account multiple
              duration timers in effect, that is not necessarily a good thing.

              The use case is a control device (i.e. wall switch) that could specify
              a duration so that it's priority slot can timeout after a period of
              time (i.e. after hours timeout). If another control entitiy uses a
              duration option at a different priority slot, then the original
              control device priority slot is orphaned in a non-null state, causing
              lights to remain on or off when they were not intended to do so.

              We should be able to still provide the option for Lighting Output
              objects to be lightweight (i.e. without multiple priority slot
              timers), while giving others the ability to implement them. An
              implementer would have the option to implement multiple priority slot
              timers to handle multiple durations (automatic relinquish at every
              priority slot), or only a single duration timer.

              Possible language for this option could be:

              An implementation may choose to have one duration timer or sixteen
              duration timers (one duration timer for each priority slot). If only
              one timer is implemented, and a priority field and a duration field
              are specified together, then a Result(-) shall be returned with an
              error class of PROPERTY and an error code of
              OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

              The purple highlighted language should be modified to deal with the
              possibility of multiple priority slot duration timers. Perhaps:

              If a duration is specified and is greater than zero, it shall reset
              any previously specified duration that is currently in effect for that
              priority slot. If a duration of zero is specified, it shall stop any
              duration currently in effect for that priority slot, canceling the
              automatic relinquish.

              Best Regards,

              Steve
              --
              http://steve.kargs.net/

            • Steve Karg
              Hi David, ... I agree with those principles. The language I had proposed (now modified since David F figured out about one less timer, and includes the
              Message 6 of 6 , Nov 11, 2009
              • 0 Attachment
                Hi David,

                > I believe the principle should be:
                >
                > 1.       If you only support one timer then you must only support writing a Lighting Command at the priority specified in the Lighting Command Priority property.
                >
                > 2.       If you support writing at any priority then you must support concurrent auto-relinquish on each of those priorities (i.e., multiple timers)

                I agree with those principles.

                The language I had proposed (now modified since David F figured out
                about one less timer, and includes the surrounding text) does just
                that by returning an error in the case of (1) for a single timer
                implementation. You could optionally ignore the priority field in
                that case, but I didn't think that was a good option.

                <change to 12.X.9 Lighting_Command>
                Any lighting command operation can specify a time duration in seconds
                after which the target level Priority_Array slot is relinquished
                automatically by writing a NULL value to that slot.

                An implementation may choose to have one duration timer or fifteen
                duration timers (one duration timer for each priority slot, except
                Priority 6). If only one timer is implemented, and a priority field
                and a duration field are specified together, then a Result(-) shall be
                returned with an error class of PROPERTY and an error code of
                OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

                If duration is not specified, then no automatic relinquish shall be
                assumed and any previously specified duration shall remain in effect.

                If a duration is specified and is greater than zero, it shall reset
                any previously specified duration that is currently in effect for that
                priority slot. If a duration of zero is specified, it shall stop any
                duration currently in effect for that priority slot, canceling the
                automatic relinquish.
                </change>

                Best Regards,

                Steve
                --
                http://steve.kargs.net/
              Your message has been successfully submitted and would be delivered to recipients shortly.