It has been almost two months since my last post. The website has been quiet, but the workbench has been busy.

Since writing about the robot project, I have been spending a lot of time on another system that brings together software, networking, embedded hardware, and custom enclosures.

It is called GrowCircuit.

I am building a growing journal that runs on your own computer, with optional sensors and control for the equipment around your grow. Alongside the software, I am developing my own hardware under the Grow Buddy name.

The hardware approach is deliberately open. I want you to be able to use the equipment you already own, build something yourself, or use my devices if they suit your setup. The software should give those devices a useful place to send their readings and expose their controls.

That has meant building considerably more than a screen with a temperature gauge on it.

The Starting Point#

The first application commits landed in late August. The early version tracked grows, accepted readings from ESP32 sensors, and stored environmental history.

That gave me the basic pieces: a grow, a sensor, a database, and a way to see what was happening over time.

From there, the project expanded quickly. I added a Windows desktop application and installer, plant tracking, photos, charts, backups, controller setup, and eventually smart outlet integration. The original Go server remains available for people who want to run it on Linux, Docker, or a machine in their homelab.

The project also changed names. Earlier work used Grow Buddy for the application. GrowCircuit became the software name, while Grow Buddy stayed with the hardware.

By the beginning of October, the application had reached version 1.11.1. The more interesting progress is in how its purpose became clearer as I used and developed it.

A Journal You Can Use Without Buying Hardware#

One of the biggest changes came when I made the journal the center of the application.

Automated readings are useful, but a sensor cannot tell the whole story of a grow. It does not know that you transplanted a plant, changed a feed, trained a branch, or noticed a problem unless you record it.

GrowCircuit now brings those activities together in a timeline. You can record watering, feeding, training, defoliation, transplanting, observations, and photos alongside environmental readings. Entries are grouped by week of veg or flower, so the record follows the grow’s actual progression.

The questions also fit the growing medium. For soil and coco, the water going in matters. For hydro, the reservoir has its own readings. Asking everyone to fill out the same fields made the interface less useful.

You can start with a thermometer, a humidity gauge, and your own notes. Type the readings in, take a photo, and record what you did. There is no sensor purchase required to make the journal work.

The home screen reflects that approach. It gives you a daily check-in: when you last watered, logged a reading, or took a photo, and what deserves your attention today. If you have sensors, you can switch to a live view.

My goal is to make keeping a useful record easy enough that you actually keep doing it.

Giving Every Plant and Grow a History#

As the journal developed, the organization underneath it needed more detail too.

A room, a grow, and a plant are different things. A room can contain several grows. A grow can contain several plants. Plants can move, and clones have a history that begins before they arrive in their current space.

GrowCircuit now supports multiple grows, individual plant IDs, strain records, plant photos, lineage, and printable tags. It tracks the dates that move a grow through veg, flower, and harvest, and calculates the day counts from those dates.

It also separates the physical space from its purpose. A tent or cabinet describes where something grows. A cloner, seed starter, or veg-only grow describes what happens there. Those distinctions affect what the application needs to ask and display.

That same distinction matters for sensors. A controller outside a tent measures the surrounding room. A sensor inside the tent measures the grow. Those readings need separate histories, even when the controller is forwarding the tent sensor’s data.

The result is a record you can follow from plant to plant and grow to grow, with enough context to understand what changed.

Connecting the Journal to the Environment#

Once sensors are involved, the journal gains a continuous view of the environment between your own check-ins.

The application can chart temperature, humidity, VPD, light, and supported nutrient readings. VPD gives temperature and humidity some shared context, while the history shows patterns that a single current reading can miss.

Light monitoring has become particularly useful. The application can work out the observed light schedule and flag when it disagrees with the phase you recorded. If you change the timer and forget to update the journal, the recorded light history can help catch that mismatch.

I have also added local phone access and photo capture, along with photos for individual plants and the whole grow. A photo belongs with the record of what was happening when you took it.

There is a growing reference library inside the application too. It covers subjects such as room setup, environmental readings, watering, feeding, lighting, and harvest. I have been revising those guides alongside the interface so the explanations match the questions the journal asks.

All of this still runs locally. Your grow records and photos stay on the machine where you run the application, without creating a cloud account. Backup and export include the database, photos, and CSV records. Recent work also added photo metadata removal, password-protected backups, and an optional Windows service that can record readings from boot without someone signing in.

My Hardware Is One Way to Connect#

I am developing my own hardware because I want a straightforward option that fits this system well.

The current design separates a small sensor inside the tent from a controller outside it. The in-tent sensor is intended to stay dark, with no normally visible display or indicator light. The outside controller provides the screen and handles the connection back to the application.

