IoT Solution Development and Prototyping

Introduction

Developing an Internet of Things (IoT) solution involves more than connecting a sensor to a microcontroller. A useful IoT system begins with a clearly defined problem, converts requirements into a practical design, selects suitable hardware and software, collects and transports data, presents information to users, and is tested against measurable criteria. Prototyping provides a controlled way to validate these decisions before investing in a production system.

This chapter presents a complete development workflow for a basic sensor-to-dashboard prototype. The example uses a development board, a sensor, an application programming interface (API), and a cloud or low-code dashboard. The same workflow applies to environmental monitoring, agriculture, asset tracking, building automation, and educational projects.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Translate an IoT use case into functional and non-functional requirements.
2. Describe the major layers of an IoT solution architecture.
3. Select suitable sensors, development boards, communication methods, APIs, and dashboards.
4. Write and explain basic firmware for sensor acquisition and data transmission.
5. Integrate a device with a cloud or low-code service.
6. Test an IoT prototype systematically and interpret its results.
7. Identify security, privacy, reliability, safety, and ethical concerns.
8. Document a prototype so that another person can reproduce and maintain it.

1. From Problem to IoT Use Case

An IoT project should begin with a real operational need rather than with a fashionable device or platform. A use case describes who needs information, what physical phenomenon is observed, how often it is observed, and what decision or action follows.

For example, a greenhouse operator may need to know whether temperature and humidity are suitable for plant growth. The system may measure conditions every five minutes, display current and historical values, and issue an alert when temperature exceeds a selected limit.

A good use-case statement identifies:

• Stakeholders: people or organizations affected by the system.
• Assets: rooms, machines, crops, vehicles, or other monitored objects.
• Events: conditions that require observation or action.
• Data: measurements, timestamps, device identifiers, and status information.
• Actions: notification, control, inspection, maintenance, or reporting.
• Constraints: cost, power, network availability, environment, safety, and privacy.

Requirements

Requirements should be testable. They are commonly divided into functional and non-functional requirements.

A requirement such as “the system should be reliable” is incomplete. It should be converted into a measurable statement, such as “at least 95% of scheduled readings shall arrive at the dashboard during a 24-hour test.”

The sampling interval affects both usefulness and resource consumption. If a device transmits once every 300 seconds, the nominal number of transmissions per day is:

where N is the number of transmissions per day and T is the interval in seconds. For T = 300 s, N = 288. This calculation assumes continuous operation and one transmission per interval; retries, startup messages, and failures are not included.

2. IoT Architecture for a Prototype

A practical IoT solution can be understood as a sequence of layers:

1. Physical layer: sensors and actuators interact with the physical environment.
2. Device or edge layer: a microcontroller reads sensors, performs simple processing, and manages communication.
3. Network layer: Wi-Fi, Ethernet, cellular, Bluetooth, LoRaWAN, or another network carries data.
4. Service or platform layer: a cloud service receives, stores, processes, and exposes data through APIs.
5. Application layer: a dashboard, mobile application, report, or alert provides value to users.
6. Management and security functions: identity, updates, logging, access control, and monitoring apply across all layers.

Figure: A layered architecture for a sensor-to-dashboard prototype.

The layers are conceptual rather than rigid. For example, an edge device may filter data, store readings temporarily, or host a local web page. A cloud service may also perform analytics and alerting.

Data Flow

A typical measurement follows this path:

1. The sensor produces a physical signal.
2. The board reads the signal using a digital bus or analogue-to-digital converter.
3. Firmware validates and formats the value.
4. The communication module sends a message to an API.
5. The platform authenticates the request and stores the reading.
6. The dashboard retrieves or subscribes to the data.
7. A user interprets the reading and takes action.

A useful data record normally includes a device identifier, timestamp, measurement name, value, and unit. For example:

{
  "device_id": "greenhouse-01",
  "timestamp": "2025-03-10T10:15:00Z",
  "temperature_c": 24.6,
  "humidity_percent": 61.2
}

Using explicit units and a standard timestamp format reduces ambiguity during integration.

3. Selecting Components

Sensors

Sensor selection should be based on the required range, accuracy, resolution, response time, operating environment, interface, power use, calibration needs, and cost. Accuracy and resolution are different: resolution describes the smallest indicated change, while accuracy describes closeness to the true value.

A sensor with a stated accuracy of ±0.5 °C does not become accurate to ±0.1 °C merely because its software displays one decimal place. Display precision must not be confused with measurement quality.

Development Boards

A development board may contain a microcontroller, processor, memory, input/output pins, power regulation, and wireless connectivity. Selection criteria include:

