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

RE: Comment on BI-040-3 and BI-041-2

Expand Messages
  • James F. Butler
    I would like to remind everyone that Bernhard would like to receive your comments on BI-040-3 and BI-041-2 by August 15. Please send your comments to
    Message 1 of 3 , Aug 10, 2012
    • 0 Attachment

      I would like to remind everyone that Bernhard would like to receive your comments on BI-040-3 and BI-041-2 by August 15.  Please send your comments to bacnet-it-wg@yahoogroups.com as John has done.




      - Jim Butler



      From: bacnet-it-wg@yahoogroups.com [mailto: bacnet-it-wg@yahoogroups.com ] On Behalf Of Hartman, John
      Sent: Thursday, August 09, 2012 5:35 PM
      To: bacnet-it-wg@yahoogroups.com
      Subject: [bacnet-it-wg] Comment on BI-040-3 and BI-041-2


      Attached are markups of BI-040-3 and BI-041-2 with some comments.


      Two big topics seem to be various issues about addresses, both unicast and multicast; and UETs.



      For the most part, addresses are “hidden”: the application will use the UET.DeviceID  or a URI, and resolution to an IP address can be done by the BACnet stack.  But the Network Port object requires a datalink to specify its address as a property.  Thus, some sort of address must be made visible for NTB.  And the Device Object has a Device/Address binding property that also exposes addresses.


      The VMAC was introduced to avoid defining addresses longer than 7 octets.  This was primarily done to limit the size of the network header, but to the extent that a legacy device can read these address from an NTB device, and such devices are likely NOT to accept 16-octet IPv6 addresses, we need to think about length and format for them, at least as translated by a Proxy and seen from a BIN.


      In existing BACnet, network number can often be a convenient way to group devices: a bunch of MS/TP VAV boxes connected to a supervisory controller can be discovered by directing Who-Is broadcasts to that network.  The equivalent on NTB would require setting up multicast addresses on each device, which might require use of a service tool when none was previously required.  Is group-by-network common enough to be worth preserving/translating in some fashion, or is that old-think?



      How "unique" are the UETs?  Per-installation?  Per vendor?  Globally?


      6.2.4 says "Including the BACnet Vendor ID into the UET is an approach for globally unique identification of BACnet NTB devices".  But it also says "Exchanging the HW of a device should not cause the UET to change", which implies that the UET can be changed in the field, as during a replacement and are NOT globally unique like an Ethernet address.


      6.3.1 uses a UET in a multicast address.  It would seem that some or many multicast groups would NOT be all of the same vendor's devices.  So this UET seems to have different rules than the UET described in 6.2.4.  Is this the SAME UET as 6.2.4, or do multicasts use a separate UET or set of UET?  It (or at least some of them) would need to be assigned and configured on the job site.


      I can imagine that vendor X might want to pre-configure their devices at the factory with a UET:multicast group “All Vendor X devices”.  But there will also need to be “all lighting devices in building X” and the like configured at installation time.




      The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

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