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

Emailing: DHR-021-05

Expand Messages
  • David Ritter
    Hi BACneteers, Here is an updated version of DHR-021 (Binary Lighting object type) for discussion at the LA-WG meeting in Denver next week. There are a few
    Message 1 of 2 , Jun 10, 2013
    • 1 Attachment
    • 301 KB
    Hi BACneteers,

    Here is an updated version of DHR-021 (Binary Lighting object type) for discussion at the LA-WG meeting in Denver next week. There are a few things to discuss before this document gets moved up to the SSPC again.

    Hope to see you in Denver,

    Best Regards,

    David Ritter
  • David Fisher
    David, As I am unable to attend the Denver meeting, here are some comments regarding this revision. First of all, the changes look OK to me based on what your
    Message 2 of 2 , Jun 11, 2013
    • 0 Attachment

      David,

      As I am unable to attend the Denver meeting, here are some comments regarding this revision.

       

      First of all, the changes look OK to me based on what your tasks

      were from the previous meeting.

       

      re: DR1 comment

      I don’t see why Change_Of_State_Count could not be used as long as it retains

      the language of 12.X.18.

       

      re: DR2 comment

      You’re correct that the language could be more consistent with BO object.

      However as an historical note the BO object has long been flawed in this

      respect because it fails to base the state change on ACTUAL changes

      by observing feedback value instead of PV. If we want a reflection of

      runtime and strike counts that are meaningful it should be using feedback

      in all cases. If there is no feedback, then it’s a local matter and you could

      implement it literally as the BO object says. If there is feedback but you use

      the PV instead, then in cases of lamp failure one would accumulate run hours

      even though the lamp isn’t running. So depending on how quickly you get

      around to noticing that the lamp has failed, your statistics are going to be skewed

      by that delay. Since the purpose of gathering run hours is at least partially to

      gauge things like lamp life, this is at cross purposes when PV is used instead.

       

      IMHO we should leave the language as-is and try to introduce similar language

      into the BO object!

       

      re: DR3 comment

      Strike_Count (or Change_Of_State_Count) should be required writable so that

      it can be cleared by writing zero. This should be coupled to Elapsed_Active_Time

      as in BO object.

       

      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 David Ritter
      Sent: Monday, June 10, 2013 6:07 PM
      To: BACnetLighting@yahoogroups.com
      Subject: [BACnetLighting] Emailing: DHR-021-05 [1 Attachment]

       

       

      [Attachment(s) from David Ritter included below]

      Hi BACneteers,

      Here is an updated version of DHR-021 (Binary Lighting object type) for discussion at the LA-WG meeting in Denver next week. There are a few things to discuss before this document gets moved up to the SSPC again.

      Hope to see you in Denver,

      Best Regards,

      David Ritter

    Your message has been successfully submitted and would be delivered to recipients shortly.