• processor and memory capacity;
• number and type of input/output interfaces;
• Wi-Fi, Bluetooth, Ethernet, cellular, or other connectivity;
• voltage levels and current limits;
• development-tool support;
• sleep modes and energy consumption;
• community and library support;
• cost and long-term availability.

Electrical compatibility is essential. A sensor designed for 3.3 V logic should not be connected directly to a 5 V signal unless the interface is specified to tolerate it or a level shifter is used. Ground connections must normally be common between communicating modules.

Communication and Protocols

HTTP is widely used for API requests and is easy to test with web tools. MQTT is designed for lightweight publish/subscribe messaging and is often suitable for constrained devices. The choice depends on message frequency, network conditions, platform support, security, and required communication pattern.

Security should use HTTPS or secure MQTT with certificate or token authentication. Unencrypted telemetry may expose personal, operational, or commercially sensitive information.

4. Firmware Design

Firmware is the program running on the device. A basic sensor program usually follows this sequence:

1. initialize hardware and communication;
2. connect to the network;
3. read the sensor;
4. validate the result;
5. construct a data message;
6. transmit the message;
7. record success or failure;
8. wait until the next sampling time.

A simplified pseudocode design is:

setup:
    start serial logging
    initialize sensor
    connect to network
    configure secure API client

loop:
    reading = read sensor
    if reading is invalid:
        record error
    else:
        payload = create JSON reading
        result = send payload to API
        record result
    wait for sampling interval

A blocking delay is acceptable in a simple prototype, but it prevents other tasks from running. A timestamp-based scheduler is preferable when a device must monitor buttons, process incoming messages, or control actuators at the same time.

Firmware should include input validation. Plausibility limits are application-specific; for example, a greenhouse temperature reading of −100 °C may indicate a disconnected sensor rather than a real environmental condition. Limits should not silently convert unusual but valid values into normal values.

Reliability and Local Buffering

Network failure is normal in distributed systems. A prototype should define what happens when transmission fails. Possible approaches include retrying with a bounded delay, storing a small number of readings locally, and marking delayed readings with their original measurement time.

A retry policy should avoid endless rapid retries, which waste energy and may overload a service. Exponential backoff increases the interval between attempts, usually with a maximum delay. The exact policy depends on the platform and application requirements.

5. API and Dashboard Integration

An API defines how software components exchange data. Important API decisions include endpoint address, method, authentication, content type, payload format, response codes, rate limits, and error handling.

A typical HTTP telemetry request uses:

• method: POST;
• a secure URL;
• an authorization token or device credential;
• Content-Type: application/json;
• a JSON payload;
• interpretation of the response status.

A successful request does not always mean that the data is useful. The application should check whether the response indicates acceptance, duplication, authentication failure, invalid data, or service unavailability.

A low-code platform can reduce development time by providing a webhook, database connector, chart widget, and alert rule. This is valuable for teaching and early validation. However, a low-code prototype still requires careful configuration of data types, credentials, time zones, access permissions, retention policies, and dashboard refresh intervals.

A dashboard should answer a user question rather than merely display available data. Useful elements may include:

• current value and unit;
• timestamp of the latest reading;
• trend chart;
• device online/offline status;
• alert state;
• data-quality indicator;
• filter by device or time range.

The dashboard must distinguish “no recent data” from a genuine zero measurement. Otherwise, a communication failure can be misinterpreted as a safe operating condition.

6. A Practical Development Workflow

A disciplined workflow reduces rework:

Step 1: Define the use case

State the operational problem, users, decisions, and constraints.

Step 2: Specify acceptance criteria

For example: “During a two-hour test, at least 95% of scheduled readings shall be visible within 30 seconds of measurement.”

Step 3: Draw the architecture

Identify sensor, board, network, API, storage, dashboard, and security boundaries.

Step 4: Build a hardware proof of concept

Confirm power, wiring, signal levels, and sensor readings before adding cloud services.

Step 5: Test communication independently

Use a serial monitor, network diagnostic tools, or an API client to verify credentials and endpoint behavior.

Step 6: Integrate one layer at a time

First send a fixed test value, then send a real sensor value, then add storage, visualization, and alerts.

Step 7: Add fault handling

Test missing network, invalid readings, expired credentials, power interruption, and service errors.

Step 8: Evaluate against requirements

Record evidence rather than relying on informal observation.

Step 9: Document and review

Record wiring, software versions, libraries, credentials policy, test results, and known limitations.

7. Worked Application: Greenhouse Monitoring Prototype

The following is an illustrative case.

Background and Problem

A small greenhouse is inspected manually several times a day. The operator wants remote visibility of temperature and humidity and wishes to identify periods in which ventilation may be required. The first prototype is not intended to control equipment automatically.

Requirements

The prototype shall:

