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

Re: [BACnetLighting] Add 135-2008i PPR4 Draft 5

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.