feat(homeassistant): split tool vs platform env vars#29199
Open
StartupBros wants to merge 1 commit into
Open
Conversation
Collaborator
Today HASS_TOKEN / HASS_URL configure BOTH: - the HA tool surface (skill calls into HA REST API) - the gateway's websocket platform (persistent notifications back to HA) Fine for the default single-target setup, but blocks operators who want: - a tool-only setup (websocket intentionally disabled) - the tool surface and the notification surface pointing at different HA instances (local proxy for tools, remote endpoint for notifications, or vice versa) Backward-compatible defaults: - HASS_TOKEN / HASS_URL still work and still configure both surfaces — existing deployments unchanged - HASS_TOOL_TOKEN / HASS_TOOL_URL override the tool surface only - HASS_PLATFORM_TOKEN / HASS_PLATFORM_URL override the websocket only - HASS_PLATFORM_DISABLE=1 suppresses websocket startup entirely Surface coverage: - gateway/config.py — env override reads PLATFORM_* with TOKEN/URL fallback - gateway/platforms/homeassistant.py — adapter prefers PLATFORM_* - tools/homeassistant_tool.py — tool prefers TOOL_* - tools/send_message_tool.py — notify path prefers TOOL_* - hermes_cli/dump.py — diagnostics treat any of the 3 token vars as present - hermes_cli/setup.py — setup summary treats any of the 3 token vars as present - tools/environments/local.py — sandboxed tool env propagation includes new vars - tests/conftest.py — test env scrub includes new token vars - hermes_cli/tools_config.py — wizard prompt keeps the single-target default but documents the split for advanced operators Tests: 139 HA tests pass; new coverage in test_homeassistant.py (env-split + HASS_PLATFORM_DISABLE), test_homeassistant_tool.py (TestGetConfig), test_send_message_missing_platforms.py (test_tool_env_var_fallback).
2372c58 to
d7f266e
Compare
This was referenced May 20, 2026
Author
|
Status re: @alt-glitch's note above: #21676 closed in favor of this. This PR covers 6 touchpoints #21676 missed: |
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
2 participants
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.
Split out from the original combined PR per CONTRIBUTING.md ("one logical change per PR"). The websocket connection-lifecycle fixes that were bundled here previously will land as a separate PR.
Problem
Today
HASS_TOKEN/HASS_URLconfigure BOTH:tools/homeassistant_tool.py)gateway/platforms/homeassistant.py)Fine for the default single-target setup, but blocks operators who want:
Solution — backward-compatible env split
HASS_TOKEN/HASS_URLHASS_TOOL_TOKEN/HASS_TOOL_URLHASS_PLATFORM_TOKEN/HASS_PLATFORM_URLHASS_PLATFORM_DISABLE=1Surface coverage (every HA env-var touchpoint)
The original split-only PR only updated the adapter + tool readers and missed every consumer that maps the env to something downstream. This revision covers them all:
gateway/config.py— env-override reader prefersHASS_PLATFORM_*withHASS_*fallback;HASS_PLATFORM_DISABLEhonoredgateway/platforms/homeassistant.py— adapter reads PLATFORM tokens firstgateway/run.py— startup warning string lists all three accepted token varstools/homeassistant_tool.py— REST tool prefersHASS_TOOL_*tools/send_message_tool.py—_send_homeassistantnotify path prefersHASS_TOOL_*hermes_cli/dump.py— diagnostics report HA as "present" if any of the three token vars is sethermes_cli/setup.py— setup-status summary treats any of the three as presenthermes_cli/tools_config.py— wizard keeps single-targetHASS_TOKEN/HASS_URLprompts (advanced operators set the new vars in~/.hermes/.envdirectly; documented in the wizard schema)tools/environments/local.py— sandboxed-tool env propagation list includes all 5 new var names so they reach child processestests/conftest.py— test env scrub includes the new token vars so cross-test leakage stays preventedTest plan
All 139 HA-related tests pass:
tests/gateway/test_homeassistant.py— new tests:test_returns_true_with_platform_token,test_platform_disable_skips_ha_platform,test_platform_specific_env_overrides_shared_values; existingtest_no_env_no_platformupdated to scrub the new vars tootests/tools/test_homeassistant_tool.py— newTestGetConfigclass covers tool-specific precedence and legacy fallback;test_available_with_tool_specific_tokenaddedtests/tools/test_send_message_missing_platforms.py— newtest_tool_env_var_fallbackcovers the notify pathManual:
HASS_TOKEN=... HASS_PLATFORM_DISABLE=1→ tool available, websocket platform not startedHASS_TOOL_TOKEN=A HASS_PLATFORM_TOKEN=B→ tool uses A, websocket uses BHASS_TOKENset → behavior unchanged (backward compat)