---
title: Turning your Raspberry Pi 4 into an edge gateway – Part 2
description: Configure your custom Raspberry Pi edge gateway with EdgeX Foundry
url: https://canonical.com/blog/turning-your-raspberry-pi-4-into-an-edge-gateway-part-2
---

1. [Blog](https://canonical.com/blog)
2. Article

---

[Galem KAYO](https://canonical.com/blog/author/galemk "More about Galem KAYO")

16 March 2020

# Turning your Raspberry Pi 4 into an edge gateway – Part 2

---

Share the article

In the [first part of this tutorial](https://ubuntu.com/blog/turning-your-raspberry-pi-4-into-an-edge-gateway-part-i), we installed and configured [EdgeX foundry](https://www.edgexfoundry.org/) on a [Raspberry Pi 4](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/), turning it into an edge gateway. In this tutorial, the gateway will be connected to dummy IoT devices. These dummy devices will be virtually simulated by software. They will send messages transmitting random measurements to an [MQTT](http://mqtt.org/) broker hosted in the cloud. These messages will be forwarded to MQTT clients that subscribes to receive them.

## Connecting the Southbound

The IoT data flow from devices to the edge gateway is referred to as the [Southbound.](https://github.com/lf-edge/glossary/blob/master/edge-glossary.md#northbound-vs-southbound-and-eastwest) In EdgeX, communication between IoT devices and gateways is assured by device services. A device service is a [microservice](https://en.wikipedia.org/wiki/Microservices) that implements an interface to an IoT communication protocol (Modbus, OPC-UA, REST, BLT, Zigbee, MQTT, BACNet, SNMP etc…).

The [Virtual Device Service](https://docs.edgexfoundry.org/1.2/microservices/device/virtual/Ch-VirtualDevice/) is convenient for configuring and testing  your Raspberry Pi 4 gateway. It allows you to carry out tests without any real IoT device. This way, microservices running on the gateway can be configured and troubleshooted without any IoT device connected. The Virtual Device Service also simulates dummy IoT devices that generate and transmit random numbers of different types: integer, unsigned integer, boolean and float.

The Virtual Device Service can be enabled very easily with the following command:

```
sudo snap set edgexfoundry device-virtual=on
```

Upon enablement, the service and the virtual devices it simulates become visible in the edgeX web UI.

## Creating an MQTT server in the cloud

Edge gateways are the juncture between devices and servers. We will now configure the receiving end in the cloud: a server hosting a custom MQTT broker. The MQTT broker will receive the messages sent from the virtual devices. The messages will then be dispatched to subscribing client devices.

The MQTT broker is installed on a [Ubuntu 18.04 (bionic) server instance running AWS cloud](https://aws.amazon.com/marketplace/pp/Canonical-Group-Limited-Ubuntu-1804-LTS-Bionic/B07K1QFB9V). MQTT is quite easily installed on the Ubuntu cloud instance in a snap, as follows:

```
sudo snap install mosquitto
```

The status of the broker can then be inquired:

```
sudo systemctl status snap.mosquitto.mosquitto.service
```

## Connecting the Northbound

With the MQTT server hosted in the cloud, a [Northbound](https://github.com/lf-edge/glossary/blob/master/edge-glossary.md#northbound-vs-southbound-and-eastwest) connection needs to be established between the Raspberry Pi 4 gateway and the server. An [EdgeX Export Service](https://docs.edgexfoundry.org/2.0/walk-through/Ch-WalkthroughExporting/) is a microservice that moves data collected by device services to a server in the cloud. An Export Service can be created as follows:

```
sudo snap set edgexfoundry export-client=on
```

```
sudo snap set edgexfoundry export-distro=on
```

Upon activation, data transfer to the MQTT server can be configured. Parameters like the server IP address, port, communication protocol, data format, topic and encryption are to be specified as described in the screenshot below.

Once saved, the Export Service will connect to the MQTT broker and create a topic. The Export Service will publish data collected from virtual devices through this topic.

## Consuming the virtual IoT data flow

At this point, you have a Raspberry Pi 4 gateway listening to virtual IoT devices, and forwarding the data collected from devices to an MQTT server hosted on a public cloud.

Now, any MQTT client running on any device can consume the IoT data flow originating from virtual devices. Clients only need to subscribe to the associated topic via our MQTT broker.

To read this data flow, we will install an MQTT client on a Ubuntu desktop, and subscribe to the topic created above via the Export Service. It should be noted that this data flow can be accessed via any MQTT client software installed on any desktop device.

```
sudo snap install mosquitto
```

```
mosquitto_sub -h <your_ip_adress_here> -t <topic_name_here>
```

The virtual IoT data flow can be read in the terminal. The stream corresponds to the data created by the Virtual Devices, in the format specified by our Export Service.

## Resources

* [EdgeX Foundry documentation](https://docs.edgexfoundry.org/index.html)
* [Mosquitto documentation](https://mosquitto.org/)
* [Mosquitto snap store](https://snapcraft.io/mosquitto)
* [Install instructions for Ubuntu on the Raspberry Pi 4](https://ubuntu.com/download/raspberry-pi)

## Next steps

In the third part of this tutorial, the gateway will be connected to a physical IoT device. We will also test the device management capabilities of EdgeX Foundry.

[Get in touch

Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form)

## Sign up for our newsletter

Get the latest Canonical news and updates in your inbox.

Work email:

\*I agree to receive information about Canonical's
products and services.

In submitting this form, I confirm that I have read and agree to
[Canonical's Privacy Notice](https://canonical.com/legal/data-privacy/contact)
and [Privacy Policy](https://canonical.com/legal/data-privacy).

Sign up

## Share on

---

## Related posts

[### AI infrastructure for telcos](https://canonical.com/blog/ai-infrastructure-for-telcos)

Why moving from pilots to production changes the platform Artificial intelligence has moved beyond the demonstration phase. Telco operators are already exploring it for fault...

[Benjamin Ryzman](https://canonical.com/blog/author/benjaminryzman)

2 October 2026

[### Canonical named a Challenger in the 2026 GartnerⓇ Magic Quadrant™ for Server Virtualization Platforms](https://canonical.com/blog/canonical-a-challenger-in-2026-gartner-magic-quadrant-for-server-virtualization-platforms)

Canonical has been recognized as a Challenger in the 2026 GartnerⓇ Magic Quadrant™ for Server Virtualization Platforms. The inaugural edition of the report provides an...

[Canonical](https://canonical.com/blog/author/canonical)

1 October 2026

[### Canonical announces the alpha release of Charmed OpenShell to help secure autonomous AI agent fleets](https://canonical.com/blog/charmed-openshell-alpha-release)

To streamline enterprise deployment and lifecycle management, Canonical is announcing the alpha release of Charmed OpenShell.

[Canonical](https://canonical.com/blog/author/canonical)

28 September 2026

[### Ubuntu coming soon to Snapdragon X2 Series platforms, unlocking more Linux PCs for the agentic world](https://canonical.com/blog/ubuntu-coming-soon-to-qualcomm-snapdragon-x2-series-platforms)

Canonical and Qualcomm Technologies announce upcoming native Ubuntu support for Qualcomm’s flagship laptop silicon, delivering multi-day battery life, 80 TOPS NPU acceleration,...

[Canonical](https://canonical.com/blog/author/canonical)

23 September 2026
