bacnet4linux-developer

[Bacnet4linux-developer] BACNet4Linux TimeSync

[Steve K. <sk...@us...>]

Hello Heiko,

You have been added to our developer list.  Welcome!

>>> For this we are using NTP (the Network Time Protocol) and when some 
>>> customer told me about BACNet today, I wanted to find out how a 
>>> BACNet network dealing with time synchronization.
>>
>> You are at the right place!
>>
> That's good :-) I am not quite sure about the market chances we have 
> with such a device. What do you think, could a native BACnet UTC time 
> source be of interest to end users of this system? And, what do you 
> think about the market shares of BACnet in the Building Automation 
> market? I heard of something called LONWorks which looks like a 
> competiting system and cannot really determine at the moment which 
> system is the most wanted in the BA world..

Yes, LON is the competition.  BACnet is the better system :-)

>>> Can you shed some light on this for me? I would like to find out if 
>>> it would make sense to add BACNet support to our time servers which 
>>> then could be used in a BACNet installation. Because they are 
>>> stand-alone appliances, the time synchronization could be taken off 
>>> the shoulders of the workstation and this could add stability and 
>>> (maybe accuracy, too) to the time base of such a network. For this it 
>>> would probably make sense to use your BACNet4Linux and add support 
>>> the four BIBBs I mentioned earlier.
>>
>> It should be trivial to add BACnet support for TimeSync and 
>> UTCTimeSync under Linux using the BACnet4Linux code as a baseline.  In 
>> fact, we already have support for TimeSync in the core code.  You 
>> would probably want to strip out some things, like the HTML and the 
>> query new device code.
>>
> That would make sense. I did not look into your code but I guess it is 
> possible.
> 
>> Also, to be a good BACnet citizen, you need to have a BACnet Device 
>> Object with a unique BACnet ID.  The current code has this using 
>> command line parameters when starting the daemon.
>>
> That's something we have to ask for someone I guess.

It's really just a matter of configuration.  The unique BACnet ID is 
just like an IP address in that it is unique on the LAN and needs to be 
configured in the device.  There is also a special BACnet address that 
acts like a DHCP kind of thing.

If you are going forward to making a BACnet device, you would also get a 
unique Vendor ID, which is free.  A link to the request form is at:
http://www.bacnet.org/VendorID/

>> The BACnet Ethernet layer is working well, but the BACnet/IP layers 
>> needs a little attention.
>>
> Can you specify "needs a little attention" ? :)

With the current code base, BACnet/IP seems to send out messages, but I 
couldn't get it to receive any messages (when I disable the BACnet 
Ethernet layer).  Coleman swears that it used to work, and also has 
given me his latest code which he says works, but I haven't taken the 
time to compare the two to find out why the current BACnet4Linux 
BACnet/IP is not receiving (or possibly not sending with the right 
network layer data).

>> The UTCTimeSync would need to be added, but it should be trivial as it 
>> would mostly be a copy/paste from the TimeSync function.
>>
>> Most of the time the TimeSync is sent out as a global or local 
>> broadcast, but occasionally it is sent out as unicast to a specific 
>> device.  Our current code only has the broadcast.  There is a time 
>> sync reception list in the Device Object, which can contain a 
>> broadcast address or the address of a specific device, and can be 
>> writeable.  I don't think we have that list in our current code.
>>
> How does this work? A "-B" device tells the "-A" device that it wants to 
> receive unicast time synchronization messages at a specific interval? Or 
> on request? Or is the -A device responsible for querying the network and 
> finding devices which need TS messages in unicast form?

Usually the specific interval is a configuration issue and doesn't come 
from an A or B side device.  But it is possible to have a writeable 
recipient list where the B side device requests to be added to the list. 
  In the Lithonia Lighting BACnet device, I have the list configured to 
send out local or global broadcast of time sync at a specific interval 
if it is enabled.  But since that list is not writeable, I don't even 
support the recipient list property of the device object.

Coleman has been doing some work with the 
time-synchronization-recipients property lately.  Perhaps he can chime in.

Best Regards,

Steve
-- 
http://www.kargs.net/

RE: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Coleman B. <col...@co...>]

