pirate-weather-ha: keeping Dark Sky dashboards alive after the API shut down

What it is, and the problem it was built for

The integration is described as designed to replace the defunct Dark Sky integration in Home Assistant with a modified and updated, but fully compatible version that relies on the Pirate Weather API instead.

That framing tells you the whole project in one sentence. Dark Sky announced a shutdown, and every Home Assistant installation using the default weather integration broke at once. The alternative was to migrate to a different provider and rebuild the dashboards, automations and templates that depended on Dark Sky's specific structure, in particular its minute-by-minute precipitation forecast.

The background story is in the Why section. Since the Dark Sky API has shut down, the author set out to write an alternative API that would return results with the identical syntax, allowing it to be used as a drop-in replacement. That work became the Pirate Weather API, described as a series of AWS Lambda functions that read, process and serve NOAA weather forecasts in the same style and syntax as the Dark Sky API did.

So there are two projects here and they are separable. The API is the data source, hosted at pirateweather.net, and the repository in question is the Home Assistant integration that consumes it. The integration is a client of somebody else's API, and the API is the part with the operational cost: the README is candid that it takes money to run the AWS back-end, and that the free tier would not be possible without ongoing sponsorship from the project's sponsors, with a sponsorship link and a buy-me-a-coffee link both provided.

The primary language is Python, the licence is Apache-2.0, the default branch is master, and the homepage is pirateweather.net. The recent releases are v1.9.3 with a fix to the tests from 2026-10-18, v1.9.2 removing a deprecated constant from 2026-08-21, and v1.9.0 adding air quality sensors and a service from 2026-07-16. The last push was on 2026-10-19 with the project not archived, so the maintenance is current.

The compatibility claim, and where it stops

The Notices section is the most important part of the README for anyone deciding whether to install this, and it is admirably precise about the limits.

While the integration is designed to be compatible with Dark Sky, the underlying code is significantly different. This version is designed to work with more modern versions of Home Assistant, and relies on asyncio, unified data update coordinators, and setup via the UI.

So the compatibility is at the data level, not the implementation level. The same sensors appear with the same values, and existing dashboards and templates keep working, but the machinery underneath is a modern Home Assistant integration rather than the old one.

The next paragraph sets the expectation for accuracy. The underlying API should return similar results, but specific weather variables may be missing, and additional testing is needed to find and correct these edge cases. The project asks users to document issues, with the offer to update either the integration or the weather API depending on where the fault lies.

Then the two concrete gaps, which are named rather than buried. The two most notable missing pieces are the language options and the text summaries. The author explains that both are possible with the way the code is designed, but the code that generates the text still has to be written and then fed into the Dark Sky translation module. For now, the text will display whatever the icon is showing, and it will always be in English.

That last detail is the kind of thing that matters in practice. A Dark Sky installation in a non-English locale produced translated forecast sentences, and this one produces English text on a German dashboard, which is a visible difference even though the data underneath is right.

A legacy branch is also available, described as a one-to-one replacement for the previous Dark Sky integration, but not recommended. It exists for people who cannot upgrade, and the README gives a specific symptom for identifying who those are: if you get an AttributeError: PRECIPITATION upon importing the integration, you are running Home Assistant 2022.10 or earlier, and you should either update or use the legacy branch.

Where the data comes from, and the show me the numbers argument

The argument for Pirate Weather over another weather provider is stated in the Why section and it is about provenance rather than features.

The integration preserves anything that relies on unique aspects of Dark Sky, such as the minute-by-minute forecast, and lets existing dashboards keep working. But the more interesting claim is about how the forecast itself is produced: if you are interested in knowing exactly how your weather forecasts are generated, this is the show me the numbers approach, since the data returned is directly from NOAA, and every processing step is documented.

That is a real difference from the typical commercial weather API. Instead of a model whose internals are a trade secret, this is a public pipeline over NOAA forecasts, with the steps written down, and the README links to an infrastructure overview document and to a thirty-four page PowerPoint about why it rained when the forecast said it would not.

The point of the slide deck reference is worth pausing on. It is a joke, but it is also a real signal about the audience: the project is aimed at people who read weather model documentation for pleasure, and the same audience is comfortable with a JSON API and a Home Assistant YAML dashboard.

For evaluation purposes, two resources are named. merrysky.net is offered as a way to get a feel for the data the API returns, and a status page at pirateweather.xitoring.io shows the current state of the service.

The second one matters more than it looks. A Home Assistant integration that is a thin client of a third-party API is only as reliable as that service, and a status page is the difference between an outage you understand and one you debug at midnight. The API runs on AWS Lambda, so its availability depends on somebody else's account, and the free tier is the tier most people would use.

The repository, and what a HACS custom component looks like

The repository layout is the standard shape of a Home Assistant custom component, and reading it tells you what the project is.

There is a custom_components/ directory, which is where the integration itself lives, and a hacs.json file at the root, which is what makes the component installable through HACS, the Home Assistant community store. A user who adds the repository to HACS gets the integration offered in the Home Assistant interface, and the config/ directory and scripts/ directory hold the development environment and helper scripts.

