homebridge-tuya-plus 3.14.0-dev.44 → 3.14.0-dev.45

package/lib/TuyaCloudDevice.js

@@ -77,6 +77,7 @@ class TuyaCloudDevice extends EventEmitter {
         this._announcedProperties = false;
         this._catchupTimers = null; // post-write state re-reads (see _scheduleStateCatchup)
         this._writeChain = null;    // serializes cloud writes to this device (see update)
+        this._reportsOverMqtt = false; // set once any realtime update arrives; disables the catch-up
 
         // Bidirectional data-point maps, learned from the device's thing-shadow on
         // connect. They let this cloud transport (and the LAN+cloud TuyaDevice that
@@ -226,6 +227,10 @@ class TuyaCloudDevice extends EventEmitter {
     // makes the catch-up self-cancelling: it costs an HTTP read only on devices that
     // actually need it.
     _onRealtime(status) {
+        // This device reports over MQTT, so the catch-up is pure overhead for it —
+        // latch it off for good and drop any pending one. Only devices that never
+        // report here (the stream carries nothing for them) keep the catch-up.
+        this._reportsOverMqtt = true;
         if (this._catchupTimers) {
             this._catchupTimers.forEach(t => clearTimeout(t));
             this._catchupTimers = null;
@@ -452,10 +457,12 @@ class TuyaCloudDevice extends EventEmitter {
     // to "opening") shows up in the cloud within ~a second, but the realtime stream
     // doesn't always carry it — and an accessory that mirrors a status DP (the
     // garage door) would otherwise sit on the old value forever. So re-read the
-    // device a couple of times after a command to catch the transition. Each new
-    // command re-arms it, so a burst of writes only triggers one catch-up; it only
-    // runs on the cloud path, so a LAN-reachable device pays nothing.
+    // device a couple of times after a command to catch the transition. Strictly
+    // supplemental: a device that has ever reported over MQTT skips this entirely
+    // (realtime is its path), each new command re-arms it, and it only runs on the
+    // cloud path — so a LAN-reachable or MQTT-covered device pays nothing.
     _scheduleStateCatchup() {
+        if (this._reportsOverMqtt) return;
         if (this._catchupTimers) this._catchupTimers.forEach(t => clearTimeout(t));
         this._catchupTimers = [2000, 8000].map(delay => {
             const t = setTimeout(() => this._catchupOnce(), delay);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "homebridge-tuya-plus",
-  "version": "3.14.0-dev.44",
+  "version": "3.14.0-dev.45",
   "description": "A community-maintained Homebridge plugin for controlling Tuya devices in HomeKit. LAN-first, with an optional Tuya Cloud fallback for any device the LAN can't reach.",
   "main": "index.js",
   "scripts": {

package/test/TuyaCloudDevice.test.js

@@ -355,6 +355,18 @@ describe('TuyaCloudDevice', () => {
             dev.stop();
         });
 
+        test('once a device has reported over MQTT, later writes never arm a catch-up', async () => {
+            const api = makeApi();
+            api.getShadowProperties = jest.fn().mockResolvedValue([{code: 'switch_1', dp_id: 1, value: false}]);
+            const dev = makeDevice(api, null, {key: 'abc'});
+            await dev._connect();
+            dev._onRealtime([{code: 'switch_1', value: true}]); // device reports over MQTT → latch
+
+            await dev.update({'1': false});
+            expect(dev._catchupTimers).toBeNull(); // strictly supplemental: no read for MQTT-covered devices
+            dev.stop();
+        });
+
         test('a refresh reads via the shadow, so a thing-model device whose /status is empty still updates', async () => {
             const api = makeApi();
             let rs = 13;