Logging abstraction

[rjwats]

It would be good to have an abstraction for logging with log levels and an appender registration mechanism. This can help us hide debug messages

Supporting:

• TRACE, DEBUG, INFO, WARN, ERROR levels
• moduleId, so appenders can filter if required
• Initially supporting: Serial appender with ANSI colors for fun

I'm thinking moduleIds like: "System.WifiSettingsService" will do the trick, so all of the system messages can be filtered out if required.

[rjwats]

@kasedy I'm going to start working on this - it sounds fun.

Let me know if you had any particular things on your wishlist that I havent mentioned above. I'm only going to implement the SerialAppender for now - of course leaving it open so we can add more later.

[kasedy]

1. First of all logging system should not be complicated and take lot of memory.
2. It should be configurable in a runtime with ability to redirect output into websocket, udp and mqtt. Optionally to enable/disable logging for a module.
3. It should be possibility to completely disable logging at compile time that it won't consume space or memory
4. It must have formatted output like dbg("Debug value %s", value)
5. All string literal must be stored in PROGMEM

Class/function tracking could be implemented with __PRETTY_FUNCTION__, __FUNCTION__, __func__.

I also suggest on looking into RemoteDebuglibrary source code as a good example.

[rjwats]

Thanks @kasedy

[rjwats]

Having a play around with this, with some progress. Bear in mind it's a rough draft. I've been looking at logging over WebSockets and EventSources and I have some suff in a branch over here:

https://github.com/rjwats/esp8266-react/tree/logging-spike

Having some stability issues, and I'm wondering how best to deal with the synario of logging messages being created at too fast a rate for the buffers to keep up (doing an OTA update for example). There's also the matter of wanting to see logs you may have missed due to the the device re-connecting or restarting. The network connection doesn't always exist... Tomorrow I'm going to look at file system logging. I think a combination of a small filesystem buffer and EventSource might make a robust solution.

[proddy]

this would a great addition. I did an adaption last year using an external log library (see #85 (comment)) which writes to any stream including syslog. It's both non-blocking and thread-safe and I've been using it on all my projects without any issues so far. Initially, I had a home-grown rotating file log in SPIFFS but got scared about the wear. Now I also included a 50-line internal buffer so if there is a network drop or crash you could still figure out where it flunked. Happy to contribute if you need help with your version.

[FernandoGarcia]

Hi!
I'm interested in this feature.
Could you make a rebase of spike or spike2 branch?
I tried but I found some problems in App build that I'm not able to solve.
Best regards.