The Problem#

The logic for starting, stopping, and managing the grinding process was scattered across multiple functions, making it difficult to understand and maintain.

Looking at the main loop() of the Arduino-based software showed this:

void loop() {
  // ...
  if (automaticGrindingOngoing) {
    auto currentWeight = getCurrentWeightAndPublish();
    if ((currentWeight + thresholdTargetGrams) < desiredGrams) {
      // Start or continue the grinding
    } else {
      // The current weight with a given threshold has reached the target weight ..
      if (currentWeight < desiredGrams) {
        // .. now approach the desired weight slowly.
        // (the grinder retention and the distance between the grinder and the scale forced this approach)
        startGrinding("automaticGrinding", 150);
      } else {
        // .. or the desiredGrams have been reached.
      }
    }

  } else if (grindingOngoing &&
       (millis() - grindingStartedTime) > grindingTime) {
    // Time-based grinding was ongoing and we have reached the desired grinding time -> Stop the grinder.
  } else {
    // We are not grinding, so handle anything else (such as updates over the air).
  }
}

Code parts were replaced by comments to ease the reading. Here is a link to the full code section.

When MQTT messages are received to start grinding, the bool flags automaticGrindingOngoing or grindingOngoing are set.

Looking at the callback, I was surprised that there wasn’t a startAutomaticGrinding function called or that the startGrinding function starts the grinding but doesn’t care about stopping it. The stopping logic was handled separately in the loop(), leading to a fragmented and hard-to-follow codebase.

Improving the Code#

The first idea was to extract the entire grinder and MQTT handling logic to their own libraries.

This left the program.cpp with less code only handling the update over the air and the connection to the Wi-Fi.

Final Thoughts#

It was fun to refactor this old project. Often my ESP-based projects start off as a quick proof of concept through which the code quality often suffers.

Additionally, I no longer own that grinder and therefore no longer use this project. My current grinder is a so-called “single dose coffee grinder” - you weigh the beans before pouring them into the grinder and the output of the grinder is exactly the same weight.

But still having the load cell available enabled me to “experience” my own documentation for the setup - where the schematic allowed me to quickly have something up and running. For testing, I chose to skip the relay and instead use the built-in LED of the D1 mini to indicate the current state of the grinder.

There are still several code parts that would benefit from a refactoring:

• The new callback function is rather long for being a mapping of topic to function.
• A lot of logic is still hidden. That removing GrindingController::getCurrentWeightAndPublish() results in no MQTT messages being updated is not something I would expect.

Additionally, further functions could be added:

• Fallback to ensure that the relay is switched off if anything bad happens (firmware crashes, etc.).
• Hardware buttons to control the grinder: MQTT enables many ways to control the grinder. But in real life, one would always control the grinder while standing there. It would be great to adjust settings and start the grinding without the need for any MQTT-compatible device.

If any of those code updates will come is unclear since I am no longer a user of the project. But I also did not expect to refactor this project and yet here we are.

For a detailed view of the changes, you can check out the GitHub pull request.