controls:protocols:bacnet:qna
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | |||
controls:protocols:bacnet:qna [2020/10/04 00:48] – old revision restored (2020/09/30 16:24) 92.220.10.100 | controls:protocols:bacnet:qna [2020/10/04 07:06] (current) – old revision restored (2020/09/30 22:04) 178.151.245.174 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Questions and Answers ====== | + | ====== |
Here are a few interesting Q&A gathered from the BACnet mailing list. | Here are a few interesting Q&A gathered from the BACnet mailing list. | ||
Line 29: | Line 29: | ||
- Coleman | - 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, | ||
+ | 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 | ||
+ | enddate | ||
+ | |||
+ | 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 << | ||
+ | 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 ===== | ===== max_info_frames ===== | ||
Line 47: | Line 106: | ||
- John Hartman | - 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, | ||
+ | |||
+ | -Cliff Copass |
controls/protocols/bacnet/qna.1601772516.txt.gz · Last modified: 2020/10/04 00:48 by 92.220.10.100