homebridge-tuya-plus 3.14.0-dev.9 → 3.14.0-pr.94.55

package/AGENTS.md

@@ -91,6 +91,29 @@ When adding or changing a device type, follow the existing pattern:
   `no-prototype-builtins`) as tech debt; don't rely on or expand that. Keep new
   code clean.
 
+## Logging
+
+Users run this in Homebridge and read these logs; a chatty plugin is a real
+complaint. The bar for a non-debug line is high.
+
+- **`debug` is the default.** Anything routine, per-message, per-state-change,
+  per-connect, or protocol-level (odd/raw/malformed frames, reconnects, socket
+  recycling, DP dumps, "X changed: …") goes to `this.log.debug`. If it can fire
+  more than a handful of times in normal operation, it's `debug`.
+- **`info`/`warn`/`error` are for what the user must see or act on**, and the
+  level must match real severity — a harmless condition (e.g. a cloud-fallback
+  failure while the device is reachable over the LAN) is not a `warn`/`error`.
+  Prefer one actionable line over a vague one; name the device.
+- **Never spam.** A condition that recurs on a timer or hot path must be
+  deduplicated (surface once, then drop repeats to `debug` until it changes) and
+  its retry backed off — see `TuyaCloudDevice._onConnectFailure` and the
+  discovery port-in-use guard for the pattern.
+- **Use the Homebridge logger** (`this.log` / `this.log.debug|info|warn|error`),
+  never `console.*`, in plugin/runtime code. (The standalone `bin/` CLIs are the
+  exception: their `console.*` is intentional user-facing output.)
+- **Logging must never throw and must never leak secrets** — don't dump a whole
+  config/props object (it carries the device's local `key`); log the id/name.
+
 ## Backwards compatibility (read before changing behavior)
 
 This is the most important rule in this repo. Users have working setups and
@@ -108,6 +131,25 @@ devices already paired in HomeKit; a careless change can break them silently.
   routing.
 - When a change must alter behavior, make it opt-in.
 
+## Debug config block
+
+The platform reads an **undocumented** top-level `debug` object from the config
+(see `_debugConfig()` in `index.js`). It holds dev/test-only switches and is
+deliberately **kept out of `config.schema.json`** so it never appears in the
+Homebridge UI. Treat it as the one place such switches belong; add new ones as
+optional, off-by-default flags read through `_debugConfig()` and coerced with
+`coerceBoolean`.
+
+- `debug.forceCloudFallback` — pretend LAN discovery fails for every device, so
+  the whole platform runs over the Tuya Cloud fallback. Lets the cloud path be
+  exercised end-to-end without taking devices off the LAN (needs a configured
+  `cloud` block to be useful).
+- `debug.logCloudHttp` — trace every Tuya Cloud HTTP request/response (method,
+  path, headers, body, status, response) at `debug`, with all credentials
+  (token, signature, password, access key/id, uid) redacted. Verbose and
+  per-request — keep it off in normal operation, and remember Homebridge
+  debug logging must be on to see it.
+
 ## Git & PR workflow
 
 - Develop on the branch you've been assigned; never push to `main` directly.

package/Changelog.md

@@ -4,11 +4,24 @@ All notable changes to this project will be documented in this file. This projec
 
 ## Unreleased
 
-* [+] **Tuya Cloud support for devices that can't be reached over the LAN** — most notably battery-powered "sleepy" irrigation/sprinkler timers, which sleep almost all the time and only ever talk to Tuya's cloud, so the local protocol can never reach them. The plugin stays LAN-first: cloud is strictly opt-in. Add a top-level `cloud` credentials block (or a per-device `cloud` object) and set `"cloud": true` on the device.
+* [+] **Tuya Cloud is now a transparent, global fallback for every device.** What started as an experiment to reach battery-powered "sleepy" irrigation timers (which never appear on the LAN) is now a general, optional fallback: add a top-level `cloud` credentials block once and the plugin keeps a single Tuya Cloud/MQTT session alive in the background, falling back to it whenever a device can't be reached on the LAN — a flaky moment, or hardware that's never local. The plugin stays **LAN-first** (local is always tried first and preferred) and cloud remains **strictly opt-in** (nothing runs unless credentials are present).
+  * **No per-device configuration.** There is one global session and no per-device cloud settings. Every device automatically uses the LAN first and the cloud as a fallback; a device with no local `key` is reached over the cloud only. Existing LAN configs (numeric data-points) keep working over the cloud — the data-point id↔code map is learned from Tuya's device shadow (`/v2.0/cloud/thing/{id}/shadow/properties`) — and if both transports fail, HomeKit shows "No Response" as before. This mirrors the official Tuya/Smart Life app (LAN when possible, cloud as a backup).
   * Realtime updates arrive over Tuya's **MQTT** message service (via the optional `mqtt` dependency, installed automatically); initial state and control use the Tuya OpenAPI. There is no polling.
   * Works with both **Custom** and **Smart Home** Cloud projects (the latter via app-account login).
-  * The existing **IrrigationSystem** accessory works unchanged over the cloud — its data-points are simply addressed by Tuya "code" (e.g. `switch_1`, `battery_percentage`) instead of a numeric id; the device logs its codes on startup. Battery-only controllers with no rain sensor: set `"noRainSensor": true`.
-  * See the wiki: **[Tuya Cloud Setup](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Tuya-Cloud-Setup.md)**.
+  * The **IrrigationSystem** accessory no longer has any cloud-specific handling — like every other accessory it's transport-agnostic, with the LAN+cloud fallback handled underneath.
+  * If your devices sometimes drop off the LAN and show "No Response", adding cloud credentials is an easy way to smooth that over. See the wiki: **[Tuya Cloud Setup](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Tuya-Cloud-Setup.md)**.
+* [*] **Fix realtime (MQTT) cloud updates being silently dropped** — external changes (physical buttons, the Tuya app, the device's own timers) now show up in HomeKit within a second or two. The decryptor was verifying the AES-GCM auth tag (`decipher.final()`), but Tuya's real status frames don't carry a tag that verifies against the documented AAD, so every realtime message was being thrown away. Now decrypts with `update()` only, matching the official `tuya/tuya-homebridge` and `0x5e/homebridge-tuya-platform` implementations.
+* [*] **Fix cloud irrigation valves that could be turned on but not off** — the per-zone write coalescer was dropping any command that matched the last-known `device.state`. Cloud devices never optimistically advance `state` (it only moves once the realtime stream confirms the device), so an "off" issued before the "on" was echoed matched the stale "off" and was discarded — HomeKit showed the zone closed while it kept running. Queued commands are now sent as-is (callers already queue only genuine changes).
+* [*] **IrrigationSystem: remove the rain sensor.** It never reported reliably on these devices, and bundling a sensor (a different HomeKit category) in the same accessory forced the Home app to fragment the sprinkler into "sub-accessories" — blocking control from the main tile and hiding the system master on/off. The accessory is now a single, clean sprinkler tile (IrrigationSystem + valves + optional battery); any leftover Contact/Leak sensor service from a previous build is removed automatically on restart. The `noRainSensor`, `rainSensorType`, `rainInverted`, `dpRain` and `rainOnValue` options are gone.
+* [*] **IrrigationSystem: add the HAP Service Label service for multi-valve controllers** — an accessory that exposes a collection of same-type services (more than one `Valve`) must include a `ServiceLabel` service to anchor each valve's `ServiceLabelIndex`. It was missing, so stricter Home app clients (notably iOS) scattered the zones as separate tiles instead of nesting them under the single irrigation tile. The service is added automatically (with the Arabic-numerals namespace) whenever there is more than one valve; user-set zone names still take precedence.
+* [*] **IrrigationSystem: stop the valve toggle flickering after a press** — tapping a zone briefly snapped back to the old state before settling on the new one. The `Active` getters returned the raw `device.state`, which (for cloud devices) only advances once the realtime stream echoes the write back, so a read in that window reported the pre-press value. The getters now report the value HomeKit already shows (optimistic on press, then confirmed/corrected by device-side change events); they still surface "No Response" while disconnected.
+* [*] **Tuya Cloud: report real device online/offline status.** Cloud devices previously always showed as reachable. They now mirror Tuya's `online` flag (read from the device record on connect and re-checked when the realtime stream reconnects), so HomeKit shows **"No Response"** when the device is genuinely offline. If the lookup isn't permitted (the project lacks the device-management API), the device is assumed reachable so control is never blocked.
+* [*] **Signal unreachable devices with `HapStatusError`.** The shared getters (`getStateAsync` / `getDividedStateAsync`, used by nearly every accessory's read handlers, plus the irrigation `Active` getter) threw a plain `Error` to make HomeKit show "No Response". Newer Homebridge logs a characteristic warning for that before falling back to a generic status; they now throw `HapStatusError(SERVICE_COMMUNICATION_FAILURE)` directly — same "No Response", no warning spam. No behaviour change for users.
+* [*] **Surface write and connection failures to HomeKit, universally across device types.** Previously a command sent to an unreachable device was silently dropped while HomeKit still reported the tap as successful, and several accessories kept showing their last-known state instead of going "No Response" — the clearest example was a LAN gate that logged `skipping write, device not connected` yet still appeared online and "accepted" open/close taps. Now:
+  * **Writes** to a disconnected device (or a write the device/cloud rejects) fail the HomeKit operation instead of pretending success. The shared write helpers (`setState` / `setMultiState` / `setMultiStateLegacy` and their `*Async` variants) now signal a communication failure, so accessories whose set handlers swallowed it (garage door, switches/outlets, RGB hue + saturation, blinds, vertical-tilt blinds) report it on a tap.
+  * **Reads** that returned a cached/optimistic or constant value (brightness, colour, hue/saturation, blind position/state, garage-door state, valve in-use/duration, heater state, …) now report **"No Response"** when the device is unreachable — matching the read handlers that already did.
+  * **Cloud** commands that fail over HTTP (a network error, or a command Tuya rejects) are surfaced too: `TuyaCloudDevice.update()` now resolves to the real command result so the write helper can await it, rather than firing and forgetting.
+  * Internal/background writes (auto-shutoff timers, multi-step open/close sequences, debounced batches) stay non-fatal via dedicated non-throwing helpers (`setStateInBackground` / `setMultiStateInBackground` / `setMultiStateLegacyInBackground`), so an unreachable device can never crash Homebridge with an unhandled error.
 
 ## 2.0.1 (2021-03-25)
 This update includes the following changes:

package/Readme.MD

@@ -14,7 +14,7 @@
 
 
 
-A community-maintained Homebridge plugin for controlling Tuya devices locally over LAN. Control your supported Tuya accessories locally in HomeKit.
+A community-maintained Homebridge plugin for controlling Tuya devices locally over LAN. Control your supported Tuya accessories locally in HomeKit, with an optional Tuya Cloud fallback for devices the LAN can't reach.
 
 * [Supported Device Types](#supported-device-types)
 * [Supported Tuya Protocol Versions](#supported-tuya-protocol-versions)
@@ -38,7 +38,7 @@ A community-maintained Homebridge plugin for controlling Tuya devices locally ov
 * Fan v2<sup>[7](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md)</sup>
 * Garages<sup>[8](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#garage-doors)</sup>
 * Heaters<sup>[9](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md)</sup>
-* Irrigation Systems / Sprinklers<sup>[17](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#irrigation-systems--sprinklers)</sup> (multi-valve, per-zone timers, rain sensor, battery)
+* Irrigation Systems / Sprinklers<sup>[17](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#irrigation-systems--sprinklers)</sup> (multi-valve, per-zone timers, battery)
 * Lights
   * On/Off<sup>[10](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md)</sup>
   * Brightness<sup>[11](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#tunable-white-light-bulbs)</sup>
@@ -48,34 +48,11 @@ A community-maintained Homebridge plugin for controlling Tuya devices locally ov
 * Switches<sup>[15](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#switch)</sup>
 * Vertical Blinds<sup>[16](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Supported-Device-Types.md#vertical-blinds-with-tilt)</sup>
 
-Note: Motion, and other sensor types don't behave well with responce requests, so they will not be added. 
+## Cloud fallback
 
-## Supported Tuya Protocol Versions
+The plugin is LAN-first — everything is controlled locally by default. If you add Tuya Cloud credentials in a top-level `cloud` block, it keeps a cloud session in the background and uses it as a fallback: each device is tried on the LAN first, and only falls back to the cloud when it can't be reached locally — a brief LAN hiccup, or hardware that never appears on the LAN at all (e.g. battery-powered "sleepy" devices). It's opt-in and local always comes first, and existing configs need no changes — so it's also a handy fix if some devices occasionally show as "No Response".
 
-The plugin speaks every published Tuya LAN protocol version:
-
-| Tuya LAN protocol | Framing | Encryption | Status |
-|---|---|---|---|
-| 3.1 | `0x55AA` | AES-128-ECB (base64, control only) | ✅ Supported |
-| 3.2 | `0x55AA` | AES-128-ECB | ✅ Supported |
-| 3.3 | `0x55AA` | AES-128-ECB | ✅ Supported |
-| 3.4 | `0x55AA` | AES-128-ECB, session key, HMAC-SHA256 | ✅ Supported |
-| 3.5 | `0x6699` | AES-128-GCM, session key | ✅ Supported |
-| 3.6 and newer | — | — | ✅ Forward-compatible (see below) |
-
-The protocol version is auto-detected from the device's discovery broadcast, so you normally don't need to configure anything.
-
-Protocol **3.5** is currently the newest Tuya LAN protocol in existence: it is the latest version implemented by Tuya's own open-source device SDK ([TuyaOpen](https://github.com/tuya/TuyaOpen)) and by the reference reverse-engineered implementations ([tinytuya](https://github.com/jasonacox/tinytuya/blob/master/PROTOCOL.md)). No device firmware speaking a "3.6" protocol has been observed in the wild so far.
-
-This plugin is nevertheless **3.6-ready**: if a device reports a newer protocol version (e.g. `3.6`) in its broadcast, the plugin automatically talks to it using the newest (3.5/GCM) protocol stack while tagging payloads with the device's reported version — the same forward-compatibility strategy used by tinytuya. Should such a device misbehave, you can pin it to a specific protocol with the `forceVersion` device option (e.g. `"forceVersion": "3.5"`), or use `version` to set a protocol for devices that can't be discovered (e.g. on another subnet).
-
-## Cloud devices (for hardware that can't be controlled locally)
-
-This is a **LAN-first** plugin — virtually every Tuya device is controlled locally, which is faster, more private, and keeps working without internet. A few devices, though, simply **can't** be reached over the LAN: battery-powered "sleepy" devices — for example the **irrigation / faucet timers** — sleep almost all the time and only ever connect out to Tuya's cloud, so they never answer on the local network.
-
-For exactly these cases the plugin can talk to a device through the **Tuya Cloud** instead — strictly **opt-in, per device**. You add your Tuya Cloud project credentials once and set `"cloud": true` on the device; everything else works the same.
-
-👉 **[Tuya Cloud Setup guide](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Tuya-Cloud-Setup.md)** — how to get credentials and configure a cloud device.
+See the **[Tuya Cloud Setup guide](https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Tuya-Cloud-Setup.md)** for credentials and setup.
 
 ## Installation Instructions
 
@@ -92,8 +69,7 @@ sudo npm install -g homebridge-tuya-plus
 #### Bleeding-edge (`dev`) builds:
 
 Every commit to `main` is automatically published to npm under the `dev` tag — a
-separate, unstable channel. The stable release always stays on `latest`, so this
-won't affect normal installs. To try the latest in-development build:
+separate, unstable channel. To try the latest in-development build:
 
 ```
 sudo npm install -g homebridge-tuya-plus@dev
@@ -102,20 +78,6 @@ sudo npm install -g homebridge-tuya-plus@dev
 These are versioned like `3.14.0-dev.<n>` and may be unstable; use the default
 install above for production.
 
-#### Testing a specific pull request:
-
-Maintainers can publish an unmerged PR as a throwaway test build by commenting
-`/publish` on it. The build goes to its own `pr-<number>` tag — never `latest`
-or `dev` — so it never reaches normal installs. The bot replies on the PR with
-the exact install command, e.g.:
-
-```
-sudo npm install -g homebridge-tuya-plus@pr-57
-```
-
-Each build also gets a unique, immutable version like `3.14.0-pr.57.<n>` that you
-can pin or paste into the Homebridge UI's "Install Alternate Version" field.
-
 ## Configuration
 > UI
 
@@ -148,7 +110,7 @@ If you have new accessory logic for a new device, please add a function defined
 
 #
 
-Go check out my other Homebridge plugins:
+Check out my other Homebridge plugins:
 
 * [homebridge-futurehome](https://github.com/adrianjagielak/homebridge-futurehome) ([npm](https://npmjs.com/package/homebridge-futurehome))
 * [homebridge-tuya-plus](https://github.com/adrianjagielak/homebridge-tuya-plus) ([npm](https://npmjs.com/package/homebridge-tuya-plus))

package/config.schema.json

@@ -21,8 +21,8 @@
       },
       "cloud": {
         "type": "object",
-        "title": "Tuya Cloud (optional — only for devices that can't be reached over the LAN)",
-        "description": "This plugin is LAN-first. A few devices — notably battery-powered 'sleepy' irrigation timers — sleep most of the time and only ever talk to Tuya's cloud, so they cannot be controlled locally. Create a free Cloud project at iot.tuya.com, enter its credentials here, then tick 'Control via Tuya Cloud' on each such device. See the wiki for step-by-step setup.",
+        "title": "Tuya Cloud fallback (optional)",
+        "description": "<a href='https://github.com/adrianjagielak/homebridge-tuya-plus/blob/main/wiki/Tuya-Cloud-Setup.md'>Tuya Cloud API Setup</a>.",
         "properties": {
           "accessId": {
             "type": "string",
@@ -69,12 +69,6 @@
               { "title": "Tuya Smart", "enum": ["tuyaSmart"] },
               { "title": "Smart Life", "enum": ["smartlife"] }
             ]
-          },
-          "realtime": {
-            "type": "boolean",
-            "title": "Realtime updates (MQTT)",
-            "default": true,
-            "description": "Receive instant updates over Tuya's MQTT message service (uses the 'mqtt' package, installed automatically). If disabled, devices stay controllable and show their state at startup, but external changes (physical buttons, the device's own timers) won't be reflected until restart."
           }
         }
       },
@@ -96,7 +90,7 @@
                 {
                   "title": "Switch Gang / Basic Switch",
                   "enum": ["Switch"]
-                },                
+                },
                 {
                   "title": "Smart Plug / Barely Smart Power Strip",
                   "enum": ["Outlet"]
@@ -197,16 +191,7 @@
             "key": {
               "title": "Tuya Key (local key — required for LAN devices)",
               "type": "string",
-              "description": "The device's local key. Required for normal (LAN) devices. Not needed for cloud devices (tick 'Control via Tuya Cloud' below).",
-              "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices].type !== 'null';"
-              }
-            },
-            "cloud": {
-              "type": ["boolean", "object"],
-              "title": "Control via Tuya Cloud (instead of the LAN)",
-              "default": false,
-              "description": "Enable for devices that can't be reached locally (e.g. battery-powered irrigation timers). Uses the platform-level 'cloud' credentials above. Advanced: instead of a checkbox you can set this to an object with per-device { accessId, accessKey, region, … } to use different credentials for this one device.",
+              "description": "The device's local key. Required for normal (LAN) devices. A device with no key is treated as cloud-only and is reached through the Tuya Cloud session configured above (e.g. a battery-powered 'sleepy' irrigation timer).",
               "condition": {
                 "functionBody": "return model.devices && model.devices[arrayIndices].type !== 'null';"
               }
@@ -318,9 +303,9 @@
               "title": "Sync brightness to WLED (IP[:port])",
               "placeholder": "192.168.1.100",
               "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['WledDimmer', 'SimpleDimmer'].includes(model.devices[arrayIndices].type);"
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['WledDimmer'].includes(model.devices[arrayIndices].type);"
               }
-            },            
+            },
             "dpColorTemperature": {
               "type": "integer",
               "placeholder": "3",
@@ -421,6 +406,12 @@
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
               }
             },
+            "noAuto": {
+              "type": "boolean",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
+              }
+            },
             "cmdCool": {
               "type": "string",
               "placeholder": "COOL",
@@ -435,6 +426,42 @@
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
               }
             },
+            "cmdAuto": {
+              "type": "string",
+              "placeholder": "AUTO",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
+              }
+            },
+            "noRotationSpeed": {
+              "type": "boolean",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
+              }
+            },
+            "fanSpeedSteps": {
+              "type": "integer",
+              "placeholder": "3",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
+              }
+            },
+            "fanSpeedValues": {
+              "type": "array",
+              "description": "Ordered string values used by the device for each fan speed (low → high), e.g. ['low', 'middle', 'high']. Overrides fanSpeedSteps.",
+              "items": {
+                "type": "string"
+              },
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
+              }
+            },
+            "noChildLock": {
+              "type": "boolean",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner', 'Convector'].includes(model.devices[arrayIndices].type);"
+              }
+            },
             "noSwing": {
               "type": "boolean",
               "condition": {
@@ -569,30 +596,31 @@
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['Convector'].includes(model.devices[arrayIndices].type);"
               }
             },
-            "noChildLock": {
+            "noTemperatureUnit": {
               "type": "boolean",
               "condition": {
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['Convector'].includes(model.devices[arrayIndices].type);"
               }
             },
-            "noTemperatureUnit": {
-              "type": "boolean",
+            "temperatureDivisor": {
+              "type": "integer",
+              "placeholder": "1",
               "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['Convector'].includes(model.devices[arrayIndices].type);"
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['SimpleHeater', 'AirConditioner'].includes(model.devices[arrayIndices].type);"
               }
             },
-            "temperatureDivisor": {
+            "currentTemperatureDivisor": {
               "type": "integer",
               "placeholder": "1",
               "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['SimpleHeater'].includes(model.devices[arrayIndices].type);"
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['AirConditioner'].includes(model.devices[arrayIndices].type);"
               }
             },
             "thresholdTemperatureDivisor": {
               "type": "integer",
               "placeholder": "1",
               "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['SimpleHeater'].includes(model.devices[arrayIndices].type);"
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['SimpleHeater', 'AirConditioner'].includes(model.devices[arrayIndices].type);"
               }
             },
             "temperatureOffset": {
@@ -717,7 +745,7 @@
               "type": "integer",
               "title": "Number of Valves / Zones",
               "placeholder": 4,
-              "description": "How many valves/zones the controller has. They are assumed to be on data-points 1, 2, 3, … (or, for cloud devices, on the codes switch_1, switch_2, …). For non-sequential data-points use the 'valves' list instead.",
+              "description": "How many valves/zones the controller has. They are assumed to be on data-points 1, 2, 3, … (over the cloud these map to the codes switch_1, switch_2, … automatically). For non-sequential data-points use the 'valves' list instead.",
               "condition": {
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type);"
               }
@@ -730,9 +758,27 @@
               "items": {
                 "type": "object",
                 "properties": {
-                  "name": { "type": "string", "title": "Zone name", "placeholder": "Lawn" },
-                  "dp": { "type": ["integer", "string"], "title": "Data-point (numeric id, or cloud code)", "placeholder": "1 or switch_1" },
-                  "defaultDuration": { "type": "integer", "title": "Default run time (seconds, 0 = run indefinitely)", "placeholder": 600 }
+                  "name": {
+                    "type": "string",
+                    "title": "Zone name",
+                    "placeholder": "Lawn"
+                  },
+                  "dp": {
+                    "type": ["integer", "string"],
+                    "title": "Data-point (numeric id, or cloud code)",
+                    "placeholder": "1 or switch_1"
+                  },
+                  "dpCountdown": {
+                    "type": ["integer", "string"],
+                    "title": "Countdown data-point (numeric id, or cloud code)",
+                    "description": "Optional. The device's built-in auto-off timer for this zone. Defaults to the switch data-point + 16 (so switch 1 → countdown 17). Set this only for code-addressed or non-standard zones.",
+                    "placeholder": "17 or countdown_1"
+                  },
+                  "defaultDuration": {
+                    "type": "integer",
+                    "title": "Default run time (seconds, 0 = run indefinitely)",
+                    "placeholder": 600
+                  }
                 }
               },
               "condition": {
@@ -752,7 +798,16 @@
               "type": "integer",
               "title": "Maximum Run Time (seconds)",
               "placeholder": 7200,
-              "description": "Upper bound advertised to HomeKit for the duration picker (HAP default is 3600 / 1h). Apple's Home app only offers presets up to 1h regardless; longer values can be set from the config or apps like Eve.",
+              "description": "Upper bound advertised to HomeKit for the duration picker (HAP default is 3600 / 1h). Apple's Home app only offers presets up to 1h regardless; longer values can be set from the config or apps like Eve. Also bounds the hardware countdown: a device countdown longer than this (or the 120-min hardware cap) is corrected on connect.",
+              "condition": {
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type);"
+              }
+            },
+            "nativeCountdown": {
+              "type": "boolean",
+              "title": "Use the device's built-in countdown timer",
+              "placeholder": true,
+              "description": "When the controller exposes per-zone countdown data-points (countdown_1.., DP 17.. by default), mirror each zone's duration to the hardware timer so a zone still auto-closes on schedule even if Homebridge or the network drops out mid-run. Disable to fall back to the software-timer-only behaviour. Has no effect on devices that don't report a countdown data-point.",
               "condition": {
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type);"
               }
@@ -818,49 +873,13 @@
                 "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type) && !model.devices[arrayIndices].noBattery;"
               }
             },
-            "noRainSensor": {
-              "type": "boolean",
-              "title": "No rain sensor",
-              "description": "Disable the rain sensor (use if your controller doesn't report 'rain_sensor_state').",
-              "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type);"
-              }
-            },
-            "rainSensorType": {
-              "type": "string",
-              "title": "Rain sensor type",
-              "default": "contact",
-              "oneOf": [
-                { "title": "Contact sensor (Open / Closed)", "enum": ["contact"] },
-                { "title": "Leak sensor (Leak Detected / Dry — note: fires critical alerts)", "enum": ["leak"] }
-              ],
-              "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type) && !model.devices[arrayIndices].noRainSensor;"
-              }
-            },
-            "rainInverted": {
-              "type": "boolean",
-              "title": "Invert rain sensor",
-              "description": "Flip the reported state if 'raining' and 'dry' appear reversed in HomeKit.",
-              "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type) && !model.devices[arrayIndices].noRainSensor;"
-              }
-            },
-            "dpRain": {
+            "dpRainState": {
               "type": ["integer", "string"],
               "placeholder": "49 or rain_sensor_state",
-              "title": "Rain sensor data-point (numeric id, or cloud code)",
+              "title": "Rain-sensor data-point (numeric id, or cloud code)",
+              "description": "Enum data-point reporting rainfall ('rain' / 'no_rain'), surfaced as a Leak Detected characteristic on the irrigation system so HomeKit can notify and automate on rain. Defaults to DP 49; if your controller doesn't report it, Leak Detected simply stays clear.",
               "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type) && !model.devices[arrayIndices].noRainSensor;"
-              }
-            },
-            "rainOnValue": {
-              "type": "string",
-              "placeholder": "rain",
-              "title": "Rain sensor 'raining' value",
-              "description": "The enum value the device reports when it is raining (default 'rain').",
-              "condition": {
-                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type) && !model.devices[arrayIndices].noRainSensor;"
+                "functionBody": "return model.devices && model.devices[arrayIndices] && ['IrrigationSystem'].includes(model.devices[arrayIndices].type);"
               }
             }
           }
@@ -868,4 +887,4 @@
       }
     }
   }
-}
+}