OVMS3: an open source telemetry module that plugs into the OBD2 port and gives the data back

The gap OVMS3 is built to fill

The README frames the problem as a data ownership problem rather than a feature gap. It argues that while most new vehicles ship with some remote control system, very few allow deep insight, some do not work in every region, and none hand you control over your personal data. OVMS is the answer to that argument: an all open source vehicle remote monitoring, diagnosis and control system that also lets you add these features to vehicles that never had them.

What the module reports is concrete. Live monitoring covers state of charge, temperatures, tyre pressures and diagnostic fault conditions. The system alerts you about critical conditions and events such as a charge abort, a battery cell failure or a potential theft. Depending on the vehicle integration, it also lets you take control of the charge process, climate control and engine tuning parameters.

The second target audience is fleet monitoring. A fleet manager can track vehicle locations, monitor the state of the vehicle, check fault conditions remotely, offer services such as automatic preheating, and take active control if a vehicle is being used abusively. Because the system is fully scriptable, the README says custom access and control systems can be integrated. The code is C, with a client directory, a plugin directory, a plugins directory and a vehicle directory at the top level of the repository, and the documentation is built with Read the Docs through a .readthedocs.yaml file.

Three CAN buses, a fourth optional, and a toolkit for reverse engineering

The module has three built-in CAN buses and can be extended by a fourth, with the project pointing at a separate SWCAN board for that purpose. For developers and technicians the README lists the tooling in the box: multiple logging formats, a configurable OBD2 translator, a DBC decoder, a reverse engineering toolkit and a CANopen client.

Connectivity is unusually open for a device of this kind. The module provides SSH access and WebSocket streaming, and it can stream and inject CAN frames over TCP. That combination is what makes the reverse engineering toolkit practical: you can watch frames arrive in real time, then send frames back. Both the module and the web frontend can be customised by plugins, so the extension points are on the device side and on the server side.

The vehicle support list is where the reverse engineering assumption becomes concrete. Native integration is documented for a long list of models, including the BMW i3 and i3s, the BYD Atto 3, the Chevrolet Bolt EV and Opel Ampera-e, the Chevrolet C6 Corvette, the Fiat 500e and e-Doblo, the Hyundai Ioniq vFL and Ioniq 5, the Kia e-Niro, Kia Soul EV and Mini Cooper SE, the Mercedes-Benz B250E, the Nissan Leaf and e-NV200, the Renault Twizy, Zoe and Kangoo, the Smart ED Gen.3 and the Smart EQ Gen.4. The list also includes Energica motorbikes and NIU electric motorcycles, which tells you the same firmware family covers more than cars.

One entry is worth reading carefully. The Chevrolet Volt and Opel Ampera appears without a documentation link, and so do the Livan Maple 60s, the Maxus Euniq 6 and the Mitsubishi Trio. That is the shape of an integration that exists in the code but is not written up, and the difference matters when you are deciding whether a given car is genuinely supported.

The hardware kit, its certifications and how it connects

The base component is a small hardware module that plugs into the vehicle OBD2 port. The standard kit in the current version 3.3 includes a 2G, 3G or 4G modem for cellular connectivity and a GPS receiver. That kit is described as FCC certified and CE certified, which is a rarity for an enthusiast project and matters if you intend to carry the device across borders.

The connection surface is well covered. The module provides a built-in Web App as its user interface, plus remote control through native mobile apps for Android and iOS. It integrates into home and process automation systems over MQTT, and it provides data logging to an SD card on the device and to a server.

MQTT is the piece that changes how the project can be used. Because vehicle state is published to a topic broker, the data can feed anything that speaks MQTT: a home automation rule that starts a preheating cycle, a dashboard, a script that pages you when a fault appears. The README does not document the topic structure or the message payloads in the visible text, so anyone building on that integration should expect to read the protocol documentation rather than guess at it.

The warning section is the honest part of the documentation

