Bee colony remote monitoring based on IoT using ESP-NOW protocol

Location description

This research and measurements were carried out at LBTU’s (Latvia University of Life Sciences and Technologies) apiary, located at Strazdu iela 1, Jelgava, Latvia (coordinates: 56.6630, 23.7538) starting from 01 of June 2022 till 31 of August 2022.

Apiary description

Five honey bee (Apis mellifera) colonies were selected (based on a beekeeper’s suggestion) for remote monitoring. Colonies were placed in different types of hives (Latvian design type and polyfoam hives). All hives were put in the same location in an open environment.

Monitoring system

Setup of distance and node connection time tests between nodes

Before the implementation in the field, we evaluated the distance between two devices using the ESP-NOW protocol. We were mostly interested to test the distance in an open environment, since the bee hives are placed in an (more or less) open field. For this purpose, we used the main node and one monitoring node. The monitoring node sent a data packet in size of 50 bytes (similarly as it would be in the bee colony monitoring case) every 5 s. The main node additionally was equipped with a display to show the received data. After the data was transmitted to the main node, the onboard LED (Light Emitting Diode) blinked and the received data were displayed on the screen, showing a successful data transfer session. Afterwards, the approximate distance was measured using the Google Maps distance measure tool.

To test the time that is required for the measurement node to establish a connection to be able to send data we compared two scenarios—using Wi-Fi protocol (like in our previous work) and using the ESP-NOW protocol. The time was measured within the software by calling the Arduino Cores built in time function. In the Wi-Fi scenario, we were only interested in measuring the time to establish a connection with the wireless access point excluding the time to establish connection with the MQTT broker. In this way the two scenarios could be comparable, because when using ESP-NOW, the MQTT broker is also not directly involved (the connection is managed by the main node afterwards).

Comparison of the short range network protocols

Within this study we compared the short range network protocols using the available literature sources (Glória, Cercas & Souto, 2017), manufacturer data sheets and already conducted experiments by other authors (Eridani, Rochim & Cesara, 2021; Random Nerd Tutorials, 2020). The general characteristics of each protocol can be seen in Table 1.

Distance and node connection time tests between the ESP-NOW enabled devices

Based on the performed tests, it was concluded that data can be transferred reliably up to 250 m in an open field (no obstacles) which is inline with the characteristics provided in Table 1. For the task of bee colony monitoring such a distance is more than enough, as usually bee colonies are placed closely together within one apiary.

At the experimental site, the hives with measurement nodes were placed at varying distances, where the furthest distance did not exceed 20 m. Some problems were observed with one measurement node, where the direct line of sight was being blocked by a wooden wintering building, therefore data transmission from this node was inconsistent.

Besides the distance tests we also evaluated the time needed for the measurement nodes to establish a connection with a main node in two scenarios: when using Wi-Fi (like in our previous work) where the access point was considered as the main node and, when using ESP-NOW protocol, where the main node was based on ESP32 (ref. to chapter Material and methods 3.2). On average it took approximately 5 s to wake the Wi-Fi module, set the wireless network credentials and establish a connection with the access point. As mentioned in chapter Material and methods 4, here we did not include the time needed to connect to the MQTT broker. In the case when using the ESP-NOW protocol, the time needed for the node to initialize the ESP-NOW, set configuration parameters and send data to the main node, was approximately 5 ms, which was significantly faster than in the first scenario.

Power consumption

Power consumption of the monitoring nodes

The operation of measurement nodes involves mainly deep sleep activity, when the node is consuming significantly less current compared to active mode (sensor reading and data transmission). In our case, the time it took for the node to take all sensor readings, initialize the ESP-NOW protocol and transmit data was approximately 3 s (the majority of the time the node is taking multiple weight measurements and selecting the median value), after which it was put to deep sleep (when the only active part on the ESP8266 microchip is the real time clock (RTC) module) for 30 min. During the active period, the node’s current consumption was 40 mA on average, but during the deep sleep around 0.83 mA. The relatively high current consumption during deep sleep (as later found) was caused by some inefficient electronic components and the Secure Digital (SD) card module for data backup purposes. The current consumption measurements were made with the UT61D multimeter and its logging feature.

Examples of the battery discharge curves of two measurement nodes are demonstrated below (Fig. 4). The drop in both curves (on June 13 for Node 2 and on June 22 for Node 1) was due to battery replacement. As Fig. 4 shows, the monitoring nodes operated without interruptions for more than two months.