The images Integration_Setup_A.png and Integration_Setup_B.png at the root are a sign of a project that expects to be installed by people who have never used HACS before, which is worth having given that the audience includes people who just want their weather back.

The dev tooling is modern and tight. There is a .devcontainer.json, so the development environment is a container, and a .python-version file pinning the interpreter. There is a .ruff.toml, and ruff at 0.17.1 in the requirements, which is the fast Rust-based linter and formatter for Python. There is a pytest.ini and a requirements_test.txt, so the test suite is pytest based, and the v1.9.3 release note is literally Fix Tests.

The requirements file itself is short and worth reading:

colorlog==6.12.0
homeassistant==2026.10.1
pip>=26.2.1,<26.3
ruff==0.17.1

The homeassistant pin at 2026.10.1 is the significant line, because it means the test suite runs against a specific recent release of Home Assistant, which is how a custom component stays compatible with a platform that changes its own internals every few months. The pip constraint is a band rather than a pin, which is unusual to see and suggests a deliberate policy against a specific pip release range.

Everything is pinned exactly with the double equals sign, including colorlog, which is the formatter the project uses for its logging output. The NOTICE file and the CODE_OF_CONDUCT.md are present as you would expect, and the Apache-2.0 licence is the permissive one.

Documentation, and what a maintainer still has to write

The documentation section is short and does two things.

First, it points at the archived Dark Sky documentation. Since the integration returns the same type of data as the default Dark Sky integration, the parameter documentation is the same as described in the archived Home Assistant weather card page and the archived sensor page, and both links are web archive URLs because the original pages are gone.

That is a smart piece of documentation design. Rather than rewriting a parameter reference that Home Assistant already documented well, the project links to the archived original, which means the reference is complete and the reader gets the original wording rather than a paraphrase.

Second, it points at the project's own documentation site for the full integration documentation and installation instructions, at docs.pirateweather.net.

The last part of the documentation story is the open work, and it is in the Notices section. The two missing pieces, language options and text summaries, are described as possible with the way the author has things designed, but the code that generates the text has to be written and then fed into the Dark Sky translation module.

The shape of that work is worth understanding. The integration can generate a text forecast and hand it to the translation layer that the old Dark Sky integration used, which means the localisation already exists in Home Assistant's own translation files. The missing part is not the plumbing but the generation of a human-readable sentence from the forecast data, which is a separate piece of work, and until it is done the summary text is simply the icon label.

For a user, the practical guidance is in the same paragraph: document any issues, and the author can update either the integration or the weather API. That division of responsibility is the right one for a two-project setup, and it means an issue report is more useful when it says which half is wrong.

How to evaluate it, and who should install it

There are three questions, and the first is the one that determines whether this is for you at all.

Does your Home Assistant setup depend on Dark Sky? The whole value proposition is preserving what already exists: the minute-by-minute forecast, the dashboards built on it, the automations keyed to specific attributes. If you are starting fresh with Home Assistant in 2026, a native weather integration is simpler and needs no API key, no external service and no sponsor. If you have a Home Assistant install that has been running for years with Dark Sky in it, this is the path that keeps it working with the least disruption.

Second, can you accept the two known gaps? English-only text summaries and missing language options are visible in the interface. If you run a non-English Home Assistant, that is a real regression against the old integration, and it is a known and acknowledged one rather than a bug.

Third, what is your tolerance for depending on a third-party free tier? The integration is a client of a service running on AWS Lambda, funded by sponsorship, with a status page. That is a legitimate model and the maintainer is explicit about the cost. But it means your weather data is one sponsor's continued support away from disappearing, and it means you cannot self-host it.

The project-specific checks are the ones the README already tells you. If you hit an AttributeError: PRECIPITATION on import, you are on Home Assistant before 2022.10 and the fix is to update, with the legacy branch as the fallback if updating is not possible. The legacy branch is explicitly not recommended, so treat it as a bridge rather than a destination.

What you get in return is a maintained, tested, modern integration that speaks a data format nobody else still supports. The release history shows steady work through 2026, with an air quality feature added in July and a test fix in October, and the pinning of the Home Assistant version in the requirements shows the maintainer is testing against a specific current release rather than drifting.

For a Home Assistant user whose dashboards have outlived the shutdown of the API they were built on, that is a good outcome, and the documentation design makes adopting it straightforward.

Editorial conclusion

Adopt pirate-weather-ha if your Home Assistant installation has been running on the retired Dark Sky integration and you want to keep its dashboards, automations and minute-by-minute forecast working with the least disruption. Do not adopt it for a fresh Home Assistant setup, where the native weather integration is simpler and needs no third-party key, and do not expect localised forecast text, since the summary generation and language options are acknowledged gaps and the text is English only for now. Before you commit, check whether you are on Home Assistant 2022.10 or later, since the AttributeError: PRECIPITATION on import means the legacy branch is your only fallback and it is not recommended, read the archived Dark Sky parameter documentation the project points to, and decide whether you are comfortable depending on a free third-party API that runs on AWS Lambda and is funded by sponsorship.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Pirate-Weather/pirate-weather-ha on GitHub
3. Project website
4. README
5. Releases