• measure temperature and relative humidity;
• sample every five minutes;
• display current values and a six-hour trend;
• identify readings outside configured limits;
• continue recording the measurement time when the network is temporarily unavailable;
• use a low-voltage development board and a digital sensor.

Proposed Solution

A Wi-Fi development board is connected to a combined temperature-humidity sensor. Firmware reads the sensor, creates a JSON record, and sends it over HTTPS to a cloud webhook. The platform stores the record and displays charts. An alert is generated when temperature exceeds the operator’s configured threshold for several consecutive readings.

The system should not trigger a physical fan in this prototype because automatic control would introduce additional safety and failure requirements. A later phase could add an actuator after risk assessment and separate testing.

Test Design

The team conducts the following tests:

Suppose 288 readings are scheduled in a 24-hour test and 280 arrive successfully. The delivery rate is:

Thus, the delivery rate is (280 / 288) × 100% ≈ 97.2%. This meets a 95% criterion, assuming the readings are correctly timestamped and the test conditions are representative.

Outcome and Learning Points

The prototype demonstrates the complete sensor-to-dashboard path. It also reveals that sensor placement matters: a sensor near a door may measure local drafts rather than average greenhouse conditions. The case illustrates that technical integration alone does not guarantee useful information. Installation, calibration, timestamps, user interpretation, and acceptance testing are equally important.

8. Testing and Evaluation

Testing should cover both individual components and the integrated system.

• Unit testing: test functions such as conversion, validation, and payload creation.
• Integration testing: verify that the sensor, board, network, API, storage, and dashboard work together.
• System testing: evaluate the complete solution under realistic conditions.
• Performance testing: measure delay, throughput, battery life, and resource use.
• Failure testing: deliberately introduce disconnection, invalid data, and service errors.
• Usability testing: ask representative users whether the dashboard supports decisions.

Useful measurements include latency, delivery rate, data completeness, uptime, and energy use. If the dashboard receives a reading 8 seconds after measurement, then the observed latency is 8 seconds; it should not be confused with the five-minute sampling interval.

For battery-powered devices, energy planning is important. If average current is I amperes and operating time is t hours, an idealized charge requirement is:

where Q is in ampere-hours. Real batteries require allowance for temperature, aging, discharge characteristics, conversion losses, and peak current. Therefore, this equation is a first estimate, not a guarantee of operating life.

9. Security, Privacy, and Governance

Security must be considered from the first prototype, even when the system is educational. Good practices include:

• change default passwords;
• avoid hard-coding secrets in public repositories;
• use secure transport;
• give each device a distinct identity where practical;
• apply least-privilege access;
• validate incoming data;
• update libraries and firmware;
• maintain logs without exposing secrets;
• revoke credentials when a device is retired.

IoT data may reveal occupancy, production activity, health conditions, or household behavior. Data minimization means collecting only what is necessary. Users should understand what is collected, why it is collected, where it is stored, and how long it is retained. Applicable privacy and cybersecurity laws depend on the country, sector, and type of data.

If a prototype affects safety-critical equipment, it must not be treated as production-ready merely because a dashboard works. Safety controls, fail-safe behavior, hazard analysis, independent testing, and regulatory compliance may be required.

10. Challenges and Limitations

Common difficulties include sensor drift, poor installation, unstable wireless networks, cloud outages, incompatible voltage levels, undocumented APIs, platform lock-in, and inaccurate timestamps. Cloud dashboards can accelerate development but may impose usage limits, recurring costs, or dependence on a vendor.

Prototype results may not predict production performance. A classroom test with one device and a strong Wi-Fi signal does not establish reliability across hundreds of devices or harsh environmental conditions. Scaling introduces device provisioning, fleet management, database capacity, monitoring, software updates, and cost-control problems.

Artificial intelligence can be added later for anomaly detection or prediction, but it should not be used to conceal poor sensor quality or insufficient data. A simple threshold may be more explainable and appropriate than a machine-learning model when the requirement is straightforward.

11. Best Practices

1. Start with a measurable user problem.
2. Define acceptance criteria before building.
3. Use explicit units, timestamps, and device identifiers.
4. Prototype the smallest complete end-to-end path.
5. Test hardware and communication separately before integration.
6. Design for network and power failure.
7. Protect credentials and personal data.
8. Keep dashboards focused on decisions.
9. Record software versions, wiring, assumptions, and test evidence.
10. Distinguish a demonstration prototype from a production system.

Chapter Summary

IoT solution development is a structured process that begins with a use case and testable requirements. A prototype normally includes sensors, an edge device, a communication network, an API or cloud service, data storage, and a dashboard. Component selection must consider electrical compatibility, accuracy, power, communication, cost, and maintainability. Firmware reads and validates sensor data, formats it, transmits it securely, and handles failure. APIs define the exchange of data, while dashboards convert measurements into information for decisions. Systematic testing should include normal operation, invalid data, network loss, restart, security, and usability. Privacy, safety, governance, and long-term maintainability must be considered even at the prototype stage.

