mqtt - freeCodeCamp.org

How to Build Real-Time Update Systems with MQTT and Express.js

David Aniebo — Tue, 10 Mar 2026 16:05:25 +0000

Real-time updates are everywhere – like live sports scores, stock tickers, chat applications, and IoT dashboards. If you want to build systems that push data to users the moment it changes, you need the right tools.

Message Queuing Telemetry Transport (MQTT) is a lightweight messaging protocol that excels at this. Combined with a broker like Mosquitto and a web framework like Express, you can build a production-ready real-time system in a single afternoon.

In this tutorial, you'll build a complete real-time football (soccer) sports update system from scratch. You'll create an admin interface for uploading scores and match details, a viewer interface for watching live updates, and a backend that uses MQTT to broadcast changes instantly to every connected client.

By the end of this guide, you'll understand how to integrate MQTT with Express, set up the Mosquitto broker, and deliver real-time data to web browsers using Server-Sent Events. You will have a working system that you can extend for production use.

What You Will Learn
Prerequisites
Understanding the Architecture
What is MQTT and Why Use It?
- MQTT Topic Design
- Why Server-Sent Events Instead of WebSockets?
Project Setup
How to Set Up the MQTT Broker
How to Build the Express Server
How to Implement the Match Routes
How to Bridge MQTT to the Browser with Server-Sent Events
How to Build the Admin Upload Interface
- Admin HTML Structure and Styles
- Admin JavaScript Logic
How to Build the Live Viewer Interface
- Viewer JavaScript Logic
How to Build the Home Page
How to Run and Test the System
How to Extend the System for Production
API Reference
Troubleshooting
Conclusion

What You Will Learn

During this tutorial, you'll learn how to:

Connect an Express server to an MQTT broker using the MQTT.js library
Publish and subscribe to MQTT topics for real-time messaging
Use Server-Sent Events to push MQTT messages to web browsers
Build a REST application programming interface (API) for match and score management
Create a simple admin interface for uploading match data
Create a viewer interface that updates in real time without page refreshes

Prerequisites

Before you start, you should have:

Node.js version 18 or later installed on your machine
Basic familiarity with JavaScript, Express, and HTML
A terminal or command line for running commands
Docker installed (optional, for running Mosquitto in a container)

If you don't have Node.js installed, you can download it from the official Node.js website.

Understanding the Architecture

The system has three main parts:

Admin interface – A web page where you create matches, update scores, and add events such as goals and cards.
Express server – Receives HyperText Transfer Protocol (HTTP) requests from the admin, publishes data to MQTT, subscribes to MQTT topics, and streams updates to viewers via Server-Sent Events.
Viewer interface – A web page that connects to the server and displays live scores and events as they arrive.

How the flow works
When you submit a score update in the admin panel, the Express server publishes a message to the MQTT broker. The server also subscribes to those same topics. When a message arrives, the server forwards it to all connected viewers through Server-Sent Events. The viewers update their display without refreshing the page.

What is MQTT and Why Use It?

MQTT stands for Message Queuing Telemetry Transport. It's a lightweight, publish-subscribe messaging protocol designed for low bandwidth and unreliable networks. It's widely used in Internet of Things (IoT) applications, but it works well for any real-time system where you need to broadcast updates to many subscribers.

Here are some reasons to use MQTT for a sports update system:

Low overhead: Messages are small and efficient, which helps when you have many clients.
Built-in Quality of Service (QoS): You can choose how many times a message is delivered (at most once, at least once, or exactly once).
Topic-based routing: You organize messages by topic (for example, sports/football/match/123) so subscribers receive only what they need.
Broker-based: A central broker (Mosquitto) handles all message distribution, so your application logic stays simple.

Mosquitto is a popular, open-source MQTT broker that's easy to install and configure.

MQTT Topic Design

MQTT uses a hierarchical topic structure. For this project, the topics are:

sports/football/match/{id}: One topic per match. When you publish the full match object here, any subscriber receives the complete state. This makes it easy to add new match fields later without changing the topic structure.
sports/football/scores: A single topic for score-related notifications. Messages include a type field (match_created or score_update) so subscribers can handle them differently.
sports/football/events: A topic for match events such as goals and cards. Subscribers receive { type: 'match_event', matchId, event }.

The # wildcard in a subscription means "match this level and all levels below." So sports/football/# subscribes to every topic under sports/football, including sports/football/match/abc123 and sports/football/scores. The + wildcard matches exactly one level. For example, sports/+/match/# would match any sport, not just football.

Why Server-Sent Events Instead of WebSockets?

You might wonder why this tutorial uses Server-Sent Events (SSE) instead of WebSockets. Both can push data to the browser. The main difference:

Server-Sent Events: One-way (server to client). Built on HTTP. Automatic reconnection in the browser. Simpler to implement. No extra libraries.
WebSockets: Two-way. Requires a different protocol. More flexible but more complex.

For a sports score viewer, you only need server-to-client updates. The viewer never sends messages back over the same channel. Server-Sent Events is a better fit. If you later need the client to send commands (for example, to filter by league), you can add a separate HTTP API or switch to WebSockets.

Project Setup

Start by creating a new folder for your project and initialize it with npm. The mkdir command creates the directory, cd moves into it, and npm init -y creates a package.json file with default values without prompting you for input.

mkdir mqtt-football-scores
cd mqtt-football-scores
npm init -y

Install the required dependencies. Each package serves a specific role in the application. Run this command in the project root directory.

npm install express cors mqtt uuid

express: Web framework for the HTTP server and API. It provides routing, middleware, and static file serving.
cors: Enables Cross-Origin Resource Sharing so your frontend can call the API from a different origin (for example, if you serve the HTML from a different port or domain).
mqtt: MQTT client for Node.js. It handles connection, publish, subscribe, reconnection, and Quality of Service (QoS) flows.
uuid: Generates unique identifiers (Universally Unique Identifiers) for matches and events. Each ID is practically unique across all systems.

Next, create the following folder structure. The server folder holds the Node.js backend code. The public folder holds the HTML, CSS, and client-side JavaScript that the browser loads. The routes subfolder keeps the match-related route handlers separate from the main server file.

mqtt-football-scores/
├── server/
│   ├── index.js
│   ├── sse.js
│   └── routes/
│       └── matches.js
├── public/
│   ├── index.html
│   ├── admin.html
│   └── viewer.html
├── mosquitto.conf
├── docker-compose.yml
└── package.json

