Shouldn't outOfService object property be writable?

[veodko]

I'm interested with this project and tried to start some of the examples, like the ThermostatDevice custom class.

I noticed though, that the outOfService object property seems to be readonly, trying to write to this property results in an ERROR_CODE_WRITE_ACCESS_DENIED. Looking at the source code this seems to be caused by the configuratio nof BDSingletProperty writable parameter as false in object.js:

this.outOfService = this.addProperty(new BDSingletProperty(PropertyIdentifier.OUT_OF_SERVICE, ApplicationTag.BOOLEAN, false, false));

bacnet:transport:debug server got message from 10.1.2.79:51451: 810a0016010400756f0f0c0000000119513e113f4910 +10s
  bacnet:client:trace handlePdu Header:  {
  func: 10,
  sender: { address: '10.1.2.79:51451', forwardedFrom: null },
  apduType: 0,
  expectingReply: true
} +10s
  bacnet:client:trace Received service requestwith invokeId 111: writeProperty +2ms
  bacnet:client:trace Handled service requestwith invokeId 111: writeProperty {"len":4,"type":0,"service":15,"maxSegments":112,"maxApdu":5,"invokeId":111,"sequencenumber":0,"proposedWindowNumber":0,"header":{"func":10,"sender":{"address":"10.1.2.79:51451","forwardedFrom":null},"apduType":0,"expectingReply":true,"confirmedService":true},"payload":{"len":12,"objectId":{"type":0,"instance":1},"value":{"property":{"id":81,"index":4294967295},"value":[{"type":1,"value":true}],"priority":16}}} +12ms
  bacnet:client:trace listener count by name emits writeProperty with content. {
  bacnet:client:trace   len: 4,
  bacnet:client:trace   type: 0,
  bacnet:client:trace   service: 15,
  bacnet:client:trace   maxSegments: 112,
  bacnet:client:trace   maxApdu: 5,
  bacnet:client:trace   invokeId: 111,
  bacnet:client:trace   sequencenumber: 0,
  bacnet:client:trace   proposedWindowNumber: 0,
  bacnet:client:trace   header: {
  bacnet:client:trace     func: 10,
  bacnet:client:trace     sender: { address: '10.1.2.79:51451', forwardedFrom: null },
  bacnet:client:trace     apduType: 0,
  bacnet:client:trace     expectingReply: true,
  bacnet:client:trace     confirmedService: true
  bacnet:client:trace   },
  bacnet:client:trace   payload: {
  bacnet:client:trace     len: 12,
  bacnet:client:trace     objectId: { type: 0, instance: 1 },
  bacnet:client:trace     value: {
  bacnet:client:trace       property: { id: 81, index: 4294967295 },
  bacnet:client:trace       value: [ { type: 1, value: true }, [length]: 1 ],
  bacnet:client:trace       priority: 16
  bacnet:client:trace     }
  bacnet:client:trace   }
  bacnet:client:trace } +2ms
  bacnet:device:device req #+10s: writeProperty
  bacnet:device:device error while handling request: Error: not writable

Is there any way to actually make outOfService writable without having to make a custom clone of the built-in basic object?

[jacoscaz]

@veodko hello! The outOfService property is currently non-writable because we haven't had the time (nor the need, for now) to look into its semantics and what setting it to true would mean for the rest of the object. It's a feature that is currently missing from this library.

Multiple ways forward:

1. If you are familiar with BACnet and the semantics of this property, a PR would be more than welcome. I'd be more than happy to provide any guidance needed.
2. If not or if you do not have the means/time for a PR, having this issue open is a good way for me to prioritise this feature during my next round of tweaks to this library as I know someone else has a need for it.

[veodko]

Thanks for such a quick response.
I'm not really that familiar with BACnet, just a novice. Having tested some other stacks earlier (like the C bacnet-stack) the default behaviour was to block any presentValue updates while outOfService was set. I guess it depends on the use case if outOfService should be implemented or not, but having any way to decide if it should be writable would be nice so it could be handled in code.
As for now I think it's impossible to override this without having to reimplement the entire object, because it's all private in the internal classes.

By the way, is there any way to manipulate object identifiers/instance numbers in a custom manner? Currently object identifiers are incremented automatically and I think there is no other way, because even if I'd use the internal __setIdentifier() method before adding object to device, the call to device.addObject() throws an error since it tries to set the identifier again. Perhaps should be a separate issue.

[jacoscaz]

Thanks for such a quick response.

No worries :). Doesn't always happen but this morning it's a mail-heavy morning, helps with noticing things quickly.

Having tested some other stacks earlier (like the C bacnet-stack) the default behaviour was to block any presentValue updates while outOfService was set.

I will have a look at the ASHRAE spec. If that's all of the semantics of outOfService then implementing it should be a (very) quick thing.

As for now I think it's impossible to override this without having to reimplement the entire object, because it's all private in the internal classes.

That's correct. I guess one possible intermediate step would be to simply make that property optionally writable and let users act according to it. I will have a look at let you know.

By the way, is there any way to manipulate object identifiers/instance numbers in a custom manner?

No, as you correctly identified right now numbering is automatic. Please feel free to open a dedicated issue for this. Out of curiosity, what use case of yours requires custom numbering?

[jacoscaz]

Ok, things seem a little more complex. Here's an excerpt from section 12.2.10 of ASHRAE Standard 135-2020, which details the Out_Of_Service property within the context of the Analog Input object type:

This property, of type BOOLEAN, is an indication whether (TRUE) or not (FALSE) the physical input that the object represents
is not in service.

When Out_Of_Service is TRUE:

1. the Present_Value property is decoupled from the physical input and will not track changes to the physical input;
2. the Reliability property, if present, and the corresponding state of the FAULT flag of the Status_Flags property shall
   be decoupled from the physical input;
3. the Present_Value property and the Reliability property, if present and capable of taking on values other than
   NO_FAULT_DETECTED, shall be writable to allow simulating specific conditions or for testing purposes;
4. other functions that depend on the state of the Present_Value or Reliability prop

Based on the above, the exact implementation semantics of Out_Of_Service are highly context-specific and probably not something that can be easily generalised in this library. Proposal:

1. Add an option to configure the writability of the Out_Of_Service property.
2. Add new object-level out-of-service, in-service events and isOutOfService(), setOutOfService() methods to surface this state at the object level.

@veodko @robertsLando @mandrake-sw what do you think?

[veodko]

I think letting the end user decide if or how he wants to implement this is okay, as long as it's possible to allow writing to this property.

As for the numbering use case, I've seen actual BACnet devices often follow this pattern of numbering objects in "groups" that reserve space for any future updates of the object list.

So something like:

# Configuration block 1
AV1001
AV1002
AV1003

# Configuration block 2
AV2001
AV2002
AV2003

this allows easy future updates when you know new objects could be added in the future. Prevents shifting current instance numbers (lets say some clients rely on them, that would cause troubles) and keeps things organized.

[jacoscaz]

@veodko are you in a position to test #30 ? See the dedicated example: https://github.com/bacnet-js/device/blob/7184b6ad6f3426d5ae54edef51130d1eb38abc81/src/examples/06-out-of-service.ts .

[robertsLando]

@jacoscaz sorry for the late reply. I agree with @veodko comment