MQTT on Nalar

ESP32 MQTT over TLS: Transport Encryption and Broker Authentication Are Separate

Sat, 19 Sep 2026 00:00:00 +0000

An ESP32 that moves an MQTT connection from port 1883 to 8883 crosses more than a port boundary. The TCP stream is now expected to carry MQTT inside TLS. Data in transit is protected only when the TLS client also validates the broker certificate. MQTT username/password authentication is separate: credentials identify the client to the broker, while certificate validation identifies the broker to the ESP32.

Calling this “MQTT with HTTPS” mixes two application protocols. MQTT does not become HTTP when TLS is added. MQTT can run over plain TCP or over a TLS-protected TCP connection.

ESP32 MQTT Sensor State: Publishing DHT22 Temperature and Humidity as One JSON Message

Sat, 19 Sep 2026 00:00:00 +0000

A DHT22 read produces temperature and relative humidity from the same sampling event. Publishing them on separate MQTT topics works, but it also creates two independent message boundaries. A subscriber can receive the new temperature before the matching humidity value arrives.

Putting both measurements in one payload preserves the relationship explicitly:

copied = false, 1600)" class="absolute right-3 top-3 z-10 rounded-lg border border-line-strong bg-surface px-2 py-1 font-mono text-[0.8rem] text-muted opacity-0 transition group-hover:opacity-100 hover:bg-ink hover:text-white dark:border-night-line dark:bg-night dark:text-night-muted dark:hover:bg-white dark:hover:text-ink">

{"temperature":25.34,"humidity":60.21}

MQTT does not require JSON. The useful property here is that both measurements travel in one publication and can be treated as one sensor-state snapshot.

FCM Is a Wake-Up Path, Not a Real-Time Transport

Sat, 19 Sep 2026 00:00:00 +0000

FCM Is a Wake-Up Path, Not a Real-Time Transport

A mobile application can maintain a WebSocket while it is active and still need Firebase Cloud Messaging when the operating system suspends it. Those mechanisms solve different failure conditions.

WebSocket, MQTT, and SignalR assume that a client can participate in a live communication session. FCM is useful precisely when that assumption no longer holds: the application may be backgrounded, its process may not be running, or its persistent connection may have disappeared.

MQTT and QUIC Solve Different Parts of a Chat Transport

Sat, 19 Sep 2026 00:00:00 +0000

MQTT and QUIC Solve Different Parts of a Chat Transport

MQTT and QUIC are often placed in the same comparison table when discussing real-time chat. That comparison is convenient, but it collapses two different protocol layers into one choice.

MQTT is an application-layer messaging protocol. It defines concepts such as clients, brokers, topics, subscriptions, retained messages, session state, and delivery quality of service. QUIC is a secure transport protocol over UDP. It provides connections, streams, flow control, loss recovery, encryption, and connection migration mechanisms.