homebridge / homebridge/plugins

Verification Request: homebridge-anthemreceiver-plus

Open
#1,220 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

awaiting-final-review request-verification
Dominant language
TypeScript
Stars
369
Forks
24
PR merge metrics
No merged PRs in 30d

Description

Plugin Name

homebridge-anthemreceiver-plus

Link To GitHub Repo

https://github.com/pponce/homebridge-anthemreceiver-plus

Plugin Icon (Optional)
Image
The plugin does not offer the same nor less functionality than that of any existing verified plugin.

🟢 Yes

The plugin successfully installs and does not start unless it is configured.

🟢 Yes

The plugin does not require the user to run Homebridge in a TTY or with non-standard startup parameters, even for initial configuration.

🟢 Yes

The plugin does not contain any analytics or calls that enable you to track the user.

🟢 Yes

If the plugin needs to write files to disk (cache, keys, etc.), it stores them inside the Homebridge storage directory.

🟢 Yes

The plugin does not throw unhandled exceptions, the plugin must catch and log its own errors.

🟢 Yes

More Information

Thank you for reviewing [homebridge-anthemreceiver-plus](https://github.com/pponce/homebridge-anthemreceiver-plus). This is a verification request for my independently maintained plugin, which builds on the existing verified homebridge-anthemreceiver project.

The original project provided the foundation for this work, and its attribution and license have been preserved. Its latest default-branch commit is from October 2023, while issues and pull requests remain open, including a request for SLM support. I developed Plus to improve reliability and add functionality.

The original maintainer has not formally announced that the project is discontinued. I am not claiming to be its appointed successor or requesting ownership of the original repository or npm package. I maintain the separate Plus project and am requesting verification for that package.

Compared with the original verified plugin, Plus includes:

  • Configurable HomeKit volume mapping based on a maximum volume in dB.
  • A dedicated, receiver-confirmed None selection for Audio Listening Mode.
  • A custom configuration UI with connection testing, receiver information, and diagnostic reports for troubleshooting and investigating additional Anthem hardware.
  • MRX SLM support with single-zone handling and input-name decoding.
  • Separate experimental STR Preamplifier and Integrated Amplifier profiles, with model-specific volume handling and restricted commands. Physical STR validation is still needed, and that limitation is clearly documented.
  • Improved TCP reply buffering, connection recovery, command confirmation, and input-service reconciliation.
  • Automated checks covering Node.js 22/24, Homebridge 1/2, receiver simulations, configuration UI behavior, packaging, and migration.

I recognize that maintenance and stability improvements alone may not establish different functionality. The additional controls, volume mapping, diagnostics, and hardware profiles are the substantive extensions I’m asking the team to consider.

I also want to explicitly disclose that Plus retains AnthemReceiver as its platform name. The npm package and registered plugin identifier are distinct: homebridge-anthemreceiver-plus.

Retaining the platform name was an intentional compatibility decision. Together with preserving accessory identifiers and bridge configuration, it allows existing users to replace the package while retaining their configuration and supporting Homebridge’s reassociation of cached accessories. I successfully migrated my own MRX 540 8K installation without rebuilding scenes or automations, and automated migration tests cover identity preservation for both main-bridge and child-bridge configurations.

The [migration instructions](https://github.com/pponce/homebridge-anthemreceiver-plus/blob/main/MIGRATION.md) explain that users must replace the original package and run only Plus. Retaining the platform name does not imply endorsement by the original maintainer or an automatic transfer of the original verification badge.

This is my first time requesting verification for a separately maintained plugin that retains an existing platform name. What would be the best way to proceed? Would the team consider verifying Plus with AnthemReceiver retained for migration compatibility? How would you prefer to handle the overlap with the existing verified plugin—separate verification, consideration as a replacement on the verified list, or another approach?

I’m happy to provide additional testing evidence or make changes based on your guidance. Thank you for your time and for maintaining the verification program.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the verification request and the linked MIGRATION.md, then review the stated differences from homebridge-anthemreceiver and the migration constraints. Done means the verification team has decided how to handle the retained AnthemReceiver platform name and the plugin's relationship to the existing verified project.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
developer-experience, release
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.