Welcome!

RE:  BACnet/IP

There were some bugs in the original code I checked in.  Actually, a
pretty silly one was causing the original B/IP code to not work 100% of
the time, the IPLEN variable was calculated incorrectly.  It worked for
addresses like 192.168.1.14, but not 172.62.1.14.  This had a direct
effect on broadcasts.  This is before I knew about the other definition
in the BSD headers.  The current B/IP code has been working (send and
receive!) like a clock for months now...

It's actually a strncpy(npdu->dest_ip, Local_Broadcast_Address, IPLEN)
type of problem.  If the IPLEN variable is wrong, dest_ip didn't contain
the full bcast address.  

RE:  Time-Sync

A BACnet device isn't allowed to simply broadcast time-syncs.
Unfortunately, this is how the current implementation of B4L works.
BACnet device *have* to contain a time-sync-recipient property and it
must be writable.  Even more than that, there are some bizarre rules
with what can be written.  However, Steve is right, it's implemented and
works beautifully.  

What I had considered doing was letting my BACnet device receive it's
time via NTP (ntpd???) and then have my BACnet stack broadcast TimeSync
requests occasionally, say every 15-30 minutes.  So, from my point of
view (in the case of my current implementation), yes this is quite
helpful.  However, can't this be accomplished by the current NTP
mechanisms?  However, my device isn't a workstation.   

Coleman




> -----Original Message-----
> From: bac...@li...
> [mailto:bac...@li...] On Behalf
Of
> Steve Karg
> Sent: Thursday, March 10, 2005 10:51 AM
> To: bac...@li...
> Subject: [Bacnet4linux-developer] BACNet4Linux TimeSync
> 
> Hello Heiko,
> 
> You have been added to our developer list.  Welcome!
> 
> >>> For this we are using NTP (the Network Time Protocol) and when
some
> >>> customer told me about BACNet today, I wanted to find out how a
> >>> BACNet network dealing with time synchronization.
> >>
> >> You are at the right place!
> >>
> > That's good :-) I am not quite sure about the market chances we have
> > with such a device. What do you think, could a native BACnet UTC
time
> > source be of interest to end users of this system? And, what do you
> > think about the market shares of BACnet in the Building Automation
> > market? I heard of something called LONWorks which looks like a
> > competiting system and cannot really determine at the moment which
> > system is the most wanted in the BA world..
> 
> Yes, LON is the competition.  BACnet is the better system :-)
> 
> >>> Can you shed some light on this for me? I would like to find out
if
> >>> it would make sense to add BACNet support to our time servers
which
> >>> then could be used in a BACNet installation. Because they are
> >>> stand-alone appliances, the time synchronization could be taken
off
> >>> the shoulders of the workstation and this could add stability and
> >>> (maybe accuracy, too) to the time base of such a network. For this
it
> >>> would probably make sense to use your BACNet4Linux and add support
> >>> the four BIBBs I mentioned earlier.
> >>
> >> It should be trivial to add BACnet support for TimeSync and
> >> UTCTimeSync under Linux using the BACnet4Linux code as a baseline.
In
> >> fact, we already have support for TimeSync in the core code.  You
> >> would probably want to strip out some things, like the HTML and the
> >> query new device code.
> >>
> > That would make sense. I did not look into your code but I guess it
is
> > possible.
> >
> >> Also, to be a good BACnet citizen, you need to have a BACnet Device
> >> Object with a unique BACnet ID.  The current code has this using
> >> command line parameters when starting the daemon.
> >>
> > That's something we have to ask for someone I guess.
> 
> It's really just a matter of configuration.  The unique BACnet ID is
> just like an IP address in that it is unique on the LAN and needs to
be
> configured in the device.  There is also a special BACnet address that
> acts like a DHCP kind of thing.
> 
> If you are going forward to making a BACnet device, you would also get
a
> unique Vendor ID, which is free.  A link to the request form is at:
> http://www.bacnet.org/VendorID/
> 
> >> The BACnet Ethernet layer is working well, but the BACnet/IP layers
> >> needs a little attention.
> >>
> > Can you specify "needs a little attention" ? :)
> 
> With the current code base, BACnet/IP seems to send out messages, but
I
> couldn't get it to receive any messages (when I disable the BACnet
> Ethernet layer).  Coleman swears that it used to work, and also has
> given me his latest code which he says works, but I haven't taken the
> time to compare the two to find out why the current BACnet4Linux
> BACnet/IP is not receiving (or possibly not sending with the right
> network layer data).
> 
> >> The UTCTimeSync would need to be added, but it should be trivial as
it
> >> would mostly be a copy/paste from the TimeSync function.
> >>
> >> Most of the time the TimeSync is sent out as a global or local
> >> broadcast, but occasionally it is sent out as unicast to a specific
> >> device.  Our current code only has the broadcast.  There is a time
> >> sync reception list in the Device Object, which can contain a
> >> broadcast address or the address of a specific device, and can be
> >> writeable.  I don't think we have that list in our current code.
> >>
> > How does this work? A "-B" device tells the "-A" device that it
wants to
> > receive unicast time synchronization messages at a specific
interval? Or
> > on request? Or is the -A device responsible for querying the network
and
> > finding devices which need TS messages in unicast form?
> 
> Usually the specific interval is a configuration issue and doesn't
come
> from an A or B side device.  But it is possible to have a writeable
> recipient list where the B side device requests to be added to the
list.
>   In the Lithonia Lighting BACnet device, I have the list configured
to
> send out local or global broadcast of time sync at a specific interval
> if it is enabled.  But since that list is not writeable, I don't even
> support the recipient list property of the device object.
> 
> Coleman has been doing some work with the
> time-synchronization-recipients property lately.  Perhaps he can chime
in.
> 
> Best Regards,
> 
> Steve
> --
> http://www.kargs.net/
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Bacnet4linux-developer mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet4linux-developer

