@apocaliss92/nodelink-js 0.4.34 → 0.4.36

package/dist/cli/rtsp-server.cjs

@@ -16308,7 +16308,19 @@ function computeDeviceCapabilities(params) {
     // lightType >= 2 indicates controllable white LED / floodlight (1 = IR only).
     // ledCtrl > 1 is a secondary signal that rescues firmwares like the Duo 3
     // WiFi which under-report lightType (=1) despite having a real spotlight.
-    hasFloodlight: Number.isFinite(lightType) ? lightType >= 2 || hasFloodlightFromLedCtrl : hasFloodlightFromAbilities || hasFloodlightFromLedCtrl,
+    //
+    // Doorbell exception: the Reolink desktop app's native SDK exposes
+    // three SEPARATE ability flags — `supportFloodLight`, `supportDoorbellLight`
+    // (with KeepOff/KeepOn sub-flags) and `supportIndicatorLight`. Doorbell-class
+    // devices route the ring / button-area LED through `supportDoorbellLight`,
+    // which is NOT a controllable white-light floodlight. We don't have a
+    // documented bit-level mapping for ledCtrl, so we use the narrowest
+    // rule that matches Reolink's own taxonomy: when the firmware is
+    // categorical with lightType=0 AND the device identifies itself as a
+    // doorbell (doorbellVersion > 0), trust lightType=0 and ignore the
+    // ledCtrl bitmask. Verified against UID 9527000ICL1T1MDS (lightType=0,
+    // ledCtrl=3073, doorbellVersion=31, no spotlight hardware).
+    hasFloodlight: Number.isFinite(lightType) ? lightType >= 2 || hasFloodlightFromLedCtrl && !(isDoorbellFromSupport && lightType === 0) : hasFloodlightFromAbilities || hasFloodlightFromLedCtrl,
     hasPir: hasPirFromAbilities || hasPirFromSupport,
     isDoorbell,
     hasAutotracking: ptzDisabledBySupport ? false : hasAutotrackingFromSupport || hasAutotrackingFromAbilities,
@@ -26885,8 +26897,18 @@ ${xml}`
    * This is more reliable than autoPt in SupportInfo which can be a false positive
    * (e.g., NVR channels report autoPt=1 but don't actually support autotracking).
    *
+   * Doorbell exception (mirrors the {@link computeDeviceCapabilities} floodlight
+   * rule): video-doorbell firmwares (doorbellVersion > 0) ship AiCfg with
+   * `smartTrackMode=1` (the current mode) yet `smartTrackModeAbility=0` (the
+   * firmware's own "no, this device cannot autotrack" flag). Without a PT
+   * motor a doorbell physically cannot autotrack, so when the caller flags the
+   * device as a doorbell AND the firmware admits `smartTrackModeAbility=0`,
+   * trust the firmware and return false. Verified against UID
+   * 9527000ICL1T1MDS: smartTrackMode=1, smartTrackModeAbility=0,
+   * ptzType=0, ptzMode="none", doorbellVersion=31.
+   *
    * @param channel - Channel number (0-based)
-   * @param options - Optional timeout
+   * @param options - Optional timeout and doorbell context hint
    * @returns true if autotracking is supported, false otherwise
    */
   async probeAutotrackingSupport(channel, options) {
@@ -26896,6 +26918,14 @@ ${xml}`
       const xml = await this.sendXml({ cmdId: 299, channel: ch, timeoutMs });
       const smartTrackModeRaw = getXmlText(xml, "smartTrackMode");
       const smartTrackMode = Number(smartTrackModeRaw ?? 0);
+      const smartTrackModeAbilityRaw = getXmlText(
+        xml,
+        "smartTrackModeAbility"
+      );
+      const smartTrackModeAbility = smartTrackModeAbilityRaw === void 0 ? void 0 : Number(smartTrackModeAbilityRaw);
+      if (options?.isDoorbell && Number.isFinite(smartTrackModeAbility) && smartTrackModeAbility === 0) {
+        return false;
+      }
       return smartTrackMode > 0;
     } catch {
       return false;
@@ -26988,7 +27018,8 @@ ${xml}`
     const features = this.parseFeaturesFromSupport(support);
     const objects = await this.getAiDetectTypes(ch, { timeoutMs: 1500 });
     const autotrackingProbed = await this.probeAutotrackingSupport(ch, {
-      timeoutMs: 1500
+      timeoutMs: 1500,
+      isDoorbell: capabilities.isDoorbell === true
     });
     capabilities.hasAutotracking = autotrackingProbed;
     let presets;