Overview

Over the end of year 2023 Holidays I had a vacation and started working on revamping some tech for my chicken coop. This blog post is going to detail what we had initially, what I’m building, and some future ideas for the chicken tech.

Equipment/Software Used

• Original Helium Hotspot - Any official Helium Hotspot¹ or home-built Data-Only² hotspot will work
• SenseCAP 2103 (2)³ - LoRaWAN Temp, Humidity, and CO2 Sensor
• Raspberry PI 4b 8GB (2) - Local k8s cluster running in my home
• Helium Console⁴ - Helium Network console provided by the Helium Foundation, but any Helium-compatible console will work
• SenseCAP-Decoder⁵ - Javascript function for decoding 210X sensors provided by SenseCAP.

Initial Build

To start we were running two SenseCAP 2103 sensors, one inside and one outside the chicken coop, using entirely pre-made integrations in the Helium Console and using a modified version of the SenseCAP-Decoder to work without using DataCake.

A general overview of how the data flowed was something like:

• Sensor broadcasts data
• Helium Hotspot takes data and sends to Helium Console
• Helium Console uses the modified SenseCAP-Decoder function to decode the sensor payload
• Helium Console takes the decoded payload and uses the provided Google Sheet integration to upload the data to Google Sheets

What went well & what didn’t?

For me the biggest thing was being able to log the data, in the morning I wanted to check what the coldest temp the coop got to overnight. Secondary goals included wanting to compare the inside and outside temps and humidity, and monitoring/comparing CO2 levels in the coop during the day and night.

The drawbacks are a lot of the monitoring and analyzing the data was manual work, and the more data that gets added to the Google Sheet the slower it loads on my phone. The setup was great for an MVP to get some data to look at but it’s definitely not a long term viable solution.

What I’m building for CoopTech2.0

For the revamp I decided my requirements would be simple, a proper permanent data store and simple website or app to view the data.

At the time of writing this the Helium Console hosted by the Foundation offers two “core” integrations, HTTP and MQQT, as well as 12 community integrations for various managed services like AWS IoT Core, Azure IoT Hub, Google Sheets, etc.

Unfortunately none of the provided integrations completely satisfied by requirements so I decided I’d build my own using the HTTP integration.

The new proposed data flow looked more like this:

• Sensor broadcasts data
• Helium Hotspot takes data and sends to Helium Console
• Helium Console sends an HTTP POST request to an endpoint I provide
• Custom written sensor-decoder-service takes the HTTP POST request, decodes the data, and stores it in a database

New Infrastructure

The proposed revamp requires some additional infrastructure to run now that we’re not relying entirely on the Helium Console to manage and run our integrations.

• A server of some sort that can take an HTTP POST
• A service that can decode the sensor payload data
• A database

For the server I chose to run a small kubernetes cluster in my house, having done this in the past for educational purposes it seemed like it’d be fun to do it again. This also gives me the ability to easily add new services, scale the cluster size, and replace broken nodes with fairly minimal effort.

For the decoder service I’ve started work on a gRPC service I’m calling the sensor-decoder-service, at the time of writing this it’s successfully taking data from the Helium Console HTTP POST request and decoding it. To make the HTTP POST<->gRPC integration work I have another small service called sensor-decoder-service-proxy that uses grpc-gateway to make a REST API proxy for the service.

I went with gRPC for two main reasons:

1. It allows me to generate a lot of the code I need simple by writing a protobuf file
2. Education and personal growth, gRPC seems like a great new set of tools to work with and while I’ve worked with it on occasion it feels good to use it for this project.

The database I still haven’t decided on yet. While I’ve been working on all of this I still have the legacy system in place dutifully logging the data to Google Sheets, so I have some time to figure out what best fits my needs. I’ve been considering some free tier cloud hosted services since the amount of data is fairly minimal, but still undecided.

Next steps & future plans

• Pick a database
• Rewrite the sensor-decoder-service to strictly decode data and return a result
• Write a new service to handle data ingress from the Helium Console, use the sensor-decoder-service to decode the data, and then store it in the db
• A UI of somesort to view the data

The biggest thing I need to do is settle on a data store, while I’m trying to figure that out the next couple of tasks are mainly cleanup ones.

I want to change the sensor-decoder-service to do exactly what the name says, decode the data, and have a new service worry about getting and storing the data. This separation will make it easier in the future when I’m adding more sensors of different kinds to the coop.

Closing

This was meant to be a fairly high level overview of where we were, where we are, and where we’re going. It’s been a lot of fun having chickens again and I’m glad this Coop Tech project was born, in the future I plan to do another post with more in-depth details on everything and make the code open source.