ESPHome Buttons

Expose ESPHome device buttons as HomeKit switches. By default one accessory per button so each shows its correct name in Home (e.g. “Fan on/off (mainbedroom)”). Optionally use one “remote” per device (grouped) — the Home app may then show the same name for every control. Fire-and-forget: only turning a switch On triggers the button; turning it Off does nothing. No state is read back from the device.

ESPHome setup

1. Enable the web server on your ESPHome device (you already have web_server: in your YAML).

2. Give each button a stable id so the plugin can call it. The plugin calls POST {baseUrl}/button/{id}/press.

   In your ESPHome YAML, add an id to each template button, for example:

   button:
     - platform: template
       name: 'Fan on/off'
       id: fan_on_off # use this id in Homebridge config
       on_press:
         - remote_transmitter.transmit_rc_switch_raw: ...

   If you don’t set id, ESPHome generates one from the name (e.g. "Fan on/off" → fan-on-off). You can find the generated id in the device’s web UI or by listing the buttons.

3. In Homebridge, add the ESPHome Buttons platform and list your devices and buttons (see example below).

Homebridge config example

Based on your mainbedroom.yaml, you can configure the platform like this:

{
  "platform": "BetterHttpRemote",
  "name": "ESPHome Buttons",
  "devices": [
    {
      "name": "Main Bedroom",
      "baseUrl": "http://mainbedroom.local",
      "buttons": [
        { "name": "Fan on/off", "id": "fan_on_off" },
        { "name": "Light on/off", "id": "light_on_off" },
        { "name": "Brighter lights", "id": "brighter_lights" },
        { "name": "Lower lights", "id": "lower_lights" },
        { "name": "Fan speed 1", "id": "fan_speed_1" },
        { "name": "Fan speed 2", "id": "fan_speed_2" },
        { "name": "Fan speed 3", "id": "fan_speed_3" }
      ]
    }
  ]
}

Use your device’s hostname (e.g. mainbedroom.local) or IP as baseUrl. Each device becomes one HomeKit accessory (e.g. “Main Bedroom Remote”) with all its buttons as toggles inside; turning a toggle on triggers that button on the device (fire-and-forget).

Discover all ESPHome devices on the network (no baseUrl needed)

You can skip listing devices and baseUrls entirely. Set discoverDevicesOnNetwork: true and the plugin will find all ESPHome devices on your LAN via mDNS (they advertise _esphomelib._tcp), then discover buttons from each device:

{
  "platform": "BetterHttpRemote",
  "name": "ESPHome Buttons",
  "discoverDevicesOnNetwork": true
}

Homebridge must run on the same network as the ESPHome devices. You can still add a devices array; discovered and manual devices are merged. Each discovered device uses discoverButtons: true so buttons are also auto-discovered.

Auto-discover buttons (per device)

Set discoverButtons: true on a device and omit buttons to have the plugin discover all button entities from the device at startup (via its /events stream). The device must be reachable when Homebridge starts. Example:

{
  "name": "Main Bedroom",
  "baseUrl": "http://mainbedroom.local",
  "discoverButtons": true
}

You can still set buttons manually for full control; discovery is for convenience when you want all buttons with default settings.

One tile (digital remote) vs many tiles

• Default (singleRemotePerDevice: false): One HomeKit accessory per button. Each button is its own tile in the room (e.g. “Fan on/off (mainbedroom)”, “Brighter lights (mainbedroom)”). Clear names, but many tiles.
• singleRemotePerDevice: true: One tile per device. Tap it to open a detail view with all buttons inside—like a digital remote. Keeps the room view clean.

To get a single tile (e.g. “Ceiling Fan”) that opens to all fan and light controls:

1. Set singleRemotePerDevice: true in the platform config.
2. Optionally set accessoryName on the device (e.g. "Ceiling Fan") so the tile shows that name instead of “{Device Name} Remote”.

Example: one “Ceiling Fan” tile in Master Bedroom that opens to Fan on/off, Fan reverse, Fan speeds, Brighter/Lower lights, etc.:

{
  "platform": "BetterHttpRemote",
  "name": "ESPHome Buttons",
  "singleRemotePerDevice": true,
  "devices": [
    {
      "name": "Main Bedroom",
      "accessoryName": "Ceiling Fan",
      "baseUrl": "http://mainbedroom.local",
      "discoverButtons": true
    }
  ]
}