Key Terms

API: A defined interface through which software systems exchange requests and data.

Actuator: A device that produces a physical action, such as switching a motor or valve.

Authentication: Verification of the identity of a user, device, or service.

Cloud service: Internet-accessible computing service used for storage, processing, communication, or applications.

Dashboard: A visual interface that presents data and status information.

Edge device: Hardware near the physical environment that reads, processes, or transmits data.

Firmware: Software stored and executed on an embedded device.

HTTP: A web communication protocol based on requests and responses.

IoT architecture: The organized structure of devices, networks, services, applications, and management functions in an IoT system.

Latency: The time between an event or measurement and its reception or display.

Low-code platform: A software platform that enables applications to be assembled with limited hand-written code.

MQTT: A lightweight publish/subscribe messaging protocol commonly used in IoT systems.

Payload: The data portion of a transmitted message.

Prototype: An early implementation used to test feasibility, requirements, and design decisions.

Sampling interval: The time between successive measurements.

Sensor: A device that detects a physical condition and produces a measurable signal.

Telemetry: Measurement data transmitted from a device to a receiving system.

Webhook: An HTTP endpoint that receives data or event notifications from another system.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional IoT requirement?
2. Name the main layers in a sensor-to-dashboard IoT architecture.
3. Why should a data record include a unit and timestamp?
4. What is the purpose of API authentication?
5. Distinguish sensor accuracy from sensor resolution.

Long Answer Questions

1. Explain a complete workflow for developing and testing an IoT prototype.
2. Compare HTTP/REST and MQTT for telemetry applications.
3. Discuss the factors that should guide development-board and sensor selection.
4. Explain how a dashboard can distinguish missing data from a genuine zero value.
5. Discuss security, privacy, and safety issues that may arise in an IoT greenhouse system.

Analytical / Application Questions

1. A device samples every 10 minutes. Calculate the nominal number of readings in 24 hours and identify two reasons why the actual number received may be lower.
2. Design an acceptance test for an IoT system that must display readings within 30 seconds and achieve at least 95% delivery.
3. A prototype works reliably on a laboratory bench but fails intermittently in a greenhouse. Analyse at least four possible causes and propose an investigation plan.

Multiple Choice Questions with Answers

Question 1

Which activity should normally occur first in IoT solution development?

A. Define the user problem and requirements

B. Purchase the most powerful development board

C. Create a dashboard with random data

D. Deploy machine-learning software

Correct Answer: A. Define the user problem and requirements

Question 2

Which item belongs primarily to the edge layer?

A. A dashboard chart

B. A microcontroller reading a sensor

C. A cloud database

D. A user privacy policy

Correct Answer: B. A microcontroller reading a sensor

Question 3

What is the nominal number of transmissions per day when a device sends one reading every 300 seconds?

A. 144

B. 240

C. 288

D. 360

Correct Answer: C. 288

Question 4

Which protocol uses a publish/subscribe communication model?

A. MQTT

B. HTML

C. CSV

D. GPIO

Correct Answer: A. MQTT

Question 5

Why should a prototype validate sensor readings before transmission?

A. To make the sensor physically more accurate

B. To identify implausible or failed measurements

C. To eliminate the need for network security

D. To increase the battery voltage

Correct Answer: B. To identify implausible or failed measurements

Question 6

Which dashboard feature most directly helps identify stale data?

A. A decorative background image

B. The latest-reading timestamp

C. A larger font for the title

D. A fixed colour palette

Correct Answer: B. The latest-reading timestamp

Question 7

What is the main purpose of an API in a sensor-to-dashboard system?

A. To define how software components exchange data

B. To convert a battery into a sensor

C. To replace all testing

D. To guarantee physical sensor accuracy

Correct Answer: A. To define how software components exchange data

Question 8

A test schedules 288 readings and receives 280. What is the approximate delivery rate?

A. 90.3%

B. 95.0%

C. 97.2%

D. 102.9%

Correct Answer: C. 97.2%

Question 9

Which practice best protects an IoT device credential?

A. Publishing it in source code

B. Using the same password for every device

C. Storing and managing it securely with limited access

D. Sending it without encryption

Correct Answer: C. Storing and managing it securely with limited access

Question 10

Why is a laboratory prototype not automatically production-ready?

A. Production systems never use sensors

B. Real deployments introduce scale, environmental, security, and reliability challenges

C. Dashboards cannot be used outside laboratories

D. Cloud services cannot store telemetry

Correct Answer: B. Real deployments introduce scale, environmental, security, and reliability challenges