Bridging the Gap: MQTT Communication on AWS IoT Greengrass v2 — SciTech Edge Advance 1.1

Executive Summary¶

In the previous log, we mastered local IPC for device-internal communication. Today, we open the "bridge" to the outside world using MQTT. This log documents the transition to cloud-connected messaging, where the Greengrass device acts as a node in a larger distributed system.

We explore the role of the MQTT Broker as a middleman, handle recipe version updates (moving to v1.0.8), and validate bi-directional communication using both local Docker consoles and the AWS IoT Cloud Console.

Hardware Stack¶

• Edge Device: Raspberry Pi
• Compute Module: Raspberry Pi CM5
• Architecture: ARM64
• OS: Raspberry Pi OS (64-bit)

Software & Tooling Stack¶

• AWS IoT Greengrass v2 Core
• MQTT Broker (Moquette / EMQX / AWS IoT Core)
• AWS IoT Console (Cloud Test Client)
• Local Debug Console

Technical Walkthrough¶

The Architecture: MQTT Broker as the Middleman

Unlike direct IPC, MQTT introduces a Broker.

1. Publisher: Sends a message to the Broker.
2. Broker: Routes the message to any subscribed clients.
3. Subscriber: Receives the message from the Broker.

This architecture decouples the device from the cloud. The code on the Raspberry Pi doesn't need to know who is listening—it just pushes to a topic, and the Broker handles the rest.

Recipe Configuration & Versioning (v1.0.8)

We updated our component recipe to support MQTT operations. A critical part of maintaining stable edge deployments is strict versioning.

For this deployment, we bumped the component version to 1.0.8.

# Deploying the updated version
sudo /greengrass/v2/bin/greengrass-cli deployment create \
--recipeDir ./recipes \
--artifactDir ./artifacts \
--merge "com.example.MqttPublisher=1.0.8"

Why 1.0.8? We iterated through several failed configuration attempts (versions 1.0.2 - 1.0.7) where the permission policies for the MQTT bridge were too restrictive.

Cloud-to-Device Communication

The true power of Greengrass is the ability to react to cloud commands.

Test Scenario:

1. Device: Subscribed to test/topic running on the Raspberry Pi CM5.
2. Cloud: AWS IoT Console -> MQTT Test Client.

When we published "Hello from AWS IoT Console" from the browser:

{
"message": "Hello from AWS IoT Console",
"timestamp": 1705910000
}

The message appeared instantly on the Raspberry Pi's log stream. This verifies that the IoT Thing Policy attached to the device certificate allows iot:Subscribe and iot:Receive on this specific topic filter.

The "Rogue Insight"

Verification¶

We validated the system using a dual-console approach:

1. Local Docker Console: We used a local containerized test client to publish messages.

   "Whenever I publish, the same message comes over here."

2. AWS IoT Console: We confirmed that messages generated on the device successfully reached the cloud.

[INFO] (Copier) com.example.MqttPublisher: Received message on topic
'test/topic': Hello World from Local

Closing Note¶

By establishing a reliable MQTT bridge, we've effectively turned the Raspberry Pi CM5 into a connected industrial node. It can now report telemetry to the cloud and receive commands from the control plane—the two fundamental operations of any Industrial IoT system.

— DK Swami Founder, Scitech Industries