Mqttv5 Server-Side Session Expiry For Deterministic Iot Telemetry

If you publish device telemetry to MQTT, one of the most painful debugging problems is “stale state”: messages or subscriptions that hang around longer than you expect. MQTT v5 gives you fine-grained control over when the broker should expire a client session, which is especially useful for IoT fleets that intermittently connect (battery devices, mobile gateways, intermittent networks).

This post is about a random-but-practical topic: using MQTT v5 Server-Side Session Expiry to make telemetry behavior more deterministic.

---

Why Session Expiry Matters in IoT

In MQTT v3.1.1, session persistence can be confusing because “clean session” behavior doesn’t express time-based expiry. MQTT v5 adds:

• Session Expiry Interval (server-side): how long the broker keeps the session after the client disconnects.
• This affects whether subscriptions and queued QoS messages remain available when the device reconnects.

For intermittent IoT devices, picking a short session expiry interval can prevent:

• Out-of-date subscription state
• Old queued messages being delivered long after they’re relevant

---

A Practical Configuration Strategy

A common strategy for telemetry sensors:

• QoS 1 for at-least-once delivery
• Clean start = false (so you want sessions when appropriate)
• Session Expiry Interval set based on your acceptable “offline window”
  • Example: if you can tolerate at most 60 seconds offline, set expiry to 60 seconds

---

Working Example: Connect with Session Expiry (Node.js)

Below is a complete, working script using the popular mqtt package. It connects to an MQTT broker with MQTT v5, requests a session expiry interval, publishes a message, then disconnects.

Prerequisites:

• Node.js installed
• An MQTT broker running at mqtt://localhost:1883 with MQTT v5 enabled (many brokers do)

Install:

npm install mqtt

// File: mqtt-session-expiry.js
// Run: node mqtt-session-expiry.js
const mqtt = require("mqtt");

const brokerUrl = "mqtt://localhost:1883";
const topic = "iot/demo/telemetry";

const client = mqtt.connect(brokerUrl, {
  protocolVersion: 5,
  clientId: "sensor-001",
  clean: false, // MQTT v5 Clean Start (mapped by the library)
  properties: {
    sessionExpiryInterval: 60 // seconds
  }
});

client.on("connect", () => {
  const payload = JSON.stringify({
    ts: new Date().toISOString(),
    value: Math.random()
  });

  client.publish(topic, payload, { qos: 1 }, (err) => {
    if (err) {
      console.error("Publish failed:", err);
      client.end(true);
      return;
    }
    console.log("Published:", payload);

    // Disconnect after publish. Session may persist up to sessionExpiryInterval.
    client.end(false);
  });
});

client.on("error", (err) => {
  console.error("Client error:", err);
});

---

Verifying Behavior (Conceptually)

To confirm this works as intended, you can:

1. Run the script.
2. Disconnect the device (it does this automatically).
3. Reconnect within 60 seconds and check whether prior session data (like subscriptions) remains.
4. Reconnect after 60 seconds and observe that the broker may treat it as an expired session (subscriptions/queued messages can differ based on broker behavior and what was stored).

Different brokers may store different session elements, but session expiry is standardized: the broker removes state after the interval elapses.

---

Key Gotchas

1) Session expiry isn’t “message retention”

Queued QoS messages and subscriptions may depend on:

• Whether the broker actually queues them
• Whether you previously established subscriptions
• How the broker implements storage

2) Use retained messages for durable latest-state (separately)

If you want devices to always obtain the latest known value immediately, you may also use MQTT retained messages—that’s different from session expiry.

3) Choose expiry based on real network patterns

Battery IoT devices might reconnect quickly sometimes, but occasionally take hours. Setting expiry too low can force re-subscription each time; too high can deliver outdated queued messages.

---

Conclusion

MQTT v5 Server-Side Session Expiry Interval is a powerful lever for IoT telemetry systems that experience intermittent connectivity. By setting an appropriate expiry value (like 60 seconds in the example), you can reduce stale state and make reconnection behavior more predictable.