Differences

This shows you the differences between two versions of the page.

--- en_alt:reporting [2026/08/10 14:23] – Image heights, wording and section cleanup (review feedback) hajo
+++ en_alt:reporting [2026/08/15 00:05] (current) – removed hajo
@@ Line 1: / Line 1: @@
-====== Reporting to OTM ======
-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 [[https://opentrafficmap.org|live map]]. This page describes that path — the broker, the topics and the format.
-This is the machine side. The things you click are on [[en_alt:your_node|Your Node]].
-===== The central broker =====
-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 [[en_alt:receivers#other_receiver_projects|Other receiver projects]] can all feed the same map without any coordination beyond agreeing on the format.
-===== Wire 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.
-===== Connecting =====
-  * The **connection string** — host and port — is defined in the firmware: [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/src/branch/main/main/config.c|its-g5-receiver-firmware/main/config.c]]. Taking it from there rather than from this page means you always have the current value.
-  * The broker is ''cits1.opentrafficmap.org'', reached over MQTT with TLS. The other receiver projects connect to it on the standard MQTT-over-TLS port 8883.
-  * **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 [[en_alt:your_node#friendly_name|Friendly name]].
-===== Topics =====
-Everything a node publishes lives under ''its/<node>/'', where ''<node>'' is the node name described above.
-^ Topic ^ Direction ^ Content ^
-| ''its/<node>/packet'' | published | One message per received frame: the raw 802.11p frame. QoS 0, not retained. |
-| ''its/<node>/status'' | published | ''online'' on connect, ''offline'' as the last will. Retained, so it always reflects the current state. |
-| ''its/<node>/info'' | published | Sent once on connect: the MAC address, the firmware version and the hardware variant. |
-| ''its/<node>/stats'' | published | Telemetry, published periodically: temperature and seconds since boot. |
-| ''its/<node>/command'' | subscribed | The node listens here. This is how the [[en_alt:your_node|self-service portal]] configures a node remotely — the payload is run on the node's console. |
-| ''its/<node>/command_result'' | published | The result or error message of a command. |
-To follow everything a node does, subscribe to the wildcard ''its/<node>/#''.
-**TODO:** This wiki previously documented a topic ''its/nodeXXX/packet/json'' carrying decoded packets as JSON. The node firmware itself publishes only the raw frame to ''its/<node>/packet'', so a JSON topic would have to be produced by the backend rather than by the node. Please confirm whether ''packet/json'' exists, and if so, add it to the table above with a note that it is generated server-side.
-===== Subscribe to your node =====
-While publishing is open, **reading** is not: you need credentials, and the [[en_alt:your_node|self-service portal]] shows you the ones for your own node.
-Any MQTT client will do:
-^ Client ^ Platforms ^ Homepage ^
-| MQTTX | Linux, Windows, macOS | https://mqttx.app |
-| MQTT Explorer | Linux, Windows, macOS | https://mqtt-explorer.com |
-| MQTT Viewer | Linux, macOS | https://mqttviewer.app |
-| MQTT.fx | Windows | https://mqttfx.jensd.de |
-Subscribe to ''its/<node>/#'' and you will see your node's frames and telemetry as they happen. Note that a raw frame is binary — most clients will show it as hex rather than as text.
-===== What is published =====
-  * The received **raw C-ITS frames** — CAM, DENM, MAPEM, SPATEM and IVIM. See [[en_alt:c-its#message_types|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.
-===== Monitoring in Home Assistant =====
-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 [[en_alt:receivers#esphome_firmware|ESPHome firmware]].