Re: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Steve K. <st...@ka...>]

Hi Coleman,

> in the BSD headers.  The current B/IP code has been working (send and
> receive!) like a clock for months now...

Excellent! I will have to fix the bacnet4linux code soon, and yes, that 
string copy caused me problems initially (seg faults) so I converted ALL 
the bacnet4linux code to use the BSD IP address (struct in_addr ip;) as 
address storage and not a string.  I must have missed something else...

> A BACnet device isn't allowed to simply broadcast time-syncs.

Well, actually it is allowed to broadcast time-syncs, provided it has a 
broadcast address as one of the addresses in the list of recipients.

> BACnet device *have* to contain a time-sync-recipient property and it
> must be writable.  Even more than that, there are some bizarre rules
> with what can be written.  However, Steve is right, it's implemented and
> works beautifully.  

You are right - the Time-Synchronization-Recipients property is required 
if the PICS indicates that the device is a Time Master, and it is 
required to be writable if implemented.

Well, it should simply be a matter of implementing the list and handling 
the write property services.  You should be able to whip that code out 
in 15-30 minutes, no? :-)

> What I had considered doing was letting my BACnet device receive it's
> time via NTP (ntpd???) and then have my BACnet stack broadcast TimeSync
> requests occasionally, say every 15-30 minutes.  So, from my point of
> view (in the case of my current implementation), yes this is quite
> helpful.  However, can't this be accomplished by the current NTP
> mechanisms?  However, my device isn't a workstation.   

ntpdate/ntpd keeps the system clock updated, and can update other 
devices via NTP.  BACnet TimeSync would simply rely on the system clock 
and update BACnet devices that are in its recipient list, or simply 
update via global or local broadcast if that is in its recipient list.

Thanks for the update, Coleman, and for the insight!

Best Regards,

Steve
-- 
http://kargs.net/

RE: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Coleman B. <col...@co...>]

Hi Steve,

> -----Original Message-----
> From: bac...@li...
> [mailto:bac...@li...] On Behalf
Of
> Steve Karg
> Sent: Saturday, March 12, 2005 7:04 AM
> To: bac...@li...
> Subject: Re: [Bacnet4linux-developer] BACNet4Linux TimeSync
> 
> Hi Coleman,
> 
> > in the BSD headers.  The current B/IP code has been working (send
and
> > receive!) like a clock for months now...
> 
> Excellent! I will have to fix the bacnet4linux code soon, and yes,
that
> string copy caused me problems initially (seg faults) so I converted
ALL
> the bacnet4linux code to use the BSD IP address (struct in_addr ip;)
as
> address storage and not a string.  I must have missed something
else...

