Wiznet makers

Introduction

Beekeeping at scale is a data problem. A healthy colony can change dramatically in 24 hours — swarms form, queens fail, parasites take hold, nectar flows peak and collapse — and most of these events leave detectable signatures well before they become visible to the human eye. Yet the vast majority of beekeepers still rely on weekly manual inspections, by which point much damage is already done.

ApiaryGuard Pro is an open-source project that addresses this gap head-on. Built by Bartosz Ruta, it is a full-stack, multi-hive monitoring and management system designed for apiary-scale deployment in real field conditions. The system combines a Raspberry Pi 2 as a central server with Raspberry Pi Pico (RP2040) microcontrollers inside each hive, connected over Ethernet PoE or LTE, and capable of processing over 338 sensor metrics per hive in real time. It is written entirely in C++ and Bash — zero Python — and is licensed under Apache 2.0.

The project is not a prototype or a proof of concept. It is a production-oriented platform with a full installer, systemd service management, a REST API, a web dashboard, an Android app, and a documented roadmap toward AI-assisted colony health analysis.

Project Description

ApiaryGuard Pro follows a master-slave architecture. One Raspberry Pi 2 acts as the central server for an entire apiary, and each individual hive gets its own Raspberry Pi Pico slave node. The master handles data collection, storage, the web interface, and external connectivity. The slave handles real-time sensor acquisition, signal processing, and effector control at the hive level.

What the system measures

Each Pico slave runs a comprehensive sensor suite covering every dimension of hive health:

Weight is tracked via an HX711 24-bit ADC paired with strain gauges, with a precision of ±5 grams on hives up to 200 kg. From raw weight, the system derives 105+ metrics including nectar inflow rate, honey production index, food reserve days, starvation risk, and a 24-hour weight forecast.

Audio is captured through a MEMS microphone with a 20 Hz–20 kHz range. The firmware applies FFT analysis to extract 97+ acoustic metrics including swarm probability, queen piping detection, bee activity index, spectral centroid, and harmonic-to-noise ratio. The acoustic channel is one of the earliest indicators of both swarming and queenlessness.

Environment is covered by a DHT22 sensor for temperature and humidity, an SGP41 or BME688 for CO₂, VOC, and NOx concentrations, a barometric pressure sensor for weather trend prediction, and a light sensor for circadian synchronisation. Together these feed metrics like heat index, dew point, brood stress index, mould risk, and foraging conditions.

Motion and presence are detected by an MMWave radar operating at 24 GHz or 60 GHz, providing a hive_health_index, target_density, and anomaly_score — useful for detecting bee traffic patterns and potential intrusion events. A piezoelectric transducer adds vibration analysis, contributing metrics like intrusion_probability and predator_vib_score.

Vision is handled by a PoE camera that captures images every 60 seconds for bee counting, intruder detection, and time-lapse archiving.

What the system controls

Each Pico node also drives a set of effectors for autonomous hive management:

A 10W heater at 12V DC handles thermoregulation and varroa thermal treatment. A PWM-controlled fan manages ventilation and cooling. A precision dispenser (±0.1 ml accuracy) delivers medications, essential oils, or sugar syrup. Solenoid valves control the hive entrance for night or winter closure. An 8-channel relay board (10A per channel) provides general-purpose switching for any additional peripherals.

PID control loops manage the heater and fan in tandem, and the dispenser enables fully automated treatment protocols for varroa, fungal infections, and nutritional supplementation.

The backend stack

The Raspberry Pi 2 server runs three main components. apiary_collector is a high-performance C++ UDP server listening on port 5005, receiving telemetry from all Pico nodes, computing statistical aggregates, and writing to a local SQLite database. apiary_logger handles event logging with debug helpers. An Apache server hosts the PHP-backed REST API and the HTML/JavaScript web dashboard, which refreshes every five seconds and renders trend charts, alerts, and per-hive controls.

The web interface is complemented by apiary_tui.sh, a Bash terminal UI for local administration via SSH — useful in field conditions without reliable internet.

Installation

A single installer script, hive_monitor_installer.sh, handles the entire setup: it installs system dependencies (build-essential, sqlite3, Apache, PHP), compiles all C++ components, configures the SQLite schema, deploys the WebUI to /var/www/html/apiary/, and creates a apiary-collector systemd service. A TUI menu guides the operator through configuration.

WIZnet's Role in the Project

Reliable network connectivity is the backbone of any multi-hive monitoring system. Each Pico slave node needs to transmit sensor data to the central RPi2 server continuously and without interruption, even in an outdoor apiary environment where connectivity conditions are unpredictable.

ApiaryGuard Pro supports two primary connectivity paths: LTE via an Aero2 SIM-free modem on the master, and Ethernet PoE from the master to each slave node. The Ethernet path uses PoE splitters to simultaneously power and connect the Pico nodes — a clean, cable-efficient approach that eliminates the need for separate power supplies at each hive.

