Hello

Can anyone tell what is the state of discussion on inverted networks?

Are there any related proposals under consideration? Rejected? Tabled?

What is the committee or OS-WG opinion on it?

Does anyone care on bringing any of the porposals further down the
road?

Thanks for upadting me on this.

Bernhard

Dear OS-WG members,

Our BACstac team has been reviewing the latest public review draft of
Addendum 135-2004b, and they have some questions/comments about the
Global Group object type which I am forwarding to you for your
consideration.

Regards,

- Jim Butler



1. In 12.Y.8 Status_Flags, there is a reference to the Out_Of_Service
property, but there is no such property in the Global Group object.

2. The purpose of Update_Interval (12.Y.13, page 15) is not exactly
clear. In particular, I wonder how different it is from the
Requested_Update_Interval? Shall they always be same or can they differ?
When and how?

3. In 12.Y.21 Notification_Period (page 16), it is said that
UnconfirmedCOVNotification messages should be sent with this period, but
it is not clear to whom. If notifications are sent to those who
subscribed to the Present_Value then the question is whether we should
filter out those who subscribed to confirmed notifications? Or maybe
this unconfirmed notification is meant as some sort of global broadcast?

4. The criteria for sending COV notifications described in Table 13.1
(page 17) are very confusing. They are defined as:

  If Present_Value changes at all
  or
    Member_Status_Flags changes at all
  or
    A periodic update of Present_Value occurs


Accordingly to 12.Y.10 Member_Status_Flags (page 14),
Member_Status_Flags is
defined on basis for Present_Value. Therefore it cannot change unless
Present_Value is changed. So the second condition seems to be redundant.
Then it is not clear what is meant by a periodic update of Present_Value
occurs. Does it mean the notification should be sent with
Update_Interval or
Requested_Update_Interval? Also, the criteria for sending notification
does
not mentioned Notification_Period at all, though 12.Y.21 requires that
unconfirmed notifications send with this period.

5. There is a small notice at the bottom of page 17 saying:
==
Elements of Present_Value must be sent in order, and the first element
shall
be element 0 (the array size). If the notification is too large to fit
within a single message, then multiple notifications shall be sent in
order to convey all elements.
==

5.1. Do I understand correctly that notifications sent Present_Value not
as a single array value, but as sequence from its element starting with
element 0?

Is this format for sending notifications specific for this particular
property or if a device supports COV subscriptions to another array
property (using SubscribeCovProperty service) then the value of that
property should be sent in the same way?

5.2. The last sentence of that notice requires that a notification that
is too large to fit in one request shall be sent as multiple
notifications. Does this requirement apply to confirmed notifications
too? I mean, in 13.7 on page 29, this requirement is added for
unconfirmed service, but there is no such requirement for unconfirmed
service. However, if the destination device does not support
segmentation, then we have the situation with too long request exists
for both confirmed and unconfirmed requests.

6. In 12.Y.10 Member_Status_Flags (page 14), Member_Status_Flags is
defined as "a logical combination of all the Status_Flags properties
contained in the Present_Value." However, the value of one (or more)
the Status_Flags
properties contained in the Present_Value may have a value of type
PropertyAccessError. Obviously, it is impossible to apply logical
operation in this case. So what should be the value of
Member_Status_Flags property?

7. What should be done when Group_Members property is changed?

The addendum says:

        12.Y.7 Present_Value
        ....
        If the Group_Members property is writable and the size of
        the array is increased, the Present_Value array shall be
        increased in size to match with the value of the new array
        elements being determined through the same mechanism that
        is used to update the values.


        12.Y.7.1 Initializing New Array Elements When the Array
        Size is Increased

        If the size of the Present_Value array is increased by
        writing to the size of either the Group_Members or
        Group_Member_Names property, the new array entries shall be
        initialized with the Access Result parameter having a value
        of type PropertyAccessError, with an Error Class of
        PROPERTY and an Error Code of VALUE_NOT_INITIALIZED. The
        other parameters shall have values consistent with the
        corresponding entry in the Group_Members array.