Add "type": "module" to your package.json so you can use JavaScript modules (import and export). The type field tells Node.js to treat .js files as ES modules, which allows you to use import and export syntax instead of CommonJS require and module.exports.

{
  "name": "mqtt-football-scores",
  "version": "1.0.0",
  "type": "module",
  "main": "server/index.js"
}

How to Set Up the MQTT Broker

You need an MQTT broker running before the server can connect. You have three options.

Option 1: Docker (Recommended)

Create a docker-compose.yml file. This file defines a single service named mosquitto that runs the Eclipse Mosquitto 2 image. The ports directive maps port 1883 on your host to port 1883 in the container so your Express server can connect. The volumes directive mounts your local mosquitto.conf into the container so the broker uses your configuration. The restart: unless-stopped option ensures the container restarts automatically if it crashes or if you reboot your machine.

version: "3.8"

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mqtt-football-mosquitto
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf
    restart: unless-stopped

Create a mosquitto.conf file. The listener 1883 directive tells Mosquitto to listen on port 1883 for MQTT connections. The protocol mqtt specifies the standard MQTT protocol (as opposed to WebSocket). The allow_anonymous true setting permits connections without a username and password, which is fine for local development but should be disabled in production. The log_dest stdout and log_type all directives send all log output to the console so you can debug connection issues.

listener 1883
protocol mqtt
allow_anonymous true
log_dest stdout
log_type all

Start the broker:

docker-compose up -d

Option 2: Local Install

On macOS with Homebrew:

brew install mosquitto
mosquitto -c mosquitto.conf

On Ubuntu or Debian:

sudo apt install mosquitto mosquitto-clients
sudo systemctl start mosquitto

Option 3: Public Test Broker

You can use the public test broker at test.mosquitto.org without installing anything. Set the environment variable when you start the server:

MQTT_BROKER=mqtt://test.mosquitto.org npm start

Note: The public broker is shared and not suitable for production. Use it only for development and testing.

How to Build the Express Server

In this step, you'll create the main server that powers the real-time application. The Express server handles HTTP requests, serves static files like HTML and JavaScript, and acts as the bridge between the browser and the MQTT broker. It also provides endpoints that allow data to be sent and received in real time. Essentially, this server is the backbone of the application, enabling communication between all components.

Begin by creating the main server file at server/index.js:

import express from 'express';
import cors from 'cors';
import mqtt from 'mqtt';
import { fileURLToPath } from 'url';
import { dirname, join } from 'path';
import { v4 as uuidv4 } from 'uuid';

import { matchRoutes } from './routes/matches.js';
import { setupSSE, addSSEClient } from './sse.js';

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const MQTT_BROKER = process.env.MQTT_BROKER || 'mqtt://localhost:1883';
const PORT = process.env.PORT || 3000;

const app = express();
app.use(cors());
app.use(express.json());
app.use(express.static(join(__dirname, '../public')));

let mqttClient = null;

function connectMQTT() {
  mqttClient = mqtt.connect(MQTT_BROKER, {
    clientId: `football-scores-${uuidv4().slice(0, 8)}`,
    reconnectPeriod: 3000,
    connectTimeout: 10000,
  });

  mqttClient.on('connect', () => {
    console.log('Connected to MQTT broker at', MQTT_BROKER);
    mqttClient.subscribe('sports/football/#', { qos: 1 }, (err) => {
      if (err) console.error('Subscribe error:', err);
    });
  });

  mqttClient.on('error', (err) => {
    console.error('MQTT error:', err.message);
  });

  mqttClient.on('close', () => {
    console.log('MQTT connection closed');
  });

  mqttClient.on('reconnect', () => {
    console.log('MQTT reconnecting...');
  });

  return mqttClient;
}

const mqttClientInstance = connectMQTT();
const { publishMatch, publishScoreUpdate, publishEvent, getMatches } = matchRoutes(mqttClientInstance);
setupSSE(mqttClientInstance);

app.get('/api/events', (req, res) => addSSEClient(res));
app.post('/api/matches', publishMatch);
app.patch('/api/matches/:id/score', publishScoreUpdate);
app.post('/api/matches/:id/events', publishEvent);
app.get('/api/matches', getMatches);

app.listen(PORT, () => {
  console.log(`Football Scores Server running at http://localhost:${PORT}`);
  console.log(`Admin (upload):  http://localhost:${PORT}/admin.html`);
  console.log(`Viewer:          http://localhost:${PORT}/viewer.html`);
});

Here is what each part does:

Imports: The fileURLToPath and dirname utilities replicate the __dirname variable that CommonJS provides, since ES modules don't have it. You need __dirname to build the path to the public folder.
Environment variables: MQTT_BROKER defaults to mqtt://localhost:1883 so the server connects to a local Mosquitto instance. You can override it for Docker or a remote broker. PORT defaults to 3000.
Middleware: cors() allows requests from any origin, which is useful during development. express.json() parses JSON request bodies. express.static() serves files from public so /admin.html and /viewer.html are available.
connectMQTT: Creates an MQTT client with a unique client ID (required by the broker), a 3-second reconnect interval, and a 10-second connection timeout. On connect, it subscribes to sports/football/# with QoS 1. The # wildcard means "all topics under sports/football."
matchRoutes: Returns the route handlers that create matches, update scores, and add events. Each handler publishes to MQTT and responds with JSON.
setupSSE: Registers a listener on the MQTT client's message event. When a message arrives, it forwards the payload to all connected Server-Sent Events clients.
addSSEClient: Called when a viewer opens /api/events. It sets the response headers for Server-Sent Events, flushes the headers so the connection stays open, and adds the response object to a set of active clients.
Routes: The GET /api/events route establishes the Server-Sent Events stream. The POST, PATCH, and GET routes for matches delegate to the handlers from matchRoutes.

The server serves static files from the public folder, so your HTML pages are available at the root.

How to Implement the Match Routes

In this step, you'll create the route handlers that manage matches, scores, and events. These routes allow the server to receive requests from the admin interface, update match data, and publish real-time updates to MQTT. They also store match information in memory so it can be retrieved and updated during the session.

Begin by creating the file at server/routes/matches.js:

