GrowerHub Manage your farm from one dashboard

GrowerHub: from one irrigation controller to a farm management platform

GrowerHub evolved on a working installation. Its public repository history starts on October 6, 2025: since then the project has moved from one ESP32 irrigation controller to a platform with sensor history, zones, Zigbee2MQTT, and automations.

Our goal

Turn the accumulated experience into a clear platform where people can connect equipment themselves, see its state, and gradually automate a farm.

What the project demonstrates

We do not hide the project's radical changes: Git shows which ideas were introduced, tested, and replaced. The operational snapshot confirms that the code is connected to a long history of real measurements and actions, not only synthetic demo screens.

Verifiable facts

This snapshot was recorded on July 23, 2026. The repository and production aggregates were checked separately; no device addresses, IEEE values, logins, or credentials are published.

777

commits on main

The public history covered 98 separate development days from October 6, 2025 through the audit date.

2,140,650

stored native sensor readings

The retained series starts on January 8, 2026 and reaches the audit date; the installation contained five sensor records.

130,127

Zigbee device state events

From July 5 through July 23, 1,366,273 individual property values were also stored across nine end devices and 25 property types.

165

watering journal entries

The first retained entry is dated November 26, 2025; the latest one in this snapshot is dated July 17, 2026.

5

enabled automation scenarios

Two working sections log lighting schedules and climate actions; the automation history starts on June 29, 2026.

How the snapshot was produced

Development history was counted on the main Git branch. Operational facts came from read-only PostgreSQL aggregate queries and were matched to the dates when features entered the codebase. These counts show retained history and date ranges; they do not claim uninterrupted uptime, successful harvests, or a number of customer installations.

How the project changed

  1. One controller and one taskSmart Watering System was imported into Git: an ESP32 read soil moisture, air temperature and humidity, controlled a pump and a light, while FastAPI and PostgreSQL received the data.
    GrowerHub repository
  2. MQTT, command acknowledgements, and GrovikaMQTT manual irrigation commands, state, and ACK handling appeared. The controller was named Grovika — our own device used to work through pump, light, sensor, and remote-control behavior.
    MQTT irrigation · Grovika naming
  3. From a device to a productThe first retained watering journal entry is dated November 26. Two days later a React interface with separate public pages and guides replaced the single technical screen.
    First React interface
  4. A new architecture and long-running data historyThe backend moved from FastAPI to Java and Spring. Grovika firmware gained a second architecture with an MQTT codec, ACK handling, heartbeat, and pump and light control. Sensors, pumps, plants, and history became separate domains. The retained sensor series starts on January 8.
    Spring Boot backend begins · Grovika firmware v2
  5. Zones, Zigbee2MQTT, and automationsA Zigbee2MQTT coordinator, universal exposes, and zones were added alongside native devices. Lighting schedules and climate thresholds entered production; the retained Zigbee history starts on July 5.
    Zigbee coordinator · Automation scenarios
  6. Self-service connectionGrowerHub moved from one internal installation to a multi-user platform with isolated coordinators, MQTTS, onboarding, user-owned zones, and automations. A complete English version arrived the same day.
    Self-service platform · English version

What this history actually demonstrates

  • Grovika and the native device path evolved alongside a real watering journal and telemetry; they were not added only as a description of a future product.
  • The architecture changed several times after operational use: from one controller and FastAPI to domains, history, Zigbee2MQTT, and user isolation.
  • Lighting and climate automations continue running in production; content verification sends no test commands to pumps, plugs, or lights.
  • Synthetic public screenshots protect internal addresses and names. The aggregate figures above come from the working installation.

Contact and source code

Start with your first device

Use GrowerHub independently, inspect the source code, or ask us for help in Telegram.

Start for free Telegram support