So how to initialize a new element when the is increased?
My interpretation of the text above is that the new property shall be
initialized to with an Error Class of PROPERTY and an Error Code of
VALUE_NOT_INITIALIZED, and then updated immediately through the regular
mechanism without waiting for Required_Update_interval.

The addendum says nothing above the situation when an existing element
of the Group_Members property is changed. Should we assume that the same
procedure should be performed as for a new element?

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OS028-v1.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Spring 2007 OSWG Summary

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OS028-v1.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

rob_sbt <robjohnson@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /Add-B-Comment-Tracking-Sheet-rev01.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Addendum b PR3 comment worksheet

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/Add-B-Comment-Tracking-Sheet-rev\
01.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

rob_sbt <robjohnson@...>

Hi, All

I've posted a document to the OSWG Yahoo group listing the PR3
comments and preliminary ideas for responses.  There are a few places
where feedback from the authors of the original proposals (mainly
Global Group and Trend Log Harmonization) would be helpful.  Of
course, commenter feedback is needed as well.

Thanks in advance,

Bob Johnson
Siemens Building Technologies
OSWG Convener

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /Add-B-Comment-Tracking-Sheet-rev03.doc
   Uploaded by : carlneilson <cneilson@...>
   Description : Addendum b comment tracking worksheet

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/Add-B-Comment-Tracking-Sheet-rev\
03.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

carlneilson <cneilson@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /Add-B-Comment-Tracking-Sheet-rev04.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Addendum b comment tracking worksheet

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/Add-B-Comment-Tracking-Sheet-rev\
04.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

rob_sbt <robjohnson@...>

Hello

An addendum j PR comment highlighted that the language in
the "Criteria" column of table 13-2 for the BI, BV, MSI and MSV object
types is inconsistent with the CHANGE_OF_STATE algorithm language in
13.3.2.

I took the task to write a change proposal to fix this as part of the
resolution of that comment. But before I start with this:

Is there already any pending change proposal attempting to fix this?

Thanks for any update on this.

Bernhard

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /stk-019-3.doc
   Uploaded by : stephenkarg <steve@...>
   Description : stk-019-3 Special Property Clarifications

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/stk-019-3.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

stephenkarg <steve@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /Add-B-Comment-Tracking-Sheet-rev05.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Addendum b Comment Tracking Sheet Revision 5

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/Add-B-Comment-Tracking-Sheet-rev\
05.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

rob_sbt <robjohnson@...>

Regarding the Analog Output object:

Since the BACnet standard says that Max_Pres_Value "indicates the highest
number that can be reliably used for the Present_Value property of this
object" and since fault is tied to reliability and since AO objects don't
usually change their own present values - I would expect a TO-FAULT
transition if present value is written outside the range.

I also think it would be good practice for any device wrting present value
to enforce its own min. and max. based on what the AO has defined.

Cliff Copass
Johnson Controls, Inc.






              christoph.zeller@
              ch.sauter-bc.com
              Sent by:                                                   To
              bacnet-oswg@yahoo         bacnet-oswg@yahoogroups.com
              groups.com                                                 cc

                                                                    Subject
              07/18/2007 05:31          [bacnet-oswg] BACnet Writing Out of
              AM                        Range Values to Priority Arrays


              Please respond to
              bacnet-oswg@yahoo
                 groups.com







Hi all,
I encountered a problem writing a value to the priority array of an analog
output object.
What should happen, if I try to write a value to present-value that is
higher than max-pres-value property.
I could either respond with a VALUE-OUT-OF-RANGE error, or I could generate
a TO-FAULT transition if the value
is becoming the present-value.
The same can be achieved when writing to max-pres-value or min-pres-value.
The problem is, that for analog outputs objects there is no OVER-RANGE and
UNDER-RANGE defined as in the analog input object.
Is this a mistake?

The next problem is how to send a TO-FAULT message as this message seems
not to be described either in the standard nor in the
teststandard.

