I’ve just pushed a big git commit to standardise the support for logging levels in OVMS v3. These notes should help keep things organised:
All OVMS code should now have this near the top of it’s code:
#include "ovms_log.h"
static const char *TAG = “<some-tag>";
Please don’t use esp_log.h directly, but instead always use ovms_log.h.
Please do use just one tag for your module - something short, sweet, unique, easy to type, and descriptive.
This ovms_log.h module redefines the standard ESP_LOG? macros to something more useful for our environment. In particular, they move the implementation of logging level control from compile-time to run-time.
ESP has five logging levels. The intended use of these levels is as follows:
ESP_LOGE(TAG, format, values…)
Intended for logging errors. Non-recoverable, or otherwise serious, issues that should be shown to users.
ESP_LOGW(TAG, format, values…)
Intended for logging warnings. Recoverable, or minor, issues that should be shown to users.
ESP_LOGI(TAG, format, values…)
Informational messages. Primarily intended for developers or advanced users of the system, providing an insight into the state of the code paths.
ESP_LOGD(TAG, format, values…)
Debug messages. Intended for developers, or people debugging issues, these provide detailed diagnostic information.
ESP_LOGV(TAG, format, values…)
Verbose messages. Extremely detailed, intended for developers only.
The default logging level is set in menuconfig (Component -> Log -> Default log verbosity). In sdkconfig.default, this is now set to ‘warning’ (ESP_LOGW) and is configured as such during system boots. Log messages of severity equal to, or above, this log level will be displayed. The log level can be set at runtime with the console ‘level’ command. In particular, it can be set globally (for tag ‘*’), or per-tag. You can also put these level commands in a script if you want it set to anything other than the default (so, for example, I could have the vehicle module I am working on at debug log level, but everything else at warnings only).
I hope that the above is understandable and useful. It may not be perfect, and may need some tuning over time, but it should be workable now.
Regards, Mark.
