This week, in Episode 5, we’re diving into your questions about OT network performance, traffic limits, duplicate addressing, and how to tell when things are under‑strain. Ping‑Pook Yao, our Co‑Founder & CTO, walks through what we should watch for, what thresholds make sense, and how to avoid common pitfalls in BACnet/OT networks.
- How do I avoid duplicate addresses ?
- How much traffic is too much?
- What the heck are BACnet models devices, objects, properties & services?
Thanks for sending in all your questions! If you’d like us to tackle a particular topic—maybe about broadcast behavior, MS/TP chain length, or network segmentation—send them our way. We love digging deep to help make your BACnet/OT networks more reliable.
Send us a message on LinkedIn, Reddit, or Bluesky, or email us at marketing@optigo.net .
Here’s what Ping covers in Episode 5:
❓ How forgiving should a system be when a device isn’t responding?
On a building OT network, packet loss should be very low, ideally under 1%.
- If a device fails to respond even a couple of times, that should trigger investigation—not be shrugged off as “network noise.”
- Other warning signs: high variance in response times, devices resetting or rebooting unexpectedly, or noticeable slowdowns.
- Use diagnostic tools (e.g. OptigoVN) to monitor packet loss, dropped packets, and device behavior.
❓ Can you explain in simple terms how BACnet models devices, objects, properties & services?
Services = the actions/messages: you can read or write values, subscribe to changes, reset, etc. These are the ways devices communicate within the BACnet standard.
Device = like the whole human.
Objects = the arms, legs, organs (different functional parts).
Properties = the attributes of those objects (length, current value, status).
Transcript
Question 1 – avoiding mistakes when configuring devices
One is maintain a list.
Have an Excel spreadsheet, maintain a list, and try to maintain it as much as you can.
Second, if you are working with multiple vendors, create some kind of rule:
This vendor will use this range, that vendor will use that range, or these buildings will use this range, and that building will use that range.
And a third, but definitely not one to ignore, is check for the address that you are about to use to make sure that’s free before using it, right?
Do a WHO-IS to that device ID, do a ping for that IP address.
And of course I should mention, use a software like OptigoVN to verify for duplicate addresses.
Question 2 – how much traffic is too much for my network?
Excellent.
Incredible, good question.
It’s a very tough answer because “it depends” a lot.
What I mean by that—if you’re looking at a small device that’s running like an ARM7 processor with 64MB of memory—it’s going to have a much, much, much lower threshold for the amount of packets it can process per second compared to a big server.
If you’re looking at a smaller device, you probably want to keep it below 10 packets per second.
It sounds very little, but that’s, you know, 600 packets per minute.
The second bucket I would call a mid-range device.
You can probably do 20 to 50 packets per second—not sustained 50 packets per second, but peaking around there.
You can probably deal with it.
And then there’s the big servers, right? Where you install your BMS software on it.
It’s running a VM on it that can support a lot more.
But even then, I would still suggest to try to keep the amount of traffic to below 100 packets per second.
Note that in a lot of modern, managed switches, there is by default a cap of 100 packets per second of broadcast traffic.
So, if you go into a system that is very, very busy, your network might naturally be cutting off some of this excessive broadcast traffic, whether you expect it or not.
I should mention that MS/TP devices are a very different class.
We really want to keep that as low as possible—
Even 2 to 5 sustained packets per second is a lot in MS/TP, especially when you have a lot of devices on that chain.
So to sum up, if it’s an IP-based device, think of those three categories:
Small devices—keep it around 10 packets per second or lower.
Mid-range devices—20 to 25, maybe up to 50 packets per second.
And then large servers can do a lot more, but I’d still try to keep it below 100 packets per second.
And then there are non-IP devices—the serial devices, the BACnet MS/TP devices.
Those ones—really try to keep it to 1 or 2 packets per second of sustained traffic.
But most importantly: all these are guidelines.
If you really want to know, you have to look at:
Is the device performing as expected?
Is it dropping packets?
Is it resetting itself?
Is it slowing down?
And there are ways to measure that.
And of course, if you’re not already using OptigoVN, we do look for those things.
Question 3 – when should i fail a device?
I often get asked, “How forgiving should I be, or should my system be, to determine if a device is online or failing offline?”
It’s a tough question, but I will say, in general, I find that this is an issue where we are too forgiving.
We are too accepting of systems that are not operating properly.
What I mean by that is that when we look at the greater internet, it is normal for packets to be dropped.
But when we look at a building automation system on a local network, we really shouldn’t be that forgiving.
If it is dropping packets, if it has a large variance, that should be addressed.
We really should be failing a device if it fails to respond twice, right?
Giving it 6 times and trying it with seconds in between—
Even if it comes back to me, that’s a very strong indicator that there’s an issue in the system.
I would suggest that when we look at building automation, when we look at our local networks,
The ping time should be very low.
The number of times it fails to respond should be extremely low.
I’m talking about sub-1%.
And if it is above that, I would really take a moment and figure out where the bottlenecks are—
What is changing the system that’s causing these failures?
Question 4 – BACnet objects, properties, and services? What are they? What’s the difference?
Good question.
BACnet models a system as a system of devices:
Every device having objects, and every object having properties.
It sounds really, really fancy, but just think of it as us, as a human.
Every person is a person.
We have different objects—my left arm, my right arm—and then there are different properties.
What’s the length of my arm?
What do I do with it? [laughs]
Is it online or offline, of course.
So just think of it this way:
In BACnet, there’s a collection of devices.
Every device has a number of objects.
And every object has a set of properties.
You can read what the current status is: on or off?
What’s the present value?
What threshold am I setting on it?
Finally, services can be thought of as messages:
I can read.
I can write.
I can subscribe to a change of value.
I can reset the devices.
Services are just different messages that the BACnet standard provides—
That everyone using BACnet can use.
If you have questions around BACnet systems,
How BACnet works on OT networks,
How IT and OT work in combination—
Send in your questions and we’ll get to it.
