Updated Torque OBD-II Integration (Send your car's data to Home Assistant)

Updated Torque OBD-II Integration: Send Torque Telemetry to Home Assistant

HACS Custom
Requires Home Assistant
GitHub Release
GitHub Repo stars

Open your Home Assistant instance and open this repository in HACS.

A Home Assistant custom integration that receives vehicle telemetry uploaded by the Torque Android application and exposes it as Home Assistant sensors.

Modern rewrite of the legacy Torque logger integration for Home Assistant.

AI assistance disclosure

This project is developed and maintained with assistance from GitHub Copilot and other AI tools. Changes are tested and reviewed before release.

I am not an experienced Python developer, so community testing, code reviews, issues, and pull requests are welcome.

How It Works

The integration does not connect directly to your OBD-II adapter or vehicle.

The data path is:

Vehicle OBD-II interface
        ↓
OBD-II adapter
        ↓
Torque Android application
        ↓
HTTP or HTTPS Web Upload
        ↓
Home Assistant custom integration
        ↓
Home Assistant sensors

Torque communicates with the vehicle and adapter. This integration only receives the telemetry that Torque uploads to Home Assistant.

The resulting sensors can be used in dashboards, history, scripts, and automations.

Features

  • :automobile: Live telemetry uploads from Torque to Home Assistant
  • :bar_chart: Dynamic sensor creation based on fields received from Torque
  • :toolbox: Metadata for 151+ known telemetry fields, including common OBD-II, GPS, trip, and manufacturer-specific values
  • :world_map: Location telemetry, including latitude, longitude, altitude, and bearing when enabled in Torque
  • :electric_plug: UI-based configuration through Home Assistant
  • :mobile_phone: Multiple vehicle support using separate configuration entries and upload endpoints
  • :house: Home Assistant entities compatible with dashboards, history, and automations
  • :counterclockwise_arrows_button: Entity restoration after Home Assistant restarts

Quick Start

Installation

Option 1: HACS, Recommended

  1. Open HACS in your Home Assistant instance.
  2. Select Integrations.
  3. Open the menu in the upper-right corner.
  4. Select Custom repositories.
  5. Add:
    https://github.com/JOHLC/Home-Assistant-Torque-OBDII
    
  6. Select Integration as the category.
  7. Click Add.
  8. Search for Torque OBD-II in HACS.
  9. Click Download.
  10. Restart Home Assistant.
  11. Go to Settings → Devices & services.
  12. Click Add Integration.
  13. Search for Torque OBD-II.
  14. Enter a name for your vehicle, such as 2025 Ford Escape.
  15. Optionally enter an email address. Torque does not always include this field reliably.
  16. Save the unique upload endpoint created for the vehicle.

Option 2: Manual Installation

  1. Copy the custom_components/torque_obd directory into:
    config/custom_components/
    
  2. Restart Home Assistant.
  3. Go to Settings → Devices & services.
  4. Click Add Integration.
  5. Search for Torque OBD-II.
  6. Enter a name for your vehicle.
  7. Optionally enter an email address.
  8. Save the unique upload endpoint created for the vehicle.

Configure Torque

This project has primarily been tested with Torque Pro. Other editions of Torque may also work if they include the Web Upload feature.

  1. Open Torque on your Android device.
  2. Go to Settings → Data Logging & Upload.
  3. Configure the Web Upload URL using the endpoint created by the integration.

Local Home Assistant

Use plain HTTP only when your phone and Home Assistant are communicating over a trusted private network:

http://YOUR_HA_IP:8123/api/torque-2025-ford-escape

Remote Home Assistant

Use HTTPS whenever the connection crosses the public internet or another untrusted network:

https://YOUR_DOMAIN/api/torque-2025-ford-escape

Security warning

Do not upload vehicle telemetry, GPS coordinates, trip history, identifiers, or other sensitive information over unencrypted HTTP on a public or untrusted network.

  1. Configure the optional email address if desired.
  2. Enable logging and Web Upload in Torque.
  3. Connect Torque to your OBD-II adapter.

If uploads do not begin after the initial configuration:

  1. Open Android Settings → Apps → Torque.
  2. Tap Force Stop.
  3. Reopen Torque.
  4. Reconnect to the OBD-II adapter.
  5. Confirm that logging and Web Upload are enabled.

The integration domain is torque_obd to avoid conflicting with Home Assistant’s built-in legacy Torque integration.

Live Connectivity and Timestamps

Telemetry is uploaded while Torque is running, connected to the adapter, and able to reach your Home Assistant instance.

Important limitations:

  • The phone must have network connectivity to Home Assistant.
  • Uploads occur live or near-real-time.
  • The integration does not buffer missed uploads.
  • The integration does not replay data after connectivity is restored.
  • Data generated while Home Assistant is unreachable may be lost.
  • Home Assistant entity timestamps generally represent when Home Assistant received and processed an update, not necessarily the exact time the vehicle measurement occurred.

This integration is therefore most useful for telemetry collection, history, dashboards, and automations. It should not be treated as a guaranteed continuous vehicle data recorder.

Supported Sensors and PIDs

The integration dynamically creates sensors from telemetry fields received from Torque.

Known telemetry definitions include more than 151 fields across categories such as:

  • Speed and motion: Vehicle speed, GPS speed, acceleration, and trip distance
  • Engine: RPM, engine load, coolant temperature, intake temperature, and oil temperature
  • Fuel: Fuel level, consumption, economy, and remaining range
  • Electrical: Adapter voltage and other available voltage readings
  • Environment: Ambient temperature and barometric pressure
  • GPS: Latitude, longitude, altitude, bearing, and GPS accuracy
  • Trip information: Trip time, distance, and other Torque-calculated values
  • Manufacturer-specific values: Enhanced or custom PIDs provided by Torque

Standard OBD-II values such as speed, RPM, coolant temperature, and engine load are commonly available across many vehicles.

Manufacturer-specific and enhanced PIDs vary by vehicle, adapter, ECU, and Torque configuration. Some values may require custom PID definitions inside Torque.

The integration can only create entities for values that Torque actually sends.

:open_book: View the PID Reference

Sensor Names

Where possible, the integration uses telemetry names and known PID metadata to create readable Home Assistant entities.

Entity names and IDs are also associated with the configured vehicle, helping separate sensors when multiple vehicles are configured.

Actual sensor availability, naming, and units depend on the data provided by Torque.

Adapter Compatibility

The integration does not communicate with the OBD-II adapter itself.

Adapter compatibility is primarily determined by:

  • The Torque Android application
  • The Android device
  • The OBD-II adapter
  • The vehicle
  • The selected PID or sensor

If Torque can communicate with the adapter and successfully upload its telemetry, this integration should be able to process the supported upload fields.

Bluetooth, BLE, Wi-Fi, USB, and other adapter connection methods are handled by Torque, not by this Home Assistant integration.

Requirements

  • A supported Home Assistant version, as shown by the version badge above
  • The Torque Android application with Web Upload support
  • An Android phone or device
  • An OBD-II adapter supported by Torque
  • A compatible vehicle
  • Network connectivity between the Android device and Home Assistant

Security and Privacy

This integration is receive-only.

It does not:

  • Connect directly to the vehicle or OBD-II adapter
  • Send commands to the vehicle
  • Send OBD-II or CAN bus messages
  • Write ECU data
  • Program vehicle modules
  • Change odometer values
  • Control vehicle functions
  • Provide remote access to the vehicle

It only processes telemetry uploaded by Torque.

This does not mean that every other component in the environment is automatically secure. Users are responsible for securing:

  • Their Home Assistant instance
  • Remote access to Home Assistant
  • Their Android device
  • The Torque application
  • Their OBD-II adapter
  • Their local network
  • Any reverse proxy, VPN, tunnel, or cloud service used for remote connectivity

Recommended practices:

  • Use HTTPS for remote access.
  • Do not expose Home Assistant directly to the internet without appropriate authentication and security controls.
  • Keep Home Assistant, HACS, custom integrations, Android, and Torque updated.
  • Restrict access to Home Assistant backups and databases.
  • Review Home Assistant recorder retention settings.
  • Only enable and retain telemetry you are comfortable storing.

Vehicle telemetry may contain sensitive information, including:

  • Current and historical GPS coordinates
  • Trip history
  • Driving patterns
  • Vehicle identifiers
  • Device identifiers
  • Email addresses
  • Diagnostic information
  • Fuel usage and vehicle performance information

This information may be retained in Home Assistant history, recorder databases, logs, and backups.

Intended Use

This integration is intended for:

  • Home Assistant dashboards
  • Historical telemetry
  • Trip and fuel analysis
  • Non-safety-critical notifications
  • Automations
  • Personal vehicle monitoring and experimentation

It is not a replacement for:

  • The vehicle instrument cluster
  • Dashboard warning lights
  • Driver-assistance systems
  • Vehicle safety systems
  • Professional diagnostic equipment
  • Manufacturer service procedures
  • Regular vehicle inspections and maintenance

Do not rely on Home Assistant as the only source of safety-critical vehicle information.

Example Uses

  • Track fuel economy over time
  • Record trip distance and duration
  • Display vehicle telemetry on a dashboard
  • Track battery or adapter voltage
  • Create location-based automations
  • Review temperature or engine-load history
  • Send non-safety-critical notifications
  • Compare telemetry across multiple vehicles

Documentation

Contributing

Contributions, testing, documentation corrections, code reviews, issues, and pull requests are welcome.

When reporting an issue, please include:

  • Home Assistant version
  • Integration version
  • Torque edition and version
  • Adapter type
  • Relevant Home Assistant logs
  • Example telemetry field names, with sensitive information removed

GitHub repository:

License

This project is licensed under the MIT License.

See the LICENSE file for details.

Credits

This integration works with the Torque Android application by Ian Hawkins.

This project is independent and is not affiliated with or endorsed by Torque, Home Assistant, the Open Home Foundation, any vehicle manufacturer, or any OBD-II adapter manufacturer.

2 Likes

Looks good. Will try it out later.

1 Like

So not directly then.

What do you mean by “so not directly then”?

The Torque app sends the data directly to the Home Assistant URL, unless I am misunderstanding your point/question?

1 Like

I have just bought a bluetooth OBDII device so was searching the forum and found your thread.

1 Like

I see what you mean now. It is not direct in the sense that the OBD-II adapter connects straight to Home Assistant.

The adapter connects to the Torque app, and Torque sends the data directly to Home Assistant, where the sensors are created and displayed.

This integration is specifically for Torque Pro, rather than for any OBD-II adapter by itself. That said, if your adapter uses Bluetooth, there is a good chance Torque Pro supports it.

Why did you made it for the Torque Pro APP(cost a fee), when there are a bunch of better rated APPs, for Free ( I know it not a “big deal” ) , However the Data they show, from the Car-Interface is the same

Because I use Torque Pro, and have for years. I haven’t had much luck with other apps.

2 Likes

OK, any bidirectional features in the scope ?

Single direction, OBD II → Home Assistant

Proofreading and testing the actual instructions that you copied from other sources to make sure things are right is a good best practice to follow. So is this: AI Policy | Home Assistant Developer Docs

Atleast Your Link works
I only found the Link to TorguePro APP working above, and non to the Github of the integration

Thanks for sharing the policy. I do test the integration and follow the setup instructions step by step to verify they work.

I am not sure what you mean by the instructions being “copied from other sources.” If you found something specific that is incorrect or needs attribution, please point it out.

This is also an independent custom integration, not an official Home Assistant or Open Home Foundation project.

1 Like

I.E You copied your github “readme” and no links works in here

You also forgot to mention you are driving a specific Ford, which is only current (limited) Brand Specific Support

Will my Volvo V70 and XC70 automatically update the PIDS in the integration ?
( Not that i know whether TorquePro Support Volvo )

Thanks for confirming. I noticed the broken links and have corrected them.

The integration is not brand-specific. Any sensor that Torque sends can be created in Home Assistant. I have only added some Ford-specific PID definitions because that is the vehicle I use for testing.

Volvo or not, OBD-II is a standard across vehicles, so common values such as RPM, speed, coolant temperature, and engine load should work as long as the vehicle and Torque expose them.

The main variation is with manufacturer-specific or enhanced PIDs. Those may require additional definitions in Torque, and the exact names can differ. For your Volvos, the integration should dynamically create sensors from whatever Torque sends, but I cannot confirm in advance how Volvo-specific PIDs will be named or which enhanced values Torque supports.

1 Like

Some questions on first reading:
1: How is this superior to the other one offered directly by HomeAssistant? I see the original one is very popular, classified as Legacy, but updated only three months ago.

The Torque integration was introduced in Home Assistant 0.10, and it's used by 488 active installations.

2: What features does yours offer above the existing one?

3: Are both using the same underlying Torque API?

https://torque-bhp.com/api/ITorqueService.aidl

4: Being a cheapskate here, but maybe your AI assistant can help with this. Sometimes the free aspect of open source is attractive. Can I use the free version of the obligatory intermediate Android Torque app from Ian Hawkins instead of the paid Torque Pro one for your app?

5: Do you have any financial benefits from steering potential adoptors towards the paid Android version of Torque Pro?

6: Your thread title is misleading on first reading. Can you please update it to show “Torque Pro” in the heading. They are used intermingled but one has a fee associated, even though indirectly. I see your GitHub title has the same issue.

7: Is your licence MIT or Apache? The link and text don’t currently agree.

8: Are the issues with using cheap chinese OBD-2 dongle adapters in the original Torque app, both the free and paid Android apps, and your app all the same? Does yours have the ability to work with wired, WiFi, as well as BLE connected ones?

9: Does the Android Torque Pro/Torque app need to be running and connected to your app in HomeAssistant concurrently to store data? Is it a live process needing live connectivity on a (say) race track or workshop dyno where connectivity may be intermittent, or is it buffered and downloaded later? Will the HomeAssistant time stamp reflect the time I achieved my peak horsepower target, or the time it was uploaded/updated? I want bragging rights to match the photos please!!

10: Looking to the future: Have you considered bypassing the Torque Pro Android intermediate and just going straight from the OBD-II dongle direct, like some other projects on these forums have highlighted? Your AI assistant may be able to draw on their pitfalls and advantages and also contribute to their development as well as yours. At minimum, check if their PID tables and yours can have mutual update cross-benefits, something I see you have already done with your Ford extensions here, but they may be missing out on over there. More generally, is there scope for mutual cross-pollination, everybody standing on the shoulders of giants?

One significant different is This “TorquePro” Integration " recommends " to send/receiving your info from your PhoneApp(Pro-version) to your HA, over HTTP , instead of over HTTPS, as the CORE version requires( recommends with specific installation details for this approach ) :thinking:
( Then You can view it in Your HA-Companion APP, over HTTPs, or HTTP if you prefer … )

Maybe a big fat Warning Note would be appropriate in this README/Installation Guide

i.e OBD(Bluetooth)> PhoneApp >HA>CompanionApp, While Driving 3-4000km from Home in a busy big City Street
PS: It’s HOT in southern France and Spain this time of year ( I would primarily rely on my Car instruments( And visual inspections), then the direct Bluetooth-connection, and maybe check my CompanionApp, before i go to sleep

1 Like

Thanks. Yes, there are side issues sometimes overlooked.

I know various sensitive attributes can be updated (not just read) over ODB-II. Giving people access from outside the vehicle is not ideal. Even from inside it can be a worry. I adapted/paired a new ‘virginised’ security module to an existing Mercedes vehicle just two weeks ago using Star equipment I have at home without reference to any Mercedes stealership. Odometers can be updated, etc to reflect engine swaps, rather than distance travelled. A significant money saving exercise for a legitimate owner in the first instance, illegal in the second and refused by me whichever vehicle and how much money you offer if you are winding backwards rather than replacing a faulty unit with a new or virginised one that starts with zero on the clock. I’ve seen the stolen 4WD vehicles, security systems bypassed by simply connecting to the CAN Bus reachable under the headlight, stacked ready to be shipped by container to the middle east, and have been told by a wrecker yard guy I use regularly that visited there on holidays that the road from the airport is lined with them on the other end, still with licence plates from their originating country attached, openly displayed for parts at significantly discounted rates to local at home he cannot legitimately compete with. He is seriously talking about retirring - getting out of the business as organized crime cartels have taken over a large portion of the second-hand parts industry, globally, undercutting legitimate operators and making massive profits, moving parts around the globe.

In this fast paced era of AI discovery of supposed unlinked information, security by obscurity is not a valid option. You have to get it right, each and every time before the crooks do. They only have to get it right ONCE. I’m surprised your AI assistant didn’t flag it as a critical issue.

Driving away in somebody else’s expensive, unique vehicle somewhere in warm St Tropez, clutching your modesty modified Flipper unit is going to get somebody that has a random add-on HomeAssistant app installed onboard to raise some very awkward questions. No wonder car manufacturers are steering away from open APIs, locking up their apps, and people like me are disabling their OBD-II port with a hidden software passive proximity switch to discourage wannabe vehicle thieves. Of course nothing will stop them driving up with a removal van, winding down the ramps, winching your car up, alarm siren blaring, close the roller shutter and simply drive away, even in broad daylight, even with bystanders helping. That is where adequate insurance, both physical theft and data attack, comes in.

I’m not sure how much a stolen Ford Explorer would fetch, but it is the feeling of violation and helpnessness that I avoid, having been victim to theft a number of times, and the feeling of empowerment from successful recovery and discouragement, more than once. Smart car thieves don’t exist for long - they aspire to more ambitious roles like gym junkies, prisoners, preachers, bankers, and tyrant world leaders.

Be aware, be very aware.

On your final comment @boheme61: knowing it is hot doesn’t make it more bearable. Knowing precisely how hot, probably moreso. Stay safe and hydrated.

The HOT and far away from HA-Home was just mend as another “concern”
I.E When does the Companion APP warns me that the Car needs a little “Care/break” (or get broken) If it’s it ever will !, As im i.e Driving in a “clouded” area 4000km from home(Where my HA is) …
Not in an instance that’s for sure, So nope, such data-collection into HA, is just “for the record” / Statistics … and certainly not over HTTP
GPS coordinates of my where-beeing, user-name to HA etc. etc. i might as well leave the Key in my door

  1. In my opinion, it’s a significant improvement over the legacy integration. As you mentioned, the built-in integration is marked as Legacy and hasn’t seen much active feature development in quite some time. My goal wasn’t just to recreate it, but to modernize it while remaining compatible with the same upload mechanism.

  2. Some of the improvements include:

  • Modern UI config flow
  • Unique IDs for entities
  • Entities restore properly after Home Assistant restarts instead of becoming unavailable
  • Support for significantly more PIDs (including many manufacturer-specific ones)
  • Better logging and validation of malformed data
  1. Both integrations use the same mechanism provided by the Torque app itself. Torque is configured to upload data via HTTP(S) to a URL exposed by Home Assistant. This integration receives those uploads and creates entities from them. It is not using the Android Torque API you linked.

  2. You can certainly try the free version. If it includes the HTTP/Web Upload feature, it should work. I originally believed that feature was Pro-only, but I’m no longer certain. If someone tests it with the free version I’d be happy to update the documentation accordingly.

  3. None whatsoever. This is a hobby project that I built because I wanted a better experience than the existing integration. I don’t receive any compensation from Ian Hawkins or anyone else. Just a guy with ADHD, AI, and a love for Home Assistant.

  4. That’s a fair point. Historically both the original Home Assistant integration and the Android application have simply been referred to as “Torque,” which is why I followed the same naming. Since the upload feature may not actually require Torque Pro, I’m hesitant to rename it until that’s confirmed.

  5. Good catch. That was an oversight on my part and has now been corrected. MIT is the correct license.

  6. Adapter compatibility is determined by the Torque app itself, not by this integration. If Torque can successfully communicate with your OBD-II adapter and upload data, this integration should ingest it. I’ve personally tested with a very inexpensive Veepeak Bluetooth adapter without issues.

  7. Data is uploaded live while Torque is running (foreground or background) and has connectivity to your Home Assistant instance, either locally or remotely. There is no buffering or replay if connectivity is lost, so missed uploads are simply missed. The timestamps reflect when Home Assistant received the data, not necessarily when the measurement occurred (though that time is basically instantly). To avoid overwhelming Home Assistant, the integration also applies a rate limit to incoming updates. And yes, Home Assistant logs these like standard entities.
    As an example, I apparently managed to produce a mighty 44.35 horsepower on my commute this morning in my 1.5L three-cylinder.

  8. It’s something I’ve thought about, but it would essentially become an entirely different project. Torque already provides support for a huge range of adapters, vehicles, logging, custom PIDs, dashboards, and data collection. Rather than reinvent all of that, this integration focuses on making the Home Assistant side as seamless as possible. If there are other projects taking a direct OBD-II approach, I’d definitely be interested in seeing them. There may well be ideas we can share between projects.

1 Like