Škoda Is Opening the Door to Home Assistant

For years, connecting a modern car to a smart home has sometimes felt like trying to connect two neighbours who deliberately refuse to exchange phone numbers.

The car manufacturer has an app.
Home Assistant has an integration.
The charging station has another app.
And somewhere in the middle, there is usually a developer reverse-engineering something that was never intended to be public.

Škoda is now taking a rather different approach.

The company has launched an official public API for its connected vehicles, designed specifically to allow owners to connect their cars to smart-home platforms, charging systems and their own software. And perhaps most interestingly for Home Assistant users, Škoda is working directly with the Home Assistant community on an official integration.

That is a pretty big deal.

An official API instead of another unofficial workaround

The new MyŠkoda Public API is intended for owners of connected Škoda vehicles who want to use vehicle data in their own integrations. Škoda’s documentation explicitly mentions smart-home platforms such as Home Assistant as a use case.

The API provides access to information such as:

• Vehicle status
• Doors, windows and lights
• Odometer
• Fuel or battery information
• Charging status and charging profiles
• Air conditioning and auxiliary heating
• Parking position

It also supports remote commands, including starting and stopping charging, setting the charging limit and controlling air conditioning where the vehicle supports those functions. Availability naturally depends on the particular vehicle and its connected services.

Even better, Škoda has chosen a relatively straightforward authentication model for private users. An API key can be generated through MyŠkoda and then used by an integration.

No mysterious scraping.
No pretending to be the MyŠkoda mobile app.
No reverse-engineering the manufacturer’s private endpoints.

Just an API.

That is how this should work.

Škoda actually talked to the open-source community

This might be the most interesting part of the entire story.

Škoda did not simply publish an API and tell developers to figure it out themselves.

According to the evcc project, Škoda worked with the open-source community during the development of the API. The collaboration included developers from evcc, the existing MyŠkoda Home Assistant integration, the skodaconnect Python library and the Open Home Foundation. Feedback from those projects was used to shape the API.

That is a very different approach from the traditional automotive model of:

“Here is our app. Please enjoy the app.”

The open-source community already knew where the problems were. Instead of fighting those developers, Škoda brought some of them into the conversation.

For Home Assistant users, that is exactly the kind of cooperation we want to see.

And Home Assistant is getting an official integration

The next piece of the puzzle is already visible in Home Assistant Core.

Pull Request #181591 adds a new native Škoda integration. The proposed integration is configured through the Home Assistant UI using the vehicle VIN and an API key, and the initial implementation provides vehicle information through the sensor platform.

The current PR is deliberately limited in scope. It starts with sensors rather than trying to expose every possible vehicle function on day one.

That is actually a sensible approach.

Get the authentication working.
Get the data into Home Assistant.
Make the integration reliable.
Then add more functionality.

The PR also shows that the integration is being developed from the Mobility Lab at VŠB-TUO, which matches the description Škoda is now giving customers about its collaboration with student talent and the Mobility Lab.

At the time of writing, the PR is still open, so I would not promise a specific Home Assistant release yet. The project is clearly moving, but release timing is ultimately up to the Home Assistant development process.

What does this mean for existing MyŠkoda users?

This is where things get particularly interesting.

The existing community MyŠkoda integration has announced that it will reach end of life in October 2026 because Škoda is retiring the old unofficial API. The project maintainers are instead collaborating around the new official API and the new Home Assistant integration.

So this is not simply a new alternative.

It is effectively a migration from:

Unofficial API → Official API

And that is probably a very good thing in the long run.

Anyone who has maintained a Home Assistant integration against a private cloud API knows that it can be a slightly stressful hobby. One change on the manufacturer’s server can turn a perfectly good integration into a very expensive-looking collection of Unavailable entities.

An official API gives everyone a much more stable foundation.

Why this matters for smart charging

This is where the new API becomes especially interesting for a Norwegian Home Assistant setup.

Imagine having the car as a proper participant in the home’s energy management.

Home Assistant already knows things like:

• Current electricity price
• Solar production
• Household consumption
• Grid import/export
• EV charger status
• Weather
• Time of day

