Integrating a BLE TPMS App Into Your Own Product A practical guide for OEMs and integrators: what can be customised in the BLE service and data format, what the app status really is today, and what to agree early.

You are not buying a sensor, you are buying a data path

When an OEM evaluates a BLE TPMS sensor, the conversation starts with pressure accuracy and ends with the radio specification. What actually goes wrong is the interface between the sensor and whatever the end user looks at.

With a display-based system, that interface is a cable and a screen the supplier sells you. With BLE, it is a radio protocol and an application. Both are negotiable, and both should be settled before tooling rather than after.

The three integration routes

There are three ways to put a BLE TPMS sensor in front of a customer, and they differ mainly in who owns the software.

Route one: use the supplier's app. The sensor ships with an app that already works. You put your brand on the packaging and the customer downloads a general-purpose app. Fastest to market, weakest in brand ownership, because the customer's relationship with the software belongs to somebody else.

Route two: a branded build of the supplier's app. The app is functionally the supplier's, but it carries your name, your colours and your thresholds. This is the usual compromise for a distributor with a range of products and no software team.

Route three: your own app, using the sensor as a component. The sensor becomes a peripheral in your product. Your app talks to it over the BLE service and everything the user sees is yours. This is the correct route for an OEM with an existing app, or for anyone whose product is the app rather than the hardware.

Which route you take determines what has to be agreed. Route three is the one that needs protocol documentation, sample code and a firmware change policy.

What can be customised

For OEM programmes we can adapt the BLE service and the data format. In practice that covers:

Layer	What can change	Typical driver
BLE service and characteristics	Service and characteristic definitions, which values are read, which are notified	Your existing app architecture
Data format	Byte layout, scaling, units, flags, timestamps	Your parser and cloud schema
Advertising and identity	What the sensor advertises, how devices are named and filtered	Multi-sensor and fleet handling
Alarm behaviour	Thresholds, hysteresis, which conditions raise an alarm	Your market and vehicle class
App branding	Name, icon, colours, layout, language set	Route two above
Sensor marking	Laser marking, including your part numbers and wheel position	Dealer networks

What is not negotiable is the physical measurement: the sensing element, the measurement chain and the pressure calibration are the product. Customisation happens above that line.

The app status, stated plainly

This is where a supplier being straight with you gives an answer that is less tidy than a marketing page.

• Android is available now. The APK can be downloaded today, so an Android integration can be evaluated immediately on real hardware.
• iOS is not released yet. There is no iOS build to hand over at the time of writing. If your product plan assumes an iPhone app in the near term, that assumption needs testing with us rather than taking from a brochure.

We would rather write that down than let a programme discover it three months in. If iOS is on your critical path, raise it in the first conversation — including the route three option, where your own team builds the iOS client against the sensor protocol instead of waiting for ours. That is the general argument for route three: if the protocol is documented and stable, the app on top of it is your schedule, not somebody else's.

What integration actually involves

A BLE TPMS integration is not only reading a pressure value. The parts that consume engineering time are these.

Discovery and identification. A vehicle may have two, three or four sensors in range. Your app has to find the right ones, distinguish them from a neighbouring vehicle's, and map them to wheel positions.

Connection management. BLE connections are not free. Holding an open connection to four sensors continuously drains the phone; polling too slowly misses a fast leak. The right pattern depends on whether the product is a live dashboard or a background monitor.

Missing data. Radios lose packets. Your app needs a defined behaviour for a missed notification: show the last known value with an age, or show nothing. Both are defensible; silently presenting a stale value as live is not.

Alarm logic. Thresholds, temperature compensation, the difference between a slow leak and a cold morning, and what the alarm does when the phone is asleep. Where this logic lives — sensor or app — has to be decided once and written down.

What to agree before you start

Ask these in the first technical meeting. The answers determine whether the project is a configuration exercise or a development programme.

1. Will we receive the BLE service and data format documentation? Without it, route three is impossible and route two depends on somebody else's release schedule.
2. Can the data format be changed for us, or must we accept the default? Byte layout changes sound small and are not, because they affect every consumer of the data.
3. What is the firmware release and versioning policy? Ask what happens when the sensor firmware changes and whether it stays backward-compatible with your app.
4. What is the iOS situation, in writing? Get a date, or get a clear statement that there is no date. Both are usable; a vague answer is not.
5. Do we get evaluation units before committing? Integration problems are found on hardware, not in documents.
6. Who owns the app and the customer data? If the customer relationship is the asset you are protecting, this is the question that matters most.

Where we stand

We make the sensor ourselves. The sensing element is Infineon; the measurement, alarm logic, BLE service and data format are ours. That is what makes adaptation possible instead of asking a customer to work around a fixed catalogue part. Volume today is more than 10,000 sets a month into the Chinese two-wheeler aftermarket, with capacity of 30,000 sensor units a month. Every sensor is pressure-calibrated on our own test software before it ships, and we run water-immersion, RF-range and protocol verification in house. Certification is handled per market and per project.

If you are integrating a BLE TPMS sensor into an existing product and want to know what would have to change on both sides, send us the shape of the project — vehicle, wheel count, app platform and market. The sensor specification is on the BPU100 product page, documentation is on the downloads page, and the rest of this series is on the blog index.

FAQ

Can we use our own app instead of yours? Yes. The BLE service and the data format can be adapted for OEM programmes, so the sensor can feed your app rather than ours. That is a project conversation rather than a catalogue option, so raise it early.

Is there an iOS app? Not yet. The iOS app is not released at the time of writing. The Android APK can be downloaded now. If iOS is on your critical path, tell us and we will set out the options honestly, including building your own client against the sensor protocol.

Do you provide protocol documentation and sample code? Protocol documentation is part of an OEM engagement, since the service and data format are adapted per programme. Ask for it in the first technical discussion.

Can the app carry our brand? Yes. App branding — name, icon, colours, layout and language set — is one of the customisable layers. Whether that is a branded build of our app or your own app on top of our protocol depends on which route you choose.