Does anybody know an answer to this "problem"?

Thanks in advance
Regards Christoph Zeller

Fr. Sauter AG
Christoph Zeller
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider whether
it is really necessary to do so.
Using less paper helps the environment.

Hi David,
I was looking for your propsal DMF-036.
Thanks for pointing out the behaviour of out-of-service and the
writability.

In figure I-2 you show the behviour of an output object.
I would suggest to add an additional path for writing to interface value.
Reason, If an output is set to out of service, there is no way to set the
physical output using bacnet services.
Once in OUT-OF-SERVICE mode, the interface value will not move anymore.
If we would add the same service as in the input objects "writes to
interface value" to the left and connect this with
the true path that disables the connection from present value. We could
stick to the behaviour but savely park the
physical output in the desired position.
I would offer to add the modifications in the graphics if desired to do
so. Unfortunately I cannot edit the graphics
in the proposal.
What do you think about this modification?
Best regards Christoph

Fr. Sauter AG
Christoph Zeller
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether it is really necessary to do so.
Using less paper helps the environment.

Cristoph,
Sorry for the delay in my reply.

Yes, we could add this kind of functionality to the diagram.
There are several concerns though. We should consider these
issues before deciding what to do:

1. We do not want to FORCE writability of Interface_Value.
    Yes, if you want to implement this in your product, then OK
    it should work the way you described (maybe). This implies
    to me another parallel switch based on Out_Of_Service
    where Writes to Interface_Value are routed to nothing
    when Out_Of_Service is false and to Interface_Value when
    Out_Of_Service is true.

2. I am not sure that Interface_Value is necessarily writable
    ALWAYS under these conditions. I think it is subject to
    the Override Decision. In that case, the bucket we show
    as Last In-Service Value is really the thing that gets
    written if you write to Interface_Value, but the actual output
    may be a manual setting if it's overridden. This depends on
    how override is implemented in the device, and BACnet doesn't
    decide this.

Can you describe the use case where an output is Out_Of_Service=true
but you still need to change the physical output?

David Fisher
PolarSoftR Inc.
914 South Aiken Ave
Pittsburgh PA 15232-2212
dfisher@...
www.polarsoft.biz
412-683-2018
412-683-5228 fax


-----Original Message-----
From: Christoph Zeller [mailto:christoph.zeller@...]
Sent: Thursday, November 29, 2007 7:57 AM
To: dfisher@...; bacnet-oswg@yahoogroups.com
Subject: [bacnet] proposal dmf-036

Hi David,
I was looking for your propsal DMF-036.
Thanks for pointing out the behaviour of out-of-service and the
writability.

In figure I-2 you show the behviour of an output object.
I would suggest to add an additional path for writing to interface value.
Reason, If an output is set to out of service, there is no way to set the
physical output using bacnet services.
Once in OUT-OF-SERVICE mode, the interface value will not move anymore.
If we would add the same service as in the input objects "writes to
interface value" to the left and connect this with
the true path that disables the connection from present value. We could
stick to the behaviour but savely park the
physical output in the desired position.
I would offer to add the modifications in the graphics if desired to do
so. Unfortunately I cannot edit the graphics
in the proposal.
What do you think about this modification?
Best regards Christoph

Fr. Sauter AG
Christoph Zeller
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether it is really necessary to do so.
Using less paper helps the environment.

Dear BACneteers,
I got a few remarks from the BIG-EU concerning the event_suppression
proposal.
I thank Gerhard Baar for his valuable comments on the topic.
As announced in the BIG-EU meeting of vienna from december I herewith send
the
enhanced release of the proposal to the oswg group as well.
Thanks for your help
If required, I could present the ideas in the New York meeting as well.
Regards Christoph Zeller

Christoph Zeller
Abt. NT
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether
it is really necessary to do so.
Using less paper helps the environment.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OSWG-NY-08-Agenda-v1.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : NY OSWG Agenda, rev 1

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OSWG-NY-08-Agenda-v1.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rob_sbt <robjohnson@...>

