homebridge / homebridge/plugins
Verification Request: homebridge-anthemreceiver-plus
Nobody has claimed this yet.
- 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)
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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