That would have been the optimum solution, and probably easier on memory
requirements.  The strncpy is fairly prevalent now, in my version, so
part of it is laziness on my part to go in and break it again and fix
all those areas. :) I'll have to bite the bullet and do it, though.    


> 
> > A BACnet device isn't allowed to simply broadcast time-syncs.
> 
> Well, actually it is allowed to broadcast time-syncs, provided it has
a
> broadcast address as one of the addresses in the list of recipients.
> 
> > BACnet device *have* to contain a time-sync-recipient property and
it
> > must be writable.  Even more than that, there are some bizarre rules
> > with what can be written.  However, Steve is right, it's implemented
and
> > works beautifully.
> 
> You are right - the Time-Synchronization-Recipients property is
required
> if the PICS indicates that the device is a Time Master, and it is
> required to be writable if implemented.
> 
> Well, it should simply be a matter of implementing the list and
handling
> the write property services.  You should be able to whip that code out
> in 15-30 minutes, no? :-)
> 

Isn't it true that if a device performs a time sync request then it's
considered a time master?  

Funny you say that.  I started implementing the write property service.
The function is there with the beginnings of a parser. So, 15-20 minutes
for *that* property!  :-)

> > What I had considered doing was letting my BACnet device receive
it's
> > time via NTP (ntpd???) and then have my BACnet stack broadcast
TimeSync
> > requests occasionally, say every 15-30 minutes.  So, from my point
of
> > view (in the case of my current implementation), yes this is quite
> > helpful.  However, can't this be accomplished by the current NTP
> > mechanisms?  However, my device isn't a workstation.
> 
> ntpdate/ntpd keeps the system clock updated, and can update other
> devices via NTP.  BACnet TimeSync would simply rely on the system
clock
> and update BACnet devices that are in its recipient list, or simply
> update via global or local broadcast if that is in its recipient list.
> 

Yes, that's precisely what my design called for.  The user tells my
widget to get it's time from external time source (assuming an Internet
connection), and my widget syncs its time with that source.  Then every
15 minutes (is this too often or not often enough? -- maybe
configurable) my widget performs a time sync for everyone in its
time-sync-recipient list (I'm implementing the BACnetAddress flavor).  

> Thanks for the update, Coleman, and for the insight!
> 
> Best Regards,
> 
> Steve
> --
> http://kargs.net/
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Bacnet4linux-developer mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet4linux-developer

Re: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Steve K. <st...@ka...>]

Hi Coleman,

> Isn't it true that if a device performs a time sync request then it's
> considered a time master?  

TimeMaster was one of the functional profiles.  If you claimed Time 
Master functional group, then you had to implement the list.  I think it 
was deprecated in favor of BIBBs in Addendum D to the 135-1995 standard, 
and now there is TimeSync and UTCTimeSync BIBBs.

In the 2004 version of the standard, Time Master is mentioned only 3 
times and each alongside time-synchronization-recipients, but there is 
no definition or reference in the PICS to the Time Master, so this is 
most likely a holdout from the 1995 standard that has yet to be fixed in 
todays standard.

Perhaps we should discuss it at the BTL or the next SSPC meeting, or put 
forth a proposal to eliminate the wording, or simply ask the SSPC for a 
clarification: what is a Time Master or what is definition of a time 
master? (but clarifications requests need to be answerable as YES or NO, 
so someone needs to do the research).

> Yes, that's precisely what my design called for.  The user tells my
> widget to get it's time from external time source (assuming an Internet
> connection), and my widget syncs its time with that source.  Then every
> 15 minutes (is this too often or not often enough? -- maybe
> configurable) my widget performs a time sync for everyone in its
> time-sync-recipient list (I'm implementing the BACnetAddress flavor).  

Configurable cycle time is preferable, IMHO.

Best Regards,

Steve
-- 
http://kargs.net/