You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which node-red-contrib-bacnet version are you using?
0.3.0
What happened?
I've launched a BACNet Multiple Read Request to a BACNet server running under a Honeywell Hawk8000 controller, asking for a large amount of properties in a single request (44 properties to be exact). When the size of the response's is greater than 480, the controller tries to answer to this request segmentating the frames because the buffer size is big. This is a normal behaviour. But it looks like Node-RED BACNet client doesn't handle this response correctly.
We have analyzed the BACNet frames using Wireshark together with Honeywell, and we have found to abnormal things when the Node-RED BACNet client is handling the communication in this circumstances. I'm attaching the Wireshark frames.
Initially, in this image it can be seen that the client (IP 10.10.10.202) makes two requests to the server (IP 10.10.10.15): frame 19 and frame 60. The server responds correctly and the client handles the response accordingly, as the ADPU size of the responses are less than 480 and the server doesn't need to segmentate the response.
A request asking for 44 properties is made in frame 93 from the client to the server. On frame 94, the server responds with the first fragment of the segmentated frame. On frame 95 two abnormal things happen: first, the client sends the Segment-ACK message to the broadcast IP (instead of sending it to the server's IP 10.10.10.15). Secondly, the flag SRV of the ADPU request is set to True, and Honeywell is telling me it should be set to false as the frame generator is the Node-RED BACNet client.
This behaviour is causing this invalid-adpu-in-this-state error frame, and consequently the Node-RED Node BACNet read is displaying an ERR_TIMEOUT error on the debug tab.
Take into account that the maxSegments property in the options of the request array is set to 64 and the maxAdpu option is set to 3 on all the requests shown in this sequence.
Honeywell is telling me that they have tested the Hawk8000 controller requesting this amount of properties with the Bacshark driver and it's working smoothly, so it shouldn't be a problem of the controller.
How can this be reproduced?
Setting a BACNet server with several object properties (in my case 44), all of them being present values for either analog inputs, binaryState values or multiState values, and requesting all this properties in a single requestArray using the BACNet Read node and activating the option for multiple read.
What did you expect to happen?
I'm expecting to not receive the ERR_TIMEOUT error in Node-RED and to not see the invalid-adpu-in-this-state error in Wireshark. I'm also expecting the Node-RED BACNet client to handle the segmentated response.
Other Information
The message payload sent to the BACNet Read node is the following one:
Which node-red-contrib-bacnet version are you using?
0.3.0
What happened?
I've launched a BACNet Multiple Read Request to a BACNet server running under a Honeywell Hawk8000 controller, asking for a large amount of properties in a single request (44 properties to be exact). When the size of the response's is greater than 480, the controller tries to answer to this request segmentating the frames because the buffer size is big. This is a normal behaviour. But it looks like Node-RED BACNet client doesn't handle this response correctly.
We have analyzed the BACNet frames using Wireshark together with Honeywell, and we have found to abnormal things when the Node-RED BACNet client is handling the communication in this circumstances. I'm attaching the Wireshark frames.
Initially, in this image it can be seen that the client (IP 10.10.10.202) makes two requests to the server (IP 10.10.10.15): frame 19 and frame 60. The server responds correctly and the client handles the response accordingly, as the ADPU size of the responses are less than 480 and the server doesn't need to segmentate the response.
A request asking for 44 properties is made in frame 93 from the client to the server. On frame 94, the server responds with the first fragment of the segmentated frame. On frame 95 two abnormal things happen: first, the client sends the Segment-ACK message to the broadcast IP (instead of sending it to the server's IP 10.10.10.15). Secondly, the flag SRV of the ADPU request is set to True, and Honeywell is telling me it should be set to false as the frame generator is the Node-RED BACNet client.
This behaviour is causing this invalid-adpu-in-this-state error frame, and consequently the Node-RED Node BACNet read is displaying an ERR_TIMEOUT error on the debug tab.
Take into account that the maxSegments property in the options of the request array is set to 64 and the maxAdpu option is set to 3 on all the requests shown in this sequence.
Honeywell is telling me that they have tested the Hawk8000 controller requesting this amount of properties with the Bacshark driver and it's working smoothly, so it shouldn't be a problem of the controller.
How can this be reproduced?
Setting a BACNet server with several object properties (in my case 44), all of them being present values for either analog inputs, binaryState values or multiState values, and requesting all this properties in a single requestArray using the BACNet Read node and activating the option for multiple read.
What did you expect to happen?
I'm expecting to not receive the ERR_TIMEOUT error in Node-RED and to not see the invalid-adpu-in-this-state error in Wireshark. I'm also expecting the Node-RED BACNet client to handle the segmentated response.
Other Information
The message payload sent to the BACNet Read node is the following one:
requestArray.json
The text was updated successfully, but these errors were encountered: