Unresponsive Devices can cause a lot of unnecessary traffic on an Operational Technology network, but it can be difficult to pinpoint exactly what’s causing the problem. Unresponsive Devices could be caused by a misconfiguration, a physical issue, or a combination of the two. 

In our 10-minute Webinar, we dug into top tips for finding and fixing Unresponsive Devices. Find out what usually causes these issues, and how to resolve them. 

What is an Unresponsive Device? As the name implies, it’s a device that doesn’t respond to requests or messages other devices send. In this example, a source (represented by the computer) is sending a Who-Is message to device 249. This device is unresponsive, though, so it doesn’t send an I-Am message back to the source in reply. 

Depending on your configurations, the source might continue to send out Who-Is requests for device 249 until it gets a reply. That could be in perpetuity if you don’t fix the unresponsive device. 

The first question you need to ask is: “Should device 249 be on the network?”

Sometimes the answer is a simple no. Maybe you know that all your device IDs have a six-digit code, so a three-digit code like 249 shouldn’t be on the network at all. If this is the case, you’re likely dealing with a Phantom Device. 

Other times, the issue is a bit more complicated than that. If you’re not sure whether this device should be on your network, you can go to your device list and check whether ID 249 has been assigned. If the device should be on your network, you could be dealing with either a Failed Device or a Path Failure. 

Phantom Device

If you know for sure that device isn’t on the network, you have what’s referred to as a Phantom Device. In this scenario, the problem is actually with the source device. For some reason, the source thinks it needs to find device 249. 

There are a few things you can look at to troubleshoot this: first, is this source device programmed to look for device 249? Alternatively, is this source device receiving a message from another device that it’s supposed to route to 249? If so, you might need to capture it from another location on your network to pinpoint that issue.

Failed Device

If device 249 should be on the network and should be responding to Who-Is requests, you might have a failed device. This is a common issue that a lot of people have dealt with, and there are many potential causes. In this case, you want to go and troubleshoot the device itself. It could be a physical issue (maybe the cord accidentally got pulled), or a misconfiguration.

Path Failure

Third and finally, you could be dealing with a Path Failure. This issue is much rarer and more complicated, so we recommend that you look at the first two causes first. 

It’s likely, based on how BACnet networks are often designed, that the Who-Is message request is actually being routed through a few different devices. It could be sent via a router, a gateway, or a series of different devices.

If the source and the device are both working as they should be, you’ll have to go through and troubleshoot the path that’s connecting them. Hopefully, if this is the case, you’ll see some different failures on the network that will help you identify the root cause. This is also where it’s very helpful to have a network diagram, so you can identify if there’s a common thread — like a router, or wiring — to the devices that are struggling to communicate.

Troubleshooting the path is challenging, but if you resolve what’s broken in the path then you might fix a few devices that are struggling to communicate.

Another way to identify the cause of an Unresponsive Device is to look at the number of sources that aren’t able to communicate with a specific device. 

If a device is being sent messages from many different sources, it’s quite likely that you’ve programmed all these source devices correctly, and you have a device on the other end that’s failed. 

On the flip side, if you have one querying device, it’s more likely that there was a misconfiguration on the source device. 

That isn’t an infallible rule of thumb by any means, but it’s a great place to start if you have limited context. 

In theory, unresponsive devices are quite simple: it just means that something, somewhere, is getting lost in translation. But if the device isn’t communicating on the network, you might not even know it’s supposed to be there. Fortunately, Visual BACnet highlights exactly which devices are unresponsive, and which devices are searching for them, so you can focus on fixing the issue.