Kydoimosandanthropic/claude-opus-5
3929546ea5
Two independent bugs made a second change (e.g. adjusting the target
temperature right after switching cool -> heat) fail to take, and made
Home Assistant settle back on a previous state while DKN Cloud NA showed
the correct one.
Wrong setpoint key on write:
_writable_temperature_property_for_mode() ignored its hvac_mode argument
and resolved the key from real_mode/mode in the cached device payload.
That payload still describes the pre-change state, so a heat setpoint was
emitted as setpoint_air_cool: the unit switched to heat but the heat
setpoint never moved. The same defect broke AUTO in steady state, where
real_mode=cool made the write target setpoint_air_cool while the read
used setpoint_air_auto, so the value could never appear to change.
target_temperature() and writable_target_temperature_key() now accept the
mode the caller intends, and that mode takes priority over anything in the
device payload. Device-reported modes remain a fallback only for payloads
that do not expose the requested mode's setpoint.
async_set_temperature() no longer re-sends power+mode; async_set_hvac_mode()
already sent them, and the stale-cache condition guarding the resend was
always true. It now waits (bounded) for the cloud to echo the mode before
sending the setpoint, matching the ensure_mode ordering the smoke test uses.
REST snapshot reverting live state:
The coordinator merged {**existing, **device}, letting the lagging REST
/installations snapshot win over live Socket.IO pushes. Once the socket
confirmed a write, _reconcile_optimistic dropped the overlay, leaving
nothing to stop the next poll from reverting the state.
Socket-pushed values are now tracked per device and applied after the REST
payload. They are discarded when the socket session changes, since updates
may have been missed while it was down and REST becomes authoritative again.
Also report hvac_action and target_temperature against the effective
(optimistic-aware) mode so the action cannot contradict the reported mode
while a change propagates.
Co-authored-by: anthropic/claude-opus-5
DKN Cloud NA — Home Assistant Integration
Control your Daikin mini-split air conditioners through Home Assistant using the DKN Cloud NA cloud service.
This integration is a port of the homebridge-dkncloudna plugin by @plecong, adapted for Home Assistant and distributed via HACS.
Supported Hardware
Any Daikin mini-split system connected to the DKN Cloud NA WiFi adapter (North America). The adapter must be set up and working in the official DKN Cloud NA mobile app before using this integration.
Prerequisites
- A working DKN Cloud NA account
- Your Daikin unit(s) already set up and visible in the DKN Cloud NA app
- Home Assistant 2024.1 or later
- HACS 2.0 or later
Installation
Via HACS (recommended)
- Open HACS in your Home Assistant instance
- Go to Integrations
- Click the ⋮ menu → Custom repositories
- Add
https://github.com/thatguygriff/homeassistant-dkncloudnaas an Integration - Search for DKN Cloud NA and install it
- Restart Home Assistant
Manual
Copy the custom_components/dkncloudna/ directory into your Home Assistant config/custom_components/ directory and restart.
Configuration
- Go to Settings → Devices & Services → Add Integration
- Search for DKN Cloud NA
- Enter your DKN Cloud NA email and password
- Optionally adjust the scan interval (default: 60 seconds)
- Optionally enable Show tokens after login to view your access and refresh tokens
All discovered devices are added automatically.
Entities
Each device exposes the following entities:
| Entity | Type | Description |
|---|---|---|
| AC unit | climate |
On/off, mode (auto/cool/heat/dry/fan), target temperature, fan speed, swing |
| Room temperature | sensor |
Current room temperature (°C) |
| Exterior temperature | sensor |
Outdoor temperature (°C) — disabled by default |
| Wi-Fi signal | sensor |
RSSI in dBm — diagnostic |
| Error code | sensor |
Active error code — diagnostic |
| Connected | binary_sensor |
Whether the device is online — diagnostic |
| Machine ready | binary_sensor |
Whether the device is ready to receive commands — diagnostic |
How It Works
- Authentication. The integration exchanges your DKN Cloud NA credentials for access + refresh tokens on first setup, then uses the refresh token to keep the session alive. Refreshed tokens are persisted to the config entry so they survive restarts.
- Device discovery and polling. All installations and their devices are fetched from the REST API on a configurable interval (default 60 seconds). The poll establishes the device list and acts as a heartbeat against the cloud.
- Live updates via Socket.IO. While the integration is running, it maintains a Socket.IO connection to dkncloudna.com and applies
device-dataevents to entity state in near real-time — no waiting for the next poll cycle. - Control via Socket.IO. Mode, target temperature, fan speed, and swing commands are sent as Socket.IO machine events. Local changes are reflected optimistically in Home Assistant and reconciled when the cloud echoes the new state back.
- Temperature units. Home Assistant always presents temperatures in Celsius. Devices reporting in Fahrenheit are transparently converted in both directions — values you set in HA are sent to the device in its native units.
Known Limitations
- Reauthentication is required if your refresh token expires (e.g. you change your DKN Cloud NA password). Home Assistant will surface a "Reconfigure" prompt when this happens.
- Multi-zone systems are exposed as one climate entity per indoor unit; there is no aggregate "installation" entity.
Credits
- Original Homebridge plugin: homebridge-dkncloudna by @plecong
- EU counterpart inspiration: DKNCloud-HASS by @eXPerience83