BeeSpi Revisited

Introduction

A few years ago I instrumented a couple of hives using a Raspberry Pi connected to a camera that was illuminated by infrared LEDs, and temperature and humidity sensors. The data I captured was sent to the cloud using MQTT, and it all looked rather nice. However, it eventually became tiresome for several reasons: 

• Opening the hives was awkward because of the wires.
• IR photos of bees wandering between the frames are uninspiring.
• Power and connectivity were difficult because of the distant location.
• The data did not really tell me anything.

There are probably other issues too, but these were the main annoyances.

However, I realise that there must be value to capturing sensor data from the hive, although these issues need to be overcome. So, I have decided to revisit the project but this time I want to capture the important data in a manageable way.

So this is the first in a series of creating a more modern solution to spy on the bees.

Requirements & Goals

I think the first question to ask is what we want to track. The obvious ones are:

• temperature, 
• humidity, 
• CO2 levels,
• weight fluctuations, and
• audio patterns

These need to be controlled by some MCU that uses a tiny amount of power, and the whole thing should occupy little space with few if any connecting wires, at least no wires that get in the way. Of course, the device must be able to communicate the information home, to allow it to be processed, and these data should be sent in real time (or close to real time).

The next question is what we want to achieve. The goals should include:

• Track the colony health, identifying any stress conditions.
• Identify swarming plans, preferably early, but even a few minutes before it happens would be helpful.
• Reduce the need to open the hive.

As I write this, it is not clear if these can be achieved, but we can certainly get some distance towards them.

Implementation

Hardware

MCU

While there are several devices that could be used, the obvious choice is something based on the Espressif ESP32, specifically the ESP32-S2-WROOM development kit. This has the following features:

• ESP32-S2 embedded, Xtensa single-core 32-bit LX7 microprocessor.
• 128 KB ROM, 320 KB SRAM
• 802.11 b/g/n Wi-Fi
• Bluetooth BLE and classic
• Hardware accelerators for AES and SSL/TLS
• Deep sleep support
• Interfaces:
• USB OTG
• GPIO (up to 43)
• SPI
• UART
• I2C
• I2S
• ADC
• DAC
• temperature sensor
• and more …

Each hive should have its own individual controller and set of sensors. Of course, this all needs to be powered, and an 18650 battery should be sufficient for run this for quite a long time.

I have a few ESP32 devices, and they have various formats:

 Figure 1. ESP32 38-pin DevKitC V4 board (source) 

 

Figure 2. ESP 30-pin Doit Devkit board (source) 

Peripherals/Sensors

For my original solution, I used a set of DS18B20 1-wire waterproof temperature sensors and a single DHT22 temperature/humidity sensor, but this is unnecessary. Instead, a single DHT22 should provide sufficient data for each hive. Instead, we should use the following in each hive:

• DHT22 temperature and humidity sensor – requires 10kΩ pull-up resistor.
• CCS811 air-quality sensor to measure VOC and eCO2 levels. This needs to be verified – there may be a more appropriate sensor available.
• Weight sensors comprising:
• 4 x load sensors to provide up to 250kg measurements.
• HX711 load cell amplifier to allow connecting of the sensors.
• INMP441 low-power omnidirectional MEMS microphone

Software

The solution requires several functions of the software:

• Collection of sensor data
• Transmission of the sensor data
• Management of the system
• Processing of the data
• Presentation of the results

Data capture

The data capture is relatively straightforward, merely reading the sensor information at regular intervals and putting it in a format that can be consumed by external systems. This implies a certain level of processing, but this processing should be kept to a minimum since the backend system is far more capable of this task. 

Communication

The ESP32 has two communications systems built in: Wi-Fi and Bluetooth. While it is tempting to simply use Wi-Fi for everything, the reality is that this is probably more of a drain on the battery than we would like. On the other hand, BLE has a limited range. However, the ESP32 has a proprietary communications protocol from Espressif called ESP-NOW, and it is perfect to use as a mechanism whereby the individual hive instruments send their data to a controlling ESP32 which itself handles communications with the backend.

ESP32 management

The key functions of this are to manage how the ESP32 does its job, following the loop:

1. Go into deep sleep. 
2. Wake after 10 minutes.
3. Loop through the sensor read cycle, gathering the hive information.
4. Transmission to the controlling ESP32.
5. Back to step 1.

Data processing

There is an initial massage of the data on the ESP32 to put them into a format that is easily transmitted. These data are sent to the controlling ESP32 where they are encrypted and uncritically forwarded to the backend.

The other part of the processing is on the backend. This could either be a local physical server or perhaps a cloud-based virtual server. The difference in coding for these is rather small, although a cloud service may have some other functionality available that would be difficult to set up locally.

Presentation

When the data are processed, they can be presented as graphs showing trends, etc. Any audio patterns will have to be tracked and compared to try to understand what’s happening inside the hive, so a machine-learning solution will have to be used to analyse this.

Conclusion

This is an initial analysis of the creation and deployment of an in-hive-monitoring solution. It remains to be seen if this will provide a useful solution.