Differences

This shows you the differences between two versions of the page.

--- controls:protocols:bacnet:qna [2020/10/03 19:23] – old revision restored (2020/09/30 16:24) 192.99.13.75
+++ controls:protocols:bacnet:qna [2020/10/04 07:06] (current) – old revision restored (2020/09/30 22:04) 178.151.245.174
@@ Line 29: / Line 29: @@
 - 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
+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:
+. Is today’s year within the range of years?
+and
+. Is today’s month within the range of months?
+and
+. Is today’s day-of-month within the range of days?
+and
+. 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 =====
@@ Line 56: / Line 115: @@
 - 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