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/