After changing to singleRemotePerDevice: true or editing accessoryName, restart Homebridge. You may need to remove the old accessories from the Home app and re-add the bridge (or let the plugin re-register) so the single tile appears correctly.

Button labels in the single-remote view: The plugin sets ConfiguredName on each Switch service so the Home app shows each button's real name (e.g. "Fan on/off", "Brighter lights") instead of the accessory name. This requires iOS 17 or later. On older iOS, the Home app may show the accessory name for every row; long-press a control, open Settings, clear the name, accept the suggested name, and tap Done.

Important: After switching to singleRemotePerDevice or changing button names, you may need to remove the accessory from the Home app and re-pair the bridge so that ConfiguredName values are picked up fresh. Cached accessories keep their old names.

Button vs switch (control type)

HomeKit only exposes Switch for “tap in app → trigger,” so both styles use a Switch in the Home app. You choose the behavior:

• controlType: "button" (default) – Momentary: fire-and-forget, single press, switch resets to Off. Good for toggles and one-shot actions.
• controlType: "switch" – Toggle: switch can stay On, optional hold-to-repeat; turning Off does not send a second press.

You can set controlType at the platform (default for all), per device, or per button. Example: one button as switch for hold-to-repeat brightness, rest as momentary:

{
  "platform": "BetterHttpRemote",
  "name": "ESPHome Buttons",
  "controlType": "button",
  "devices": [
    {
      "name": "Main Bedroom",
      "baseUrl": "http://mainbedroom.local",
      "buttons": [
        { "name": "Fan on/off", "id": "fan_on_off" },
        { "name": "Brighter lights", "id": "brighter_lights", "controlType": "switch", "repeatIntervalMs": 200 },
        { "name": "Lower lights", "id": "lower_lights" }
      ]
    }
  ]
}

With discoverButtons: true, all discovered buttons use the platform/device controlType default. When you list buttons manually (no discovery), you can set controlType and repeatIntervalMs per button as in the example.

Fire and forget (default: on)

By default, each switch resets to Off after a press and turning it Off does nothing (no second trigger). Set fireAndForget: false in the platform config if you prefer the switch to stay On until you turn it Off yourself (turning Off still does not send a second press). When using controlType: "button", fire-and-forget is always on for that control unless you override with fireAndForget per button.

Hold to repeat (brightness, fan speed, etc.)

For buttons you want to "hold" (e.g. brighter / dimmer, fan speed), the switch stays on while you hold it and sends repeated presses at an interval:

• Platform: repeatIntervalMs (default 250) – how often (ms) to send a press while the switch is on. Set to 0 for single-press only.
• Per button: repeatIntervalMs – override (e.g. 0 for toggles, 200 for brightness).

Turn the switch on to start (one press + repeat); turn it off to stop. With repeatIntervalMs: 0, a quick tap sends one press and the switch resets to off.

Testing on another server (remote Homebridge)

To run this plugin on a different machine than where you develop:

1. Build and pack on your dev machine

cd /path/to/homebridge-esphome-buttons
npm run build
npm pack

This creates a file like homebridge-esphome-buttons-1.0.0.tgz.

2. Copy the tarball to the server

Use scp, SFTP, or any copy method, e.g.:

scp homebridge-esphome-buttons-1.0.0.tgz user@your-homebridge-server:~/

3. Install the plugin on the server

SSH into the server, then install the plugin globally (so the global Homebridge can load it):

ssh user@your-homebridge-server
sudo npm install -g ./homebridge-esphome-buttons-1.0.0.tgz

If your Homebridge runs as a user (e.g. hb-ui or your own user) and uses a global Homebridge:

npm install -g ./homebridge-esphome-buttons-1.0.0.tgz

(Use the same user that runs Homebridge, and omit sudo if you use a user-level Node/npm.)

4. Add the platform to Homebridge config

On the server, edit the Homebridge config (often ~/.homebridge/config.json or under /var/lib/homebridge if you use the service). Add a platform block like:

