fix: minimize timeouts

[marcnause]

I set timeouts to 0 in order to increase throughput. I did some measurements (getting oscilloscope data) and in my setup data transfer was up to 20 percent faster. This is not the breakthrough I was hoping for, but it is an improvement.

Summary by Sourcery

Enhancements:

• Disable timeouts on Serial and WiFiClient connections to reduce communication delays and improve throughput by up to 20%

[sourcery-ai]

Reviewer's Guide

Disabled default timeouts on the serial interface and WiFi client, eliminating waiting delays to boost throughput by roughly 20%.

Sequence Diagram: Configuring Serial Timeout in Setup

sequenceDiagram
    participant S as Setup
    participant Ser as Serial
    S->>Ser: setTimeout(0)

Loading

Sequence Diagram: Configuring WiFiClient Timeout on Available Client

sequenceDiagram
    participant L as Loop
    participant Serv as WiFiServer
    participant Cli as WiFiClient
    L->>Serv: available()
    Serv-->>L: client
    L->>Cli: setTimeout(0)

Loading

File-Level Changes

Change	Details	Files
Disable operation timeouts for data transfer	Add Serial.setTimeout(0) in setup() Add client.setTimeout(0) in loop()	src/ESP01Firmware/ESP01Firmware.ino

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @marcnause - I've reviewed your changes and they look great!

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[bessman]

Are there any drawbacks to setting timeout to zero? What is the default value?

[marcnause]

The default values are 1000ms for Serial and 5000ms for the WiFi connection. I found both values in the code of the used libraries and I also requested them in the code and logged it to the serial console using a NodeMCU V3 ESP8266 board.

I would never set the timeouts to zero in other contexts, but I don't think it hurts here since we are in an infinite loop which only has two things to do and if we miss a value, we will catch it in the next iteration. I don't see any drawbacks, but of course that does not mean that there is anything I am missing.

I did not have any issues with the changes so far, but it would be great if we could test it more thoroughly.

I have created an issue for this PR: #18

[CloudyPadmal]

Do we have any end-of-packet delimiter in the UART packets? Maybe someone is waiting until the timeout to detect the end of packet? Or maybe it is waiting for a buffer to be empty. Or maybe this slowness is due to something else..

[bessman]

Given that this provides an immediate benefit with no obvious drawback, I see no reason not to merge it as-is. We will continue to refine the wireless handling as we go.