Bug #2
closed
Conflict of device instance ID
0%
Description
2022-02-21 06:38:54:843 +0100 [BACnet4J transport for device 83340] WARN com.serotonin.bacnet4j.service.unconfirmed.IAmRequest - Another instance with my device instance ID found at Address [networkNumber=0, macAddress=[a9,fe,5e,2e,ba,c0]]
Was found in the error-file on node "WASH" on the morning of 220221 after being unreachable since 220218 about lunch.
Possibly related to this in the node "ELOX" errorfile the following message was found:
2022-02-21 05:40:24:526 +0100 [pool-2-thread-2328] WARN com.serotonin.bacnet4j.service.unconfirmed.IAmRequest - Error in device 83323 while discovering extended device information from 83340 at Address [networkNumber=0, macAddress=[a9,fe,5e,2e,ba,c0]]
The node was physically restarted in the morning of 220221 and was than able to function as normal.
Updated by Torbjorn Carlqvist Admin about 2 years ago
- Target version deleted (
6)
Updated by Torbjorn Carlqvist Admin about 2 years ago
- Target version set to Unplanned backlogs
Updated by Torbjorn Carlqvist Admin almost 2 years ago
- Status changed from New to Closed
This is an issue when a DTX loosing it's network connection. in Linux Debian the IP is randomly selected to : a9,fe,5e,2e,ba,c0 (169.254.94.46:47808) which will be the new BACnet UDP socket, temporarley. And now because the node still has the same BACnet-device-id it complains on that there is a collision between the previous 192.168.x.x IP and this new temp IP for the same BACnet-device-id. So this is not a collision on the network, it is a collision in the internal address mapping between IP-BACnet device-id.
I would say it is harmless and a lot of efforts has bean made since this report to handle the loss of IP for the BACnet-stack.