The decision this page is about
If the tyre data has to live on your platform, there are two ways to get it there:
1. Your controller reads the CAN data and publishes it yourself. Most control, most work — you
need the frame layout and you build the whole uplink.
2. A gateway publishes it for you over MQTT to a broker you already run. Least work — you need to
agree a payload and a topic, and nothing else on your side changes.
This page is about option 2, because it is the one that gets a pilot running in days rather than a
project cycle.
The chain, in one line
`sensors → receiver → CAN → 4G gateway → MQTT broker → your platform`
The receiver's side is covered on the CAN integration page. What matters here is that
the gateway is a separate unit, not a feature of the receiver. That is a good thing: it means the
vehicle side can be a normal receiver + CAN node, and the connectivity can be swapped or added without
touching the tyre hardware.
What the gateway actually does
| Property | What it means for you |
|---|---|
| MQTT over TLS, mutual authentication | You issue credentials, the device presents a certificate. No shared password in a config file. |
| Change-triggered uplink | A value that has not changed is not sent. In a fleet, this is the difference between a few kilobytes a day and a constant stream you pay for. |
| Local buffering | When coverage drops, data is stored and forwarded. A tunnel or a yard with no signal is not a data hole. |
| A/B partition FOTA with rollback | Firmware can be updated in the field without a truck coming back, and a failed update reverts itself. |
| 4G Cat.1, with 2G/3G fallback | Cat.1 is cheap and sufficient for this data volume; fallback keeps old networks working. |
| Optional GNSS | Position tags each reading, which matters as soon as you have more than one vehicle. |
Topic design: agree it before anything else
Most painful MQTT integrations fail on topic structure, not on connectivity. Three patterns work:
Pattern A — per vehicle, one topic. `fleet/{vehicle_id}/tpms` — simple, everything arrives together.
Pattern B — per vehicle, per position. `fleet/{vehicle_id}/tpms/{axle}/{side}` — fine-grained
subscription, more topics to manage.
Pattern C — one topic, vehicle inside the payload. `fleet/tpms` + a `vehicle_id` field. Cheapest to
manage, but you cannot subscribe per vehicle without filtering in your own code.
For a pilot, A is almost always right. Go to B only if your platform genuinely needs per-position
subscriptions; go to C only when the fleet is large and the platform already de-multiplexes.
Two more things to fix in writing: the retained flag (do you want the last value served on
subscribe — usually yes for pressure) and the QoS level (QoS 1 for pressure, QoS 0 for anything
you can afford to lose).
Publishing the values themselves
The payload we hand over is plain and documented — a JSON object per reading with the fields you
asked for, plus a timestamp and the wheel position. We are not sending our internal frame and asking
you to decode it; that is the whole point of the gateway path.
What we need from you is the contract, not the protocol:
- field names you want (or a schema you already use),
- units (kPa or bar; gauge — we do not send absolute),
- how you want a missing position represented (absent, null, or a quality flag),
- whether a reading should carry the position label or be nested under it.
If you already publish other sensors to your platform, give us one example message of your own
format and we will match it. That is faster than any specification document.
What this is not
- Not an OBD replacement. It does not read the engine, and it does not decode the vehicle's own
J1939 parameters beyond the tyre data we produce.
- Not a reason to hand over your CAN protocol. We publish values to your broker; your definitions
stay yours.
- Not a dashboard. We do not ship a platform. If you want one, our own is available, but the point
of this path is to keep the data in yours.
The four decisions that close it
1. Broker and topics — host, port, TLS mode, topic pattern, retained flag, QoS.
2. Credentials — how the device authenticates, and how you rotate it.
3. Payload — field names, units, gauge/absolute, missing-value convention.
4. Volume — how many vehicles, readings per day expected, and whether you need position at all.
With those four, a trial unit can be publishing into your broker without anyone writing a decoder.
That is the practical difference between this path and a raw CAN integration: **the work moves from
your firmware team to a table you fill in once.**
See the DTU / gateway options or the wider view on
CAN bus TPMS integration. If you already have a broker, send us a sample message and
we will match it.