The GitHub mirror is gone, so the HACS packaging and the GitHub-only CI
no longer have anything to run against.
Remove hacs.json and the .github/ workflow. Both of its jobs (hassfest
and hacs/action) were gated on `github.server_url == 'https://github.com'`
and are GitHub-hosted actions, so neither can run on the Gitea runner.
Replace them with .gitea/workflows/ci.yml:
- lint: ruff check + ruff format --check, version pinned because ruff's
default rule set and formatter output move between releases
- validate: byte-compile, then scripts/validate_integration.py, which
covers the part of hassfest that matters for a manually installed
custom component (manifest keys, domain/directory agreement, and
translations matching strings.json key for key)
README now documents manual installation only, and points at the local
CI commands. manifest.json documentation and issue_tracker point at the
Gitea repo; NOTICE keeps its upstream attribution.
Adopting ruff surfaced two real defects, fixed here:
- climate.async_set_hvac_mode raised HomeAssistantError for an
unsupported mode from inside a try that catches Exception, so the
message was re-wrapped as "Failed to set HVAC mode: Unsupported HVAC
mode: ...". The validation is now hoisted above the try.
- config_flow.async_step_reauth_confirm swallowed unexpected exceptions
into a bare "unknown" error with no log, unlike the user step. It now
logs via _LOGGER.exception.
Remaining changes are mechanical: import ordering, docstrings on public
methods, ClassVar on mutable class attributes, contextlib.suppress, and
asyncio.TimeoutError -> TimeoutError (an alias since 3.11). The smoke
test now reads the new DknCloudNaClient.socket_connected property rather
than reaching into _socket.
Co-authored-by: anthropic/claude-opus-5
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
The DKN cloud REST endpoint lags behind the unit for several seconds
after a write, even though the unit itself and the DKN app reflect
the change immediately. The previous 2.5s optimistic-overlay TTL
expired well before the cloud caught up, so the next coordinator
publish (REST poll or socket device-data push) carried stale values
and the HA UI reverted to the previous setting.
Extend the overlay TTL to 30s as a safety bound, and track the
underlying device key + expected device value alongside each overlay.
On every coordinator publish, clear overlays whose device key now
reports the expected value (cloud has confirmed). The TTL still
caps how long a silently-failed write can hold a wrong value.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
The DKN Cloud NA API returns 404 (not 401) when tokens are expired,
which caused the integration to silently fail with UpdateFailed
indefinitely instead of attempting a token refresh or triggering
reauth. Refreshed tokens were also only held in memory, so they
were lost on Home Assistant restart.
- Add 404 to auth_error_statuses on is_logged_in, refresh_access_token,
and fetch_installations.
- Persist refreshed access + refresh tokens back to the config entry
after each successful coordinator update.
- Skip the entry reload listener for token-only option updates to
avoid a reload loop on every refresh.
- Log API 4xx responses at WARNING with the body so failures are
visible in HA logs without enabling debug logging.
Daikin-blue rounded square with white snowflake motif.
Satisfies HACS brands check and HA integrations UI display.
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Kydoimosandanthropic/claude-opus-5
thatguygriffandClaude Opus 4.7
Sebastien Lavoie