The OpenTrafficMap server

Every receiver, whatever it is built from, ends up doing the same thing: publishing raw 802.11p frames to one central MQTT broker, which feeds the live map. That broker is the OpenTrafficMap server, and this page covers both directions — how data gets there, and how to read it back.

This is the machine side. The things you click are on Your Node.

All nodes publish to a single broker. It runs MQTT over TLS, and the connection is verified against the server certificate.

Publishing requires no username and no password, and no registration. If you build a receiver and point it at the broker, its data arrives. Registration exists only so that you can be given a friendly name, a place on the map and read access to your own node — none of which is required for contributing data.

This deliberate lack of a barrier is why the various independent projects on Other receiver projects can all feed the same map without any coordination beyond agreeing on the format.

Nodes publish the raw 802.11p frame, unmodified. No decoding, no JSON, no re-packing happens on the node.

That has two consequences worth knowing:

• All the ASN.1 UPER decoding happens in the backend, so a node stays simple and does not need updating when a message type changes.
• Every project produces byte-identical output. The OpenWrt bridge running on a FRITZ!Box and the ESP32 firmware are indistinguishable on the broker, which is what makes the catalogue of alternative receivers viable in the first place.

There is no offline buffer. C-ITS is a live data stream by design, and a frame that arrives late is of no use to a live map. If the node loses its network connection, the frames received during the outage are gone. As of firmware 0.5.1 there is no local logging to the SD card either.

• The broker is cits1.opentrafficmap.org, reached over MQTT with TLS on port 8883. The host is compiled into the firmware — main/config.c always has the current value.
• No credentials are needed to publish.
• Each node identifies itself with its node name. By default this is the Ethernet MAC address of the ESP32, written as twelve lowercase hexadecimal characters with no separators, for example aabbccddeeff. If we have given you a friendly name, that is used instead — see Friendly name.

Everything belonging to a node lives under its/<node>/, where <node> is the node name described above. Most of it comes from the node itself; the decoded JSON is added by the server.

To follow everything belonging to a node, subscribe to the wildcard its/<node>/#.

While publishing is open, reading is not: you need credentials, and the self-service portal shows you the ones for your own node.

Any MQTT client will do:

Subscribe to its/<node>/# and you will see your node's frames and telemetry as they happen. Note that packet carries the raw frame and is binary — most clients will show it as hex. If you want something readable, subscribe to packet/json instead, where the server has already decoded it.

• The received raw C-ITS frames — CAM, DENM, MAPEM, SPATEM and IVIM. See Message types for what each of them means.
• Node telemetry and status: temperature, uptime, online state, firmware version and hardware variant.

Nothing else. The node has no microphone, no GPS and no knowledge of your network beyond what it needs to reach the broker.

If you already run Home Assistant, you can watch your node from there. The node keeps doing its own job and publishes its telemetry to the broker; Home Assistant simply reads along through the MQTT integration, using the credentials from the self-service portal. From there you can build sensors, automations and dashboards — an alert when the node has been offline for an hour, for example, or a graph of its temperature over the summer.

This is monitoring only. It does not change what the node does.

Not to be confused with running the receiver on ESPHome, where Home Assistant becomes the receiver itself and the node is an ESPHome device. That is a different setup, described under ESPHome firmware.