Skip to content

Customer Scenarios

Customer Scenarios

This section maps common customer scenarios to the IoT technology stack. By the end of this section, you will be able to:

  • Identify the most common IoT customer requirements on
  • Map each customer scenario to specific technology components
  • Understand customer pain points and how the solution addresses them
  • Use scenario knowledge to structure effective customer conversations

Scenario 1: Factory Environment Monitoring

Section titled “Scenario 1: Factory Environment Monitoring”
  • Industry: Manufacturing, food processing, pharmaceutical
  • Region: Southeast Asia, South America, Africa
  • Typical customer: Factory owner or production manager who needs to monitor temperature, humidity, and air quality across production areas
  • Product quality issues caused by uncontrolled environmental conditions
  • Regulatory compliance requirements (HACCP, GMP) demand documented temperature logs
  • Manual monitoring is labor-intensive and error-prone
  • No visibility into conditions when away from the facility
NeedTechnology ComponentHow It Works
Temperature/humidity sensingESP32 + DHT22/BME280 sensorSensor reads conditions every 5-60 minutes
Data transmissionMQTT → Mosquitto brokerESP32 publishes readings to topic factory/zone1/env
Data processingNode-REDParses JSON, validates ranges, formats for storage
Data storageInfluxDBStores time-series data with zone and sensor tags
Real-time visualizationGrafanaDashboard shows current values, trends, historical charts
Threshold alertsGrafana AlertingSends email/Telegram notification when temperature exceeds limit
  • “Your customer can see real-time factory conditions from anywhere in the world”
  • “The system automatically records temperature logs for compliance audits”
  • “Alerts can be sent to mobile phones when conditions go out of range”
  • “Multiple zones can be monitored from a single dashboard”
  • “Implementation cost starts at under $50 per monitoring point”

Q: Can it integrate with my existing systems? A: Yes, Node-RED supports HTTP APIs, database connections, and custom protocols. Data can be forwarded to existing ERP or MES systems.

Q: What happens if WiFi goes down? A: ESP32 can buffer readings and transmit when connectivity is restored. For critical applications, consider cellular backup (external LTE module).

Q: How accurate are the sensors? A: DHT22 offers ±0.5°C accuracy, suitable for most industrial monitoring. Higher precision sensors (BME280: ±0.3°C, SHT30: ±0.2°C) are available at incremental cost.

  • Industry: Warehousing, logistics, tool/equipment rental
  • Region: Middle East, Europe, East Asia
  • Typical customer: Warehouse manager needing to track tool check-in/check-out or asset movement
  • Tools and equipment frequently lost or misplaced
  • No visibility into who last used an asset or when it was returned
  • Manual sign-out sheets are unreliable and rarely updated
  • Time wasted searching for missing equipment
NeedTechnology ComponentHow It Works
Tag readingESP32 + RC522 RFID moduleReader scans tag UID when brought near (3-5cm range)
Tag identificationMFRC522 libraryDecodes RFID tag unique identifier
Data transmissionMQTT → Node-REDSends check-in/out events with tag ID and timestamp
User/asset mappingMariaDBStores tag-to-asset and tag-to-person relationships
Status displayNode-RED DashboardShows current location and status of each asset
Usage historyGrafanaTimeline of check-in/out events per asset
  • “Each RFID tag costs under $0.50, making it affordable to track hundreds of assets”
  • “The system records who checked out what and when — full audit trail”
  • “Alerts can be set for overdue returns or unauthorized movement”
  • “Integration with existing inventory management systems is straightforward via Node-RED”

Q: What’s the reading range? A: Standard RC522 has 3-5cm range. For longer range (up to 1m), upgrade to UHF RFID readers.

Q: Can it read multiple tags at once? A: Standard RC522 reads one tag at a time. Anti-collision algorithms exist but throughput is limited. For bulk scanning, use UHF readers.

Q: Does it work with metal assets? A: Metal surfaces interfere with RFID. Use on-metal RFID tags or mount tags on non-metal brackets.

  • Industry: Manufacturing, security, construction monitoring
  • Region: All regions
  • Typical customer: Overseas customer who wants to remotely verify production progress or inspect facility conditions
  • Cannot physically visit factories to inspect production status
  • Existing video surveillance is not accessible remotely or too expensive
  • Need periodic visual confirmation without deploying personnel
  • Requires tamper-evident documentation for compliance