For Pico nodes on the Ethernet path, the project provides a dedicated firmware variant in src/pico_w6100/, built around the WIZnet W6100 Ethernet controller. The W6100 is a hardware TCP/IP offload chip — it handles the full Ethernet MAC, PHY, IP stack, and TCP/UDP sessions in silicon, communicating with the RP2040 over SPI. This design decision has several practical benefits for a hive monitoring context:

The RP2040's 264 KB of SRAM is entirely reserved for application work: sensor acquisition, FFT computations, radar signal processing, weight trend calculations, and HTTP server operation. None of that memory is consumed by a software TCP/IP stack.

The W6100 adds native IPv6 support alongside IPv4, making the system future-ready for modern network infrastructure without any firmware changes.

The SPI interface runs at 50 MHz, giving the node ample bandwidth for the continuous sensor telemetry stream as well as the embedded HTTP API server that the RPi2 master uses to query and command each slave.

The standard Pico firmware variant uses the W5500 (the well-established predecessor), meaning the project supports both chips and operators can choose based on hardware availability and IPv6 requirements. Switching between them is a build-time selection — the application code is identical.

In practice, WIZnet's role is what allows ApiaryGuard Pro to operate as a true multi-node networked system rather than a single-device gadget. Each hive becomes a fully addressable network endpoint with its own HTTP API, reachable from the central server, the web dashboard, the Android app, or any REST client on the local network.

Why This Project Matters to Other Developers

ApiaryGuard Pro is valuable to the embedded systems community well beyond its beekeeping application. Several of its design choices address challenges that appear in any distributed IoT monitoring project.

It demonstrates a complete multi-node IoT architecture. The master-slave pattern — a capable single-board computer as the aggregation hub, with lightweight microcontrollers as edge nodes — is one of the most common embedded IoT topologies. ApiaryGuard Pro implements it in full, including the data transport (UDP), the server-side aggregation (C++ collector), local persistence (SQLite), and the user-facing layers (REST API, web dashboard, Android app). Developers building factory floor monitoring, environmental sensing networks, or agricultural IoT can study and adapt this architecture directly.

The sensor pipeline is exceptionally comprehensive. Few open-source projects show how to integrate this many heterogeneous sensors — ADC-based load cells, MEMS microphones with FFT analysis, gas sensors, radar, barometric sensors, light sensors, and cameras — in a single coherent firmware. The modular C++ structure (sensors.cpp, audio_analysis.cpp, radar_analysis.cpp, air_quality.cpp, weight_analysis.cpp) provides well-separated, reusable drivers for each sensor class.

The statistical analytics layer is production-grade. The apiary_collector_computation.h layer computes not just raw readings but statistical summaries (mean, std, min, max, variance, skewness, kurtosis, Gini coefficient), temporal derivatives (rate, acceleration, jerk), spectral features, and multi-horizon trend slopes (1h, 4h, 24h). This pattern — computing a rich feature vector server-side from raw telemetry — is exactly what any ML-ready IoT system needs, and ApiaryGuard Pro provides a working reference implementation.

The project is AI-integration ready by design. The system is architected with a forthcoming Qwen Agent integration in mind, with the REST API designed to feed structured JSON to an LLM-based assistant. The planned dialogue interface — where an operator asks "show me hives with health problems" and receives a ranked list with sensor evidence and recommended actions — is a useful model for how LLM agents can be grounded in real-time sensor data rather than hallucinated facts.

It handles field deployment realities. Watchdog timers, auto-recovery scripts, thermal protection fuses, IP68 enclosure specs, EMF shielding for radar modules, dual power redundancy (PoE plus battery), and a quarterly maintenance schedule are all documented. This is the difference between a lab prototype and a system someone can actually deploy in an outdoor apiary and leave running for a season.

The codebase is clean and well-structured. The zero-Python policy (pure C++ and Bash) reflects a deliberate choice for performance and minimal runtime dependencies on the RPi2 server. The "Gentle Code Pattern" — handling errors without crashing the collector process — means sensor data keeps flowing even when individual hives go offline. These are the kinds of production engineering decisions that are hard to find in open-source IoT projects.

Apache 2.0 licensing means the project is usable in both commercial and non-commercial products without restriction.

Getting Started

The project targets a Raspberry Pi 2 (or newer) as the server and Raspberry Pi Pico boards as hive nodes, with WIZnet W5500 or W6100 modules for Ethernet connectivity.

# On the Raspberry Pi 2 server: git clone https://github.com/bartoszruta26-droid/Hive_monitor
cd Hive_monitor
chmod +x hive_monitor_installer.sh
./hive_monitor_installer.sh
# Select option 10: Install Apiary Collector (Full)

The Pico firmware lives in src/pico_refactored/ (standard) or src/pico_w6100/ (WIZnet W6100 Ethernet variant) and is built with Arduino IDE or PlatformIO. Pin assignments are configured in include/config.h.

Once the collector is running, the web dashboard is available at http://<server-ip>/apiary/ and the REST API at http://<server-ip>/apiary/api.php.

The full source, detailed hardware specs, and all 15 documentation files are available at github.com/bartoszruta26-droid/Hive_monitor under the Apache 2.0 license.