I just started using openhab and am hoping to control my home’s bacnet devices with it.
I am getting the following stack trace error on startup:
Exception in thread “bacnet-client-2-discovery” java.lang.IllegalArgumentException: Not an I/P mac
at com.serotonin.bacnet4j.npdu.ip.IpNetworkUtils.getIpBytes(IpNetworkUtils.java:115)
at com.serotonin.bacnet4j.npdu.ip.IpNetworkUtils.toIpString(IpNetworkUtils.java:106)
at com.serotonin.bacnet4j.npdu.ip.IpNetworkUtils.toIpPortString(IpNetworkUtils.java:110)
at com.serotonin.bacnet4j.npdu.ip.IpNetworkUtils.toString(IpNetworkUtils.java:122)
at org.code_house.bacnet4j.wrapper.api.Device.toString(Device.java:114)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at org.openhab.binding.bacnet.internal.BacNetBinding.deviceDiscovered(BacNetBinding.java:250)
at org.code_house.bacnet4j.wrapper.api.DiscoveryCallable.iAmReceived(DiscoveryCallable.java:89)
at org.code_house.bacnet4j.wrapper.api.util.ForwardingAdapter$2.run(ForwardingAdapter.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
The openhab log shows one bacnet device detected :
I did some more troubleshooting on this and it looks like both devices responds to the who-is requests correctly yet for some reason, device 61001 does not end up detected. See the wireshark capture of the traffic. Could it be that the address length is 1 and that somehow this is not acceptable to the binding ? Any help on this would be greatly appreciated !
@splatch - sorry to tag you directly like this… Any insight on this particular issue ? Seems like the binding is rejecting the device due to some issue reading the device address. I can see (and control) the device just fine in Wacnet or Yabe…
Hey @Pierre-Luc_Pelletier,
Thank you for reaching me - indeed this is bug in bacnet wrapper code. Yyou have two devices running on single IP and thats something which may cause troubles. I will have to revisit how device addresses are collected. From stack trace seems second address is formatted differently thus it doesn’t pass.
Did some additional testing tonight after cleaning up my network configuration (connected the BACnet device directly to the primary router).
I am getting a bit further (I think) but still errors out for the device I need.
In addition to the errors, the devices are now being discovered but the address transformation seems to fail. I bolded the relevant line (Failed toString). A few lines below, you can see the other device being detected correctly.
Looks like this is related to this error in the console :
SLF4J: Failed toString() invocation on an object of type [org.code_house.bacnet4j.wrapper.api.Property]
Reported exception:
java.lang.NullPointerException
at org.code_house.bacnet4j.wrapper.api.Property.toString(Property.java:76)
at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:299)
at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:271)
at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:233)
at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:173)
at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:151)
at org.ops4j.pax.logging.slf4j.Slf4jLogger.error(Slf4jLogger.java:918)
at org.openhab.binding.bacnet.internal.queue.ReadPropertyTask.run(ReadPropertyTask.java:35)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Hey @Pierre-Luc_Pelletier, your errors are straight and I need no extra input so far. There is an error with addressing requests passed to bacnet4j under the hood. Wacnet doesn’t have this problem because it recognises properly devices.
I need to revisit how addresses are collected and most likely amend internals of our bacnet4j wrapper. Will answer in this topic once I will have fix for you.
In case if I will not return soon enough you can ping me over forum, message or github issue created for this bug: https://github.com/Code-House/bacnet4j-wrapper/issues/6
Good evening Pierre,
Please find test version of binding available for download:
I removed unecessary ip address creation, however I can not guarantee at this moment that it will work any better. Please give it a try and see if you can read any property values. If you would be so kind - please try to traverse network using console client as described on wrapper wiki: https://github.com/Code-House/bacnet4j-wrapper/wiki/Discovering-devices
This will confirm or deny that “client” code itself is fine without pulling binding logic.
I just gave this a quick test this morning and it seems to work !
The only thing I had to do was force the network number in the config file to the network number of the second device and then the binding detected both devices. So far I am able to read and set analog values. Will try other types later tonight but so far so good. I will confirm the results for other property types here.
