163RE: [bacnet-ip-wg] Re: CLB-013 - Network Port Object
- May 27, 2011
I understand what you mean. But that's assuming the device is able to automatically choose its home port in all cases.
I think the ultimate benefit of the NetworkPort object is that anyone can configure anyone else's devices. If we leave this concept out of the NetworkPort object, then control of the home port will become hidden in the "local matter" realm and kind of defeat the purpose. Since single-homing is a current practice with some vendors, a standard way of controlling it should be included in the NetworkPort object.
I'm not saying we should overly specify the behavior of this property either. I wouldn't want to force all vendors that do single-homing to allow the property to be writable. It could be read-only and informational in some vendor's devices. I do think the presence or absence of the property would be a good way to determine if a device is a single- homed implementation or not.
Engineer Software Pr
Alerton Dealer Business
Honeywell Automation & Control Solutions
6670 185th Ave NE
Redmond WA 98052
Phone – 425.897.3980
Fax – 425.869.8445
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Coleman Brumley
Sent: Friday, May 27, 2011 5:44 AM
Subject: RE: [bacnet-ip-wg] Re: CLB-013 - Network Port Object
I don't think removing the property necessarily removes the option of being a single homed device. It just removes the BACnet application visible aspect of it. Meaning, that if we remove the property, then there's no way to tell via ReadProperty (for example) if a device is single homed or not. I'm not certain that's a problem or not, and that's the only use case I envision for that property. There may be others, especially regarding NS, but I'm having a hard time coming up with anything else.
- << Previous post in topic