Flightradar24 for Home Assistant: a HACS integration for live aircraft

Aircraft as Home Assistant data

The integration is described as bringing real-time aviation tracking into Home Assistant, so that you can track flights above your location, monitor airports, follow specific aircraft worldwide, and trigger automations based on live flight events.

The point that decides whether this is useful to you is in a single line of the README: No Flightradar24 subscription required. The commercial flight-tracking products sell access to their data, and this component uses the same public-facing source that Flightradar24's own site and apps rely on. That is convenient for a hobbyist and it is also the constraint, because a public endpoint can change or throttle without notice.

The distribution is the standard Home Assistant one. It is a custom component, it is in the Home Assistant Community Store as a default integration, and the repository carries a HACS badge, a HACS validation workflow and a code checks workflow. The version badge states Home Assistant 2025.1+, and the maintainer is @AlexandrErohin.

The primary language is Python and the licence is MIT. The recent releases are v2.3.0 from 2026-10-06, v2.2.2 from 2026-10-02 and v2.2.1 from 2026-09-22, and the last push to the repository was on 2026-10-21.

What you actually get: sensors, cards, trackers and triggers

The feature list is short and high level, so the more useful document is the numbered list of capabilities underneath it.

You can know how many flights are in your area right now, or just whether one has entered or exited it, and get a list of flights with full information for every relevant flight on the sensor. You can track a particular plane or planes no matter where they currently are, even if it is a scheduled flight. You can monitor daily statistics such as on time, delayed and canceled flights for the selected airport, and you can get the top 10 most tracked flights on Flightradar24.

Then the automation half. You can create notifications, with the README giving the examples of a notification when a flight enters or exits your area and a notification when a tracked scheduled flight takes off, and you can create automations that automatically track a flight by your needs.

The dashboard side is the fourth group. There is a live map card with aircraft markers and flight tracks, a flights table for your area rendered through the Lovelace Card, and departures and arrivals boards for the selected airport through the Lovelace Airport Card. Two Home Assistant-native integrations come on top of that: flights can be tracked as a `device_tracker`, which is what makes the device appearing or disappearing useful in automations, and there is a Last Flights History Sensor for information about the last flights that were in your area or about the latest exited flight.

The screenshots in the README show the map card, the flights table, the sensor readouts and both airport boards, so the shape of each surface is visible before installation.

Installing from HACS takes four clicks

The recommended route is the Home Assistant Community Store, and the steps are short:

The steps are short: install HACS from hacs.xyz, open HACS, search for `Flightradar24`, click Download in the search result, and restart Home Assistant.

There is also a one-click install link that opens the repository inside your own Home Assistant instance, which is the same path with the browser handing off to the local instance.

For a reader assessing the project, the HACS badge is more than a convenience marker. A component listed as a default integration in the store has gone through HACS validation, and the repository carries a badge for that validation workflow alongside one for code checks, so both are visible in the README rather than something you discover later.

Restarting Home Assistant after the download is part of the documented sequence rather than an optional extra, and it comes back in the configuration section too.

Manual installation and the configuration flow

The manual route is three steps and involves no tooling beyond a file copy:

1. Locate the `custom_components` directory in your Home Assistant configuration directory. It may need to be created.
2. Copy the `custom_components/flightradar24` directory into the `custom_components` directory.
3. Restart Home Assistant.

The note that the directory may need to be created is the detail to note. On a fresh Home Assistant installation the custom_components directory does not exist, and an integration that is not in that directory is not loaded.

Configuration is done through the GUI rather than YAML, which follows the modern Home Assistant convention. The README links the Home Assistant documentation on integrations for the general details, and the flow is:

1. Go to the <b>Settings</b>-><b>Devices & services</b>.
2. Click on `+ ADD INTEGRATION`, search for `Flightradar24`.
3. You may change the default values for Radius, Latitude and Longitude
4. Click `SUBMIT`

The three configurable values define your area of interest, and the README notes that the default data is preset already, so the configuration form works without changes if the defaults suit where you live. Radius is what determines the boundary for the flights-over-your-area sensor and the enter and leave triggers, and the latitude and longitude are the centre of that circle.

The note after the configuration is the part to read

