daikin_onecta: pulling Daikin cloud devices into Home Assistant

A cloud integration with an account prerequisite

This is a Home Assistant custom component for devices supported by the Daikin Onecta app, and the mechanism it uses is the Daikin Onecta API rather than local hardware communication. That single fact determines both its value and its limits.

The value is real. Several Daikin product lines, including the Altherma line named in the repository topics, are controlled through the Onecta cloud, and without this component they simply do not appear in Home Assistant. Once installed, the devices attached to the Daikin cloud account become visible within Home Assistant.

The limits follow from the same fact. Every piece of state comes from a vendor server over the internet, so the integration depends on Daikin Developer Portal account creation, on an OAuth application, and on Daikin's cloud being up. The README links a status page for the Daikin cloud so you can check its state, which is a reasonable thing to have and also an admission that the dependency is real.

There is also a licensing constraint on the tokens themselves. The README carries a warning that sharing, selling or distributing access and refresh tokens is strictly prohibited according to the Daikin developer terms of use, and that sharing them could cause serious issues for the user. This is the one piece of this integration you must not treat as ordinary configuration data.

The OAuth dance, and the one setting that silently breaks it

The setup path is a multi-step OAuth flow, and the documentation is unusually explicit about where it goes wrong.

The sequence is: create an account on the Daikin Developer Portal, then create an application there, following the Getting started page. The redirect uri to use first is always https://my.home-assistant.io/redirect/oauth. The client id and secret the portal hands out are what you enter in Home Assistant.

In Home Assistant you start the config flow, either through My Home Assistant or manually through Settings, then Devices and Services and the ADD INTEGRATION button, selecting Daikin Onecta. In the Add credentials form you give a user-defined name such as daikin_onecta and paste the OAuth Client ID and OAuth Client Secret. The flow then redirects you to the Daikin website, where you tick the permission checkbox, press I agree, and are returned to the redirect uri where you press Link account. If the instance URL shown is wrong, the pencil icon lets you edit it before linking.

The setting that breaks things quietly is the developer account email. The prerequisites section says to sign up for the developer account with the same login method and email address as you use with the Onecta app, and warns that using a different login method or email address results in no devices shown in Home Assistant. No error, no warning, just an empty device list.

There is a fallback for the redirect itself. If the redirect back to your Home Assistant does not work, install or enable My Home Assistant first. If that also fails, use <HOME_ASSISTANT_URL>/auth/external/callback as the redirect uri, and the URL must match your base URL exactly, including the scheme, and including a port only when your instance is actually served on that port. The documentation gives concrete examples, such as http://homeassistant.local/auth/external/callback or http://192.168.0.2:8123/auth/external/callback.

Installing through HACS or by copying one folder

There are two install paths, and the HACS one is the short one.

With HACS, you select HACS, search for the daikin_onecta integration, select it and press the Download button. After that you continue with the config flow described above.

The manual path is a file copy. You copy the daikin_onecta folder and all of its contents into your Home Assistant custom_components folder, which is often inside the /config folder. The README covers the deployment variants: on Hass.io you use SAMBA to copy the folder over, and on Home Assistant Supervised the custom_components folder might be at /usr/share/hassio/homeassistant. If the folder does not exist you create it in the proper location, and then copy the daikin_onecta folder and its contents inside. Home Assistant has to be restarted afterwards for the component to be loaded properly.

That restart step is easy to forget, and the symptom of forgetting it is an integration that does not appear in the add-integration list.

For multiple Daikin Onecta accounts the documentation points at the application credentials guide for adding the extra credentials first, and then setting up the integration through My Home Assistant. The repository structure supports this: the integration lives under custom_components/ and the top level also carries hacs.json for the HACS listing, blueprints/, tests/, scripts/ and a pre-commit configuration.

Polling intervals, and the limit you do not control

The integration exposes a set of configuration settings whose entire purpose is to reduce how much it polls Daikin. The list is specific: a high frequency period update interval in minutes, a low frequency period update interval in minutes, the start time of the high frequency period, the start time of the low frequency period, and the number of seconds during which a data refresh is ignored after a command.

That last one is the interesting design decision. After you send a command to a device, the cloud may not reflect the change immediately, so a short ignore window prevents the integration from immediately polling and reporting a stale value that contradicts the command you just issued.

The two-tier interval structure is the standard answer to a rate limited cloud API. A device that is being actively adjusted needs fresh data, while a device sitting idle does not, so the high frequency window covers the hours you care about and the low frequency window covers the rest.

The hard constraint is that Daikin sets the limit, not you. The README says current poll limits can be found under system health in Home Assistant. That is the honest version of the story: the intervals you configure are a request, and the vendor's quota is the boundary, so aggressive settings will eventually get your requests refused. The system health panel is where you find out where that boundary currently sits.

Error sensors that only say something went wrong

The last documented feature is worth reading closely, because it is an example of a component being honest about its own limits.

There are three binary sensors: Is in error state, Is in warning state and Is in caution state. The README states that these sensors only tell you that the unit signalled a problem; they do not tell you, and the sentence is cut off there, what the problem actually is.

So the integration surfaces the fact that a device reported a problem without exposing its cause. For a consumer climate unit that might be acceptable, since the physical device often shows a more useful message on its own display. For an air-to-water heat pump in a plant room where nobody looks at the indoor unit, it is thin. The Altherma line in the repository topics suggests exactly that kind of equipment, and a warning state with no detail is a signal you would have to follow up on out of band.

The repository does include a blueprints/ directory, which is the Home Assistant mechanism for shipping reusable automation templates, so the intended response to these sensors is a ready-made automation rather than a richer diagnostic. The coverage badge and a tests/ directory indicate the component is tested, and the presence of a .yamllint configuration and a pre-commit setup suggests the repository is maintained with some care.

How this compares with local control of the same hardware

The alternative is a local integration. For some Daikin hardware there are community integrations that talk to the unit on the local network, typically through the unit's own web interface or an onboard API, and those need no cloud account and no developer registration.

The difference in approach is exact. A local integration keeps the device reachable when the internet is down, has no third party in the data path, and imposes no poll quota because there is no cloud to rate limit. It also has no onboarding ceremony: no developer portal account, no OAuth application, no redirect uri to get right.

The trade is coverage and fragility. Local integrations only work for the specific product lines whose protocols someone has reverse engineered and reimplemented, and they break when the vendor changes the firmware of the device. The cloud integration in this repository works for the whole Onecta range, as long as the cloud is up and the account matches.

So the choice is not really about features. It is about whether a heating or cooling decision for your home depends on a third party server being reachable. For a weekend house, cloud control is fine and probably the only option. For a primary residence with a heat pump in the winter, a local path is worth the extra setup effort, and this component is the fallback rather than the destination.

Editorial conclusion

Adopt daikin_onecta if you run Home Assistant and own Daikin hardware that is only reachable through the Onecta cloud, and skip it if you need local control that keeps working when the internet is down, because this component polls a vendor cloud rather than talking to the device. Before you install, create a Daikin developer application with the redirect uri set to https://my.home-assistant.io/redirect/oauth and use the same login method and email address as your Onecta app, since a mismatch means no devices appear, and note that the last push was on 2026-10-20 with release v5.0.2 on 2026-10-14.

Frequently asked questions

Official sources

1. jwillemsen/daikin_onecta on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases