After rebooting the Ignition server the device is connected. Is there anything i can do to reproduce the connection issue?
It would also be good to enable a connection without the broadcast. Our production firewall blocks broadcast traffic, so i can only connect to devices that are not behind those firewalls.
Now i am able to browse from the designer, but the browse result is not as expected.
I noticed you had restarted the module at least once, I think there may be some kind of missing cleanup there. I couldn't explain the multiple who-Is requests to the same device happening in your Wireshark capture unless it's because multiple instances of something weren't cleaned up.
I don't know what information the server in your screenshots is using to name those nodes. Maybe it uses some specific BACnet property as the browse name or display name?
Yes, i was able to reproduce the effect. It happens when the module is restartet with the Bind Address set to the IP of the gateway. When changing the Bind Address without restart, the device is immediately connected.
Okay, I’m guessing that server is just using the Object_Name property if it’s set. I can’t remember why I stopped doing this… I’ll play around with it and see if it works now.
It is the Object_Name and the Description of the Analog Input Object. I think it would be very useful to enable access to those properties at least. Even better would be a seperate browse tree with object name and descriptions.
I’m going to work on mapping Object_Name and Description BACnet properties to their OPC UA equivalents for each object type.
Unfortunately Ignition itself is unable to take advantage of the OPC UA Description attribute right now… but it’ll be there for some future where it can.
The next nightly build will have Edge compatibility and BrowseName/DisplayName attributes populated using the Object_Name property.
Edge compatibility will require a full gateway upgrade, not just the module.
So we need to wait for next release of Edge ?
The nightly builds include Edge distributions. Just wait until Monday and download Edge from the nightlies page.
Awsome 
Works great on Edge now !
The OPC Browser still doesn’t use the ObjectName property tough.
Is it possible for you to get a Wireshark capture while the driver is connecting?
Did you download a new copy of the BACnet driver too? What does the full version number in the modules page say?
Works great with the new version of the Bacnet module!
Kevin, I have the Beta 1.0.0-SNAPSHOT (b2020062302) installed. I can’t seem to get the OPCUA Device to indicate a status of Initialized. It constantly switches between Initializing and Uninitialized. I have configured the local device with bind and broadcast addresses being the same (192.168.0.10). If I change the broadcast to .255, then I get this DefaultTransport error. I have tried changing the network number from default 1 to 0 to match what the error indicates and errors stop, but device keeps cycling. I made sure to edit then save Ignition’s OPC-UA Server as indicated.
Using Inneasoft BACnet Explorer on the same gateway I am able to browse the multiple devices under a specific IP address. These are Zigbee wireless thermostats that connect to an Ethernet “gateway”. Each device Id represents a thermostat. Would I need to create an OPC Device connection for each ID even though they share the same IP Address?
Nevermind. Somehow it shows Initialized now. And I answered my own question. Yes, I’ll have to create a connection for each device (over 70 in this building…ouch!)
Kevin, What if the Device Id could be part of the OPC item Path? Similar to Modbus TCP/IP, that way we can create a device connection using the IP address only and then leverage UDTs to dynamically create necessary tags by specifying the unique device Id. For example, ns=1;s=[ViconicsGW1]Device301.AnalogValue7.Present_Value maps to the Room Temperature of thermostat with Device Id 301. Device Id 302 is also located on the same IP address, However, this might not be how BACNet works in general.
Thanks for developing this module!
That won’t work, aside from being way too late, it assumes every device id on the other side of some gateway or IP is exactly the same, implements the same services, and doesn’t need different transport settings or anything else.
You’ll just have to create a lot of devices.
Your broadcast address should definitely be the .255 variant. It will never be the same as the bind address.
We have been charting BACnet equipment parameters using a homegrown python application for some months. All the target BACnet devices are on a completely different network (10.A.B.0/24) than the polling Linux system (10.A.X.0/24).
We just installed the ignition BACnet driver. Unfortunately we cannot get the ignition driver to pass the initializing stage. Using TCPdump, we see packets leaving, but there is no reply from the remote device. We use both the default and what we feel is the actual instance id for the remote system with the same results. I’ll DM you the packet capture.
What did you use as the bind address and broadcast address when configuring the local device instance?
The bind address was the IP address of the Linux client on which ignition was installed. The broadcast address what the same address ending in .255. Basically, the output of the Linux ifconfig command. Packets leave, but don’t return as you’ll see in the capture I sent. You’ll also see a known working example of communication between the same client and target using a python script.