NeedTechnology ComponentHow It Works
Image captureESP32-CAM + OV2640Captures JPEG photo on MQTT command or motion trigger
Motion detectionPIR sensor (HC-SR501)Detects movement, triggers camera via ESP32 interrupt
Image encodingESP32 Base64 libraryEncodes image for MQTT transport (or stores on SD card)
Image transmissionMQTT (fragmented)Sends image in chunks if file exceeds MQTT size limit
Display & storageNode-RED + file systemDecodes and displays image, saves to server storage
NotificationGrafana Alerting / TelegramSends notification with image link on motion detection
  • “customers can request a photo of their production line anytime via MQTT command”
  • “Motion-triggered images create an event log for security and compliance”
  • “Low-cost solution: total hardware cost under $15 per camera point”
  • “Images can be stored long-term for audit and quality documentation”

Q: What image quality can I expect? A: OV2640 supports up to 1600×1200 (2MP). For MQTT transmission, we typically use 640×480 (compressed to ~30-50KB) for balance of quality and speed.

Q: Can it stream video? A: No, ESP32-CAM is not suitable for video streaming. It captures still images on demand. For video, recommend dedicated IP cameras integrated via RTSP to Node-RED.

Q: How does it work at night? A: ESP32-CAM has a built-in flash LED that can be triggered. For low-light environments, add external IR illuminators.

Scenario 4: Automated Dosing / Liquid Control

Section titled “Scenario 4: Automated Dosing / Liquid Control”
  • Industry: Agriculture, chemical processing, water treatment
  • Region: Africa, Middle East, Southeast Asia
  • Typical customer: Farm owner, greenhouse operator, or plant manager needing automated liquid dispensing
  • Manual dosing is imprecise and labor-intensive
  • Overdosing wastes expensive chemicals or nutrients
  • No remote visibility into tank levels or dosing history
  • Equipment damage from dry-running pumps
NeedTechnology ComponentHow It Works
Level sensingESP32 + water level / ultrasonic sensorMeasures liquid level at configurable intervals
Pump controlESP32 + relay moduleSwitches pump ON/OFF based on schedule or level
SchedulingNode-RED timer nodesConfigurable dosing schedules (time, duration, frequency)
Safety logicNode-RED Function nodeDry-run protection, max run time limits, overflow prevention
Level monitoringGrafana dashboardReal-time and historical tank level visualization
AlertsGrafana Telegram alertLow level, pump failure, schedule deviation notifications
  • “Precise, programmable dosing reduces chemical/nutrient waste by up to 30%”
  • “Remote monitoring eliminates daily manual tank checks”
  • “Safety features (dry-run protection, overflow prevention) protect equipment”
  • “Historical dosing data supports compliance reporting and optimization”

Q: How precise is the dosing? A: Relay-based control is ON/OFF only, so precision depends on timer accuracy (±1 second) and pump flow rate consistency. For higher precision, recommend peristaltic pumps with pulse control.

Q: What happens if WiFi fails during a dosing cycle? A: ESP32 can be programmed with a fallback schedule stored locally. Critical safety limits (max runtime, dry-run) are enforced at the ESP32 level, not dependent on network.

Q: Can it handle multiple dosing points? A: Yes, each dosing point needs its own ESP32 + relay + sensor. They can all be managed from a single Node-RED dashboard. For multi-point coordination, use Node-RED’s join and split nodes.

Scenario 5: Energy Monitoring and Management

Section titled “Scenario 5: Energy Monitoring and Management”
  • Industry: Manufacturing, commercial buildings, cold storage
  • Region: Europe, North America (high energy costs)
  • Typical customer: Facility manager looking to reduce energy costs and track carbon emissions
  • Rising electricity costs with no visibility into consumption patterns
  • Cannot identify which equipment or processes are energy-intensive
  • Carbon reporting requirements demand accurate energy data
  • No actionable insights for energy reduction initiatives
