Implementation of Mobile IoT Application for Greenhouse Monitoring
A 10-hectare greenhouse farm lost 80% of its tomato crop because the mobile app didn't show a heater failure overnight. The operator saw the notification only the next morning — by then the temperature had dropped to 5°C. How to avoid such scenarios? Our mobile IoT application addresses this through a reliable stack of MQTT, critical alerts, and automatic control. With over 7 years of experience, we have launched more than 20 projects in the agricultural sector, each requiring a custom architecture.
A greenhouse is a closed environment where every parameter affects yield. Even a 2°C temperature fluctuation can reduce productivity by 10-15%. Humidity, CO₂, light, soil moisture, pH, and EC of the nutrient solution — all these values must be monitored in real time. Unlike open fields, greenhouses have good connectivity (Wi-Fi, Zigbee) but strict reliability requirements: a critical temperature drop at night or a humidifier failure can destroy the crop in hours.
We use industrial sensors with I²C, UART, and SDI-12 interfaces, connected to ESP32 microcontrollers. Data is published to an MQTT broker with QoS 1, ensuring delivery without duplication. The mobile app subscribes to the relevant topics and displays up-to-date information on the dashboard. Climate control is achieved by sending commands to relays via MQTT. Our expertise covers the full development cycle of a greenhouse app.
Which Sensors and Protocols Do We Use?
Standard set for one greenhouse section:
- Temperature/humidity: SHT40 (I²C), DHT22 (One-Wire) — on ESP32-based nodes
- CO₂: MH-Z19B (UART) or SenseAir S8 (Modbus)
- Light: VEML7700 (I²C), lux and photosynthetically active radiation (PAR)
- Soil moisture: TEROS 12 (SDI-12)
- EC/pH of nutrient solution: Atlas Scientific EZO-EC and EZO-pH (I²C UART)
Nodes based on ESP32 with firmware (ESPHome or Tasmota) publish data to MQTT. Home Assistant or a custom MQTT broker (Mosquitto) aggregates data. The mobile app communicates via REST API or WebSocket on the backend.
Why MQTT Is Better Than HTTP for IoT?
MQTT provides asymmetric push with minimal latency. Compared to HTTP polling, network load is 10–15 times lower. For greenhouses with 50+ sections this is critical: each device sends data every 30 seconds. MQTT QoS 1 guarantees delivery without duplication. We use it for all real-time scenarios.
Detailed protocol information can be found on Wikipedia. Comparison of MQTT and HTTP for IoT:
| Criterion | MQTT | HTTP |
|---|---|---|
| Model | Publish-Subscribe | Request-Response |
| Latency | <10 ms (push) | >100 ms (polling) |
| Network load | Low (persistent connection) | High (each request) |
| Delivery guarantee | 3 QoS levels | N/A (requires retries) |
| Scalability | Topics, automatic balancing | Server-limited |
Real-Time Data via MQTT on Android
class GreenhouseMonitorService : Service(), MqttCallbackExtended { private lateinit var mqttClient: MqttAndroidClient private val sectionData = ConcurrentHashMap<String, GreenhouseSectionState>() fun startMonitoring(sections: List<String>) { sections.forEach { sectionId -> mqttClient.subscribe("greenhouse/$sectionId/+", 1) } } override fun messageArrived(topic: String, message: MqttMessage) { val parts = topic.split("/") val sectionId = parts[1] val parameter = parts[2] val value = String(message.payload).toDoubleOrNull() ?: return val current = sectionData.getOrPut(sectionId) { GreenhouseSectionState(sectionId) } val updated = when (parameter) { "temperature" -> current.copy(temperatureC = value) "humidity" -> current.copy(humidityPercent = value) "co2" -> current.copy(co2Ppm = value.toInt()) "light_lux" -> current.copy(lightLux = value.toInt()) "soil_moisture" -> current.copy(soilMoistureVwc = value) "ec" -> current.copy(nutrientEc = value) "ph" -> current.copy(nutrientPh = value) else -> current } sectionData[sectionId] = updated broadcastUpdate(updated) } } Section Dashboard and Threshold Values
For multiple sections, use a horizontal PageView or TabBar with a dashboard for each section. Each section card shows color indicators: green (normal), yellow (warning), red (critical).
Threshold ranges for tomatoes as an example:
| Parameter | Critically Low | Normal | Critically High |
|---|---|---|---|
| Night temperature | < 12°C | 15-18°C | > 25°C |
| Day temperature | < 18°C | 22-28°C | > 35°C |
| Humidity | < 50% | 65-80% | > 90% |
| CO₂ | < 400 ppm | 800-1200 ppm | > 1500 ppm |
| EC solution | < 1.5 | 2.0-3.5 | > 5.0 |
| pH solution | < 5.5 | 5.8-6.5 | > 7.0 |
The backend stores threshold configuration; the mobile app downloads it on startup and caches it in SharedPreferences.
How to Control Climate from the App?
Climate control is a key feature of greenhouse automation. Vents, heaters, humidifiers, CO₂ generators are controlled from the app. MQTT commands to relays:
Future<void> setVentilation(String sectionId, bool open) async { _mqttClient.publishMessage( 'greenhouse/$sectionId/vent/command', MqttQos.exactlyOnce, (MqttClientPayloadBuilder()..addString(open ? 'OPEN' : 'CLOSE')).payload!, ); } For automated scenarios (open a vent if temperature > 28°C), the logic can be on the backend (Node-RED, Home Assistant automation) or as a local rule within the app.
How to Set Up Critical Alerts?
Critical alerts for a greenhouse go beyond simple notifications. A below-zero temperature at night means a heater failure — immediate action is required.
On Android: FCM with PRIORITY_HIGH plus a Foreground Service with Wake Lock for reliable delivery in night mode. On iOS: Critical Alerts via the com.apple.developer.usernotifications.critical-alerts entitlement — they play at full volume regardless of Do Not Disturb mode.
Additionally, we implement escalation calls via Twilio Voice API for multiple responsible persons if an alert is not acknowledged within 10 minutes.
What Does the Event Log and Reports Provide?
Agronomists need not only real-time data but also history: when the heater turned on, when vents opened, what the temperature was at 2 AM. An event log with filtering by type and period is an important feature.
Exporting reports to Excel/CSV is a requirement for most industrial clients to document growing conditions. The backend generates reports, and the mobile app downloads them and opens via Share Sheet (iOS) or FileProvider (Android).
Development Process
We follow this plan:
- Analysis: study your greenhouses, sensors, scenarios. Prepare architecture documentation.
- Design: UI/UX prototype, API and MQTT topic specification.
- Implementation: write app code (iOS/Android), backend, and ESP32 firmware.
- Testing: integration testing with your sensors, load testing.
- Deployment: upload to App Store and Google Play, configure MQTT broker, commissioning.
- Support: 3 months of technical support after launch, training your team.
Example MQTT topic configuration: each greenhouse section uses a topic hierarchy — greenhouse/{sectionId}/temperature, greenhouse/{sectionId}/humidity, greenhouse/{sectionId}/co2, greenhouse/{sectionId}/vent/command, greenhouse/{sectionId}/heater/status. This simplifies filtering on both the app and backend sides.
What Is Included in Development
We provide a complete package:
- Architecture documentation (diagrams, API specification)
- Source code for the app (iOS/Android) and backend
- MQTT broker configuration and sensor integration
- Upload to App Store and Google Play (your accounts)
- 3 months of technical support after launch
- Training your team on system operation
Timeline and Warranty
A basic version with monitoring and notifications starts from 5 weeks. A multi-section greenhouse with full logging and export takes up to 3 months. The cost is determined individually. We provide a 12-month warranty on all code. Order development — contact us for a project assessment.
We will assess your project free of charge — write to us, and we will prepare a commercial proposal within 2 days.