npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

homebridge-python-plugin

v1.0.2

Published

This plugin enables the execution of python scripts for different devices.

Readme

Homebridge Python Plugin

[!IMPORTANT] This plugin supports Node.js 22 and 24 and is intended to run with Homebridge v1.8 or later, including Homebridge v2.


This plugin exposes values returned by Python scripts as temperature or light sensors in Homebridge. Each script must print a numeric value to standard output.

Configuration

Pass script arguments separately with scriptArgs:

{
  "platform": "SensorPlatform",
  "name": "Sensor Platform",
  "sensors": [
    {
      "name": "Outdoor Temperature",
      "type": "temperature",
      "scriptPath": "/var/lib/homebridge/luxorliving/temperature.py",
      "scriptArgs": ["4"],
      "interval": 60
    }
  ]
}

For backwards compatibility, version 1.0.2 and later also accept the previous form "scriptPath": "/var/lib/homebridge/luxorliving/temperature.py 4". New configurations should use scriptArgs, especially when paths or arguments contain spaces.

Setup Development Environment

To develop Homebridge plugins you must have Node.js 22 or 24 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:

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

Verify Plugin Compatibility

Run the complete local verification before opening a pull request or publishing:

npm run check

This lints and builds the plugin, runs registration and Homebridge startup smoke tests, and verifies the npm package contents. CI repeats these checks with Node.js 22 and 24 against Homebridge 1 and 2.

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 ~/.homebridge/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.

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 To npm From GitHub

The publish.yml workflow publishes the package when a GitHub Release is published. It uses npm Trusted Publishing with GitHub OIDC, so no long-lived npm token is required.

Before enabling automated releases:

  1. Replace all template metadata in package.json, remove "private": true, and keep src/settings.ts and config.schema.json in sync with the final plugin name.
  2. If the npm package does not exist yet, publish it once from a trusted local machine with npm login, npm run check, and npm publish --access public.
  3. In the package settings on npmjs.com, add a GitHub Actions trusted publisher for this repository. Set the workflow filename to publish.yml, the environment to npm, and allow npm publish.
  4. In the GitHub repository settings, create an environment named npm. Add required reviewers if releases should need manual approval.
  5. Commit the version bump, create a GitHub Release whose tag exactly matches v<package version> (for example v1.0.1), and publish the release.

The workflow validates the package metadata and tag, installs from the lockfile, runs all checks, and only then calls npm publish.

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, currently Node v22 and v24.
    • 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