homebridge-tuya-plus 3.14.0-dev.8 → 3.14.0-dev.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +120 -0
- package/CLAUDE.md +1 -0
- package/package.json +1 -1
package/AGENTS.md
ADDED
|
@@ -0,0 +1,120 @@
|
|
|
1
|
+
# AGENTS.md
|
|
2
|
+
|
|
3
|
+
Guidance for AI coding agents (Claude Code, Codex, etc.) working in this
|
|
4
|
+
repository. Human contributors may find it useful too.
|
|
5
|
+
|
|
6
|
+
## What this project is
|
|
7
|
+
|
|
8
|
+
`homebridge-tuya-plus` is a community-maintained [Homebridge](https://homebridge.io)
|
|
9
|
+
plugin that exposes Tuya smart-home devices to Apple HomeKit. It is
|
|
10
|
+
**LAN-first**: virtually every device is controlled locally over Tuya's LAN
|
|
11
|
+
protocol (faster, more private, works without internet). A small, strictly
|
|
12
|
+
opt-in **Tuya Cloud** path exists only for hardware that genuinely cannot be
|
|
13
|
+
reached on the LAN (e.g. battery-powered "sleepy" irrigation timers).
|
|
14
|
+
|
|
15
|
+
It is published to npm and installed by end users into their Homebridge setups,
|
|
16
|
+
many of whom already have devices paired with HomeKit. **Treat it as production
|
|
17
|
+
software with a large existing install base.**
|
|
18
|
+
|
|
19
|
+
## Tech stack & layout
|
|
20
|
+
|
|
21
|
+
- **Node.js, CommonJS** (`require`/`module.exports`). No TypeScript, no build
|
|
22
|
+
step — the source that ships is the source in the repo.
|
|
23
|
+
- Target runtimes: Node `^20.18 || ^22.10 || ^24`, Homebridge `^1.8 || ^2.0`
|
|
24
|
+
(see `engines` in `package.json`). Keep changes compatible with both
|
|
25
|
+
Homebridge 1.x and 2.x.
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
index.js Platform entry point. Registers the TuyaLan platform,
|
|
29
|
+
maps config "type" -> accessory class (CLASS_DEF), runs
|
|
30
|
+
discovery, and creates/reuses cached HomeKit accessories.
|
|
31
|
+
lib/
|
|
32
|
+
BaseAccessory.js Shared base class for all accessories (state helpers,
|
|
33
|
+
unit/color conversions, getCategory()).
|
|
34
|
+
*Accessory.js One class per device type (lights, fans, garage doors,
|
|
35
|
+
irrigation, AC, blinds, ...). Each extends BaseAccessory.
|
|
36
|
+
TuyaAccessory.js The LAN protocol implementation (framing, encryption,
|
|
37
|
+
discovery, reconnection) for protocol versions 3.1-3.5+.
|
|
38
|
+
TuyaDiscovery.js UDP broadcast discovery of devices on the LAN.
|
|
39
|
+
TuyaCloud*.js Opt-in Tuya Cloud client (OpenAPI + MQTT realtime).
|
|
40
|
+
bin/ Standalone CLI helpers (tuya-lan*, key discovery/decode).
|
|
41
|
+
test/ Jest unit tests; shared HAP mocks in test/support/mocks.js.
|
|
42
|
+
scripts/ Maintenance scripts (e.g. PR-tag cleanup).
|
|
43
|
+
wiki/ User-facing docs (device setup, cloud setup, mappings).
|
|
44
|
+
config.schema.json Drives the Homebridge Config UI X settings form.
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Commands
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
npm ci # install (CI uses this; lockfile is committed)
|
|
51
|
+
npm test # Jest unit tests — keep these green
|
|
52
|
+
npm run lint # ESLint (flat config in eslint.config.mjs)
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
CI runs `npm test` and `npm run lint` on every pull request to `main`. Run both
|
|
56
|
+
locally before you consider a change done.
|
|
57
|
+
|
|
58
|
+
## How an accessory works
|
|
59
|
+
|
|
60
|
+
When adding or changing a device type, follow the existing pattern:
|
|
61
|
+
|
|
62
|
+
1. Create `lib/<Name>Accessory.js` extending `BaseAccessory`.
|
|
63
|
+
2. Implement `static getCategory(Categories)` returning a real HAP category
|
|
64
|
+
constant (don't leave the `OTHER` fallback unless truly generic).
|
|
65
|
+
3. Build HomeKit services/characteristics in `_registerCharacteristics(dps)`,
|
|
66
|
+
which runs once the device reports its first state.
|
|
67
|
+
4. Read/write device data points (DPs) via the `BaseAccessory` helpers
|
|
68
|
+
(`getState`/`setState`/`setMultiState` and their `*Async` variants) rather
|
|
69
|
+
than poking `this.device` directly.
|
|
70
|
+
5. Register the type in `CLASS_DEF` in `index.js`.
|
|
71
|
+
6. Add the device's config options to `config.schema.json` so they appear in the
|
|
72
|
+
Homebridge UI.
|
|
73
|
+
7. Add Jest tests using `makeInstance(...)` from `test/support/mocks.js`.
|
|
74
|
+
|
|
75
|
+
## Conventions
|
|
76
|
+
|
|
77
|
+
- **Match the surrounding code.** Mirror the existing file's naming, spacing,
|
|
78
|
+
quoting (single quotes), and structure. Don't introduce a new style.
|
|
79
|
+
- **Write code that reads clearly without comments.** Prefer descriptive names
|
|
80
|
+
and straightforward control flow over cleverness.
|
|
81
|
+
- **Comment the "why", not the "what".** Existing comments explain non-obvious
|
|
82
|
+
protocol quirks, HomeKit/Homebridge gotchas, and decisions that protect
|
|
83
|
+
backwards compatibility (often citing an issue/PR number). Add comments of
|
|
84
|
+
that kind where they save the next reader real time; skip narration of obvious
|
|
85
|
+
code.
|
|
86
|
+
- **Tests where they make sense.** Pure logic (state mapping, value
|
|
87
|
+
conversions, protocol encode/decode, config coercion) should have Jest tests.
|
|
88
|
+
The HAP layer is mocked — don't reach for real hardware or the network in
|
|
89
|
+
tests.
|
|
90
|
+
- ESLint currently disables a few rules (`no-unused-vars`, `no-empty`,
|
|
91
|
+
`no-prototype-builtins`) as tech debt; don't rely on or expand that. Keep new
|
|
92
|
+
code clean.
|
|
93
|
+
|
|
94
|
+
## Backwards compatibility (read before changing behavior)
|
|
95
|
+
|
|
96
|
+
This is the most important rule in this repo. Users have working setups and
|
|
97
|
+
devices already paired in HomeKit; a careless change can break them silently.
|
|
98
|
+
|
|
99
|
+
- **Config is a public API.** Don't rename, repurpose, or remove existing config
|
|
100
|
+
keys (platform- or device-level). Add new options as optional with safe
|
|
101
|
+
defaults, and keep `config.schema.json` in sync. Be lenient in what you
|
|
102
|
+
accept (see `_coerceBoolean` / `coerceBoolean`).
|
|
103
|
+
- **Keep cloud strictly opt-in.** LAN remains the default path. Cloud code runs
|
|
104
|
+
only when a device sets `cloud: true` (or a `cloud` object) and credentials
|
|
105
|
+
are present. `mqtt` is an optional dependency — don't make it mandatory.
|
|
106
|
+
- **Preserve protocol support.** The plugin speaks Tuya LAN 3.1-3.5 and is
|
|
107
|
+
forward-compatible with newer versions; don't drop versions or break version
|
|
108
|
+
routing.
|
|
109
|
+
- When a change must alter behavior, make it opt-in.
|
|
110
|
+
|
|
111
|
+
## Git & PR workflow
|
|
112
|
+
|
|
113
|
+
- Develop on the branch you've been assigned; never push to `main` directly.
|
|
114
|
+
- `main` is protected and merges via squash; each commit there is auto-published
|
|
115
|
+
to npm under the `dev` tag, so keep `main` releasable.
|
|
116
|
+
- Match the existing commit style: a concise, imperative subject (the PR number
|
|
117
|
+
is appended automatically on merge, e.g. `... (#62)`).
|
|
118
|
+
|
|
119
|
+
</content>
|
|
120
|
+
</invoke>
|
package/CLAUDE.md
ADDED
|
@@ -0,0 +1 @@
|
|
|
1
|
+
See @AGENTS.md for project guidance.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "homebridge-tuya-plus",
|
|
3
|
-
"version": "3.14.0-dev.
|
|
3
|
+
"version": "3.14.0-dev.9",
|
|
4
4
|
"description": "A community-maintained Homebridge plugin for controlling Tuya devices locally over LAN. Includes new features, fixes, and updated device support.",
|
|
5
5
|
"main": "index.js",
|
|
6
6
|
"scripts": {
|