You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem you have/What new integration you would like
Logging to the serial port stalls the event loop for the time it takes to write messages. It noticeably affects overall performance and it's quite likely that no one is even watching the output since esphome devices are typically administered over wifi once deployed.
With the default logging level set to DEBUG, every state change results in several dozen or a few hundred bytes of logs. At the default 115200 baud rate, writing a 100 byte log message to the UART takes about 9 ms. That's a significant fraction of the 30 ms recommendation for blocking the event loop and it adds up very quickly.
I think we should do one or more of the following things:
Disable serial logs by default in the default esphome yaml templates used when setting up new devices (non-breaking change)
Disable serial logs by default in the yaml schema (a breaking change)
Write serial logs using buffered I/O without blocking
Lower the default logging level (although I find DEBUG logs useful)
Somehow determine when serial logs are actually needed and only enable them then (perhaps watch for an attention sequence from the host)
Increase the default baud rate
Please describe your use case for this integration and alternatives you've tried:
I was curious why I was seeing warnings about my components taking so long to update considering how little work they did.
For example, I have an interval component that updates 4 resistance sensors associated with NTC thermistors. It was taking over 150 ms to do the work which seemed ridiculous. After disabling serial logs, it's down to about 70 ms while observing it over wifi. So a whopping 80 ms was spent writing several hundred bytes of sensor state change logs.
Ironically, the warning message about slow components exacerbates the problem. This message is 165 bytes long and takes about 15 ms to output.
[12:52:40][W][component:237]: Component interval took a long time for an operation (66 ms).
[12:52:40][W][component:238]: Components should block for at most 30 ms.
Additional context
For anyone following along, here's how you disable serial logs:
logger:
level: DEBUGbaud_rate: 0
The text was updated successfully, but these errors were encountered:
Incidentally, I found the documentation for tx_buffer_size a bit misleading. It sounds like an option to control the size of a transmit buffer for non-blocking writes to the serial port but it's really just the memory allocated for formatting a single log message. Log messages longer than this get truncated.
I might suggest a new name such as max_log_message_length or similar to distinguish it's about formatting not really about transmission.
Describe the problem you have/What new integration you would like
Logging to the serial port stalls the event loop for the time it takes to write messages. It noticeably affects overall performance and it's quite likely that no one is even watching the output since esphome devices are typically administered over wifi once deployed.
With the default logging level set to DEBUG, every state change results in several dozen or a few hundred bytes of logs. At the default 115200 baud rate, writing a 100 byte log message to the UART takes about 9 ms. That's a significant fraction of the 30 ms recommendation for blocking the event loop and it adds up very quickly.
I think we should do one or more of the following things:
Please describe your use case for this integration and alternatives you've tried:
I was curious why I was seeing warnings about my components taking so long to update considering how little work they did.
For example, I have an interval component that updates 4 resistance sensors associated with NTC thermistors. It was taking over 150 ms to do the work which seemed ridiculous. After disabling serial logs, it's down to about 70 ms while observing it over wifi. So a whopping 80 ms was spent writing several hundred bytes of sensor state change logs.
Ironically, the warning message about slow components exacerbates the problem. This message is 165 bytes long and takes about 15 ms to output.
Additional context
For anyone following along, here's how you disable serial logs:
The text was updated successfully, but these errors were encountered: