As it is, it seems the only way to remove a remote device from the local device list is to reset the local device.
This means that if a remote device is removed form the network, or if it crashes and no longer answers any queries,
we have to go through the whole process of terminating the local device, only to prop it up again immediately after.
Would it be possible to provide a removeDevice method for the local device?
This way we could manually remove any remote device which isn't answering and keep a 'clean' list of remote devices.
Tested with both 1.2.4 and 1.2.5.
An initialized bacnet4J device will easily handle the PropertyIdentifier.all for all of its objects, except for the 'device' object.
A little Wireshark exploration shows that a readPropertyRequest sent for the device object, with PropertyIdentifier.all, will receive as a response an error 'unknown property'.
I wanted to upgrade my BACnet4J.jar file and noticed on the
CVS repo that there's some commit for the BACnet4J 2.0. (With sweet sweet MS/TP support)
If it is, may I inquire on what might be causing this error when trying to build?
error: cannot find symbol [javac] import gnu.io.SerialPort; [javac] ^ [javac] symbol: class SerialPort [javac] location: package gnu.io
I've double checked and RXTXcomm.jar is indeed in the lib-opt directory.
Thank you very much in advance!
I just wanted to announce that I've made a BACnet webserver using the awesome BACnet4J library.
(Consequently, it's entirely open source!) :mrgreen:
Here is a quick presentation on how to run and use it:
However, I did not write it in java... I wrote it in Clojure!
The advantages are shown in the REPL page, where you can define and use commands on-the-fly.
I might end up rewriting some parts in Clojure (such as the [url=https://github.com/Frozenlock/bacure/blob/master/src/bacure/read_properties.clj]read-properties functions),
but for now it's overwhelmingly BACnet4J :wink:
New version of Wacnet! (1.1.0)
As usual, completely free!
Detailed review of what changed:
Download link and instructions:
If you are on Windows, you could try adding another IP to your network card.
This way, you could have:
Device 1, 192.168.0.3:47808
Device 2, 192.168.0.4:47808
Playing with the ports if a little delicate, as some devices will only respond the port on which they are located.
When you say you see them 'chirping' and answering to your WhoIs, are they answering to a broadcast address your machine can receive?
For example, suppose your IP is 188.8.131.52 and your broadcast address is 184.108.40.206.
A device situated on 192.168.0.4 might receive it, but if they answer on 192.168.255.255, you will never get it.