Although it should be noted that during the experiments we observed different battery discharge rates for some batteries and some measurement systems. This led to the assumptions that some of the measurement system components and batteries might be defective or behave differently outside the laboratory environment. An example of such an undesired behavior is presented in Fig. 5, where two different battery discharge rates (for the same system) are depicted. It can be seen that the system was operating for 34 days without interruptions (battery discharge rate ∼15 mV/day). After the battery replacement (Fig. 5, circle 1), the system operated for about 15 days (battery discharge rate was ∼17 mV/day), then the voltage started to drop dramatically, leading to a battery discharge rate of ∼160 mV/day (Fig. 5, circle 2).

Advantages and disadvantages of the ESP-NOW protocol

Specific communication protocols are essentially required for connecting deployed IoT devices to the network in a distributed manner. For the bee colony monitoring task ESP-NOW protocol is suitable and can be used. The ESP-NOW protocol has great distance support in LoS (Line-of-Sight) conditions with low latency. However, it consumes more power, compared to the ZigBee, and obstructions quickly weaken the signal strength. But, if a responsive device, short-range communication, and a minimal amount of data transmission is desired, ESP-NOW is suitable. For bee colony monitoring, long-range monitoring is not a critical point, as beehives are usually placed close one to another within the apiary location. With respect to the Wi-Fi protocol, it is clear that establishing a connection is quite a time and power consuming task, but it provides much higher data rates therefore is better suited for applications that require high data transfer rates, such as video streaming or large file transfers.

The fast response speed of the ESP-NOW protocol provides a lot of general advantages, like direct control of other paired devices and lower power consumption (Amponis et al., 2022) in a battery operated scenario.

Some disadvantages of the ESP-NOW protocol can be mentioned as well. For instance from the security aspect it is only possible to encrypt 10 nodes. The ESP-NOW is proprietary to Espressif Systems and it could be difficult and require some effort to combine it with other vendor products (like Raspberry Pi, although there have been some attempts to implement this in a Linux operating system). This can limit its interoperability with other devices and systems. ESP-NOW is designed for small-scale applications, and it may not be suitable for large-scale deployments that require a high number of devices. Another disadvantage could be the payload size that is limited to 250 bytes per message and could be a determining factor for some applications. These limitations are more general and not affecting the applicability of this protocol for bee colony monitoring purposes.

Collected data

One aspect of this research was also focused on the urban beekeeping approach, as it was important to identify if the colony would have enough foraging resources within the city environment. This can be determined by analyzing colony weight dynamics. The collected data showed that the active foraging period started after June 22 and lasted till the first week of July, when the weight change was significant for almost every hive (see Fig. 6), except one (see Fig. 6, Hive 5), which swarmed and lost its strength. During this period the weight for colonies 1 to 5 increased by approximately 19 kg, 23 kg, 37 kg, 27 kg and 8 kg, respectively.

Additionally, the ambient temperature and temperature inside the hive was also monitored. The in-hive temperature can provide valuable information about the bee colony state (Kviesis et al., 2020b). It should be emphasized that in order to get an insight of the colony status by temperature data (when measured by a single temperature sensor), the position of the sensor within the hive is very important. Honey bees regulate the brood temperature to be stable: from 35 to 36 °C (Seeley, 1985; Bujok et al., 2002). Previous studies (Zacepins et al., 2011; Stalidzans & Berzonis, 2013; Kviesis et al., 2020a; Kviesis et al., 2020b) have shown that it is sufficient to place a single sensor above the brood nest. An example of the in-hive temperatures during the active foraging period in our experiment is illustrated in Fig. 7. The recorded temperatures of Hive 5 were not included due to sensor misplacement after the colony swarmed. Another example of sensor misplacement can be seen in Hive 2 data, as it shows large fluctuations, although the colony was healthy (according to the beekeeper).

Costs estimation

The economic aspect of the monitoring system is very important, so the costs should be kept as low as possible to make it financially viable for beekeepers. The system hardware components used in this experiment with approximate unit prices are summarized in Table 2. The provided costs are calculated based on the market prices in our country Latvia and can differ in other regions.

The calculated costs for the described experimental set (main node and five monitoring nodes) are 846.00 EUR. System installation, maintenance, data storage, or GSM SIM card with appropriate data plan and usage of the web system are not considered in these calculations. The total costs of the system can be reduced by using only one weight system per apiary so that the beekeeper can roughly estimate the start of the nectar flow at his apiary as well as the yield. With one weight system per apiary the cost reduction would be by 400.00 EUR.

System installation process

The system installation process should be as simple as possible, because usually beekeepers are not very open to new technologies and mostly not very experienced information technology (IT) specialists (Zacepins et al., 2017). In our case the user (beekeeper) only needs to put the scales under the hive, insert a temperature sensor into the hive and switch on the nodes, no specific configuration and assembling is required. All module configuration is done by the IT specialists before the initial installation in the field.