BACnet’s trend log is dead, long live the trend log!

Trend log

BACnet’s object #20, the trend log, is an object in which you can store another object present value at regular time interval, or on change-of-value trigger. It is invaluable when the need to debug a system arises (or to prove to a client that, no, it’s not cold. He simply is hungry and should eat something).

https://frozenlock.files.wordpress.com/2012/07/wpid-trendlog.png

A typical trend log, as shown on bacnethelp.com

Unfortunately, there’s something really bad with trend logs. Really, really really bad. You need to configure them before a problem occurs. For every IOs you want to monitor, you have to create a trend log object and make sure it’s logging the correct IO. (Unless of course you are using my quickly hacked together bacnet-io-creator, which creates a trend log for every IOs.) Another downfall is that logging an object takes non-negligible space in a controller. Thus, you are often really limited in the number of object you can monitor, in addition to the length of time you can monitor it.

There is of course some workaround, such as external databases, which will download the trend logs data at a given interval. Still, the trend log needs to exist for this to work. In addition, this simple step isn’t free even if you use your own SQL database. Again, BACnet proves itself to be very costly!

Continuous logging

With all the disk space available today, why should we limit ourselves with a couple hundred datapoints? Why choose between a temperature and a power consumption? Can’t we just log every friggin thing? Well yes, we can.

Introducing the BACnet Help Logger Vigilia. It’s simple. At every given interval of time, it takes a snapshot of the BACnet network and saves everything1. Now, when a problem arises, you can check the historical data of every BACnet objects regardless of the existence of a trend log object!

Everything is sent to the webserver, which means there’s nothing coming in the user network; there is absolutely no security risk for the user!

The bandwidth usage is also minimum, as the data is compressed and the logger only connects once every hour to send the last hour records2.

And of course, the necessary fail-safes are in place to insure that no data is lost even in case of Internet connection problems. As long as the logger is unable to connect to the server, it keeps the data locally. When the connection is re-established, it then sends everything back to the server. Chances are that the user will never notice anything!

With all this, the trend log object is rendered obsolete! Yet, its spirit lives on. We now have the opportunity to log everything. Long live the trend log!

Footnotes:

1 except trend logs; they are made redundant by this feature

2 by default there’s 6 scans per hour


2 responses to “BACnet’s trend log is dead, long live the trend log!

  • Daniel Porragas

    Hi! the link is broken with Bacnet Help Logger… this is awesome, I worked with ControlNet and DeviceNet (real time logging) before and I hate the fact of being attached to created trendlog objects. By the way, What is the sampling rate of the scanner?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: