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).
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!
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.
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!