Add the vehicle’s battery state and charging controls, and suddenly the car becomes another controllable energy consumer.

For example:

Electricity price drops below 0.30 NOK/kWh → check that the car is home → check battery level → start charging.

Or:

Solar production exceeds household consumption → charge the car with the available surplus.

Or:

Car needs to be ready at 07:00 → calculate whether charging needs to start during the cheapest hours.

The official API exposes the building blocks required for this kind of automation, although the exact entities and actions available in Home Assistant will depend on the final integration and the capabilities of the individual vehicle.

A simple Home Assistant example

Once the official integration exposes the relevant charging entities, an automation could look something like this:

alias: Škoda - Charge when electricity is cheap
description: Start charging the Škoda when the electricity price is low
triggers:
  - trigger: numeric_state
    entity_id: sensor.nordpool_kwh_no3_nok_3_10_025
    below: 0.30

conditions:
  - condition: state
    entity_id: binary_sensor.skoda_at_home
    state: "on"

  - condition: numeric_state
    entity_id: sensor.skoda_battery_level
    below: 80

actions:
  - action: button.press
    target:
      entity_id: button.skoda_start_charging

mode: single

The entity names here are intentionally examples rather than copy-and-paste entities. The final Home Assistant integration is still being developed, and the actual entity and action names may differ.

But the important part is the architecture.

Home Assistant knows the price.

Škoda knows the car.

The API provides the bridge between them.

And that is much more interesting than another dashboard showing whether the boot is open.

The car becomes part of the home

Once vehicle data is available natively in Home Assistant, the possibilities go well beyond charging.

Imagine arriving home with the car:

Car arrives
      ↓
Home Assistant detects arrival
      ↓
Turn on driveway lights
      ↓
Open garage lighting
      ↓
Check charging state
      ↓
Start charging if appropriate
      ↓
Update the energy dashboard

Or leaving for work:

Car leaves
      ↓
Turn off driveway lights
      ↓
Set house to away mode
      ↓
Check doors and windows
      ↓
Reduce heating if appropriate

And because Home Assistant already connects cars, lights, heating, security, energy monitoring and hundreds of other systems, the vehicle no longer needs to be treated as a separate technological island.

It becomes another device in the house.

Admittedly, a rather expensive device.

This is also a good example of why APIs matter

There is a broader lesson here.

Smart-home users increasingly expect their devices to cooperate.

We don’t necessarily want ten different apps controlling ten different things. We want the washing machine, heat pump, EV charger, solar inverter, lights and car to be able to participate in one automation system.

Manufacturers don’t have to build the perfect smart-home platform themselves.

They just need to provide a good, secure and documented API.

Let Home Assistant, Apple Home, Google Home, evcc and other platforms do the integration work.

Škoda’s new API is therefore more important than the individual sensors it exposes.

It represents a change in attitude.

Instead of asking:

“How do we keep users inside the Škoda ecosystem?”

the approach becomes:

“How can the car participate in the ecosystem the user has already built?”

That is a much healthier philosophy for connected devices.

There is still work to do

Of course, this is not the end of the story.

The current Home Assistant PR is still under development, and the first version is deliberately sensor-focused. More functionality can be added later.

There are also practical questions around API limits, vehicle capabilities, polling intervals and exactly which remote commands will be exposed through Home Assistant.

And naturally, the API depends on Škoda’s cloud services. This isn’t a fully local integration where your Home Assistant talks directly to the car parked in your garage.

But compared with an unofficial API that can disappear without warning?

I’ll take the official API.

A small step for Škoda, a big step for the garage

For a car manufacturer, publishing an API might not sound revolutionary.

For someone running Home Assistant, it is.

Škoda has effectively opened the garage door and said:

“Here. You can integrate the car.”

That is exactly the direction the connected-car industry should be heading.

The interesting part will now be seeing what the Home Assistant community does with it.

Because once the Škoda becomes another entity in Home Assistant, I’m fairly certain someone will eventually automate something completely unnecessary with it.

And honestly?

That’s half the fun of Home Assistant.