HVAC Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== BACnet Questions and Answers ======

Here are a few interesting Q&A gathered from the BACnet mailing list.


===== Broadcasts =====
??? Can devices ignore Who-Is broadcasts?
When sending a Who-Is broadcast, I have some devices that won't answer I-Am like I would expect them to.

- Christian Fortin

!!!
(…) broadcasts can and will get lost, especially when there are a lot of them. If you broadcast a Who-Is with no parameters, ALL devices have to answer, so you will get a flurry of I-Am, some of which may get dropped.

- John Hartman

!!! See the related [[http://blog.hvac.io/2015/01/11/network-discovery-with-devices-ignoring-whois/|blog post]]

??? Should a BACnet/IP router answer to global broadcast messages?

New version of the Tridium Jace bacnet module, if configured to act as a bacnet/ip - MSTP router, will respond to "local" broadcast message (ex. 192.168.1.255)

But not to Global broadcast messages (ex. 255.255.255.255)

- Christian Tremblay

!!!
B/IP messages sent to 255.255.255.255 should be handled as normal BACnet broadcasts, as that address is reserved for broadcasting on the local subnet. So, these messages should be handled identically to messages sent to the broadcast address of the subnet.

- Coleman


===== DateRange =====

??? BACnetDateRange every year

One of our customers wants to setup a BACnetDateRange from 1.November to 30.April. _Every Year_

In my reading of the BACnet Spec, this is not allowed:
Chapter 12:
...Date_List property ...  Both startDate and endDate may be an unspecified date or a specific date only.

Is there an other solution?

- Andreas

!!!

There is a long and complex history behind DateRanges in Schedules.
The short version is that the original 1995 language in the standard was not sufficiently
clear about how DateRanges were intended to work, due to a lack of consensus
about the wording. Regrettably this caused several incompatible implementations to
exist in the marketplace. When the SSPC attempted to readdress this issue in the
2004 standard, the compromise was to make the restriction of “all wildcard” or “no wildcard”
as the only options for DateRange. This is too bad because there are many DateRange
wild combinations that are useful.
 
The original idea (which was not articulated thoroughly in the standard) was that in DateRanges
where there are any wildcards, each of the four ranges needs to be treated in a strict
order of precedence: year, month, day-of-month, day-of-week. The test for something
being “within the date range” is that it passes four tests in this order:
1. Is today’s year within the range of years?
and
2. Is today’s month within the range of months?
and
3. Is today’s day-of-month within the range of days?
and
4. Is today’s day-of-week within the range of days of week?
 
So using Gerhard’s example:
startdate             year=ANY, month=ANY, day=ANY, dayofweek=Monday
enddate               year=ANY, month=April, day=ANY, dayofweek=ANY
 
To match this range a date must perform these steps:
>since start and end year=ANY it always matches year
>since start and end month is ANY through April this is the same as having said “January through April”
>since start and end day=ANY it always matches day
>since start and end dayofweek is Monday through ANY this is the same as having said “Monday through Sunday”
 
So the <<intended>> logic of Gerhard’s example boils down to “is the month between
January and April inclusive”?
 
The key idea, which a lot of people didn’t get because the standard was not clear enough,
was that the evaluation of range is different when there are any “ANYs” in the 8 fields of the range.
 
This is a moot point now, but that’s how we intended for it to work.
 
- David Fisher

===== max_info_frames =====


??? Can adjusting the max_info_frames increase overall network speed?

Would it matter if the devices do NOT support read_property_multiple?

- Bob Kline
!!!
Adjusting max_info_frames can improve performance – or make it worse.
 
If the link has a “system controller” who initiates most requests (read a bunch, write a bunch, repeat), then increasing that device’s max_info_frames is usually a good idea, to avoid needing to wait for a token pass that no one else will use anyway.
 
Similarly, a router from IP to MS/TP should usually have a reasonably large max_info_frames, since the router often represents multiple devices on some other network.
 
BUT: if you go TOO large, then one device can dominate the link, slowing the token rotation time, so that everyone else will have to wait longer to send their own requests.  And a gigabit IP device can ALWAYS swamp a 76800 baud MS/TP link
 
- John Hartman

!!!
To question 2) 
Devices not supporting READ-PROPERTY-MULTIPLE may significantly slow down the network. 
The reason is: 
- If multiple properties from the same device need to be polled by another deivce (controller or workstation) then individual READ-PROPERTY services need to be issued. 
The amount of extra tokens used when a workstation updates it's status depends on how many properties are read from single devices. 

- Christoph Zeller



===== Status Indicator =====

??? Are there any specific requirement for status indicators (LED) for BACnet?

We have Module & Network Status Led for Ethernet IP and its behavior is driven from standard.
Are there any specific requirement for status indicators for BACnet IP as well? I don’t see any in specifications?

-Gajanan S Bhatarkar

!!!
BACnet does not specify status indicator LEDs, for any of its datalinks. Any status indication on BACnet/IP and other media by LEDs is purely a product determination.

- Bernhard Isler

===== SubscribeCOVProperty =====
??? SubscribeCOVProperty with Large Analog Value Objects

While implementing new objects we found a potential issue:
 
How do I subscribe to the Present Value of a Large Analog Value object?
The service seems to use REAL only, DOUBLE seems not to be supported.
Is the COV_Increment supposed to support REAL only and we need to convert it internally?

- Frank Schubert

!!!
There was an Interpretation Request started during the last meeting in April dealing with this exact issue.
 
The basic question was stated as
The COV Increment in the SubscribeCOVProperty service is of datatype REAL, but the concept of a COV Increment applies to any numeric datatype (see 13.15.1.1.6).  …
 
The proposed interpretation offered by the author (Carl) was:
When the datatype of the monitored property is numeric, and not REAL, the server shall accept the COV Increment and convert it to the datatype of the monitored property.
 
My memory is that there were some rough edges in the Interpretation Request language that made simple agreement problematic, and the author was going to make a few changes, and resubmit so that this could be resolved.  We have some history with data type coercion in the lighting area (Channel), so it may be possible to use most of the same ideas.
 
-Cliff Copass