{
  "platform": "BetterHttpRemote",
  "name": "ESPHome Buttons",
  "devices": [
    {
      "name": "Main Bedroom",
      "baseUrl": "http://mainbedroom.local",
      "buttons": [
        { "name": "Fan on/off", "id": "fan_on_off" },
        { "name": "Brighter lights", "id": "brighter_lights" }
      ]
    }
  ]
}

Use the server’s hostname or the ESPHome device’s IP if mainbedroom.local doesn’t resolve from the server (e.g. http://192.168.1.20).

5. Restart Homebridge

Restart the Homebridge process (service, Docker, or homebridge -D), then in the Home app the new switches should appear.

Tip: After code changes, run npm run build and npm pack again, copy the new .tgz to the server, and re-run the install command (same path); then restart Homebridge to pick up the new build.

Publishing to npm (so others can install it)

To have your plugin installable like any other Homebridge plugin (from the Homebridge UI or npm install -g homebridge-esphome-buttons):

1. Before first publish

• npm account: Create one at npmjs.com if you don’t have it.
• package.json: Set author to your name or "Your Name <[email protected]>" (homepage/repository/bugs URLs are already set for this repo).
• GitHub: Ensure the repo is pushed to GitHub so the package links work.

2. Publish to npm

From the project root:

npm run lint          # must pass
npm run build         # builds dist/
npm login             # log in to npm (one-time or when session expires)
npm publish          # publishes; runs prepublishOnly (lint + build) first

• The first time you publish, the package name homebridge-esphome-buttons will be created on npm (it must be unused).
• After that, only you can publish new versions of this package (same npm user).

3. Installing the published plugin

Once published, anyone (including you) can install it like other plugins:

• Homebridge UI: Plugins → search for “ESPHome Buttons” or “homebridge-esphome-buttons” and install.
• CLI:

  npm install -g homebridge-esphome-buttons

Then add the BetterHttpRemote platform to the Homebridge config (see config example above) and restart Homebridge.

4. Releasing updates

Bump the version, then publish again:

npm version patch   # 1.0.0 → 1.0.1 (or minor/major)
npm publish

5. Automatic publish from GitHub (optional)

A Publish to npm workflow runs when code is pushed to the latest branch. It runs lint, build, then npm publish.

• Repo secret: In the repo settings, add a secret NPM_TOKEN with an npm access token (use “Automation” type for CI).
• To release: Bump the version in package.json (e.g. npm version patch), push to latest; the workflow will publish that version to npm. If the version was already published, the job will fail (reminder to bump again).

Homebridge Platform Plugin Template (development)

[!IMPORTANT] Homebridge v2.0 Information

This template currently has a

• package.json -> engines.homebridge value of "^1.8.0 || ^2.0.0-beta.0"
• package.json -> devDependencies.homebridge value of "^2.0.0-beta.0"

This is to ensure that your plugin will build and run on both Homebridge v1 and v2.

Once Homebridge v2.0 has been released, you can remove the -beta.0 in both places.

This is a template Homebridge dynamic platform plugin and can be used as a base to help you get started developing your own plugin.

This template should be used in conjunction with the developer documentation. A full list of all supported service types, and their characteristics is available on this site.

Clone As Template

Click the link below to create a new GitHub Repository using this template, or click the Use This Template button above.

Create New Repository From Template

Setup Development Environment

To develop Homebridge plugins you must have Node.js 20 or later installed, and a modern code editor such as VS Code. This plugin template uses TypeScript to make development easier and comes with pre-configured settings for VS Code and ESLint. If you are using VS Code install these extensions:

• ESLint

Install Development Dependencies

Using a terminal, navigate to the project folder and run this command to install the development dependencies:

npm install

Update package.json

Open the package.json and change the following attributes:

• name - this should be prefixed with homebridge- or @username/homebridge-, is case-sensitive, and contains no spaces nor special characters apart from a dash -
• displayName - this is the "nice" name displayed in the Homebridge UI
• homepage - link to your GitHub repo's README.md
• repository.url - link to your GitHub repo
• bugs.url - link to your GitHub repo issues page

When you are ready to publish the plugin you should set private to false, or remove the attribute entirely.

Update Plugin Defaults

Open the src/settings.ts file and change the default values:

• PLATFORM_NAME - Set this to be the name of your platform. This is the name of the platform that users will use to register the plugin in the Homebridge config.json.
• PLUGIN_NAME - Set this to be the same name you set in the package.json file.

Open the config.schema.json file and change the following attribute:

• pluginAlias - set this to match the PLATFORM_NAME you defined in the previous step.

See the Homebridge API docs for more details on the other attributes you can set in the config.schema.json file.

Build Plugin

TypeScript needs to be compiled into JavaScript before it can run. The following command will compile the contents of your src directory and put the resulting code into the dist folder.

npm run build

Link To Homebridge

Run this command so your global installation of Homebridge can discover the plugin in your development environment:

npm link

You can now start Homebridge, use the -D flag, so you can see debug log messages in your plugin:

homebridge -D

Watch For Changes and Build Automatically

If you want to have your code compile automatically as you make changes, and restart Homebridge automatically between changes, you first need to add your plugin as a platform in ./test/hbConfig/config.json:

{
...
    "platforms": [
        {
            "name": "Config",
            "port": 8581,
            "platform": "config"
        },
        {
            "name": "<PLUGIN_NAME>",
            //... any other options, as listed in config.schema.json ...
            "platform": "<PLATFORM_NAME>"
        }
    ]
}

and then you can run:

npm run watch

This will launch an instance of Homebridge in debug mode which will restart every time you make a change to the source code. It will load the config stored in the default location under ~/.homebridge. You may need to stop other running instances of Homebridge while using this command to prevent conflicts. You can adjust the Homebridge startup command in the nodemon.json file.

Customise Plugin

You can now start customising the plugin template to suit your requirements.

• src/platform.ts - this is where your device setup and discovery should go.
• src/platformAccessory.ts - this is where your accessory control logic should go, you can rename or create multiple instances of this file for each accessory type you need to implement as part of your platform plugin. You can refer to the developer documentation to see what characteristics you need to implement for each service type.
• config.schema.json - update the config schema to match the config you expect from the user. See the Plugin Config Schema Documentation.

Versioning Your Plugin

Given a version number MAJOR.MINOR.PATCH, such as 1.4.3, increment the:

1. MAJOR version when you make breaking changes to your plugin,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

You can use the npm version command to help you with this:

# major update / breaking changes
npm version major

# minor update / new features
npm version update

# patch / bugfixes
npm version patch

Publish Package

When you are ready to publish your plugin to npm, make sure you have removed the private attribute from the package.json file then run:

npm publish

If you are publishing a scoped plugin, i.e. @username/homebridge-xxx you will need to add --access=public to command the first time you publish.

Publishing Beta Versions

You can publish beta versions of your plugin for other users to test before you release it to everyone.

# create a new pre-release version (eg. 2.1.0-beta.1)
npm version prepatch --preid beta

# publish to @beta
npm publish --tag beta

Users can then install the beta version by appending @beta to the install command, for example:

sudo npm install -g homebridge-example-plugin@beta

Best Practices

Consider creating your plugin with the Homebridge Verified criteria in mind. This will help you to create a plugin that is easy to use and works well with Homebridge. You can then submit your plugin to the Homebridge Verified list for review. The most up-to-date criteria can be found here. For reference, the current criteria are:

• General
  • The plugin must be of type dynamic platform.
  • The plugin must not offer the same nor less functionality than that of any existing verified plugin.
• Repo
  • The plugin must be published to NPM and the source code available on a GitHub repository, with issues enabled.
  • A GitHub release should be created for every new version of your plugin, with release notes.
• Environment
  • The plugin must run on all supported LTS versions of Node.js, at the time of writing this is Node v18, v20 and v22.
  • The plugin must successfully install and not start unless it is configured.
  • The plugin must not execute post-install scripts that modify the users' system in any way.
  • The plugin must not require the user to run Homebridge in a TTY or with non-standard startup parameters, even for initial configuration.
• Codebase
  • The plugin must implement the Homebridge Plugin Settings GUI.
  • The plugin must not contain any analytics or calls that enable you to track the user.
  • If the plugin needs to write files to disk (cache, keys, etc.), it must store them inside the Homebridge storage directory.
  • The plugin must not throw unhandled exceptions, the plugin must catch and log its own errors.

Useful Links

Note these links are here for help but are not supported/verified by the Homebridge team

• Custom Characteristics