homebridge-govee: Govee lights and sensors inside HomeKit

Four ways to reach the same light

The plugin information in the project notes is compact and worth reading closely, because the whole design follows from it. The plugin supports Govee OpenAPI discovery, state and control when an OpenAPI key is provided. It requires your Govee credentials for most Cloud, AWS and BLE connections. It can control certain models locally over LAN control without any Govee credentials. And it may use different connection methods depending on the device model and on what your account capabilities allow.

Four methods then, with very different properties. OpenAPI control is the vendor's own interface, keyed by an API key that you obtain, and it covers discovery, state and control. LAN control talks to the device on your own network, which is the one that needs no account at all and is the only method that keeps your commands off the internet. AWS control is a cloud path built on the vendor's AWS infrastructure, which is where the MQTT and the AWS IoT dependencies come from. BLE control is Bluetooth, which is the method that needs a Bluetooth stack on the host and a device in range.

The consequence for a user is that a Govee strip and a Govee sensor may reach HomeKit by entirely different routes, and the configuration you write depends on that.

The plugin does not pick the method for you

Because the choice depends on the model and on the account, the documentation is organised around connection methods rather than around devices. The wiki carries a supported devices page and a connection methods page, and the second one has its own pages for OpenAPI control, LAN control, AWS control and BLE control, plus a separate page for scene, music and DIY modes.

That structure is a design decision about where the complexity lives. A plugin that hard-coded one method would either work for half the devices or need a flag for every device, and the flags would multiply. Splitting the documentation by method means the question you have to answer is which methods apply to you, and the answer is a per-model question that the wiki answers for you.

The scene, music and DIY modes deserve a mention because they are the part of Govee hardware that has no equivalent in the standard light bulb model. A strip with a scene mode does not just switch on and off, it has a set of named scenes and a running programme, and exposing that to HomeKit means deciding how much of it to surface as a controllable entity. The plugin has a whole wiki page for it, which is a hint that this is where the mapping work is.

Node majors are narrow, and Bluetooth is partial

The prerequisites are specific, and the Node requirement is the one that will bite first. The plugin needs the latest version of v22, v24 or v26, and any other major version is not supported. Homebridge itself needs to be v1.6 or above.

The manifest is more precise than the prose, and it also allows for a Homebridge 2:

  "engines": {
    "homebridge": "^1.6.0 || ^2.0.0",
    "node": "^22.12.0 || ^24.0.0 || ^26.0.0"
  },

Bluetooth is where the caveats live. For Bluetooth connectivity you may need to install extra packages on your system, and the project points at a wiki page for that. Bluetooth works best on a Raspberry Pi, and it has not been tested on Windows. macOS is newly supported from v11.32.2 and has only been tried on a handful of devices, so on a Mac you have to give the node binary that runs Homebridge permission under the Bluetooth section of the system privacy settings, and the project asks you to report anything that does not work.

That combination of platform caveats is normal for a protocol integration that talks to vendor hardware, but it means the BLE method is the one to test first rather than last.

The connection paths are third-party libraries

The credits section explains where the actual protocol work comes from, and the answer is that the plugin builds on other people's clients. The BLE connection to the LED strips is made possible by the govee-led-client library, and the BLE connection to the sensors by the govee-bt-client library. The AWS connection is made possible by the govee_api library, and the LAN connection by the work of a contributor who made that path possible.

Leak sensor support has its own lineage, coming from the code of the homebridge-govee-water-detectors plugin. That is a good pattern to note, because it means the plugin is not trying to be a from-scratch implementation of four vendor protocols. It is an integration layer that knows how to drive each path and how to present the result as HomeKit accessories.

The npm dependencies tell the same story from the other side. The AWS IoT device SDK and the MQTT client are there for the cloud paths, axios for the OpenAPI requests, node-forge for the cryptographic work that the AWS and OpenAPI authentication needs, node-persist for local state, a queue library for rate limiting, and the Homebridge UI utilities for the config UI. The plugin is JavaScript, published as an ES module, with the entry point at lib/index.js and the HomeKit accessory code in the lib directory.

Patches at install time, and a config schema

The install script is worth noticing, because it is not a no-op. The manifest runs patch-package as a postinstall step, which means the plugin applies its own patches to its dependencies at install time. That is a pragmatic way to fix upstream libraries without forking them, and it is also a thing to know about when you audit what a Homebridge install is doing, because patches are applied silently on every install and reinstall.

The rest of the tooling is a modern JavaScript setup. Linting runs with ESLint and a strict setting, failing on any warning at all rather than only on errors, and the test suite runs on Vitest with a watch mode and a coverage variant. There is a separate script that synchronises the changelog with something in the repository's own scripts directory, which is how the changelog stays in step with the releases.

The repository also carries a configuration schema file, which is how the plugin's settings get validated in the Homebridge config user interface rather than failing at runtime with an unhelpful error. That file is worth a look before you write your configuration, because it tells you which fields exist and what they expect.

A personal project with a verified badge

The project states its own status plainly. The author is in no way affiliated with Govee, the plugin is a personal project maintained in their free time, and it is to be used entirely at your own risk, with a pointer to the licence for more information.

Against that, the plugin carries the Homebridge verified badge and is listed as hoobs certified, and there is a beta channel on npm alongside the latest one, with a wiki page explaining how to use it. The maintainer takes funding through GitHub Sponsors and several other services, and there is a Discord channel linked from the project notes.

The release history shows a busy pace. v11.37.1 was published on 2026-08-21, v11.39.0 on 2026-08-28, and v11.39.1 on 2026-10-18, with the last push to the repository two days later. That rate is what you would expect from a plugin tracking a vendor that ships new hardware and new modes often, and it is also the argument for reading the changelog before upgrading rather than after.

Editorial conclusion

homebridge-govee suits a Homebridge user with Govee hardware who wants the devices in HomeKit, and the LAN route is the reason to try it, because certain models can be controlled locally with no Govee account credentials in the configuration at all. It is the wrong choice if you need Bluetooth control on Windows, since that path is untested there, or if you need macOS Bluetooth support with confidence, since that has only been tried on a handful of devices. Before you install, read the supported devices page in the project wiki to confirm your model has a working connection method, and check the Node version requirement, because the plugin only accepts the v22, v24 and v26 lines and the manifest states the range precisely. The licence is MIT, the current version is 11.39.1 from 2026-10-18, and the project is a personal effort by a single maintainer with no affiliation to Govee.

Frequently asked questions

Official sources

1. homebridge-plugins/homebridge-govee on GitHub
2. Issues
3. License: MIT
4. README
5. Releases