@camstack/addon-provider-amcrest 0.2.116 → 0.2.117

package/dist/addon.js

@@ -5367,7 +5367,7 @@ var ZodIssueCode = {
 var ZodFirstPartyTypeKind;
 ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
 //#endregion
-//#region ../types/dist/sleep-Bs3xPtSh.mjs
+//#region ../types/dist/sleep-GU_us3DG.mjs
 /**
 * The audio chunk plane's byte format, and the ONE expansion from a coded
 * window to float samples (D455).
@@ -29028,11 +29028,15 @@ var motionTriggerCapability = {
 *
 * Adding a fifth name to that list would have been the wrong fix twice over:
 * that page is per-camera DETECTION tuning, and a grid's geometry belongs
-* beside PTZ and motion zones on the camera itself — which is exactly where the
-* framework already puts a widget, when the widget is declared on a CAPABILITY.
-* `deviceConfig.ui` is the mechanism (`motion-zones`, `ptz`, `ptz-autotrack`
-* all use it): the framework emits the structural section and the widget
-* self-persists through the cap's own mutations.
+* beside PTZ and motion zones on the camera itself. The device page is
+* BINDING-driven (D12), so the way in is a capability bound to the device —
+* and this cap carries its section the way `recording` does, by RETURNING it
+* from `getDeviceSettingsContribution`.
+*
+* Seven other widgets are still declared the other way, through a
+* `deviceConfig.ui` block the framework derives a section from. That route
+* gives the addon no say in where its own panel lands and no way to decline
+* for a device the panel does not suit, which is why this one does not use it.
 *
 * ## Why one addon may implement it
 *

package/dist/addon.mjs

@@ -5368,7 +5368,7 @@ var ZodIssueCode = {
 var ZodFirstPartyTypeKind;
 ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
 //#endregion
-//#region ../types/dist/sleep-Bs3xPtSh.mjs
+//#region ../types/dist/sleep-GU_us3DG.mjs
 /**
 * The audio chunk plane's byte format, and the ONE expansion from a coded
 * window to float samples (D455).
@@ -29029,11 +29029,15 @@ var motionTriggerCapability = {
 *
 * Adding a fifth name to that list would have been the wrong fix twice over:
 * that page is per-camera DETECTION tuning, and a grid's geometry belongs
-* beside PTZ and motion zones on the camera itself — which is exactly where the
-* framework already puts a widget, when the widget is declared on a CAPABILITY.
-* `deviceConfig.ui` is the mechanism (`motion-zones`, `ptz`, `ptz-autotrack`
-* all use it): the framework emits the structural section and the widget
-* self-persists through the cap's own mutations.
+* beside PTZ and motion zones on the camera itself. The device page is
+* BINDING-driven (D12), so the way in is a capability bound to the device —
+* and this cap carries its section the way `recording` does, by RETURNING it
+* from `getDeviceSettingsContribution`.
+*
+* Seven other widgets are still declared the other way, through a
+* `deviceConfig.ui` block the framework derives a section from. That route
+* gives the addon no say in where its own panel lands and no way to decline
+* for a device the panel does not suit, which is why this one does not use it.
 *
 * ## Why one addon may implement it
 *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camstack/addon-provider-amcrest",
-  "version": "0.2.116",
+  "version": "0.2.117",
   "description": "Amcrest/Dahua camera device provider addon for CamStack — Dahua CGI over HTTP(S) with digest auth (snapshot, RTSP catalog, PTZ, image/day-night config)",
   "keywords": [
     "camstack",