Different log level verbosity in the FDRS code

[aviateur17]

@timmbogner , what's your take on different log level verbosity in the code? ESP has several log levels - info, warn, debug, error, etc. Nice to not have to uncomment DBG lines to get more or less information, better to just change a #define statement. I have implemented in my testing and I enjoy it. Seeing what you think about it and others.

I have standard DBG as before but also fine and finest levels. DBG could be standard minimal output, fine could be output if having issues and finest could be for developing to get all the info.

I know you wouldn't need the timestamp at the beginning of the line so I'd keep that out.

Sample conf file

// #define FDRS_DEBUG     // Enable USB-Serial debugging
// #define FDRS_DEBUG_FINE
#define FDRS_DEBUG_FINEST

Sample output

707414776 | [fine]   Packet Address: 0xee22 Self Address: 0xee22
1707414776 | [fine]   Incoming LoRa. Size: 13 Bytes, RSSI: -50.00dBm, SNR: 9.00dB, PacketCRC: 0xa028, Total LoRa received: 0
1707414776 |          Incoming LoRa DataReading.
1707414776 | [fine]   Address 0xee23 does not want ACK
1707414776 |          Sending to ESP-NOW Neighbor #1: 0x21
1707414776 | [fine]   Sending out time
1707414776 | [finest] Sending time via LoRa
1707414776 |          Sending time to LoRa broadcast
1707414776 | [fine]   Transmitting LoRa message of size 11 bytes with CRC 0xb4a2 to LoRa MAC 0xffff
1707414776 |          Sending time to LoRa Neighbor 1
1707414776 | [fine]   Transmitting LoRa message of size 11 bytes with CRC 0x213a to LoRa MAC 0xee23
1707414776 |          Sending time to ESP-NOW Peer 1
1707414776 |          Sending time to ESP-NOW registered peers
1707414776 | [finest] Interrupt triggered
1707414776 | [finest] TxFlag: 1
1707414776 | [finest] TxStatus: 3
1707414776 | [fine]   LoRa airtime: 60203ms
1707414777 | [finest] Interrupt triggered
1707414777 | [finest] TxFlag: 0
1707414777 | [finest] TxStatus: 3
1707414777 | [fine]   Packet Address: 0xee23 Self Address: 0xee22
1707414777 | [fine]   Incoming LoRa packet of 13 bytes received from address 0xee22 destined for node address 0xee23
1707414787 |          Local date/time is: Thu Feb  8 11:53:07 2024 STD
1707414796 |          Incoming ESP-NOW System Packet from 0x21
1707414796 |          Received time via ESP-NOW from 0x21
1707414796 |          ESP-NOW time master is 0x21
1707414796 | [fine]   Time adjust 1 secs

[timmbogner]

I think it's a great idea. I've dealt with similar issues when dealing with the ESP-NOW controllers and their registration messages. Some messages are more info than most users need, but I still need them for debugging/troubleshooting.

Are 'fine' and 'finest' terms that are used elsewhere in similar situations? I haven't heard them, but I don't know these things and trust your judgement. 'deep' and 'deeper' are my own suggestions. Also, what will the function (macros) be named?

I recall being against the timestamp, but if you still would like to add it in I'd be cool with it now. Apologies for being wishy washy. I think I was a bit overwhelmed at the time. If you do, note that OLED debugging already has a timestamp appended.

[aviateur17]

The building control software that I use in my job has those log levels but it doesn't matter to me what they are called. I can change to deep and deeper.

The existing #defines are FDRS_DEBUG so maybe we can call them FDRS_DEBUG_DEEP and FDRS_DEBUG_DEEPER and then in the actual code they can be labelled as DBG, DBGD, and DBGDPR? Open to your suggestions. Just trying to keep them short.

[timmbogner]

@aviateur17
I was thinking about the functions and leaning towards DBG(), DBG1(), and DBG2(). That got me thinking that maybe we could go with "level 1" and "level 2", or a similar numbered scheme. My main reasoning is that it might be easier for non English-speaking users.

So like FDRS_DEBUG_LVL1 maybe? Perhaps even FDRS_DEBUG_1 for brevity's sake?