@homebridge-plugins/homebridge-govee 11.32.2-beta.8 → 11.32.2-beta.9

package/CHANGELOG.md

@@ -21,6 +21,7 @@ All notable changes to `@homebridge-plugins/homebridge-govee` will be documented
 - feat: give every appliance type a starting handler, so a new model works for on and off and asks for the rest
 - refactor: point models that behave identically at one shared handler instead of copies of the same file
 - fix: stop shipping the test files to npm, since they are only needed in the repository
+- docs: keep the structure notes outside the repository, since they are working notes rather than plugin documentation
 
 ## v11.32.1 (2026-08-02)
 

package/package.json

@@ -2,7 +2,7 @@
   "name": "@homebridge-plugins/homebridge-govee",
   "alias": "Govee",
   "type": "module",
-  "version": "11.32.2-beta.8",
+  "version": "11.32.2-beta.9",
   "description": "Homebridge plugin to integrate Govee devices into HomeKit.",
   "author": {
     "name": "bwp91",

package/CONTRIBUTING-STRUCTURE.md

@@ -1,66 +0,0 @@
-# How this plugin is put together, and how to extend it
-
-This is the working reference for adding models and functionality. It exists so
-that the next change follows the same shape as the last, whoever makes it.
-
-## The three ways a model gets support
-
-**1. It shares behaviour with a model already handled — alias it.**
-Nothing new is written. `lib/device/index.js` maps the new model's key to the
-existing handler:
-
-```text
-deviceHumidifierH7147: deviceHumidifierH7143,
-```
-
-This is the common case. Several Govee models are the same device with a
-different name, and a handler copied per model is a handler that has to be fixed
-per model.
-
-**2. It is a new model of a known type, but the details are unknown — let it
-say so.** Add it to the model list in `lib/utils/constants.js` and nothing else.
-The dispatch falls back to `appliance-basic.js`, which offers on and off (that
-command is identical across every Govee appliance) and makes every other control
-report what it needs and then fail, so the owner sees it in the Home app, checks
-the log, and finds a line to paste into an issue.
-
-**3. It genuinely behaves differently — write a handler.**
-Only when the controls or their commands really differ.
-
-## Where model knowledge lives
-
-Per-model differences belong in data, not in a copied file:
-
-| File | Holds |
-|---|---|
-| `lib/utils/constants.js` | which models are which type |
-| `lib/utils/device-capabilities.js` | protocol quirks — colour command, brightness scale, and firmware-dependent behaviour |
-| `lib/utils/appliance-capabilities.js` | which controls a model actually has |
-
-If a change means copying a file and editing two lines, it belongs in one of
-these instead.
-
-## Reporting anything unknown
-
-Never log an unrecognised payload by hand. Use `lib/utils/report-unknown.js`:
-
-- `logUnknownData` — something arrived that is not understood
-- `reportUnsupportedControl` — the user asked for something not worked out yet
-
-Both produce one line carrying the model, firmware, hardware, connection and
-payload, so a single copy-paste is enough to act on. Both warn once and then
-drop to debug, so a device repeating itself does not flood the log.
-
-## Things worth knowing before changing appliance code
-
-- **The power command is universal.** `33 01 01` on, `33 01 00` off, on every
-  appliance. Safe to send for an untested model.
-- **Frames are 20 bytes with an XOR checksum** — byte 20 is the XOR of bytes
-  1–19. All 407 shipped appliance commands have been verified against this.
-- **A control that silently does nothing is worse than one that fails.** Failing
-  shows up in the Home app and sends the owner to the log.
-- **Do not remove a control a model has offered for a long time** on evidence
-  alone. Someone may be using it. Confirm with an owner first.
-- **HomeKit tiles have requirements.** A humidifier must report a current
-  humidity, which many Govee humidifiers never send — hence the plain fan tile
-  by default, and the richer one only when the device says it has the sensor.