Dear BACneteers,
attached you find my notes to the proposal CLB-007-1 for discussion on
Sunday.
Regards Christoph

Christoph Zeller
Abt. NT
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider whether
it is really necessary to do so.
Using less paper helps the environment.
(See attached file: CZ-CLB-007-1.doc)

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OS031.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Winter 2008 OSWG Summary, rev 1

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OS031.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rob_sbt <robjohnson@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OSWG-Proposals-08-01-29.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Updated list of active and inactive OS-WG proposals

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OSWG-Proposals-08-01-29.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rob_sbt <robjohnson@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /08-01-21-IEIEJ-Meeting-Notes.doc
   Uploaded by : rob_sbt <robjohnson@...>
   Description : Direction on Add p, Comment on Add k, Commander Proposal

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/08-01-21-IEIEJ-Meeting-Notes.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rob_sbt <robjohnson@...>

Dear Bacneteers
enclosed you find a draft of my propsal regarding intrinis reporting.
This draft will be enlarged during the next few weeks.
Please look to the chapter up to analog inputs only.
What is the general consens about changing the behaviour of limit_enables:
I got the impression that nobody has a use-case for the current behaviour
to disable the reporting only.

Best regards Christoph Zeller
Christoph Zeller
Abt. NT
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether
it is really necessary to do so.
Using less paper helps the environment.

Dear Bacneteers,
I finally finished the first revision of the Intrinsic Reporting proposal.
Thanks for some answers, I tried to incorporate them to my proposal.
It seems that there are two main points remaining:
- Some would like to change the behaviour of Event_Enable flags, what I
think is a bad idea do to a large number of implementations. Let's keep it
as disabling reporting only this means that the Event_State will change
regardless of the flags as well as the Event_Ack bits are cleared and the
Event_Timestamps will be set.
- There are some ideas for the behaviour of the Limit_Enable which range
from
   - disable the reporting only (as mentioned in the standard but not
cleary spoken out?, does anyone has a use-case for it?)
   - disable the state machine (what it eventually was invented for?, A
mechanism for dynamic disabling is required as mentioned in the proposal)

I generally moved the description of the event-generation to Event_State
in all objects
The description has not been done for safety objects and the insertion
points for the multistate output and multistate value are not incorporated
yet.
The language has been harmonized among all objects touched

Some parts are printed in outline font and are used for historic
information only.

This draft could be used as a base for discussion in Ismaaing near Munich
on Thusday
Best regards
Christoph Zeller



Christoph Zeller
Abt. NT
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether
it is really necessary to do so.
Using less paper helps the environment.

Dear Bacneteers,
it's done I have my first edition of the new proposal regarding intrinsic
reporting ready.
The objects have partly been grouped together, for example the text ro
analog input, analog output and analog value objects has to be identical.
Life safety objects and new objects (those in addedas weather published or
in review) have not been adressed.
Please feel free to comment on the proposal. Maybe I wrote things down the
wrong way either for misunderstanding or for other reasons.
This attempts to get a better description of the whole intrinisic
reporting area.
It is not generally intended to change the current standard.
Best regards

Christoph Zeller
Abt. NT
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter-controls.com

DISCLAIMER:
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.

Before printing out this e-mail or its attachments, please consider
whether
it is really necessary to do so.
Using less paper helps the environment.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OSWG-Proposals-08-04-11.doc
   Uploaded by : bi71259 <bernhard.isler@...>
   Description : List of active and inactive OS-WG proposals

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OSWG-Proposals-08-04-11.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

bi71259 <bernhard.isler@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-oswg
group.

   File        : /OSWG-Agenda-200804-Gtown-v1.doc
   Uploaded by : bi71259 <bernhard.isler@...>
   Description : Germantown 2008 meeting agenda v1

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-oswg/files/OSWG-Agenda-200804-Gtown-v1.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

bi71259 <bernhard.isler@...>