Hi All,

I have a query regarding pointWrite operation. We are representing BACnet points in Haystack.

Understanding:

1) "level" parameter is mandatory in pointWrite operation

2) Response of pointWrite operation will always have values at level 1-17. E.g. Response will be:

level,levelDis,val,who

1,"1",,

2,"2",,

3,"3",,

...

10,"10",338,"Test"

...

16,"16",,

17,"17",,

Queries:

1) Is above understanding correct ?

2) What if point to be written is not commandable i.e. point does not have priority-array and relinquish-default parameters ?

• (a) Is "level" parameter still required in pointWrite operation ?
• (b) If "yes" for "(a)", then

(b.1) Should it be ignored for not commandable points ?

(b.2) For response, at which level, should the changed value be shown ?

(b.3) If "level" is 17 in response, should the point's value be changed ? Reason for asking this query is - level 17 represents default value (i.e. relinquish-default). User may not intend to change the value of point when he says level 17.

(b.4) If point is not commandable, showing level and levelDis in output may not make sense. Is it still required ?

Looking for your inputs.

Thank you.

1. Yes your understanding is correct. The Haystack model maps exactly to the BACnet model with a priority array of 1-16 levels and 17 being "relinquish default". You might want level 8 dis to be something like "Manual Overview" for example
2. If you are writing something that is not a classic output point with the 16-level point array, then you should not use this operation - its only for writable points that support a priority array. There is currently no generic "write tag/property" operation in the API

Thanks Brian. In BACnet, we have Analog-Value object, which can be a writable point without having a need to support 16-level priority array.

Similarly, there are other protocols like Modbus having writable point but no support for priority array.

Does it mean that all such points cannot be written using pointWrite operation ?

Does it mean that all such points cannot be written using pointWrite operation?

I would say that if the device/gateway is supporting Haystack that it should "front" the point with priority array support. That way we have interoperability that writable points always have control resolution via a priority array

But that is more of a personal opinion. Its probably more a matter for community debate if we should support writable points without priority array support.

Ahha ... And I always thought that in such a case priority will be ignored and response will show that value is written at level 16.

But as you said this is similar to Haystack gateway covering up for points having no support for priority array.

I was not sure for behavior for level 17 though. I guess, behavior for such a case can be defined for our system and documented

Hi All,

I am a bit confused about behavior of pointWrite operation.

We are representing BACnet in Haystack and developing Haystack server. Let's say Haystack Point represents some Analog Output (AO) object in BACnet.

1) Say initially AO object's properties are:

Priority-Array = PA1,
Present-Value = PV1,
Relinquish-Default = RD1

2) A pointWrite request-1 is received to read values. Response will be:

Level 1 to 16 = PA1,
Level 17 = RD1

3) A pointWrite request-2 is received to write a value. Changed values of AO would be:

Priority-Array = PA2,
Present-Value = PV2,
Relinquish-Default = RD1

Now, what would be the response ? Would it be "a)" or "b)" given below ?

a) Last known values of properties of AO, i.e.

Level 1 to 16 = PA1,
Level 17 = RD1

b) Updated values of properties of AO after serving this pointWrite request-2,

Level 1 to 16 = **PA2**,
Level 17 = RD1

Please suggest. Thanks.

The docs are a little ambiguous on that. I would say you return the updated priority array (one after write). But in our system we don't actually return anything which is probably better to define as the official behavior. You might be doing a lot of writes and I can't imagine returning the whole priority array on every write would be all that useful (for the overhead required)

I pushed change to docs for this: changeset

Thanks Brian !! This change makes it very clear :)