From the latest bacnet4j code implementation, I can see that it's only possible to set / read ActionCommand Null values, to the Commandable object / properties, which means only AO, AV, BO, BV, MO, MV and Access-Door objects / present-value property.
I'm currently working with some devices that allow Null values to be set on ActionCommand value settings for any object type so I was wondering if this was a bad standard interpretation from the device implementation.
From the readings of the Standards (I took a look both on 135/2004 and 135/2012), and I could see that the list of Commandable objects has increased but the doubt remains: should or shouldn't it be possible that the ActionCommand values maybe Null for non-Commandable object / properties.
Can somebody please enlighten me about this subject?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was looking at that code version you mentioned already. The issue that I see is in the Encoding.java file, around line 337. If I would bypass that "if condition" and treat all values as Ambiguous, then I would have no problem reading these ActionCommand with Null values, but I don't want to do something like that if it goes against the standard definition.
So, I will pose this question to the BACNet list, as you recommended, but anyway, would you care to give also your opinion on this subject?
Thanks again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My opinion is Null is ok as a value if Null is a permitted value for the referenced object type and property. If this is accurate, then i think the code is too. In what cases do you want to use Null? I.e. what object type / property combinations?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The question is not that I want to set a specific object or property to Null, but the devices that I'm working with, allow the setting of Null values in ActionCommands for any Object Type / Present-Value property.
So, if I read the Action data from these devices with current bacnet4j implementation, the Actions which have these Null values for objects like Analog Inputs, Blind-Outputs, etc (which are not commandable), will not be decoded, and the Action data will not be available.
But again, I don't want to do any sort of fix, without having some other opinions (I'm still waiting for inputs from the Bacnet-L list) which clear this point. If it is considered as valid, by the standard rules, to set these Null values also for non-commandable objects / properties, then I will need to do something about it, else I will not.
Thanks again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the latest bacnet4j code implementation, I can see that it's only possible to set / read ActionCommand Null values, to the Commandable object / properties, which means only AO, AV, BO, BV, MO, MV and Access-Door objects / present-value property.
I'm currently working with some devices that allow Null values to be set on ActionCommand value settings for any object type so I was wondering if this was a bad standard interpretation from the device implementation.
From the readings of the Standards (I took a look both on 135/2004 and 135/2012), and I could see that the list of Commandable objects has increased but the doubt remains: should or shouldn't it be possible that the ActionCommand values maybe Null for non-Commandable object / properties.
Can somebody please enlighten me about this subject?
Thanks
Note that the latest source code is now here: https://github.com/mlohbihler/BACnet4J
Also, your question might better be asked here: http://www.bacnet.org/Contact/BACnet-L.htm. You will get more authoritative answers, rather than just my opinion.
Hello Matthew,
Thank you for your answer.
I was looking at that code version you mentioned already. The issue that I see is in the Encoding.java file, around line 337. If I would bypass that "if condition" and treat all values as Ambiguous, then I would have no problem reading these ActionCommand with Null values, but I don't want to do something like that if it goes against the standard definition.
So, I will pose this question to the BACNet list, as you recommended, but anyway, would you care to give also your opinion on this subject?
Thanks again
My opinion is Null is ok as a value if Null is a permitted value for the referenced object type and property. If this is accurate, then i think the code is too. In what cases do you want to use Null? I.e. what object type / property combinations?
Hi Matthew,
Again, thank you for your answer.
The question is not that I want to set a specific object or property to Null, but the devices that I'm working with, allow the setting of Null values in ActionCommands for any Object Type / Present-Value property.
So, if I read the Action data from these devices with current bacnet4j implementation, the Actions which have these Null values for objects like Analog Inputs, Blind-Outputs, etc (which are not commandable), will not be decoded, and the Action data will not be available.
But again, I don't want to do any sort of fix, without having some other opinions (I'm still waiting for inputs from the Bacnet-L list) which clear this point. If it is considered as valid, by the standard rules, to set these Null values also for non-commandable objects / properties, then I will need to do something about it, else I will not.
Thanks again
Gotcha. I believe it is incorrect for those devices to be so lenient. BTW, i did not see a message from you on the mailing list.
It seems that I'm still on the BACNet-L 'subscription approval' waiting list...
I hope it don't take too long, else I'll be stuck.