# B-parasite is five firmware samples, one board, and two different radios under the same sensor > An open hardware soil moisture sensor that grew from one BLE sample into a Zigbee port, an ESPHome bridge, four printed cases and a first release of prebuilt binaries. **rbaron/b-parasite** — 🌱💧 An open source DIY soil moisture sensor - Repository: https://github.com/rbaron/b-parasite - Stars: 2,466 · Forks: 188 - Language: C - License: not declared - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/rbaron-b-parasite ## A soil sensor that also measures the room GitHub describes the repository as an open source DIY soil moisture sensor, and the README describes it more fully as an open source soil moisture and ambient temperature, humidity and light sensor. Both are accurate, and the difference matters when you plan a build: the GitHub one line undersells two of the four sensors on the board. The sensing chain is specific. Soil moisture is capacitive rather than resistive, and the README links three explanations of how capacitive probes work, including a blog post on capacitive soil moisture sensors and a longer explainer on capacitance measurement. Air temperature and humidity come from a Sensirion SHTC3. Light comes from an ALS-PT19 phototransistor. Power is a CR2032 coin cell, and the README's estimate is potentially for over two years. That number is a projection rather than a measurement, and the repository contains an `input` sample described as useful for power profiling GPIO interrupts, which is how you would actually check the claim on your own board. The radios are two nRF52 parts: support for both nRF52840 and nRF52833 modules. Open hardware and open source design are stated as features, and the KiCad schematic, layout and fabrication files are in the repository, so you are not limited to the reference board. For the licensing, the README is explicit and split: the hardware and associated design files are released under Creative Commons CC BY-SA 4.0, and the code under MIT. GitHub reports no license for the repository, so the README's split is the one to rely on. ## Five samples, and only one of them is the product The README's software section is a table, and the table is the fastest way to understand this repository. There are five firmware samples and they serve very different purposes. The `ble` sample is called the most battle-tested and useful firmware. It periodically reads all sensors and broadcasts them over Bluetooth Low Energy, and it works with Home Assistant plus BTHome out of the box. If you are building one of these, this is the sample you flash. The `zigbee` sample is described as experimental, educational and exploratory, a basic Zigbee sample built on nRF Connect and ZBOSS. It integrates with Home Assistant through ZHA or through Zigbee2MQTT. The three labels in that description are doing real work: read it as a port in progress, and check the current state of its own README before planning around it. The remaining three are development tools. `blinky` is the hello world. `soil-read-loop` reads the soil moisture sensor on a loop and is explicitly flagged as useful for experimenting and calibrating. `input` handles button presses and is useful for power profiling GPIO interrupts and testing debouncing on boards that have them. That last one matters more than it sounds. Calibration is the step most soil sensor projects skip, and this repository ships both a sample for it and a data directory for it, which puts it ahead of most open hardware in a way that costs nothing. ## The code directory is a west workspace, which changes how you build The repository's code directory is described as a west workspace, and that single phrase tells you more about the build than any instruction in the README. A west workspace is the dependency and build model used by Zephyr, and it means the code directory is not a standalone project you can build with one command from inside it. It is a workspace with a manifest, a set of modules, and an expectation that you use the tool. Inside that workspace sits a common `prstlib` module library and the samples, and the whole thing is built with Nordic's nRF Connect SDK. So the practical stack is: install the nRF Connect SDK, set up the west workspace, and build from there. The README deliberately does not duplicate those steps, instead sending you to the wiki for information about how to order, assemble, build the samples, protect the sensor and flash the firmware. That division is defensible for a project with this many moving parts, and it is also the thing to be aware of before you start. Toolchain setup is not one command from a README here. The wiki is part of this repository's documentation, not an external convenience. The rest of the tree shows the same pattern of a project that keeps hardware, firmware and reference material together: ``` code/ kicad/ data/ bridge/ case/ ``` Five directories, five different kinds of content. `kicad/` is the board design, `data/` is for testing and sensor calibration, `bridge/` is an ESPHome based BLE to MQTT bridge, and `case/` is 3D printable enclosures. Note that `bridge/` is a separate path outside the west workspace, because it is a different ecosystem entirely: ESPHome is Python, not C. ## The bridge, the cases and the tree entries the README skips Three parts of the repository deserve a look that the README does not really give them. The `bridge/` directory is an ESPHome based BLE-MQTT bridge. This is the piece that matters if you want your sensor data in a system that speaks MQTT rather than BLE. It also demonstrates that the project is not tied to one radio stack: the same board can feed a Bluetooth radio path or a bridged MQTT path. The case section is where the README has an internal inconsistency worth naming. It says there are three different 3D-printable cases, then lists four. The original snap-on case is two STL files, `Top.stl` and `Bottom.stl`; there is a high airflow case as a single STL; the mushroom style case is hosted on Printables; and a b-parasite Hat waterproof case is also on Printables. The accessories section adds one more item, a desk holder, also on Printables. So the sentence announcing three cases is out of date relative to the four that follow it. The listing itself is the accurate part, and the count in the sentence is what nobody updated. The tree also holds two directories the README's repository organization section never mentions: `flashing/` and `experimental/`. Given the project's subject matter, both names are suggestive of exactly the kind of work you would expect to find there and would want to browse, and neither is described anywhere in the README. There is also a `kitspace.yaml`, a `CODE_OF_CONDUCT.md` and a `.devcontainer/` directory, so there is a development environment and a code of conduct in place even though the README does not advertise them. ## Version 1.0.0 is the first release with binaries in it The single tagged release, v1.0.0, was published on 2026-05-23 and its purpose is stated plainly: it is the first official release of pre-built binaries of all samples. Until then, building meant building. The release also records two migrations that explain why a five year old project is publishing a 1.0 now. One is the move to nRF Connect SDK v3.3, credited to a contributor. The other is the move to a new code structure after west workspaces, which is the layout described in the previous sections. Both migrations are the kind of change that makes a release worthwhile: the binaries are produced by continuous integration against a selection of hardware versions, and the CI drafts a release when a new version tag is pushed. That last detail is the one to build your process around. The badge at the top of the README is a workflow status badge for the firmware build, and the release notes say the CI builds for a selection of hardware versions. So flashing a prebuilt binary is a normal path now, and picking the right one means picking the right hardware version, which the wiki documents. The autogenerated notes for that release are also a decent map of the project's history. They include a fix for ADC overflow in a dark environment, the switch to a phototransistor for light sensing, support for using the nRF52 preprogrammed random MAC address, an implementation of BLE protocol version 2, and a case revision that added gas exchange holes, a cutout for the photosensor and pry slots. The BLE protocol version 2 change is the one that could affect an existing Home Assistant setup, since it is the wire format rather than the hardware. GitHub reports 2,448 stars, 184 forks and 46 open issues, with the last push on 2026-09-21. ## What a first build actually requires you to sort out Putting the pieces together, the order of operations for a first build is roughly this. Order or fabricate the board using the KiCad files in the repository, then assemble it, following the wiki. Get the firmware built, which means the nRF Connect SDK and a west workspace rather than a plain clone and build. Flash it, and pick the binary matching your hardware version if you use the prebuilt ones from v1.0.0. Calibrate before you trust it. The `data/` directory is for testing and calibration, and the `soil-read-loop` sample exists to read the probe on a loop for exactly this purpose. A capacitive soil probe gives you a raw number that means different things in dry soil and wet soil, and different boards in the same batch will not agree. The presence of both a calibration data directory and a dedicated read loop sample is the strongest signal in this repository that the maintainer expects you to treat the readings as uncalibrated until you have done the work. Power profiling is the other step worth doing early, especially if the two year battery claim is what you are buying. The `input` sample is documented for power profiling GPIO interrupts, and with a coin cell and a BLE radio advertising, the radio duty cycle is usually where the budget goes. Finally, the protection question. The README sends you to the wiki for how to protect the sensor, which is the right call for hardware that lives in a plant pot, and it is a reminder that the mechanical design is part of the product rather than an afterthought. ## Conclusion B-parasite is unusual among hobby hardware projects because the firmware is split by purpose rather than by version. The BLE sample is the one to start with, since it broadcasts BTHome data and works with Home Assistant without a bridge; the Zigbee sample is labelled experimental and is built on a different SDK; and the three smaller samples exist to make power profiling and calibration possible rather than to be deployed. The first tagged release, v1.0.0 on 2026-05-23, is the first set of official prebuilt binaries and marks the move to nRF Connect SDK v3.3 and to a west workspace layout. GitHub reports the language as C and the license field as empty while the README states CC BY-SA 4.0 for hardware and MIT for code, so read the README's licensing paragraph rather than the metadata. Order parts through the wiki, build with the documented SDK, and calibrate against the data directory before you trust a reading. ## FAQ ### How can I make a DIY soil humidity sensor? There are two routes. Buy a finished board, where the reference design is sold or assembled from the KiCad files in the repository and the prebuilt firmware from the v1.0.0 release is flashed onto it. Or build it from the open hardware, which means ordering or fabricating the board from the fabrication files, assembling the components including a Sensirion SHTC3 for air temperature and humidity and an ALS-PT19 phototransistor for light, then building and flashing the `ble` sample through the nRF Connect SDK and west workspace setup. ### What does the BLE firmware broadcast and what does it work with? The `samples/ble` firmware periodically reads all sensors and broadcasts them over Bluetooth Low Energy. The README states it works with Home Assistant and BTHome out of the box. There is also a separate ESPHome based BLE to MQTT bridge in the `bridge/` directory if your automation stack speaks MQTT instead. ### Is the Zigbee firmware ready to use? The README describes `samples/zigbee` as experimental, educational and exploratory, built on nRF Connect and ZBOSS, integrating with Home Assistant through ZHA or Zigbee2MQTT. The BLE sample is the one called most battle-tested and useful, so start there and check the Zigbee sample's own README for current status. ### What license applies to the b-parasite hardware and code? The README splits it: the hardware and associated design files are under Creative Commons CC BY-SA 4.0, and the code is under MIT. GitHub reports no license field for the repository, so the README's split is the statement to rely on, and it matters if you plan to modify the board design, since CC BY-SA carries share-alike obligations on derivative designs. ## Sources - [Issues](https://github.com/rbaron/b-parasite/issues) - [rbaron/b-parasite on GitHub](https://github.com/rbaron/b-parasite) - [README](https://github.com/rbaron/b-parasite/blob/main/README.md) - [Releases](https://github.com/rbaron/b-parasite/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rbaron-b-parasite