Hello, I'm new member of this forum, but I've been reading as an unregistered user for a while. I'm a development engineer looking for a bit of advice.
Since each BACnet device object_identifier has to be unique on the entire internetwork, I was wondering if there are any addressing schemes in use, so we can manufacture our products with a unique device instance (the 22 bit) that no-one else is using? (Sort of like the LON neuron ID being totally unique)
The standard (or is it the BTL? I forgot.) says that this device instance has to be configurable by the installer, and I've seen a couple of ways that other vendors obtain this:
1) By DIP switches on the device or similar (this takes 22 switches!)
2) Configurable by external device and software, like a PC tool or another BACnet device
3) Configurable by display and buttons on the device.
My problems is that with our products, none of the above methods are optimal, so I was hoping there was another way to ensure a unique device instance, so we didn't have to give the installer the option of changing it?
Or are there any options for this that I've left out? I'm pretty sure there are no addressing scemes around, but it never hurts to ask.
I've seen a vendor using the MS/TP MAC address as the device instance as well, but this sets a limit of 127 devices (if master), so that isn't an option to us.
I hope someone has some input on device instances - what is possible, and what is not?
As far as I know the reason the device number needs to be adjustable is that there is no standard addressing scheme, therefore no garantee that the device number will be unique. so the integrator needs to adept the address based on specific netwrok/installtion.
I am pretty sure trane uses dip switches,
ALC use rotary switches.
Reliable controls uses software set.
Some manufacturers use their Bacnet vendor ID as prefix + a dip switch set suffix.
I suggest you leave a way for installer to modify this address in some fashion
Thank you for the fast reply, amigo.
I pretty much expected that this was how it worked. I would very much prefer the DIP switch solution, as it is very easy to integrate. Problem is that there isn't enough room for another 22 DIP switches in the casing (already have 8 switches for setting the MS/TP MAC addy, and it is very cramped for space already).
Software set is probably what I'm ending up with, but for various reasons it isn't exactly a solution that makes me happy. It is however better than leaving no option for changes for the installer.
I'm just looking into all the options here, before making any recommendations as to how we go about solving this issue.
Here is a document that explains how reliable controls does their addressing. may give you some ideas:
Thank you for the effort amigo, but I have seen that one already.
Any other inputs, ideas, etc. are most welcome.
I would use Amigo's idea.
"Some manufacturers use their Bacnet vendor ID as prefix + a dip switch set suffix."
You could use a set number for the first part of the device + the combination of the MAC address.
Then you could also have a writable point if the installer wishes to put something else in or they are installing more then 127 of your devices and are running out unique dip switch settings. You could have a dip switch that then switches device from "Use Default" address to "Use Custom".
The default would be the # + MAC. The Custom would be the writable software address.
We use a lot of Veris meters. They all come with a default BacnetID of 123. They have a writable Analog Value AV:2 that is the Device instance. So you power up the meter, connect to the device using address 123. Then once you are seeing the meter points you change the value of AV:2 to the Device Instance you want.
It would be more user friendly to have a dip switch to pick between the Default and the Custom address.
Thanks for your input. I like the idea of having a default and a custom address, with the default being vendorID*1000 + MAC, and the custom being settable from an analog value.
A DIP-switch to select between the two modes is also a good idea, I hadn't considered that. Thanks!
Unique Object_Name for Device Object
Does the name of the device object has to be unique. Is the spec correct or am I missing an update. In 2006 I was involved in supporting an Andover site where the Andover system did demand the name was unique. I thought this had more to do with the way they managed their database than anything else.
The the 2004 version of the Spec (135_2004new.pdf) paragraph 12.11.2 says
This property, of type CharacterString, shall represent a name for the object that is unique internetwork-wide. The minimum length of the string shall be one character. The set of characters used in the Object_Name shall be restricted to printable characters."
What Bacnet manufacturer are you working with? I'm a little curious of what you are trying to accomplish.
Unique Object_Name for Device Object
No vendor in particular.
The question if for an application which tests and validates BACnet devices.
Originally Posted by CAS_Chipkin
Most of the specs, including BTL Guidelines, typically require that a Device Name be unique for the device existing on the network. A good example of why this is needed is for situations where an end-user attempts to locate a device on a global-network using the Who-Has service (e.g. Send Who-Has for Device named "My Device".).
To be perfectly honest though, I cannot see any reason why it has to be uniqiue, given the one uniquie thing that is a must is the Device Instance.