The events log is the location where are displayed all the events that occur during the execution of Weather Station. You can find here, in an ante-chronological order, all the notable facts that make it possible to understand and analyze the operating status of the plugin. To get the full detail of a specific event, you have to click on its name.
The existence of such an events log should not disturb you. It is there to help you understand what really do Weather Station.
Just to be clear: it is quite expected that this log will fill with events, it is the sign of a normal operation of Weather Station. It is also “normal” that some of these events are “warnings” or “errors”: communication with meteorological stations is not always perfect …
Systems in the events log are actually subsystems of the plugin. Each of these subsystems has its own specific role, and knowing which subsystem is generating events (and why) can be used to tailor Weather Station operation to your specific environment or help you detect the causes of a malfunction. While using the events log, you may encounter the following subsystems:
- Analytics: consolidates operational analysis data.
- API/SDK: manages the link between the plugin and external services (Netatmo, OpenWeatherMap, Weather Underground, etc.).
- Authentication: supervises the connection to services and manages credentials and tokens.
- Backend: aggregates interfaces and features in the plugin admin.
- Background Process: executes and controls long-term processes.
- Cache manager: performs caching and cache cleanup.
- Core: manages the interactions with WordPress features.
- Cron Engine: collects and dispatches tasks for the WordPress scheduler.
- Data Manager: manages the integrity of the collected and stored data.
- Device Manager: manages hardware changes on the stations.
- Ephemeris Computer: computes all astronomical values needed to build ephemeris.
- History Builder: computes and builds historical data.
- History Cleaner: cleans out old history data..
- I18n Helper: takes care of internationalization features, including partial translations management.
- Logger: maintains the consistency of the events log itself and enforces logging policies.
- Pollution Collector: collects pollution data associated to stations.
- Security: handles requests made to the plugin and detects potential security threats.
- Updater: takes care of all migration topics after updating the plugin or associated translations.
- Watchdog: supervises the correct execution of the WordPress task scheduler and the cron engine.
- Weather Collector: collects weather data from stations.
- Weather Computer: computes weather indexes.
- Weather Pusher: pushes values to services to which data is shared.
Each event have a type associated with it. This type should be seen as a severity indicator of the event, regarding the considered system. Thus, a “warning” typed event for the “Core” system is certainly more important (in terms of severity) than an “error” typed event for the “Ephemeris Computer” system. The different types are as follows:
Emergency: a major error. Weather Station doesn’t run anymore or can’t start.
Alert: an error that undoubtedly affects the Weather Station system operations.
Critical: an error that undoubtedly affects the Weather Station current operations.
Error: an error that may affects the Weather Station operations.
Warning: a warning related to a temporary condition. Does not usually affect the Weather Station operations.
Notice: an important information.
Info: a standard information.
Debug: an information for coders and testers, usually generated when investigating a bug or a malfunction.
Unknown: an untyped event, indicating a degraded operation of your WordPress site.
You can set the minimal type to log in Settings > System. Under normal use of the plugin, I recommend that you do not record events of “information” or “debug” types: these types of events are indeed very numerous and can hinder an easy reading of the log.
As you can see in the header of the list, the events log offers the ability to filter the events.
The first line allows to hide events below a specific type. You can use this filter to show only relevant events regarding a severity level.
The three dropdown list, meanwhile, allows to restrict the view to a specific combination of system, service and station. This is particularly useful when you have a great number of stations and want to find some specific behavior.
As you can guess, these two types of filters can be combined to restrict the view to a specific combination of system, service and station with a minimal type.