Skip to content

Add skip_assistant_name option to the send service#31

Open
kauelima wants to merge 3 commits into
jumping2000:mainfrom
kauelima:main
Open

Add skip_assistant_name option to the send service#31
kauelima wants to merge 3 commits into
jumping2000:mainfrom
kauelima:main

Conversation

@kauelima

@kauelima kauelima commented Jul 7, 2026

Copy link
Copy Markdown

Description

Adds an optional skip_assistant_name boolean to the universal_notifier.send service. When true, the assistant name is omitted from the visual prefix:

Flags Result
none (default) [Assistant - 10:00] Greeting. Message (unchanged)
skip_assistant_name: true [10:00] Greeting. Message
+ include_time: false + skip_greeting: true Message

When the prefix is empty, no brackets or leading space are emitted — this also fixes the [ - 10:00] artifact when the configured assistant name is empty. Voice/TTS and command_* messages are unaffected.

Changes: new constant in const.py, schema + handler + prefix logic in __init__.py, new field in services.yaml, 3 new tests, service field tables in README.md/README_IT.md, and a CHANGELOG.md entry.

Motivation and Context

There is no way to send a notification without the [Assistant Name] prefix — the name can be overridden but never removed, so mobile notifications always arrive as e.g. [Home Assistant] Good Morning. Your house is flooding. This adds the missing flag, matching the existing skip_greeting / include_time options.

How has this been tested?

  • 3 new tests in tests/test_init.py covering: name removed with time kept, fully bare message (all flags), and name removed from the title prefix
  • Full suite via the project's Docker test-runner: 126 passed, existing prefix/greeting/title tests unchanged
  • Manual tests overriding the files in a Home Assistant instance to test the UI configuration and notification sent (tested on an Android companion app)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Other

Checklist

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly. (did my best in Italian readme)

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.

1 participant