The README devotes a full section to a warning that starts with USE AT OWN RISK and calls the system a HOBBYIST PROJECT, not a commercial product, designed by enthusiasts for enthusiasts. It says becoming a user means becoming part of the project community rather than becoming a customer.

Two consequences are stated plainly. Most vehicle features are based on reverse engineering rather than OEM documentation, so no compliance with OEM requirements can be guaranteed. And installing the module may damage your vehicle and void your vehicle warranty. The document also notes that installation and use require some technical knowledge, and recommends contacting other users in your area for help if you do not have that.

There is a liability paragraph as well, with the system provided as is and without warranty of any kind, and with the authors, copyright holders, service and hardware providers disclaimed from liability for claims, damages or other liability arising from use of the system. This is the standard shape of an open source disclaimer, and it aligns with the licence field on the repository, which reads as a custom licence that GitHub cannot classify, with a LICENSE file in the repository root. Anyone considering OVMS3 for a business vehicle should read that file before assuming the terms fit their use.

Where a commercial telematics box does the job better

The honest comparison here is against the connected car services that manufacturers and aftermarket vendors sell, and against generic OBD2 dongles. The commercial route wins on guarantees: a certified device with a support contract, a privacy policy you can point a customer at, and vehicle integrations that come from the manufacturer rather than from reverse engineering.

The dongle route wins on simplicity. A consumer OBD2 adapter with a mobile app gives you a few live values and no remote control, but it installs in seconds and does not ask you to accept a hobbyist warning. If what you need is a fuel economy log or a fault code reader on a trip, that is the cheaper answer.

OVMS3 earns its place in the specific case where a vehicle has a battery whose individual cells, temperatures or state of charge are worth watching closely and the manufacturer app does not expose them. The alerts for battery cell failure and charge abort, the cell-level state of charge, and the ability to intervene in the charge process are the features that no generic dongle offers and that a manufacturer app rarely exposes with that granularity.

The cost of that is exactly what the warning section says. You are running community code against a vehicle whose documentation you do not have, and the failure modes of that choice are a hardware question as much as a software one. The README also notes the module has three built-in CAN buses and can inject frames, which is the kind of capability that a warranty claims process will not enjoy.

What the codebase layout says about the project shape

The repository top-level entries give a good picture of how the work is divided. There is a client directory, a plugin directory, a separate plugins directory, a vehicle directory, and a docs directory that is built through the Read the Docs configuration. The flyer and logo directories hold project artwork, and the .gitmodules file indicates that some components are pulled in as submodules rather than kept in this tree.

The split between plugin and plugins is a small but telling detail. One is likely the plugin API or the plugin framework, the other the shipped plugin set, and separating them means a vehicle-specific plugin can be added without touching the core. That matches the README's claim that both the module and the web frontend can be customised by plugins, and it means adding support for a car that has no listed native integration is a plugin-level job rather than a firmware fork.

The build tooling is dated. The repository carries a .travis.yml file, and the primary language is C, which is the right choice for a device that has to talk to a CAN bus and fit into a small module with limited memory and flash. It also means the code has to be compiled rather than installed, so the deployment path is a firmware image rather than a package manager entry.

Maintenance is current. The repository is not archived and the last push was on 2026-10-19. There are no GitHub releases, so versions are tracked through the hardware kits and the documentation rather than through tagged artefacts you could pin in a build script.

Editorial conclusion

OVMS3 fits an EV owner who wants cell-level state of charge, temperature and fault data that the manufacturer app does not expose, and a fleet operator willing to run an enthusiast project on their vehicles. It does not fit anyone who needs a warranty-safe product, a certified commercial platform, or support for a vehicle that has no listed native integration. Before buying the hardware, confirm that your exact model appears in the native integration list, read the LICENSE file yourself since the licence is a custom one that GitHub cannot classify, and accept that the module installs behind the OBD2 socket and reports over a cellular modem with the coverage your carrier provides.

Frequently asked questions

Official sources

1. Issues
2. openvehicles/Open-Vehicle-Monitoring-System-3 on GitHub
3. Project website
4. README