Console/Terminal Log standardization

[Odyno]

Is your feature request related to a problem? Please describe.
It seems to me that if we have 2 or 3 modules enabled (like RF + BT + IR) it is very difficult to understand the logs on the console because each module writes something when requested without providing context (probably all assuming only their own module is active). Sometimes you log multi-lines not with a simple call to the LOG function but with a call to multiple LOGs... this makes it a nightmare to understand the flow.

Describe the solution you'd like
Having a clear console register in which registers are always contextualised and encapsulated.

Describe alternatives you've considered
Create a soft rules like:
A - The log need to have a prefix the module involved (Example "BT .... " or "RF ..." etc )
B - The log need to be encapsulated:

As example:

        Log.trace(F("Looking for Model_id: %d" CR), p->sensorModel_id);
        std::string properties = decoder.getTheengProperties(p->sensorModel_id);
        Log.trace(F("properties: %s" CR), properties.c_str());

should be

        Log.trace(F("BT - Looking for Model_id: %d with properties: %s" CR), 
                         p->sensorModel_id, 
                        decoder.getTheengProperties(p->sensorModel_id).c_str()
        );

[benzok]

or we could use a macro; perhaps something like this

#define LOG_TRACE(...) {               \
        Log.trace("%s: " , __FILE__);  \
        Log.trace(__VA_ARGS__);        \
}

and replace the 'Log.trace' with 'LOG_TRACE' and we would get the filename main/ZgatewayBT.ino as a prefix to the log message

[h2zero]

Since we are only building for ESP devices now I would suggest replacing the log library with the ESP_LOG macros and then we could use log tag filtering.

[Odyno]

I'm sorry, I didn't understand the next sentence....

Since we are only building for ESP devices now I would suggest replacing the log library with the ESP_LOG macros and then we could use log tag filtering.

so, OMG will be only ESP device?

[h2zero]

I thought we only had builds for ESP devices, or am I missing something?

[1technophile]

so, OMG will be only ESP device?

1.8.0 supports only ESP devices

[benzok]

I would really like log tag filtering, but does the ESP_LOG macros work with the 8266 ? It is documented in the ESP8266_RTOS_SDK Programming Guide ,but when toying around with it I did not get it to work.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.