@camstack/addon-matter-broker 0.2.113 → 0.2.114

package/dist/addon.js

@@ -5374,7 +5374,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).
@@ -29001,11 +29001,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

@@ -5372,7 +5372,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).
@@ -28999,11 +28999,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-matter-broker",
-  "version": "0.2.113",
+  "version": "0.2.114",
   "description": "Matter broker addon for CamStack — owns a Matter fabric (commissioning + the long-lived controller) via the matter.js controller and brokers commissioned Matter nodes into CamStack",
   "keywords": [
     "camstack",