BACnet/IP: Way to delay between REQ readProperty autoevent calls? #12
-
I have a BACnet/IP device that seemingly behaves poorly when multiple requests for values are made at the same time. For my use case, I have 15 inputs with autoevents set up. From looking at Wireshark, the first request takes around 180ms to get ACK'ed by the device. Any request received after the first and before the response to the first are ignored. The manufacturer suggested adding a delay between each request. (Lame I know.) Since this is device-specific, it seems like a delay would be defined on a device or device-profile basis. Is there such a setting? Or something similar in behavior that I can use? FYI I'm using v2.2 with a built version of device-bacnet-c with PR "refac: move to SDK v2". Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Hi, there's not really anything that does that. You could try defining a deviceCommand containing the 15 inputs, and then having a single autoevent which queried it - the device service would then serialize the read requests, which might be enough for your use case. We could also add a config option for bacnet to introduce a delay between requests in such an operation, if that proves necessary An enhancement which added a "one request at a time" flag to a device definition could well be useful - there's a similar request for modbus. Potential v3 feature. |
Beta Was this translation helpful? Give feedback.
-
Hi @iain-anderson. Thanks for the informative response. Indeed using a deviceCommand with the inputs does serialize the read requests. Unfortunately with the device I have, about 1 out of 4 times one of the requests is not responded to. In Wireshark, I do indeed see that requests are going out right after responses are received, so the service is behaving correctly. They are just going out faster than the device can handle. The device manufacturer says they are looking into it, however, I expect there are other devices that are not bulletproof networking-wise. Yes, a "one request at a time" may be useful at the device-level, but for this device, it'd need to be coupled with a small delay. Should I write up a request for this feature somewhere? And finally: I did run into a potential problem either in device-bacnet-c (PR: "refac: move to SDK v2 #66") or device-sdk-c (v2.2). When the bacnet-device-service gets lots of errors, it eventually gets into a state where it stops sending out requests to the device altogether, even though the logs imply that the requests were sent (the errors look the same as when there is not a response from the device). I can consistently get the bacnet-device-service in this state by setting it up to query this device for more than 1 input at a time. In less than 24 hours, it always stops sending packets. Wireshark shows no request packets going out. Simply restarting the service makes it work again. I haven't tracked down where the problem is. Thanks for your help. |
Beta Was this translation helpful? Give feedback.
Hi, there's not really anything that does that. You could try defining a deviceCommand containing the 15 inputs, and then having a single autoevent which queried it - the device service would then serialize the read requests, which might be enough for your use case. We could also add a config option for bacnet to introduce a delay between requests in such an operation, if that proves necessary
An enhancement which added a "one request at a time" flag to a device definition could well be useful - there's a similar request for modbus. Potential v3 feature.