Immediately after the configuration steps the README has an IMPORTANT NOTE block, and it is worth pointing out that the version published here is cut off mid-sentence. It reads: After integration installation or reload and after every HA restart Current

That is clearly the start of a numbered list of cautions, and the numbered structure of the note is visible even though the items are not. The phrase after every HA restart in particular suggests the note is about state that does not survive a restart, which is exactly the kind of detail an integration can lose quietly.

The reasonable reading is that the note explains what has to be done after the integration is installed, reloaded, or when Home Assistant restarts, and the numbered list continues past the cut. The full text is in the README on the repository and in the community forum thread, which is linked from the repository as the homepage.

This is a good example of why an integration's own documentation page matters. The README here is the quick reference for installation and configuration, and the community thread at community.home-assistant.io/t/custom-component-flightradar24 is where the operational detail lives, including the sections referenced later in the README such as the flight sensor, the selected airport configuration, the top ten most tracked flights, the notification examples, the automation example, the map card, the Lovelace cards, the device tracker and the last flights history sensor.

Before you build an automation on this, read that note. An integration that needs an action repeated after every restart will not behave like one that does not.

The repository is a proper custom component, with tests

The top-level entries describe a conventional Home Assistant custom component rather than a script dropped into a folder.

There is the custom_components directory holding the integration itself, a tests directory, a pytest.ini and a requirements_test.txt, which together are the test setup, and a .flake8 for linting. There is a hacs.json, the file the community store reads to know what this repository is and how to install it, and a docs directory with the media the README embeds.

There is also a CHANGELOG.md, which matters more here than usual, because a Home Assistant integration lives inside a moving platform. Home Assistant changes its own APIs between releases, and a component that is not updated for a new core version will stop working. The 2025.1+ badge tells you the floor it was written against, and the changelog is where you would look to see how it has tracked the platform since.

The release numbering tells the same story from the other side. Three releases in September and October 2026, v2.2.1 on 2026-09-22, v2.2.2 on 2026-10-02 and v2.3.0 on 2026-10-06, with a minor bump in the middle, suggests a component that is being maintained against a moving target rather than one that was published once and left.

What the repository does not contain is any test of the Flightradar24 data source itself. The tests can cover the component's own logic, but the upstream service can change its responses or its access rules without the repository noticing, and the failure would appear as empty sensors rather than as an error.

Community maintenance, and the boundary of what the data guarantees

The licensing is the easy part. MIT, with a LICENSE file at the root, and a CHANGELOG that follows the project through its releases.

The harder part is what the integration can promise. Everything it reports comes from Flightradar24, whose coverage of aircraft is incomplete by nature, since the underlying data comes from a mix of aircraft transponders, receivers on the ground and other contributors. A flight that is not in that data set does not appear in your sensors, and there is no way for the component to distinguish that from a flight that is not there.

That matters for the automations people build on top of it. A notification that fires when a tracked scheduled flight takes off is a good feature, and it is also a notification that depends on a third party's coverage and on the component's polling continuing to work. The README's own note, truncated as it is, suggests there are already lifecycle details to be careful about.

So the sensible way to use this is as an enthusiast's integration: good for knowing what is overhead right now, good for putting a plane on a dashboard, useful for a home automation that nobody depends on. It is not an air traffic service, and the project does not claim to be one.

For a comparison, the difference with the commercial products is not accuracy but the terms. A subscription gives you a documented interface, a support commitment and a data pipeline you can rely on. This integration gives you the same class of information without a subscription and without any of those guarantees, in exchange for a dependency you install from a community store and a maintainer who ships releases every few weeks.

Editorial conclusion

Flightradar24 fits a Home Assistant user who wants aircraft over their house as a sensor and a flight they are about to take as a tracked device, and who would rather install a HACS integration than write a scraper. It is the wrong choice for a flight-tracking project with hard requirements, since it is one person's community component with no subscription but also no service agreement behind the data, and the README's own note section is truncated in the version published here. Verify first which Flightradar24 data you actually need, because the component depends on a public service whose endpoints and rate limits are outside its control, and read the community thread linked from the repository before you rely on a sensor for something that matters.

Frequently asked questions

Official sources

1. AlexandrErohin/home-assistant-flightradar24 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases