**Principle: how sensor data gets into “the cloud”**

Think of it as a pipeline with 6 layers:

Sensor → Edge device → Network → Protocol → Cloud ingestion → Storage/Apps


**1) Sensor acquisition (physical → numbers)**

Your [sensor](https://www.ampheo.com/c/sensors) outputs data via interfaces like:

* Analog voltage (needs [ADC](https://www.onzuu.com/category/analog-to-digital-converters))
* I²C / SPI (digital sensors like temp/pressure/humidity)
* UART (many PM2.5 sensors)

The edge device (MCU/SBC/gateway) samples at a chosen rate, applies calibration, and turns raw readings into engineering units.

**2) Edge packaging (numbers → messages)**

You usually send a compact payload such as JSON:

`{"ts":"2026-01-14T10:12:00Z","pm25":18,"pm10":25,"tempC":24.6,"rh":45.2}`

Good practice:

* Add timestamp, device ID, units, firmware version
* Batch multiple samples if bandwidth is expensive (cellular)

**3) Network transport (edge → internet)**

Choose based on power, coverage, and bandwidth:

* Wi-Fi / Ethernet (easy, high bandwidth)
* Cellular (LTE-M/NB-IoT) for remote sites
* LoRaWAN (very low bandwidth; often goes through a gateway)

**4) Protocol (how messages travel)**

Most IoT clouds expect one of these:

* MQTT (lightweight pub/sub; great for sensors)
* HTTPS/REST (simple, heavier; good for occasional uploads)

Example: AWS IoT Core supports MQTT (and MQTT over WebSockets) and HTTPS publish.
Example: Azure IoT Hub supports MQTT and AMQP (and HTTPS), and MQTT/AMQP enable server push for cloud-to-device messages.

**5) Security + device identity (don’t skip this)**

In production, data is sent over TLS, and the device authenticates itself.

* AWS IoT commonly uses mutual TLS with X.509 certificates (device presents a cert during TLS).
* Azure IoT Hub can authenticate devices using X.509 certificates.
* [Arduino](https://www.ampheoelec.de/c/development-board-arduino) IoT Cloud uses an MQTT data pipeline, and commonly uses client certificate authentication for devices.

**6) Cloud ingestion + storage + visualization**

After the cloud receives messages, you typically:

* Route via rules/stream processing
* Store in time-series DB / data lake
* Visualize in dashboards
* Optionally send commands back (e.g., change sample rate)

Note: Google Cloud IoT Core was shut down in August 2023, so most teams now use other IoT ingestion options.

**Example 1: PM2.5 sensor PMS5003 → ESP32 → AWS IoT Core (MQTT)**

Why this combo: PMS5003 outputs PM data over UART, ESP32 has Wi-Fi + enough RAM for TLS, AWS IoT Core speaks MQTT.

**Hardware**

* PMS5003 (UART output)
* ESP32
* Common GND
* UART wiring (PMS TX → ESP RX, PMS RX optional unless you control sleep)

**Cloud steps (high level)**

1. Create an AWS IoT “Thing” and attach an IoT policy
2. Create/register an X.509 certificate and place cert + private key on the ESP32
3. ESP32 connects with MQTT over TLS (mutual auth) and publishes messages to a topic like:

factory/line1/air/pms5003

**Typical payload**

`{"pm1":12,"pm25":18,"pm10":25,"ts":1705255920}`

**Example 2: Temp/RH sensor SHT31-D (I²C) → Arduino UNO WiFi Rev2 → Arduino IoT Cloud**

Why this combo: [SHT31](https://www.ampheo.com/search/SHT31) is clean I²C; UNO WiFi Rev2 can do MQTT-style connectivity; Arduino Cloud is great for quick dashboards.

**Hardware**

* [SHT31-D](https://www.ampheo.com/search/SHT31-D) (I²C): SDA/SCL + 3.3V (or via level shifting if needed) + GND
* [UNO WiFi Rev2](https://www.ampheo.com/product/abx00021-25542449) (Wi-Fi onboard)

**Cloud steps**

1. Create a “Thing” in [Arduino](https://www.ampheo.com/c/development-board-arduino) IoT Cloud and define variables (temp, rh)
2. Provision device credentials (Arduino Cloud commonly uses certificate-based authentication)
3. Device updates cloud variables; Arduino Cloud moves updates through its MQTT event pipeline
4. Optional: use the Device API to interact with the Arduino Cloud MQTT broker from services like Node-RED.

**Example 3: Environmental sensor BME280 (I²C/SPI) → STM32 + cellular modem → Azure IoT Hub (MQTT)**

Why this combo: [STM32](https://www.ampheo.com/search/STM32) handles real-time sampling; cellular gives wide coverage; Azure IoT Hub supports MQTT endpoints.

**Azure connectivity facts**

* Azure IoT Hub supports MQTT v3.1.1 on port 8883 and MQTT over WebSocket on port 443.
* Devices can authenticate using X.509 certificates (recommended for production).

**Flow**

1. STM32 reads [BME280](https://www.ampheo.com/product/bme280-26836707) (temp/pressure/humidity)
2. Cellular modem opens a TLS connection and publishes telemetry via MQTT to IoT Hub
3. Route data into storage + dashboards (or IoT Central)