Repository files navigation

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 thedeveloper documentation. A full list of all supported service types, and their characteristics is available on this site.

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

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

• ESLint

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

npm install

Open thepackage.json and change the following attributes:

• name - this should be prefixed withhomebridge- 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'sREADME.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 setprivate to false, or remove the attribute entirely.

Open thesrc/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 Homebridgeconfig.json.
• PLUGIN_NAME - Set this to be the same name you set in thepackage.json file.

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

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

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

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

npm run build

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

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 thenodemon.json file.

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 thedeveloper 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 thePlugin Config Schema Documentation.

Given a version numberMAJOR.MINOR.PATCH, such as1.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 thenpm version command to help you with this:

# major update / breaking changesnpm version major# minor update / new featuresnpm version update# patch / bugfixesnpm version patch

When you are ready to publish your plugin tonpm, make sure you have removed theprivate attribute from thepackage.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.

You can publishbeta 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 @betanpm publish --tag beta

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

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

Consider creating your plugin with theHomebridge 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 foundhere.For reference, the current criteria are:

• General
  • The plugin must be of typedynamic platform.
  • The plugin must not offer the same nor less functionality than that of any existingverified 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 allsupported 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 theHomebridge 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.

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

• Custom Characteristics