Update zone.home from router GPS (#28) - #32
Merged
Conversation
When a user has customized zone.home in Settings > Areas & Zones, HA persists the zone with editable=True and skips wiring its core_config_updated listener. The homeassistant.set_location service then updates hass.config but never propagates to the zone.home entity, so the integration silently fails to update the home location. Detect editable=True on zone.home and log a one-time WARNING instructing the user to remove the custom home zone. Resume updates if they do.
In addition to the log warning, create a Home Assistant Repair issue when zone.home is detected as user-customized, and delete it automatically once the condition clears or the config entry unloads. Adds the corresponding translation strings for title and description.
Users cannot delete zone.home, so the prior warn-and-skip approach left customized home zones permanently stuck. Instead, when zone.home is editable, update the stored entry directly via the zone storage collection so the entity moves while preserving the user's radius, icon, and passive settings. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
homeassistant.set_location's schema requires elevation to be an int, but the integration was passing the router's float altitude (e.g. 156.2). The resulting voluptuous MultipleInvalid was swallowed by async_create_task and never surfaced under the rutos logger, so the home-location update silently failed every coordinator refresh. This was the real root cause of #28 — the editable-zone theory behind the earlier commits on this branch turned out to be wrong on modern HA releases, where set_location does propagate to editable home zones. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Temporary diagnostic commit for #28. To be reverted after investigation.
Diagnostic commit only. Listener fires every ~30s with correct GPS coords but zone.home never moves on the live HA — manual set_location calls with the same payload move the zone fine, so something between the warning log and the actual service call is failing silently. Log types + values on entry, catch the int-cast, and wrap the set_location call in try/except with .__name__ logging to expose whatever's being swallowed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The RutOS ubus /gps/position/status endpoint returns latitude,
longitude, and altitude as strings (e.g. "44.817068", "156.4"). The
integration was passing them straight into homeassistant.set_location,
where `int(round(altitude))` raised a TypeError ("type str doesn't
define __round__ method"). The exception was swallowed by the
async_create_task scheduler, so set_location never ran and zone.home
never moved — the visible symptom of issue #28.
Coerce all three fields to floats inside the listener before scheduling
the apply task, so _async_apply_home_location can rely on numeric
inputs. Drop the debug breadcrumbs now that the failure mode is
understood.
Add a regression test that mocks the router's all-strings GPS response
and asserts the dispatched service_data contains float lat/lon and int
elevation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
crbn60
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #28. With "Update Home Assistant home location from GPS" enabled,
zone.homenever moved to the router's reported GPS position.Root cause
Discovered by wiring diagnostic logging through
_async_apply_home_locationand watching it run against a live HA 2026.4.2 instance: the RutOS ubus/gps/position/statusendpoint returnslatitude,longitude, andaltitudeas strings (e.g."44.817068","156.4"). The integration was passing them straight intohomeassistant.set_location, whereint(round(altitude))raisedTypeError: type str doesn't define __round__ method. The exception was raised inside a coroutine scheduled viahass.async_create_taskand never surfaced under thecustom_components.rutoslogger, so users (and earlier diagnostic passes) saw only the symptom —zone.homefrozen at its last persisted value.This bug predates PR #32; the same uncast-altitude code exists on
dev. Two earlier theories were investigated and ruled out:zone.homeskipscore_config_updated— wrong for modern HA.homeassistant.set_locationpropagates to editable zones on 2026.4+; verified by direct service calls.elevationmust be an int — true but not the whole story. Even after casting toint, the cast itself raised on string input before reaching the service call.Fix
custom_components/rutos/__init__.py: inside_update_home_location, coercelatitude,longitude, andaltitudetofloatbefore scheduling_async_apply_home_location. If lat/lon fail to parse the listener returns silently; if altitude fails,elevationis omitted from the service call._async_apply_home_locationthen stays simple: it doesint(round(altitude))knowing the input is numeric.The belt-and-suspenders storage-collection update path (
_async_update_stored_home_zone) is kept — it is a no-op on HA 2026.4+ but guards older releases where stored zones may not followcore_config_updated.Changes
custom_components/rutos/__init__.py: float-coerce router GPS strings at the listener boundary before the service call.tests/test_home_location.py: addtest_string_valued_router_gps_is_coerced— mocks the router returning all-string GPS fields and assertsset_locationis called withfloatlatitude/longitude andintelevation.Verification on live HA
zone.homestuck at manually set test coordinates; integration listener fires every ~30 s but service call never runs.zone.homeattributes arelatitude: 44.817068, longitude: -76.23063— matches the router; zerorutoslog entries at any level; person entities correctly resolve tohomebecause the zone is now where the router is.Test plan
.venv/bin/python -m pytest tests/— 187 passed.venv/bin/ruff check custom_components/rutos/🤖 Generated with Claude Code