NeedTechnology ComponentHow It Works
Power measurementShelly devices or Tasmota-flashed smart plugsReports voltage, current, power, energy in real-time
Data collectionMQTT → Node-REDDevices publish power metrics to MQTT topics
Data processingNode-RED Function nodeCalculate cost, aggregate by zone/equipment, detect anomalies
Energy storageInfluxDBStore cumulative energy (kWh) and instantaneous power (W)
Cost dashboardGrafanaEnergy consumption by zone, cost trends, peak demand analysis
Anomaly alertsGrafana AlertingSudden power spikes, unusual consumption patterns, equipment faults
  • “Identify which equipment consumes the most energy — target reduction efforts effectively”
  • “Track energy costs in real-time and compare against production output”
  • “Automatic carbon emission calculation from energy consumption data”
  • “ROI: typical energy savings of 10-20% through monitoring and optimization”

Q: How accurate is the power measurement? A: Shelly devices offer ±1-2% accuracy, sufficient for monitoring and allocation. For billing-grade accuracy (±0.5%), use dedicated energy meters with Modbus interface.

Q: Can it monitor 3-phase equipment? A: Yes, use three Shelly 3EM devices (one per phase) or a dedicated 3-phase energy meter.

Q: What’s the maximum current it can measure? A: Shelly Pro models support up to 50A per channel. For higher currents, use current transformers (CTs) with appropriate ratio.

Scenario 6: Industrial Broadcast and Notification

Section titled “Scenario 6: Industrial Broadcast and Notification”
  • Industry: Manufacturing, warehouses, large facilities
  • Region: All regions
  • Typical customer: Factory manager needing overhead announcements, shift change alerts, or emergency notifications
  • No centralized system for broadcasting announcements across the facility
  • Shift changes, break times, and emergency alerts rely on manual paging
  • Different areas need different notifications (not one-size-fits-all)
  • Existing PA systems are expensive and inflexible
NeedTechnology ComponentHow It Works
Audio playbackESP32 + I2S audio module (MAX98357A)Decodes MP3/AAC stream and outputs to speaker
Audio sourceESP8266Audio libraryStreams from URL (HTTP internet radio, local file, or TTS)
Zone controlMQTT topic per zoneEach ESP32 subscribes to its zone-specific control topic
SchedulingNode-RED timer nodesSchedule announcements at specific times (shift change, breaks)
Emergency overrideNode-RED HTTP endpointManual trigger for urgent announcements bypassing schedule
IntegrationNode-RED → MQTTConnect to alarm systems, production line status, or external triggers
  • “Zone-based audio: different messages for different areas of the facility”
  • “Schedule automated announcements — shift changes, break times, end-of-day”
  • “Emergency override: one-click alert to all zones simultaneously”
  • “Cost-effective: each audio point costs under $10 in hardware”

Q: What audio quality can I expect? A: I2S with MAX98357A supports 16-bit 44.1kHz audio — comparable to FM radio. Suitable for speech and music announcements but not high-fidelity audio.

Q: How many audio zones can I have? A: Unlimited in theory — each ESP32 + I2S module is an independent zone. Practically limited by MQTT broker capacity. 50+ zones on a single Mosquitto instance.

Q: Can it play pre-recorded messages? A: Yes. Store audio files on a web server and configure ESP32 to stream them on demand. Or use Node-RED to trigger text-to-speech APIs (Google TTS, AWS Polly).

ScenarioPrimary HardwareData FlowKey Selling Point
Factory EnvironmentESP32 + DHT22Sensor → MQTT → InfluxDB → GrafanaCompliance, quality control
Asset TrackingESP32 + RC522RFID → MQTT → MariaDB → DashboardLoss prevention, audit trail
Remote InspectionESP32-CAM + PIRImage → MQTT → Node-RED → StorageRemote verification
Automated DosingESP32 + Relay + SensorSensor → MQTT → Node-RED → ActuatorWaste reduction, automation
Energy MonitoringShelly / TasmotaPower → MQTT → InfluxDB → GrafanaCost savings, carbon tracking
Industrial BroadcastESP32 + I2SCommand → MQTT → ESP32 → SpeakerFacility-wide communication

Pre-Sales Checklist for Customer Conversations

Section titled “Pre-Sales Checklist for Customer Conversations”

When a customer approaches with a request, use this checklist:

  1. Identify the primary scenario — What is the customer trying to achieve?
  2. Map to the technology stack — Which components are needed?
  3. Assess technical boundaries — What are the limitations?
  4. Estimate implementation complexity — Simple, moderate, or complex?
  5. Prepare talking points — How to explain the solution value?
  6. Anticipate common questions — Be ready with answers