Catching log messages

Catching log messages

When you design an automation solution intended to last, you must think about integrating tools which you will need one day to detect failure signs or aging signs. In some cases, this goes through managing error messages or exceptions. But on top of this, there can be diagnostic information transmitted by the modules: log messages. We are going to show you here how to integrate them into your projects.


Log messages are typically used to signal abnormal situations in order to understand the source of the issue. The messages are often too rich in information to be treated automatically, but you must make them available to the users to allow them to take the necessary corrective actions.

Message origin

When you work with Yoctopuce modules, there are two sources for log messages:

  1. The logs produced on the host machine by the library enabling communication with the modules, for example to signal errors or unexpected disconnections
  2. The logs produced by the modules, to signal abnormal conditions detected by the modules themselves, such as a measuring probe disconnection, for example


When you use the Yoctopuce modules interactively with the VirtualHub tool, these log messages are directly available to the developer: in the VirtualHub console for the first ones, and in a window called by the view device log button for the latter:

Log window of a Yocto-Pt100
Log window of a Yocto-Pt100



In your automation solution, it is therefore wise to collect these messages and to make them available to the user as a diagnosis tool. This is what we did for example in the Yocto-Visualization application, where the view logs option of the contextual menu enables you to access this information.


How to do so?

The best way to collect these messages is to configure a callback function which is called for each message. You can then store the message to display it later on.

To retrieve the messages of the communication library, use the RegisterLogFunction method of the YAPI global object. For example, it looks as follows in C#:

static public void apiLog(string message)
{
    // ... you must store the message
}

YAPI.RegisterLogFunction(apiLog);



To retrieve the messages produced by the modules themselves, use the RegisterLogCallback method on each module object that you want to monitor, in the same way that you would install a value change callback. One of the best places to do so is in the module arrival callback, itself installed with RegisterArrivalCallback:

static void deviceLog(YModule module, string message)
{
        string origin = module.get_serialNumber();
    // ... you must store the message and its origin
}

static void deviceArrival(YModule module)
{
    module.registerLogCallback(LogManager.deviceLog);
    // ... configure the module if need be
}

YAPI.RegisterDeviceArrivalCallback(deviceArrival);



As the syntax to set up a callback function varies a lot from one language to the other, we invite you to look at the example called Prog-EventBased in the library corresponding to the programming language that you are using. You can find there this same installation code for a module log messages callback, which you can then take over.

Tests

As any security measure designed for the future, take care to test that it is working properly by simulating an anomaly. For example, on all our modules from which you can move away the measuring sub-module, you can voluntarily disconnect the sensor. You should then see log messages mentioning "i2c" errors:

I2C communication error messages on a Yocto-Temperature-IR
I2C communication error messages on a Yocto-Temperature-IR


Add a comment No comment yet Back to blog












Yoctopuce, get your stuff connected.