Bump pysignalclirestapi to 0.3.24

[r-xyz]

pysignalclirestapi v0.3.24 enables "text_mode" for the Signal Messenger integration.

Changelog: https://github.com/bbernhard/pysignalclirestapi/compare/0.3.23...0.3.24

Breaking change

Proposed change

Type of change

• [x] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New integration (thank you!)
• [ ] New feature (which adds functionality to an existing integration)
• [ ] Deprecation (breaking change to happen in the future)
• [ ] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [ ] The code has been formatted using Ruff (ruff format homeassistant tests)
• [ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [x] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [x] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [x] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• [ ] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

Hey there @bbernhard, mind taking a look at this pull request as it has been labeled with an integration (signal_messenger) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of signal_messenger can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign signal_messenger Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[bbernhard]

Are you sure that those changes are enough? I think for the text_mode parameter to work, there are also changes in the signal integration needed.

[r-xyz]

@bbernhard thanks for the heads up, I ran the local tests but I could not double check with a real instance. After a more in depth look, you are right, code should be modified for the additional parameter to be passed. Will update as soon as I can get to my workstation.

[r-xyz]

@bbernhard I added the parameter in notify.py. Could you please have a look if it makes sense? Thank you.

I followed the example of other additional parameters, though I am wondering if it could be moved to the main data structure: from

action:
  service: notify.NOTIFIER_NAME
  data:
    message: "Test **message**"
    data:
      text_mode: "styled"

to

action:
  service: notify.NOTIFIER_NAME
  data:
    message: "Test **message**"
    text_mode: "styled"

[bbernhard]

Thanks for the PR!

I followed the example of other additional parameters, though I am wondering if it could be moved to the main data structure.

good question. Personally I do not have a preference - both is fine for me. But not sure if the Home Assistant core team has some guidelines for that.

[r-xyz]

@bbernhard In order to add text_mode parameter to DATA_SCHEMA , I had to redefine the schema.

Currently the main "breaking" change would be for url-defined attachments:

• from:

action:
  service: notify.NOTIFIER_NAME
  data:
    message: "Person detected on Front Camera!"
    data:
      verify_ssl: false
      urls:
        - "http://homeassistant.local/api/frigate/notifications/<event-id>/thumbnail.jpg"

• to

action:
  service: notify.NOTIFIER_NAME
  data:
    message: "Person detected on Front Camera!"
    data:
      urls:
        verify_ssl: false
        urls:
          - "http://homeassistant.local/api/frigate/notifications/<event-id>/thumbnail.jpg"

If that is ok from your side, I will add some additional tests for text_mode and mark for review. Alternatively, data could be restructured as follows:

• for filenames:

data:
  attachments:
    filenames:
      -  "/config/www/surveillance_camera.jpg"

• for urls:

data:
  attachements:
    verify_ssl: false
    urls:
      - "http://homeassistant.local/api/frigate/notifications/<event-id>/thumbnail.jpg"

[bbernhard]

Thanks a lot for the update @r-xyz!

I am not sure if I am qualified to answer that, as I do not know how the Home Assistant core team sees breaking changes. Personally, from the perspective of a simple Home Assistant user, I am not a big fan of breaking changes, as they require me to actively change something to get the existing behavior working again. From the perspective of a maintainer of other open source projects, I am not a big fan either, as breaking changes usually result in quite some follow up issues (e.g "Why doesn't this work anymore?").

But I can see that they are sometimes necessary to clean up technical debt. I know that in the early days of Home Assistant, breaking changes occurred quite often and one had to fix stuff manually after almost every release (at least that's how it felt). Due to shortage of free time however, I am not following the Home Assistant development in detail anymore, so I do not know what their stance on breaking changes is. Mabye someone from the Core team can chime in here.

Although personally I am not in favor of breaking changes, I am totally fine with it in case the Core team is fine with it :)

[r-xyz]

Hi @bbernhard, Thanks for the useful feedback. I agree it might be better to avoid breaking changes unless they might be needed in the future. I found a way to modify DATA_SCHEMA definition so it is compatible with previous one. I also added a test for styled mode. Please let me know if I shall also duplicate tests with successful attachment of file/urls for text_mode = 'styled'. After I receive feedback, I will submit a PR for docs and mark both for review by maintainers. PS: the PR was tested and works correctly as custom component.

[bbernhard]

Many thanks for working around the breaking change - very much appreciated!

From my side the extension looks good! :heavy_check_mark:

Thanks a lot for for working on this - this will make quite some Home Assistant users happy :)

[r-xyz]

Added additional tests and docs. The only currently failing pipeline appear to be unrelated (please check logs).

[r-xyz]

has-tests and new-feature tags were be added automatically since PR was initially opened without.

[r-xyz]

@frenck Please let me know in case additional changes are needed.

[r-xyz]

Improved exception handling, codecov is now also fully passed. It only needs approving review.

[home-assistant[bot]]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:

Learn more about our pull request process.

[r-xyz]

Requested changes were implemented. One test needed to be modified, too, since invalid text_mode attribute now gives error instead of defaulting to "normal" with warning (previous behaviour).