Skip to content

feat(satellite): prioritize service-specific configuration files#442

Open
Bluscream wants to merge 2 commits into
hass-agent:development-2.2.1from
Bluscream:feat/service-specific-sensors-commands
Open

feat(satellite): prioritize service-specific configuration files#442
Bluscream wants to merge 2 commits into
hass-agent:development-2.2.1from
Bluscream:feat/service-specific-sensors-commands

Conversation

@Bluscream

Copy link
Copy Markdown

This PR introduces support for service-specific configuration files (servicecommands.json and servicesensors.json) in the Satellite Service. If these files exist in the config directory, the service will prioritize them over the standard global configuration files. This allows for dedicated service configurations without impacting the main HASS.Agent UI-managed entities.

Additionally, this PR includes the NullReferenceException fixes for unknown entity types (previously submitted in #441), ensuring the service remains stable when skipping unsupported entities.

…avoids a NullReferenceException when the Satellite Service encounters unsupported entity types (e.g. WebViewCommand, Bluetooth sensors) that aren't available in the headless service context.
…ite Service will now try to load 'servicecommands.json' and 'servicesensors.json' before falling back to the standard 'commands.json' and 'sensors.json' files. This allows for service-specific configurations without affecting the global HASS.Agent UI-managed configs.
@amadeo-alex amadeo-alex changed the base branch from main to development-2.2.1 March 22, 2026 11:05
@amadeo-alex

Copy link
Copy Markdown
Collaborator

Hmm, the satellite service already has it's own configuration files in the "programfiles/config" directory i.e. separate from the client's configuration.
What's the use case for this? (unless I'm missing something, then eli5 please :D)

@Bluscream

Bluscream commented Mar 22, 2026

Copy link
Copy Markdown
Author

i symlink the two config dirs together because its more tidy and gives me a single source/target for backups without having to untangle the configs (ended up with satellite sensors in my agent and vice versa more than once) also when sharing configs (or backing up) makes it just so much easier to know whats what without having to open the files and guess based on content

@amadeo-alex

Copy link
Copy Markdown
Collaborator

Hmm, this is definitely not a standard use-case scenario :D
Which doesn't mean I'm against merging it, why not.

We need to make it more verbose and direct to the user that this kind of "override" happens tho.

I'll drop a few review comments in the next days if you don't mind. Once the changes are implemented I'll merge the PR.
In the meantime if you'd like to have your own go at the changes, the two main points are:

  • the files' names need to be in your face that they override the default ones ("override-commands.json" or something along those lines)
  • there needs to be a warning log printed to the logs if those files (for all files) to notify user that the default configuration has been ignored due to the presence of the override files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants