I'm not going to paste the code in the forum, because you really need the bacnet4j source so that you can test it out, download the source from http://sourceforge.net/projects/bacnet4j/files/bacnet4j/1.3/
and make sure you don't have any problems with running all the tests.
And as I said before, it's been over a year since I touched bacnet4j, so good luck, I'm sure once you have the source, you'll figure out what is going wrong.
I haven't used BACNet4j for over a year, but from the code you provided, it doesn't look like you have another bacnet device that would be responding to the requests. You'd need to have a BACnet "server" or slave device actually sending the values.
For example, to get this test to work:
You need to have this test already running in the background:
I'd recommend that you start by getting the samples working, before trying other things.
Hi Taresh,
If you're talking about the analog COV subscription changes, that was merged in Nov 2012, see: http://forum.infiniteautomation.com/forum/posts/list/1207.page
Hi Matthew,
Yes the BacnetServiceException will still be thrown, but the Siemens BMS software, goes into some aggressive polling mode when it receives a COV subscription failure. Every 5 seconds it continually tries to resubscribe, so even though the exception still bleeds through and sends a BACnet COV failure message. 5 seconds later the next COV subscription request succeeds.
Although later I was thinking a possibly better way to do it would be to accept the subscription anyway, but when sending a notification, do the check if we have the remote device yet, and simply not send a notification if we can't look up the remote device.
However we had already tested the workaround against the Siemens hardware so we decided to leave it the way it was.
Cheers,
-Joel
Hi Matthew,
Our testing with the Siemens BMS went off mostly without a hitch, so I'd say the COV code is good to merge.
The only minor issue we came up against, was when we restarted our bacnet4j connector, we couldn't accept new COV subscriptions, because we didn't know about the remote device.
So the workaround we came up with was sending out a "WhoIs" request before failing the COV subscription. There was probably a better way but this is what we did:
The original code from com.serotonin.bacnet4j.obj.BACnetObject.addCovSubscription(Address, Network, UnsignedInteger, Boolean, UnsignedInteger)
if (confirmed) {
// If the peer wants confirmed notifications, it must be in the remote device list.
RemoteDevice d = localDevice.getRemoteDevice(from);
if (d == null)
throw new BACnetServiceException(ErrorClass.services, ErrorCode.covSubscriptionFailed,
"From address not found in remote device list. Cannot send confirmed notifications");
}
We changed to:
if (confirmed) {
// If the peer wants confirmed notifications, it must be in the remote device list.
RemoteDevice d = localDevice.getRemoteDevice(from);
if (d == null) {
// Send a WhoIs before sending a failure message, so that subsequent subscriptions will hopefully work
try {
this.localDevice.sendUnconfirmed(from, network, new WhoIsRequest());
}
catch (BACnetException e) {
// If the WhoIs request fails we just ignore it.
}
throw new BACnetServiceException(ErrorClass.services, ErrorCode.covSubscriptionFailed,
"From address not found in remote device list. Cannot send confirmed notifications");
}
}
Although I don't know if you'd want to merge something like that change, as it is more of a workaround and a bit specific to how our environment is setup.
Other than that we verified that COV subscriptions for Analog devices worked flawlessly taking into account their threshold.
Hi Matthew,
Yes it was just for logical encapsulation and it made it easier to test. However if you would like me to move ThresholdCalculator to be a normal class, or just move its methods into ObjectCovSubscription. If I move the methods into ObjectCovSubscription, I should probably make isValueOutsideOfThreshold private, so the testing will be a little more fiddly, but still relatively straight forward.
Or if there is some other style you prefer, just let me know, I'm happy to change it to suit whatever coding style you prefer.
In terms of testing on real equipment, next week we'll be testing it with some Siemens hardware, so I can tell you the result of it. But then obviously you'd just be taking my word for it.
Hi Matthew,
Our client did need COV for analogs in the end. I have just implemented it and submitted a patch on sourceforge: https://sourceforge.net/tracker/?func=detail&aid=3581790&group_id=224576&atid=1062318
Can you take a look at it and let me know if you want me to change anything?
Thanks,
-Joel
As far as I can tell it is the BACnet Object Identifier that must be unique. Although I have noticed that some third party BACnet devices get a bit confused when they see objects that have the same name. Although bacnet4j only cares about the object identifier being unique.
I hope that helps
Hi Gatos,
We're still in discussions with our client if they want us to implement COV subscriptions for analog values.
A simple workaround or "dirty hack" is simply to add
supportedObjectTypes.add(ObjectType.analogValue);
supportedObjectTypes.add(ObjectType.analogInput);
supportedObjectTypes.add(ObjectType.analogOutput);
to ObjectCovSubscription
That will make it accept the COV subscriptions, and it will send COV notifications, however, it will send a COV notification for any change of the analog value. Which for analog values is probably a bad thing, because they could be changing all the time. The real solution needs to implement some sort of threshold, so that COV notifications are only sent once the value changes enough.
Hi kishorev,
You seem to be using the bacnet4j api in a bit of a strange way. But I can see a few things that might help. First of all before you ask for the object list, you probably need to do a broadcast, simply so that the responding bacnet device knows you exist, otherwise I'm pretty sure it can't respond to you.
You can do it with a broadcast:
localDevice.sendBroadcast(47808, localDevice.getIAm());
Or you can send it a direct message, since you know who you are talking to:
localDevice.sendUnconfirmed(remoteDevice.getAddress(), null, localDevice.getIAm());
Then then other problem is the way you are getting the object list, you are really using internal API methods, you are much better off using:
List<ObjectIdentifier> oids = ((SequenceOf<ObjectIdentifier>) localDevice.sendReadPropertyAllowNull(remoteDevice, remoteDevice
.getObjectIdentifier(), PropertyIdentifier.objectList)).getValues();
Where remoteDevice is an instance of a RemoteDevice, in your case:
Address address = new Address(null,BACnetUtils.dottedStringToBytes("192.168.1.3"),47808);
RemoteDevice remoteDevice = localDevice.findRemoteDevice(address, null, deviceId);