The controller work has moved from a small OLED bench setup to a Waveshare ESP32-S3 controller with a 4.3-inch touchscreen. The sensor nodes use ESP32 hardware, and the firmware supports communication through the controller over ESP-NOW or directly over Wi-Fi when configured for it.

Alongside the electronics, I have been working on printed sensor enclosures, mounting arrangements, ventilation, cable access, and PCB designs. A useful sensor has to fit where it will be used, measure the right environment, and remain accessible when it needs attention.

The hardware plans include air monitoring, hydroponic EC and pH options, soil sensing, and a more advanced light and CO2 version. These are at different stages of development. The air sensor and controller have already delivered readings into the application on actual hardware; the broader product family still needs calibration, physical testing, and validation.

But owning my hardware should never be the condition for using the software.

The sensor protocol is documented and open for anyone to implement. At its simplest, a device publishes a small JSON message over MQTT:

Topic: growcircuit/tent-1/state
Payload: {"temp_f": 76.3, "humidity": 55.2, "light_on": true}

If another sensor can produce those readings, directly or through a bridge, it can feed the journal. That leaves room for custom ESP32 projects, scripts, and existing systems that can translate their measurements into the protocol.

Home Assistant integration is part of this work as well. GrowCircuit can publish its sensors and running grows to Home Assistant through MQTT discovery, so they can appear alongside the rest of your local setup.

The goal is to support any hardware that can communicate through a suitable integration. Compatibility still takes work: devices use different protocols, expose different measurements, and offer different controls. An open approach means providing a way to connect them and continuing to build those integrations.

Control Needs More Than an On/Off Button#

Monitoring naturally led to smart outlets. Once you can see the environment and light schedule, being able to manage the equipment from the same application becomes useful.

The current application includes direct integration work for compatible Shelly and Tasmota outlets. The wider hub design adds a path for other devices, including Zigbee equipment. Support depends on what each device and integration can actually do.

The application can associate outlets with grows or rooms, show available power measurements, and manage supported schedules. That brings equipment into the same context as the journal and environmental history.

A key decision is that recurring schedules should be stored and executed in the outlet itself when the hardware supports it. The computer should not have to stay awake just to send the next scheduled command.

Confirmation matters too. Sending a command and observing the requested state are separate steps. The interface needs to show when a change is pending, when the device confirms it, and when it fails. The same applies to saving a schedule: the application needs confirmation of what the outlet actually stored.

That is where the work moves beyond drawing a switch on a page. Different devices have different capabilities, and the interface has to represent those differences honestly.

The Sensor Was Working. The Reading Was Stuck.#

One recent problem captured the kind of work that has filled the gap between posts.

The air sensor was paired to the touchscreen controller. Wi-Fi was connected. The controller was connected to the application’s MQTT broker. Yet new readings had stopped reaching the journal.

The controller’s delivery queue had filled up.

The underlying problem was the MQTT library’s default packet buffer. As the messages grew to include more device and measurement information, a complete publish no longer fit. The connection stayed up, but the publish failed. The oldest queued reading could not leave, and eventually the queue could not accept new readings either.

Increasing the buffer to accommodate the complete messages resolved the publishing blockage. After the updated firmware was installed, the queue drained and new air readings appeared in the desktop database again.

It was a useful reminder that a connected badge tells you about one part of the path. The complete path still needs to be checked: measurement, radio delivery, controller queue, MQTT publish, and database storage.

That is why I have spent time on diagnostics as well as features. The application now has views for events, raw MQTT traffic, and sensor console output, so there is a way to find where a reading stopped.

Where I Am Taking It Next#

The journal, desktop application, sensor ingestion, charts, photos, backups, and initial outlet integrations are already implemented. The hardware and the connections between those pieces are still being refined.

The next work includes more testing of the sensor and controller enclosures, stronger pairing and recovery behavior, better handling of readings buffered during an interruption, and validation of the additional probes and outlet integrations.

Calibration is a substantial part of that. A basic light sensor reports lux; a calibrated PPFD measurement needs a different level of optical design and testing. Hydro and soil probes have their own requirements. I want the application to show measurements with a clear meaning, and to show when a measurement is unavailable.

There is also an important distinction in how I am sharing the project. The application is free to use and its source is available under the PolyForm Perimeter license. The sensor protocol is explicitly open and unrestricted. Optional hardware is the intended way to support continued development while keeping the journal useful to people who bring their own equipment.

You can follow the software and hardware work in the GrowCircuit repository.

The last two months have produced an application, firmware, controller screens, PCB plans, printed enclosures, integrations, and a fair amount of troubleshooting. Bringing those pieces together has helped me settle on what I want GrowCircuit to become.

I want a grower to be able to keep a useful journal today, add monitoring when they want it, and connect control hardware that fits their setup. Whether the readings come from my sensor, their own project, or equipment they already have, they should become part of the same growing history.

That is what I have been building while the blog has been quiet.