• K
    Kevin Herron

    Update: if I request confirmed notifications instead of unconfirmed the simulator does include the correct address.

    The question still remains, then: should bacnet4j be ignoring the address (or lack of) in unconfirmed COV notifications, or should the simulator be specifying the address in unconfirmed notifications too?

    posted in BACnet4J general discussion read more
  • K
    Kevin Herron

    I'm testing against a simulator, and initially things work fine. The simulator is on network 20, address [1,0,0,0,0,0].

    When I call SubscribeCOV, the service succeeds, but then first unconfirmed notification comes from the simulator without the Source Network and Source Address in the NPDU. Bacnet4j interprets this as a new Address with network 0, address [ac,10,7f,9d,ba,c0] (IP/port) and updates the Address in the cached RemoteDevice.

    Now all subsequent communication with the device fails because its being sent to the wrong address.

    Is this a bug in the simulator or a problem with bacnet4j?

    I can provide a Wireshark capture of this if necessary.

    posted in BACnet4J general discussion read more
  • K
    Kevin Herron

    I'm a bit confused about when I should be creating a new LocalDevice instance and when I should be re-using the same in the scenario where there are multiple RemoteDevices I'm interesting in communicating with.

    I've laid out a scenario here that seems to be working well enough:

    0_1588806299666_overview.png

    But now I'm unsure what the right approach is to add another "set" of devices that are reached through the main device. I'm confused because in order to discover these devices I had to register with the remote device as a Foreign Device. This works well enough and when I use the device discoverer I see all of the devices.

    The problem is - when I need to add a 2nd or 3rd set of these, I'm already registered as a FD with the first one, and IpNetwork blows up if you try to register again.

    Does that mean I should be using a new LocalDevice instance? Should it be bound to the same network adapter/IP? Bound to the same port?

    I've played around with multiple LocalDevices bound to the same IP/port, with different device ids, but kept seeing weird behavior where one or the other didn't seem to receive messages.

    posted in BACnet4J general discussion read more
  • K
    Kevin Herron

    @terrypacker said in Multiple devices on one transport:

    But we also all creating many local devices in case you want to use them in different data sources.

    I'm not sure what you meant here.

    If it helps, I really only need a LocalDevice at all because that seems to be what's required by the library for communicating with RemoteDevices. I will be not be populating the shared or multiple LocalDevices with additional objects.

    My original plan was to have one LocalDevice per network adapter that might be used. For most systems this would mean just one LocalDevice.

    Is there any reason to have multiple LocalDevices (which I assume requires its own device number each) if I'm not going to be actually exposing any objects?

    I'm essentially only interested in reading from or writing to other BACnet devices on the network.

    posted in BACnet4J general discussion read more
  • K
    Kevin Herron

    @terrypacker Yes, I think that's what I need. Thank you.

    Now I need to decide if I should share one LocalDevice among the many different connections* my application might have or if each connection should have its own LocalDevice instance.

    If you've got any insight to share that would be welcome.

    • well, "connections", being UDP and all... but let's say configured remote device instances.

    posted in BACnet4J general discussion read more
  • K
    Kevin Herron

    Is it possible to have multiple LocalDevice instances (each with their own device number) share the same transport?

    Or am I stuck with one LocalDevice per available local IP address to bind to, essentially?

    posted in BACnet4J general discussion read more