import { v4 as uuidv4 } from 'uuid';

const TOPIC_MATCH = 'sports/football/match';
const TOPIC_SCORES = 'sports/football/scores';
const TOPIC_EVENTS = 'sports/football/events';

const matches = new Map();

function publish(client, topic, payload, qos = 1) {
  if (!client?.connected) {
    console.warn('MQTT not connected, message not published');
    return false;
  }
  client.publish(topic, JSON.stringify(payload), { qos, retain: false });
  return true;
}

export function matchRoutes(mqttClient) {
  return {
    publishMatch: (req, res) => {
      const { homeTeam, awayTeam, league, venue, kickoff } = req.body;
      if (!homeTeam || !awayTeam) {
        return res.status(400).json({ error: 'homeTeam and awayTeam are required' });
      }

      const match = {
        id: uuidv4(),
        homeTeam,
        awayTeam,
        homeScore: 0,
        awayScore: 0,
        league: league || 'Premier League',
        venue: venue || 'TBD',
        kickoff: kickoff || new Date().toISOString(),
        status: 'scheduled',
        minute: 0,
        events: [],
        createdAt: new Date().toISOString(),
      };

      matches.set(match.id, match);

      const topic = `\({TOPIC_MATCH}/\){match.id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_SCORES, { type: 'match_created', match });

      res.status(201).json(match);
    },

    publishScoreUpdate: (req, res) => {
      const { id } = req.params;
      const { homeScore, awayScore, minute, status } = req.body;

      const match = matches.get(id);
      if (!match) {
        return res.status(404).json({ error: 'Match not found' });
      }

      if (homeScore !== undefined) match.homeScore = homeScore;
      if (awayScore !== undefined) match.awayScore = awayScore;
      if (minute !== undefined) match.minute = minute;
      if (status !== undefined) match.status = status;

      const topic = `\({TOPIC_MATCH}/\){id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_SCORES, {
        type: 'score_update',
        matchId: id,
        homeScore: match.homeScore,
        awayScore: match.awayScore,
        minute: match.minute,
        status: match.status,
      });

      res.json(match);
    },

    publishEvent: (req, res) => {
      const { id } = req.params;
      const { type, team, player, minute, description } = req.body;

      const match = matches.get(id);
      if (!match) {
        return res.status(404).json({ error: 'Match not found' });
      }

      const event = {
        id: uuidv4().slice(0, 8),
        type: type || 'goal',
        team,
        player: player || 'Unknown',
        minute: minute ?? match.minute,
        description: description || `\({type}: \){player}`,
        timestamp: new Date().toISOString(),
      };

      match.events.push(event);
      if (type === 'goal') {
        if (team === match.homeTeam) match.homeScore++;
        else if (team === match.awayTeam) match.awayScore++;
      }

      const topic = `\({TOPIC_MATCH}/\){id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_EVENTS, { type: 'match_event', matchId: id, event });

      res.status(201).json({ match, event });
    },

    getMatches: (req, res) => {
      const list = Array.from(matches.values()).sort(
        (a, b) => new Date(b.createdAt) - new Date(a.createdAt)
      );
      res.json(list);
    },
  };
}

The routes use an in-memory Map to store matches. In production, you would replace this with a database such as PostgreSQL or MongoDB.

Explanation of the key logic:

publish: A helper that checks if the MQTT client is connected before publishing. If the broker is down, it logs a warning instead of throwing. The retain: false option means the broker doesn't store the last message for new subscribers.
publishMatch: Validates that homeTeam and awayTeam are present. Creates a match object with default values for league, venue, kickoff, status, and events. Stores it in the Map, publishes to the match-specific topic and the scores topic, and returns the match with status 201 (Created).
publishScoreUpdate: Looks up the match by ID. If not found, returns 404. Updates only the fields that are provided (using !== undefined so you can set a score to 0). Publishes the full match and a score_update notification.
publishEvent: Creates an event object with a short unique ID. Pushes it to the match's events array. If the event type is goal, increments the home or away score based on the team. Publishes the updated match and an event notification.
getMatches: Converts the Map to an array, sorts by createdAt descending (newest first), and returns the list as JSON.

MQTT topics used:

sports/football/match/{id}: Full match state. Used when a match is created or updated.
sports/football/scores: Score change notifications. Used for match creation and score updates.
sports/football/events: Match events such as goals and cards.

The publish function sends JavaScript Object Notation (JSON) payloads with QoS 1 (at least once delivery). MQTT defines three QoS levels: 0 (at most once), 1 (at least once), and 2 (exactly once). Level 1 ensures the broker will retry until the subscriber acknowledges the message, which reduces the chance of losing score updates if the connection drops briefly.

How to Bridge MQTT to the Browser with Server-Sent Events

In this step, you'll create the Server-Sent Events (SSE) module that bridges MQTT messages to the browser. MQTT works over TCP and browsers cannot connect to it directly, so we use SSE as a lightweight HTTP-based streaming channel. SSE keeps an open connection and allows the server to push updates to connected browsers in real time. This is what enables viewers to see match updates instantly without refreshing.

Now create the file at server/sse.js:

const clients = new Set();

export function setupSSE(mqttClient) {
  if (!mqttClient) return;

  mqttClient.on('message', (topic, message) => {
    try {
      const payload = JSON.parse(message.toString());
      const data = JSON.stringify({ topic, ...payload });
      clients.forEach((res) => {
        try {
          res.write(`data: ${data}\n\n`);
        } catch (e) {
          clients.delete(res);
        }
      });
    } catch (e) {
      console.error('SSE parse error:', e.message);
    }
  });
}

export function addSSEClient(res) {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.setHeader('X-Accel-Buffering', 'no');
  res.flushHeaders();

  clients.add(res);

  res.on('close', () => {
    clients.delete(res);
  });
}

Explanation of each part:

clients Set: A Set holds all active Server-Sent Events response objects. Using a Set makes it easy to add and remove clients without duplicates.
setupSSE: Attaches a message listener to the MQTT client. When any message arrives on a subscribed topic, the callback runs. It parses the message payload (which is JSON), merges the topic into the payload with { topic, ...payload }, and sends the result to every client. The Server-Sent Events format requires each message to be data: {content}\n\n (two newlines). The forEach loop catches write errors (for example, if a client disconnected) and removes the client from the set.
addSSEClient: Sets the Content-Type header to text/event-stream so the browser treats the response as an event stream. The Cache-Control: no-cache and Connection: keep-alive headers prevent the browser or proxy from caching or closing the connection. The X-Accel-Buffering: no header disables buffering in Nginx, which can delay or block Server-Sent Events. The flushHeaders call sends the headers immediately so the connection is established. The close event handler removes the client when the client disconnects (closes the tab or navigates away).

Server-Sent Events is one-way (server to client). For this use case, that is enough because viewers only need to receive updates, not send messages back over the same channel.

How to Build the Admin Upload Interface

The admin interface is a single HTML page where match creators can create new matches, update scores, and add events such as goals or cards. It uses standard HTML forms so data can be submitted to the server, and JavaScript will later handle form submissions and dynamic updates. All the markup, styles, and script live in public/admin.html, which the Express server serves as a static page.

Admin HTML Structure and Styles

The document starts with the standard HTML5 boilerplate. The charset and viewport meta tags ensure proper character encoding and responsive layout on mobile devices. The page loads the Outfit font from Google Fonts for a clean, modern look.

The Cascading Style Sheets (CSS) uses custom properties (variables) in the :root block so you can change the color scheme in one place. The --bg variable holds the dark background color, --surface for card backgrounds, --accent for the green accent color, and --text-muted for secondary text. The .grid class creates a two-column layout for form fields that collapses to one column on screens under 600 pixels wide. The .toast class positions the notification at the bottom-right and uses transform and opacity for a slide-in animation when the .show class is added.

Now create the file at public/admin.html:




  
  
  Admin - Football Scores Upload
  
  
  
  


  
    
      ⚽ Football Scores
      Admin
      → Open Viewer
    

    
      Create New Match
      
        
          
            Home Team
            
          
          
            Away Team
            
          
          
            League
            
          
          
            Venue
            
          
          
            Kickoff (ISO)
            
          
        
        
          
        
      
    

    
      Update Score
      
        
          
            Select Match
            
          
          
            Home Score
            
          
          
            Away Score
            
          
          
            Minute
            
          
          
            Status
            
          
        
        
          
        
      
    

    
      Add Match Event (Goal, Card, etc.)
      
        
          
            Select Match
            
          
          
            Event Type
            
          
          
            Team
            
          
          
            Player
            
          
          
            Minute
            
          
          
            Description
            
          
        
        
          
        
      
    

    
      Active Matches

The three forms use id attributes (createMatch, updateScore, addEvent) so the JavaScript can attach submit handlers. The match dropdowns (scoreMatchId and eventMatchId) are populated dynamically when the page loads. The matchList div is the container for the list of active matches. The toast element sits outside the main container so it can be fixed to the viewport.

Admin JavaScript Logic

The script block handles all interaction between the admin page and the server. It defines helper functions for showing notifications, fetching matches, updating the UI, and submitting data. When the page loads or after any action (create, update, or event submission), the UI refreshes so the latest match data is always visible.

Explanation of each part:

showToast: updates the toast text and adds the show class to trigger the CSS animation. The isError parameter switches the toast to a red background for error messages. The setTimeout removes the show class after 3 seconds so the toast slides back out.
fetchMatches: calls the GET /api/matches endpoint and returns the parsed JSON so the UI can display the latest data.
populateSelects: builds option elements from the matches array and injects them into both dropdowns, so the same match list appears in the Update Score and Add Event forms.
renderMatchList: either shows a placeholder when there are no matches or renders each match as a card with team names, scores, league, status, and an Update button.
quickScore: pre-fills the Update Score form when you click the Update button on a match card, so you can adjust the score without re-selecting the match.
loadMatches: fetches matches, populates the dropdowns, and renders the list. It runs on page load and after every successful create, update, or event submission.
onsubmit: calls e.preventDefault() to stop the default form submission, builds a request body from the form values, sends a fetch request to the appropriate endpoint, and on success shows a toast and calls loadMatches to refresh the UI.

How to Build the Live Viewer Interface

The viewer interface displays real-time match updates and connects to the Server-Sent Events endpoint so it can receive data the moment the server pushes it.

Unlike the admin page, the viewer is read-only: it shows live scores, match events, and status updates without requiring user input. The page uses a dark theme and a connection indicator so users can see whether the real-time stream is active.

Now create the file at public/viewer.html:




  
  
  Live Football Scores
  
  
  
  


  
    
      ⚽ Live Football Scores
      
        
        Connecting...
      
    

    

    
      Live Feed

Explanation of each part:

header: displays the page title and a connection indicator so users know whether the real-time stream is active.
status dot: a small circle that pulses while disconnected and turns green with a glow when the SSE connection is established.
matches container: the div with id="matches" is where match cards will be rendered dynamically by JavaScript as data arrives.
feed section: shows a chronological list of live updates so users can see recent events at a glance.
CSS theme: uses dark colors and custom properties so the look can be adjusted in one place. The live badge and border styles highlight matches that are in progress.
Server-Sent Events integration: JavaScript (added in the next step) will connect to /api/events and update this page whenever new data arrives.

The header shows the title and a connection status indicator. The matches div is the container for match cards, populated by JavaScript. The feed div displays the live feed of recent updates.

Viewer JavaScript Logic

The script powers the live viewer interface by maintaining an in-memory collection of matches and a feed of recent updates. It connects to the Server-Sent Events endpoint so data flows from the server to the browser in real time. When messages arrive, the page updates automatically to show the latest scores, events, and match details.

Explanation of each part:

The matches Map: stores match objects keyed by ID so updates can be applied efficiently without searching arrays.
The feed array: keeps a small history of recent events (limited to MAX_FEED) so the live feed remains lightweight.
setStatus: toggles the connected class on the status dot and updates the status text to “Live” or “Reconnecting…” so users know connection status.
renderMatches: converts the Map to a sorted array (newest first). If there are no matches, it displays an empty state. Otherwise it renders cards showing league, venue, teams, scores, status badge, minute, and events.
getEventIcon: returns an emoji for each event type so events are visually identifiable (goal, card, substitution, and so on).
renderFeed: displays the live feed items or a placeholder message when no updates exist.
addFeedItem: appends a timestamped message to the feed, keeps only the latest items, and re-renders the feed.
handleMessage: processes incoming data. It updates the matches Map for full match objects, score updates, and match events. For score updates and goals it adjusts scores and adds feed items so the viewer reflects real-time changes.
handleSSEMessage: parses the Server-Sent Events payload and forwards it to handleMessage. If the message contains a match topic and full match data, it stores it in the Map.
connectSSE: creates an EventSource connection to /api/events. On open it marks the connection as live. On error it closes and retries after three seconds so transient network issues do not break the stream.
loadInitial: fetches existing matches on page load so the viewer displays data even before real-time updates arrive.

How to Build the Home Page

The home page (public/index.html) is a simple landing page that links to the viewer and admin interfaces. It uses a centered card layout with two buttons. The primary button (green) goes to the viewer, and the secondary button (outlined) goes to the admin. The page uses the same dark theme and Outfit font for consistency. There is no JavaScript – it's purely static HTML and CSS.




  
  
  Football Scores - MQTT Real-Time
  
  
  
  


  
    ⚽ Football Scores
    Real-time updates via MQTT & Mosquitto
    
      View Live Scores
      Admin - Upload Scores

The Express server serves index.html when you visit the root URL (http://localhost:3000/) because the express.static middleware serves files from the public folder, and Express automatically serves index.html when the request path is /.

How to Run and Test the System

Start the MQTT broker (Docker or local install).

Then start the Express server:

npm start

Next, open http://localhost:3000/admin.html in the admin panel. Create a new match (for example, Manchester United vs Liverpool).

Open http://localhost:3000/viewer.html in another tab or window. Then update the score or add an event in the admin panel. The viewer should update within a second without refreshing.

How to Extend the System for Production

The current implementation uses in-memory storage. For production, you should:

Add a database: Store matches in PostgreSQL, MongoDB, or another database. Load matches on startup and persist every create, update, and event.
Add authentication: Protect the admin routes with JSON Web Tokens (JWT) or session-based auth so only authorized users can upload scores.
Add validation: Validate request bodies with a library such as Joi or Zod to prevent invalid data.
Enable TLS: Use HTTPS for the Express server and secure WebSockets or MQTTS for the broker in production.
Scale horizontally: If you run multiple server instances, each will have its own MQTT connection and SSE clients. The MQTT broker will deliver messages to all subscribers, so each instance will receive updates and forward them to its connected viewers.

API Reference

For quick reference, here are the endpoints your server exposes:

Method	Endpoint	Description
GET	`/api/matches`	Returns all matches as a JSON array
POST	`/api/matches`	Creates a new match. Body: `{ homeTeam, awayTeam, league?, venue?, kickoff? }`
PATCH	`/api/matches/:id/score`	Updates a match score. Body: `{ homeScore?, awayScore?, minute?, status? }`
POST	`/api/matches/:id/events`	Adds an event. Body: `{ type?, team, player?, minute?, description? }`
GET	`/api/events`	Server-Sent Events stream for real-time updates

The status field can be scheduled, live, halftime, or finished. The type field for events can be goal, yellow_card, red_card, substitution, or penalty.

Troubleshooting

You might come across various issues as you build this. Here are some common ones:

The server cannot connect to the MQTT broker. Check that Mosquitto is running. If you use Docker, run docker ps to verify the container is up. If you use the public broker, ensure you have internet connectivity and that your firewall allows outbound connections on port 1883.

The viewer does not update when you change scores. Open the browser developer tools and check the Network tab. The /api/events request should show a pending state (it stays open). If it fails or closes, check the server logs for errors. Ensure you are not behind a proxy that buffers or closes long-lived connections.

Matches disappear when you restart the server. The current implementation stores matches in memory. Restarting the server clears the data. Add a database as described in the production section to persist matches across restarts.

Conclusion

In this tutorial, you built a real-time football sports update system using MQTT, Mosquitto, and Express. You've learned how to:

Connect an Express server to an MQTT broker
Publish match and score updates to MQTT topics
Subscribe to topics and forward messages to browsers via Server-Sent Events
Build an admin interface for creating matches and updating scores
Build a viewer interface that displays live updates without page refreshes

The same pattern applies to other real-time systems: IoT dashboards, live notifications, collaborative editing, and more. MQTT gives you a reliable, scalable messaging layer, and Server-Sent Events gives you a simple way to push updates to web clients.

The code in this tutorial gives you a solid foundation. Try adding features such as match filtering by league, historical event logs, or push notifications to make the system your own.

How to Connect the nRF9160 Feather to a Self-Hosted Mosquitto Instance

freeCodeCamp — Wed, 05 Aug 2020 16:29:54 +0000

By Jared Wolff

One thing that’s always tripped me up as an IoT developer is figuring out the best way to transmit data. There are many different kinds of radios and mediums. On top of that, there are different protocols to boot.

As of this writing, there is one protocol that has reigned supreme in the IoT world:

MQTT.

Unlike an HTTP server, a device can connect, publish, and subscribe to topics. These topics then get sent to a broker and distributed to other subscribed devices. It also happens that MQTT on Nordic’s nRF9160 is well supported.

In this post, I’ll show you how to connect the nRF9160 Feather to a self-hosted Mosquitto instance. You’ll learn how to generate your own certificates, and get a hang of how to test your connections.

Ready to play? Let’s get to it.

Where to host?

If you want to host Mosquitto, you’ll need a server. Since Mosquitto is written in C it’s lightweight and can go almost anywhere. Plus it sips resources so you can install it on a budget VPS without much worry. That’s where a VPS provider like Digital Ocean or Vultr comes in.

To set up a new server here are some steps:

Login to Digital Ocean. If you don’t have Digital Ocean and would like to support click here to create an account.
Create a new Droplet

Choose the FreeBSD 12.1 with UFS.

Choose the $5 instance. That’s usually more than enough.

Make sure you import your public key. Otherwise, you won’t be able to immediately use password-less login.

Hit that green Create Droplet button, and let’s get this show on the road.

Important Extra step

For the certs to work with Mosquitto, you’ll have to set a domain to point to your VPS IP address. A CNAME or A record works. If you’re unsure how to do that, here’s a good guide. Note which (sub)domain you’ve used. We’ll need it in a bit…

Install Mosquitto

I run my servers inside of a FreeBSD jail using Bastille. In this tutorial, we’ll be skipping the jail part and focusing on getting the nRF9160 Feather working.

You should be set with a Digital Ocean instance (or similar) using FreeBSD. If you haven't done that yet, head back up to the Where to host? section.
Next, to install mosquitto on your droplet, run pkg install mosquitto. If you’re running something other than FreeBSD, this command may differ. apt-get install mosquitto works on Debian-based systems. If you want the most up to date repositories, make sure you run sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa beforehand. Here’s what the full output on FreeBSD looks like:

$ pkg install mosquitto
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
[mosquitto] Installing pkg-1.14.6...
[mosquitto] Extracting pkg-1.14.6: 100%
Updating FreeBSD repository catalogue...
[mosquitto] Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
[mosquitto] Fetching packagesite.txz: 100%    6 MiB   6.6MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 31943 packages processed.
All repositories are up to date.
Updating database digests format: 100%
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        c-ares: 1.16.1
        ca_root_nss: 3.55
        e2fsprogs-libuuid: 1.45.6
        mosquitto: 1.6.7

Number of packages to be installed: 4

The process will require 2 MiB more space.
682 KiB to be downloaded.

Proceed with this action? [y/N]: y
[mosquitto] [1/4] Fetching mosquitto-1.6.7.txz: 100%  226 KiB 231.1kB/s    00:01
[mosquitto] [2/4] Fetching ca_root_nss-3.55.txz: 100%  285 KiB 291.5kB/s    00:01
[mosquitto] [3/4] Fetching e2fsprogs-libuuid-1.45.6.txz: 100%   34 KiB  34.7kB/s    00:01
[mosquitto] [4/4] Fetching c-ares-1.16.1.txz: 100%  138 KiB 140.9kB/s    00:01
Checking integrity... done (0 conflicting)
[mosquitto] [1/4] Installing ca_root_nss-3.55...
[mosquitto] [1/4] Extracting ca_root_nss-3.55: 100%
[mosquitto] [2/4] Installing e2fsprogs-libuuid-1.45.6...
[mosquitto] [2/4] Extracting e2fsprogs-libuuid-1.45.6: 100%
[mosquitto] [3/4] Installing c-ares-1.16.1...
[mosquitto] [3/4] Extracting c-ares-1.16.1: 100%
[mosquitto] [4/4] Installing mosquitto-1.6.7...
===> Creating users
Using existing user 'nobody'.
[mosquitto] [4/4] Extracting mosquitto-1.6.7: 100%
=====
Message from ca_root_nss-3.55:

--
FreeBSD does not, and can not warrant that the certification authorities
whose certificates are included in this package have in any way been
audited for trustworthiness or RFC 3647 compliance.

Assessment and verification of trust is the complete responsibility of the
system administrator.

This package installs symlinks to support root certificates discovery by
default for software that uses OpenSSL.

This enables SSL Certificate Verification by client software without manual
intervention.

If you prefer to do this manually, replace the following symlinks with
either an empty file or your site-local certificate bundle.

  * /etc/ssl/cert.pem
  * /usr/local/etc/ssl/cert.pem
  * /usr/local/openssl/cert.pem
=====
Message from mosquitto-1.6.7:

--
The mosquitto MQTT Python driver is now provided by net/py-paho-mqtt

All installed package configuration lives at /usr/local/etc/mosquitto/. We’ll need to edit mosquitto.conf in that folder to use certificates. Here’s what it looks like:

# Daemon configuration
pid_file /var/run/mosquitto.pid
user nobody

# Port to use for the default listener.
port 8885

# At least one of cafile or capath must be defined.
cafile /root/pki/ca.crt

# Path to the PEM encoded server certificate.
certfile /root/pki/issued/mosquitto.crt

# Path to the PEM encoded keyfile.
keyfile /root/pki/private/mosquitto.key

# Path to CRL file
#crlfile /root/pki/crl.pem

# Each client has their own cert
require_certificate true
use_identity_as_username true

# listener port-number [ip address/host name]
listener 1883
protocol mqtt

# listener port-number [ip address/host name]
# listener 8080
# protocol websockets

# =================================================================
# Logging
# =================================================================
log_dest syslog

# Types of messages to log.
log_type all
#log_type warning
# websockets_log_level 127

# -----------------------------------------------------------------
# Default authentication and topic access control
# -----------------------------------------------------------------
# password_file /usr/local/etc/mosquitto/pwfile

Before we can start the server we’ll need to provision some RSA certificates. We’ll get to that in the next step.

Provision Certs

You can use easy-rsa to generate a CA server and client certs. (These instructions come from this guide.) For production, you should generate your keys and certs on an offline machine. That way your private keys are safe if your server becomes a target.

First, install easy-rsa:

$ pkg install easy-rsa
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        easy-rsa: 3.0.7

Number of packages to be installed: 1

44 KiB to be downloaded.

Proceed with this action? [y/N]: y
[mosquitto] [1/1] Fetching easy-rsa-3.0.7.txz: 100%   44 KiB  44.8kB/s    00:01
Checking integrity... done (0 conflicting)
[mosquitto] [1/1] Installing easy-rsa-3.0.7...
[mosquitto] [1/1] Extracting easy-rsa-3.0.7: 100%

Then let's begin the cert creation process:

$ easyrsa init-pki

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /root/pki
$
$ easyrsa build-ca

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
Generating RSA private key, 2048 bit long modulus (2 primes)
......................+++++
..................................................................................+++++
e is 65537 (0x010001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:testserver.jaredwolff.com

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/root/pki/ca.crt

Note: You will be prompted for a password at the build-ca step. Make sure you keep this password handy.

Then to generate a server cert use:

$ easyrsa gen-req mosquitto nopass

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019
Generating a RSA private key
...............+++++
........................................+++++
writing new private key to '/root/pki/easy-rsa-82720.X2NVQ0/tmp.akOxhO'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [mosquitto]:testserver.jaredwolff.com

Keypair and certificate request completed. Your files are:
req: /root/pki/reqs/mosquitto.req
key: /root/pki/private/mosquitto.key
$
$ easyrsa sign-req server mosquitto

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 825 days:

subject=
    commonName                = testserver.jaredwolff.com

Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
Using configuration from /root/pki/easy-rsa-82744.hyuGzt/tmp.lZHLEH
Enter pass phrase for /root/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'testserver.jaredwolff.com'
Certificate is to be certified until Nov  3 01:12:53 2022 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /root/pki/issued/mosquitto.crt

You’ll be prompted for both the Common Name (i.e. your server name) and the CA cert password in the above step. Important: the Common Name needs to match the domain name of your server! (Remember, we wrote that down earlier?)

To generate the nRF9160 cert, use:

$ easyrsa gen-req nrf9160 nopass batch
$ easyrsa sign-req client nrf9160 batch

Follow the same procedure as earlier. The only difference is that we’re generating a client cert instead of a server cert.

Once complete, we’ll need some files. Here’s a full list:

For your Mosquitto Server

/root/pki/ca.crt
/root/pki/private/mosquitto.key
/root/pki/issued/mosquitto.crt

For your nRF9160 Feather

/root/pki/ca.crt
/root/pki/private/nrf9160.key
/root/pki/issued/nrf9160.crt

If you’re using the configuration from above, it’s already pointing to your server certificates. All we have to do now is start mosquitto!

$ service mosquitto start
Cannot 'start' mosquitto. Set mosquitto_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.

If you get an error about mosquitto_enable simply run:

$ sysrc mosquitto_enable=YES
$ service mosquitto start
Starting mosquitto.

This enables mosquitto to start when your system starts.

Now, check if mosquitto is running by using ps aux:


$ ps aux
USER     PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
root   82401  0.0  0.2 11472 2424  -  SsJ  01:02   0:00.00 /usr/sbin/syslogd -ss
root   82457  0.0  0.2 11408 2284  -  IsJ  01:02   0:00.00 /usr/sbin/cron -J 60 -s
nobody 82900  0.0  0.6 16352 6212  -  SsJ  01:17   0:00.02 /usr/local/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d
root   82488  0.0  0.3 12096 2848  0  IJ   01:02   0:00.01 login [pam] (login)
root   82489  0.0  0.3 13092 3504  0  SJ   01:02   0:00.03 -csh (csh)
root   82902  0.0  0.3 11704 2540  0  R+J  01:17   0:00.00 ps aux

Now that we have a server loaded and running, let’s get the firmware working.

Firmware bits

Dealing with certificates on the nRF9160 Feather is a two-step process. The first step is to load the certificates using the at_client firmware. The second is to load the mqtt_simple library with added TLS support. Let’s tackle the certs first.

Program `at_client` first

Change directories to ncs/nrf/samples/nrf9160/at_client/ and start a fresh build:

$ west build -b circuitdojo_feather_nrf9160ns -p

Then flash to your board using:

$ west flash --erase
$ nrfjprog -r

We’ll need this sample on your board for the next step.

Add certs to device

To install our new certs, we’ll need nRF Connect Desktop installed. You can download it by going here.

You’ll also need a custom version of LTE Link Monitor. You can get the modified version on docs.jaredwolff.com.

First, Install nRF Connect Desktop app. Then, copy the LTE Link Monitor .tgz file to %USERPROFILE%\.nrfconnect-apps\local (on Windows) or $HOME/.nrfconnect-apps/local (on Linux/macOS). Here’s an example of where it is on Windows:

Close and re-open nRF Connect Desktop (if it’s open).

Then, click Open next to the v1.1.1 version of LTE Link Monitor. It will also have local written underneath it.

Next, let’s launch it!

Once you’ve opened the port, hit the reset button. Make sure you turn off Automatic requests.

Then in the command box send AT+CFUN=4. This will shut down your modem so it’s ready to upload certs. You can run AT+CFUN? to confirm your modem in that mode.

Open up the Certificate manager.

Make sure you set the security tag. In this case, I’m using 1234. This is an important identifier that you’ll need later. Make it whatever you want but I would avoid using 16842753. This is the default tag for NRF Cloud. You don’t want to blast away your nRF Cloud certs!

Copy and paste the contents of your ca.crt, nrf9160.crt and nrf9160.key into the boxes (in that order). You can easily get the certs by using cat on Unix/Linux:

$ cat cat.crt
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgIUDLkBxLLQO9wosNDtA7E9qvqHOxMwDQYJKoZIhvcNAQEL
BQAwJDEiMCAGA1UEAwwZdGVzdHNlcnZlci5qYXJlZHdvbGZmLmNvbTAeFw0yMDA3
MzEwMTExNDJaFw0zMDA3MjkwMTExNDJaMCQxIjAgBgNVBAMMGXRlc3RzZXJ2ZXIu
amFyZWR3b2xmZi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3
de1v8k+FXzY/Im7Z2YKS7wwbBRft5CUxqP1sdYJgMvheS9LhFufk81URZ0lHD9pK
aNPxU1UEmnLvVDTGLJ+YAmMH08xn17FS1R1UVPYzi2ouwqRM2pR9EStsSlP9Zj44
1MsdizABnnlkZndUVLL/gjc4cNsNncMLBSEbsz6b5WzhtAGg3rOpdAxSSblZVSFw
bquCgg5hb2NUzy+JxGtUIsE5d6CxTDdSs4Z3FK/RRYjmCG6qsaya4N5W35yf8h5O
StfKRecl3kq2kCnWa6P+lErG4wuxIBtMkgz2zV+zd1tz4aHXxSdoZTqLz7dTVbFA
zEVnKD+ZReBG+4fwUL6rAgMBAAGjgZ4wgZswHQYDVR0OBBYEFIvdGnjrxRPzvXQi
7XJ70LzpZSOjMF8GA1UdIwRYMFaAFIvdGnjrxRPzvXQi7XJ70LzpZSOjoSikJjAk
MSIwIAYDVQQDDBl0ZXN0c2VydmVyLmphcmVkd29sZmYuY29tghQMuQHEstA73Ciw
0O0DsT2q+oc7EzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBBjANBgkqhkiG9w0B
AQsFAAOCAQEAIzz1nSSDkPueNPlADRYMDOMFNkxoKA+gRXwDVa7y39As7IZp7Fqr
KAH79U1XtGyDlt6FPKTvDJ7jtd4y8auIGVQO7z3AG9pVU1imIWZHoIqgBUCEhsjp
uMxD23kRCX5kd9dsmF9WOGGxb4kkMv83Rh2rCONQmvnozuI3fJv2ZFX/ORoADGLP
OPSJPl11x+2rxPxiLi+T8RyzDh3DwqnPVsSnbRWV7hosaN0ip/cbnSTaIul9mbCY
ID6qm9leqlY/gha9aZfg+tv1Lm6PT6o8Pzek2VeDoIS5YERBMOwV84hQrZjV3vIE
jT6y663HGsl7KvqVaWdV3fM6Cr7f0QdR5A==
-----END CERTIFICATE-----

You’ll need everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----

Check the Log area for more details. If all went well, it should say that your certificates updated.

Using the mqtt_simple example

We’ll be using the mqtt_simple sample within the nRF Connect SDK repository. The full path is: ncs/nrf/samples/nrf9160/mqtt_simple. We’ll need to make a few edits to add full TLS compatibility. All the files are within the mqtt_simple directory.

First, we’ll have to update the proj.conf file. See the highlighted differences:

The # Set the PDP Context section is especially important if you’re using a Hologram SIM card (included with the nRF9160 Feather). If you are using a SIM that doesn’t need it, you do not need this section.

Adopt your CONFIG_MQTT_BROKER_HOSTNAME to your hostname (configured at the beginning of this guide).

You’ll also have to add these lines in KConfig:

config SEC_TAG
    int "Security tag to use for the connection"
    default 1234

config PEER_VERIFY
    int "Peer verify parameter for mqtt_client"
    default 1
    help
            Set to 0 for VERIFY_NONE, 1 for VERIFY_OPTIONAL, and 2 for VERIFY_REQUIRED.

Finally in main add this block to the top of your file:

#if defined(CONFIG_MQTT_LIB_TLS)
static sec_tag_t sec_tag_list[] = { CONFIG_SEC_TAG };
#endif /* defined(CONFIG_MQTT_LIB_TLS) */

Then add this block to client_init under #if defined(CONFIG_MQTT_LIB_TLS)

  struct mqtt_sec_config *tls_config = &client->transport.tls.config;

    client->transport.type = MQTT_TRANSPORT_SECURE;

    tls_config->peer_verify = CONFIG_PEER_VERIFY;
    tls_config->cipher_count = 0;
    tls_config->cipher_list = NULL;
    tls_config->sec_tag_count = ARRAY_SIZE(sec_tag_list);
    tls_config->sec_tag_list = sec_tag_list;
    tls_config->hostname = CONFIG_MQTT_BROKER_HOSTNAME;

The changes should look like this:

Then build with:

$ west build -b circuitdojo_feather_nrf9160ns -p

Finally, flash it using west flash:

$ west flash --erase
$ nrfjprog -r

Open your serial terminal and double check that your nRF9160 Feather is connecting. You can also use LTE Link Monitor to view your progress as well (Example below).

Lots of the information above came from Nordic's post on the subject.

Sending a message

We’re almost there! You’ve configured your nRF9160 Feather to connect to Mosquitto using self-generated certificates. The last part is connecting another device to see if the nRF9160 Feather replies to a message.

I’ve created a new set of certs for this purpose. I called them test.

$ easyrsa gen-req test nopass batch
$ easyrsa sign-req client test batch

I copied them to my desktop using CyberDuck (a great little visual SFTP client):

You can also use something like scp if you're confident in your command line file transfer abilities. Then, open a terminal and run:

mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/publish/topic" &
mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/subscribe/topic" -m "hello there"

You should see an output like this:

$ mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/publish/topic" &
$ mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/subscribe/topic" -m "hello there"
Client mosq-CczskQKzMKdtTo4O4s sending CONNECT
Client mosq-CczskQKzMKdtTo4O4s received CONNACK (0)
Client mosq-CczskQKzMKdtTo4O4s sending PUBLISH (d0, q1, r0, m1, '/my/subscribe/topic', ... (11 bytes))
Client mosq-CczskQKzMKdtTo4O4s received PUBACK (Mid: 1, RC:0)
Client mosq-CczskQKzMKdtTo4O4s sending DISCONNECT
MacBook-Pro:Downloads jaredwolff$ Client mosq-qK8tMlJk0Qri4Z7jUo sending PINGREQ
Client mosq-qK8tMlJk0Qri4Z7jUo received PINGRESP
MacBook-Pro:Downloads jaredwolff$ Client mosq-qK8tMlJk0Qri4Z7jUo received PUBLISH (d0, q0, r0, m0, '/my/publish/topic', ... (11 bytes))
hello there

Booyah! You have an active working connection to your very own Mosquitto server.

Conclusion

We’ve made it to the end! By this point in the post, you should have a Mosquitto server running and an nRF9160 connected. Now you can use your new-found skills to add more devices to your deployments and more.

If you haven’t had a chance to play with the nRF9160 you should check out the nRF9160 Feather. It has Nordic Semiconductor’s nRF9160 LTE-M, NB IoT + GPS Combo, plus flexible power supply, external flash, and low power shutdown.

Oh, and did I mention it’s 100% open source? Learn more by checking out the campaign on GroupGets and Hackster Launch. ?

Photo credit to the awesome folks at GroupGets!

You can read this article and lots of other good stuff at jaredwolff.com.

mqtt - freeCodeCamp.org

How to Build Real-Time Update Systems with MQTT and Express.js

Table of Contents

What You Will Learn

Prerequisites

Understanding the Architecture

What is MQTT and Why Use It?

MQTT Topic Design

Why Server-Sent Events Instead of WebSockets?

Project Setup

How to Set Up the MQTT Broker

Option 1: Docker (Recommended)

Option 2: Local Install

Option 3: Public Test Broker

How to Build the Express Server

How to Implement the Match Routes

How to Bridge MQTT to the Browser with Server-Sent Events

How to Build the Admin Upload Interface

Admin HTML Structure and Styles

Create New Match

Update Score

Add Match Event (Goal, Card, etc.)

Active Matches

Admin JavaScript Logic

How to Build the Live Viewer Interface

Live Feed

Viewer JavaScript Logic

How to Build the Home Page

⚽ Football Scores

How to Run and Test the System

How to Extend the System for Production

API Reference

Troubleshooting

Conclusion

How to Connect the nRF9160 Feather to a Self-Hosted Mosquitto Instance

Where to host?

Important Extra step

Install Mosquitto

Provision Certs

Firmware bits

Program at_client first

Add certs to device

Using the mqtt_simple example

Sending a message

Conclusion

Program `at_client` first