@camstack/addon-osd-manager 0.1.130 → 0.1.132

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (18) hide show
  1. package/dist/{MotionZonesSettings-BdgknhPk.mjs → MotionZonesSettings-BVKF49rs.mjs} +2 -2
  2. package/dist/{PrivacyMaskSettings-Daia4FHS.mjs → PrivacyMaskSettings-DoIRAuP_.mjs} +4 -4
  3. package/dist/{SceneMonitorEditor-CmH-9VEG.mjs → SceneMonitorEditor-3ApQNn3a.mjs} +3 -3
  4. package/dist/_stub.js +12 -12
  5. package/dist/{_virtual_mf-localSharedImportMap___mfe_internal__addon_osd_manager_page-CT5rLNrc.mjs → _virtual_mf-localSharedImportMap___mfe_internal__addon_osd_manager_page-mIgOkpXI.mjs} +3 -3
  6. package/dist/_virtual_mf___mfe_internal__addon_osd_manager_page__loadShare___mf_0_camstack_mf_1_types__loadShare__.js-D47POQ8_.mjs +26 -0
  7. package/dist/{hostInit-CGDQxGQr.mjs → hostInit-vbrbPLQg.mjs} +2 -2
  8. package/dist/index.js +700 -9
  9. package/dist/index.mjs +700 -9
  10. package/dist/{player-overlays-SETUglb5.mjs → player-overlays-BPpRI9aB.mjs} +1 -1
  11. package/dist/remoteEntry.js +1 -1
  12. package/dist/{responsive-dnBm2QK5.mjs → responsive-BEcoyxvC.mjs} +1 -1
  13. package/dist/{scene-monitor-copy--fsvQxHQ.mjs → scene-monitor-copy-1LhlrkfK.mjs} +1 -1
  14. package/dist/{square-DPw7AhAw.mjs → square-Bw9o8y6p.mjs} +1 -1
  15. package/dist/{trash-2-DNiVd6l-.mjs → trash-2-ClX9SCS6.mjs} +1 -1
  16. package/dist/{virtual_mf-REMOTE_ENTRY_ID___mfe_internal__addon_osd_manager_page__remoteEntry_js-DLJN80iK.mjs → virtual_mf-REMOTE_ENTRY_ID___mfe_internal__addon_osd_manager_page__remoteEntry_js-BNiwvK5v.mjs} +1 -1
  17. package/package.json +1 -1
  18. package/dist/_virtual_mf___mfe_internal__addon_osd_manager_page__loadShare___mf_0_camstack_mf_1_types__loadShare__.js-DY9EOcFz.mjs +0 -26
package/dist/index.mjs CHANGED
@@ -5359,7 +5359,7 @@ var ZodIssueCode = {
5359
5359
  var ZodFirstPartyTypeKind;
5360
5360
  ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
5361
5361
  //#endregion
5362
- //#region ../types/dist/sleep-De1BvmWo.mjs
5362
+ //#region ../types/dist/sleep-COWaSCAi.mjs
5363
5363
  /**
5364
5364
  * The audio chunk plane's byte format, and the ONE expansion from a coded
5365
5365
  * window to float samples (D455).
@@ -7625,6 +7625,24 @@ object({
7625
7625
  unreachable: number()
7626
7626
  })
7627
7627
  });
7628
+ /** The wire shape of {@link PeerBytesTicket} — see the type for what it is. */
7629
+ var PeerBytesTicketSchema = object({
7630
+ /** `http://127.0.0.1:<port>/<token>`. One `GET` takes it. */
7631
+ url: string().min(1),
7632
+ /**
7633
+ * The HOST node this URL means something on — the hub or a named agent,
7634
+ * never a runner. {@link AddonPeerBytes.open} compares it to its own and
7635
+ * refuses `cross-node` by name when they differ, without dialling.
7636
+ */
7637
+ hostNodeId: string().min(1),
7638
+ expiresAtMs: number().int().nonnegative(),
7639
+ /**
7640
+ * What the producer DECLARED the body to be, when it knows — `null` when it
7641
+ * does not. Never `0` for unknown (D393): a consumer sizing a bound off this
7642
+ * must be able to tell "the producer did not say" from "the body is empty".
7643
+ */
7644
+ declaredBytes: number().int().nonnegative().nullable()
7645
+ });
7628
7646
  /**
7629
7647
  * Adoption job — the background form of `device-adoption.adopt`.
7630
7648
  *
@@ -14678,6 +14696,118 @@ var deviceAdoptionCapability = {
14678
14696
  }
14679
14697
  };
14680
14698
  /**
14699
+ * device-admin-link — "this device has a management page of its own, and here
14700
+ * is its address".
14701
+ *
14702
+ * ## Why this is not a `deviceConfig` cap
14703
+ *
14704
+ * There is nothing to edit. A `deviceConfig` cap (D14) exists so the framework
14705
+ * can DERIVE a settings form from `getOptions` + `getStatus` and route a flat
14706
+ * patch back through a setter; it costs a `builderId` reducer in
14707
+ * `device-config-contribution.ts` and a `*-config-schema.ts` beside it, and it
14708
+ * renders a form section. This cap answers ONE question with ONE read and
14709
+ * renders a button. Nothing about it is a form, so it carries no `deviceConfig`
14710
+ * block, no `settings`, no `runtimeState` and no reducer — exactly like
14711
+ * `reboot`, the other pure-RPC device-native cap.
14712
+ *
14713
+ * ## Absent, and the difference between "no page" and "we cannot say"
14714
+ *
14715
+ * The two are answered at DIFFERENT layers, on purpose:
14716
+ *
14717
+ * - **"We cannot say"** → the provider never registers the cap for that
14718
+ * device. A VeSync humidifier, a Petkit feeder, a Dreame vacuum and a Dreo
14719
+ * fan are reached only through a vendor cloud; there is no address to hand
14720
+ * out and no page to open. A Tuya plug, a Wyze camera and a Gree air
14721
+ * conditioner DO have a LAN IP, and still have no HTTP management page
14722
+ * behind it. None of them register, so `deviceManager.getBindings` never
14723
+ * lists the cap and no surface asks.
14724
+ * - **"This device has no page, and I know that"** → the provider registers
14725
+ * and `getAdminLink` returns `null`. This is the answer for a device whose
14726
+ * sibling DOES have a page: a Reolink battery camera reached over UDP by
14727
+ * `uid` with a blank `host`, an Ecowitt gateway configured in `listener`
14728
+ * transport, a Home Assistant broker authenticated by supervisor token
14729
+ * (which carries no `baseUrl` at all).
14730
+ *
14731
+ * Both draw NOTHING. A button that opens a browser error is worse than no
14732
+ * button, and D62 is the same rule from the other side: an off switch is
14733
+ * reported off, never made to look broken. There is no third state where the
14734
+ * UI renders a disabled button "because the device might have a page".
14735
+ *
14736
+ * ## The URL never carries credentials
14737
+ *
14738
+ * Not in userinfo, not in a query string. Every provider builds through
14739
+ * `buildDeviceAdminUrl` (`device-admin-link-url.ts`), which takes host, port,
14740
+ * scheme and path as separate arguments — there is no parameter a secret could
14741
+ * arrive in — and re-checks its own output for the `scheme://user:pass@` shape
14742
+ * that `scripts/check-no-credential-urls-in-fixtures.ts` bans from recorded
14743
+ * output. `scripts/check-admin-link-builder-is-the-only-url-source.ts` is what
14744
+ * keeps providers from hand-rolling one anyway.
14745
+ *
14746
+ * This matters here more than anywhere else in the repo, because every provider
14747
+ * that knows a device's host knows its PASSWORD too: `{ host, port, username,
14748
+ * password }` sit in one object on Hikvision, Amcrest, Reolink and ONVIF alike,
14749
+ * and `http://admin:hunter2@192.168.50.139/` is a URL a browser accepts. The
14750
+ * camera's own page will ask for its own login. That is correct, and pre-
14751
+ * filling it is the operator's business, not ours.
14752
+ *
14753
+ * ## It is a LAN fact
14754
+ *
14755
+ * The URL addresses the device where the NODE can see it. It is not proxied,
14756
+ * not made reachable from outside, and not sent anywhere. A surface renders it
14757
+ * as a link the operator's own browser follows, on the operator's own network,
14758
+ * or renders nothing.
14759
+ */
14760
+ /**
14761
+ * Whose page is it. The distinction is for the OPERATOR, who needs to know
14762
+ * before clicking whether he is about to land on a camera's own web server or
14763
+ * inside Home Assistant.
14764
+ */
14765
+ var AdminLinkTargetEnum = _enum(["device", "integration"]);
14766
+ var DeviceAdminLinkSchema = object({
14767
+ /**
14768
+ * Absolute `http(s)://` URL. Built by `buildDeviceAdminUrl` and therefore
14769
+ * free of userinfo and of any credential-shaped query key.
14770
+ */
14771
+ url: string(),
14772
+ /**
14773
+ * What the surface calls it — "Web UI", "Home Assistant", "UniFi controller".
14774
+ * The PROVIDER names it, because only the provider knows what the page is;
14775
+ * a UI that invented the label from the addon id would call the Home
14776
+ * Assistant device page "Provider Homeassistant".
14777
+ */
14778
+ label: string(),
14779
+ target: AdminLinkTargetEnum,
14780
+ /**
14781
+ * Host the URL points at, without scheme, port or path — for the tooltip, so
14782
+ * an operator can see WHERE the button goes before he follows it. Redundant
14783
+ * with `url` by construction; carried separately so no surface has to parse
14784
+ * a URL to show it.
14785
+ */
14786
+ host: string()
14787
+ });
14788
+ var deviceAdminLinkCapability = {
14789
+ name: "device-admin-link",
14790
+ scope: "device",
14791
+ deviceNative: true,
14792
+ mode: "singleton",
14793
+ methods: {
14794
+ /**
14795
+ * The device's management page, or `null` when this device has none.
14796
+ *
14797
+ * `auth: 'admin'` deliberately. This is administration, not actuation —
14798
+ * the same bucket as `reboot` and `camera-credentials`, and explicitly NOT
14799
+ * the actuation set `scripts/check-actuation-not-admin.ts` protects (D403).
14800
+ * The URL is also a statement about the LAN, which a household member with
14801
+ * a `view` grant on a light has no reason to be handed.
14802
+ *
14803
+ * The surfaces gate on the QUERY, never on a role they guessed: a caller
14804
+ * without the right loses the query and draws nothing, which is the same
14805
+ * thing a device with no page draws. There is no path on which a button
14806
+ * appears and then fails — the D403 failure mode, from the other end.
14807
+ */
14808
+ getAdminLink: method(object({ deviceId: number().int().nonnegative() }), DeviceAdminLinkSchema.nullable(), { auth: "admin" }) }
14809
+ };
14810
+ /**
14681
14811
  * `device-export` — collection cap for addons that export camstack
14682
14812
  * devices to external ecosystems (HomeAssistant via MQTT discovery,
14683
14813
  * HomeKit/HAP, Alexa Smart Home, …).
@@ -29020,6 +29150,7 @@ _enum([
29020
29150
  "sleeping",
29021
29151
  "camera-refused",
29022
29152
  "no-keyframe",
29153
+ "decode-failed",
29023
29154
  "no-catalog-row",
29024
29155
  "unsupported",
29025
29156
  "unknown-device",
@@ -29294,6 +29425,32 @@ var ClipBytesSchema = object({
29294
29425
  durationMs: number().positive().optional()
29295
29426
  });
29296
29427
  /**
29428
+ * Where a clip's finished bytes can be TAKEN (D613) — the answer to
29429
+ * {@link videoclipsCapability.methods.offerClipBytes}.
29430
+ *
29431
+ * Everything {@link ClipBytesSchema} carries except the bytes themselves, plus
29432
+ * the one-shot ticket that leads to them. The metadata is answered BEFORE the
29433
+ * transfer on purpose: a consumer learns which twin it got, what to call the
29434
+ * file and how long the clip runs without having to read a byte, so a decision
29435
+ * it would make on that metadata (a wrong twin, an implausible duration) costs
29436
+ * no transfer at all.
29437
+ */
29438
+ var ClipBytesOfferSchema = object({
29439
+ /**
29440
+ * One shot, seconds-long, loopback, on the PROVIDER's own host. Open it with
29441
+ * `ctx.peerBytes.open(...)`, which refuses a ticket from another node by
29442
+ * name rather than dialling a port that means something else here.
29443
+ */
29444
+ ticket: PeerBytesTicketSchema,
29445
+ contentType: string(),
29446
+ /** Suggested filename, extension included. */
29447
+ name: string(),
29448
+ /** Which twin was actually served — see {@link ClipBytesSchema.served}. */
29449
+ served: CamProfileSchema,
29450
+ /** See {@link ClipBytesSchema.durationMs}. Absent when nothing measured it. */
29451
+ durationMs: number().positive().optional()
29452
+ });
29453
+ /**
29297
29454
  * Where a clip's STREAM can be dialled (D597) — the answer to
29298
29455
  * {@link videoclipsCapability.methods.dialClipStream}.
29299
29456
  *
@@ -29369,6 +29526,44 @@ var ClipStreamDialSchema = object({
29369
29526
  /** Why `servedAudio` is `none` although sound was asked for. */
29370
29527
  audioReason: ClipStreamAudioReasonSchema.optional()
29371
29528
  });
29529
+ /**
29530
+ * What a surface may DRAW for this provider's clips — the answer to
29531
+ * {@link videoclipsCapability.methods.getPlaybackOptions} (D612).
29532
+ *
29533
+ * The envelope is a PROVIDER fact, not a clip fact, and that is measured, not
29534
+ * assumed: the broker's `chooseClipPath` reads exactly two inputs — whether
29535
+ * `dialClipStream` and `readClipBytes` are wired — and both are constants of
29536
+ * the broker's own closure over the provider's methods. The `profile` it is
29537
+ * handed is explicitly not read. So every clip of a provider is served the
29538
+ * same way, and a per-clip channel carried a value that could not vary. The
29539
+ * per-clip `clipTransport` server message was removed for exactly that reason.
29540
+ *
29541
+ * Queried per camera, before a clip is picked, so a control is rendered or
29542
+ * DISABLED rather than offered and refused at play time (D62: a disabled
29543
+ * control reads as unavailable, one that undoes the gesture reads as broken).
29544
+ */
29545
+ var ClipPlaybackOptionsSchema = object({
29546
+ /**
29547
+ * How this provider's clips reach the player. `stream` is the provider's
29548
+ * forward-only fMP4 (D597); `file` is one bounded by-handle fetch of the
29549
+ * whole clip, `stbl` indexed (D575).
29550
+ */
29551
+ transport: _enum(["stream", "file"]),
29552
+ /** `forward` = only ahead of the playhead. `free` = anywhere. */
29553
+ seek: _enum(["forward", "free"]),
29554
+ /** Frame-step BACKWARD is meaningful. Forward always is. */
29555
+ stepBack: boolean(),
29556
+ /** Whether the scrub gesture is served, as opposed to refused by name. */
29557
+ scrub: boolean(),
29558
+ /**
29559
+ * The rates that can be delivered, ascending, always containing `1`. The
29560
+ * viewer draws its picker from this and from nothing else — a constant it
29561
+ * keeps instead is the second authority that produced the defect: `8` and
29562
+ * `16` were offered, the broker clamped them to `4`, and no line anywhere
29563
+ * said so. `0` is not a member: pause is the absence of a rate.
29564
+ */
29565
+ rates: array(number().positive()).min(1).readonly()
29566
+ });
29372
29567
  var ClipSourceAvailabilitySchema = object({
29373
29568
  state: _enum([
29374
29569
  "ok",
@@ -29547,14 +29742,18 @@ var videoclipsCapability = {
29547
29742
  *
29548
29743
  * `getClipPlayback` is the right answer for a player: it hands back a URL
29549
29744
  * on a plane the hub serves `access:'authenticated'`, which a browser and a
29550
- * viewer session satisfy. It is the wrong answer for another ADDON. There
29551
- * is no addon→addon byte transport in this framework — `AddonDataPlane`
29552
- * only lets an addon SERVE, on `127.0.0.1` behind a per-listener secret
29553
- * only the hub may present — so a recorder that wants a camera's clip
29554
- * cannot fetch that URL. This method is the one seam that exists for it,
29555
- * and it is deliberately the same shape (and the same bound) as
29556
- * `recordingExport.readExportBytes`, which exists for the mirror-image
29557
- * reason.
29745
+ * viewer session satisfy. It is the wrong answer for another ADDON: the
29746
+ * hub's proxy in front of that plane takes only a user credential, which
29747
+ * an addon does not hold, so a recorder that wants a camera's clip cannot
29748
+ * fetch that URL. This method is the shape that answer forced — the same
29749
+ * one (and the same bound) as `recordingExport.readExportBytes`.
29750
+ *
29751
+ * **It is no longer the only seam.** Until D613 there was no addon→addon
29752
+ * byte transport at all; there is now
29753
+ * ({@link offerClipBytes}, over `ctx.peerBytes`), it holds nothing on
29754
+ * either side, and it is what a clip EXPORT uses. This method remains for
29755
+ * a consumer that genuinely wants the bytes in hand, and as the named
29756
+ * fallback for a provider not yet redeployed.
29558
29757
  *
29559
29758
  * Routing needs no `provider` pin: the id is source-prefixed and
29560
29759
  * self-contained, so `device-collection-dispatch.ts` rule 3 hands the call
@@ -29621,6 +29820,65 @@ var videoclipsCapability = {
29621
29820
  auth: "protected"
29622
29821
  }),
29623
29822
  /**
29823
+ * Where this clip's finished bytes can be TAKEN — the by-handle read a
29824
+ * clip EXPORT pulls, over the addon→addon byte transport (D613).
29825
+ *
29826
+ * This is {@link readClipBytes} with the envelope removed. Same gates,
29827
+ * same vocabulary, same completion rules, same `served` contract — the
29828
+ * only difference is that the bytes travel over a one-shot loopback
29829
+ * socket instead of inside a base64 field, so neither side holds the
29830
+ * payload whole and the 50 MiB refusal on a long `high` twin stops
29831
+ * existing. The bound that remains is
29832
+ * {@link VIDEOCLIPS_MAX_OFFER_BYTES}, and it bounds the PRODUCER's own
29833
+ * copy rather than the transport.
29834
+ *
29835
+ * **The ticket is loopback and same-host.** A provider on an agent mints a
29836
+ * URL that means nothing on the hub, and `ctx.peerBytes.open` refuses it
29837
+ * `cross-node` by name rather than dialling whatever else holds that port
29838
+ * here. A consumer that can be on the other side of a node boundary from
29839
+ * its provider must be able to read that refusal and say so; it must not
29840
+ * treat it as "no bytes".
29841
+ *
29842
+ * **A ticket is a one-shot bearer credential with a seconds-long life.**
29843
+ * Take it immediately, never persist it, never log its `url`. An untaken
29844
+ * ticket costs the provider one map entry until its TTL, and outstanding
29845
+ * tickets are bounded — which is also what makes a per-frame misuse of
29846
+ * this method refuse by name rather than work slowly (D9/D18: this is a
29847
+ * by-handle fetch of finished media, not a frame pipe).
29848
+ *
29849
+ * Optional on the provider for the same reason `readClipBytes` is: a
29850
+ * source with no camera socket behind it has no bytes. A provider that
29851
+ * predates this method answers `NOT_IMPLEMENTED`, and a consumer may fall
29852
+ * back to `readClipBytes` — but it says so in the log, with the deploy
29853
+ * hint, because that fallback re-imposes the 50 MiB refusal and an
29854
+ * operator who sees `too-large-to-transfer` after this shipped is looking
29855
+ * at a stale addon, not at a clip that cannot be exported.
29856
+ */
29857
+ offerClipBytes: optionalMethod(object({
29858
+ deviceId: number(),
29859
+ clipId: string().min(1),
29860
+ /** WHICH provider holds the bytes — see `readClipBytes.provider`. */
29861
+ provider: string().min(1),
29862
+ /** Which twin — `low | mid` → the sub file, `high` → the main twin. */
29863
+ profile: CamProfileSchema.optional(),
29864
+ /**
29865
+ * The CALLER's byte bound, so an over-size clip is refused before the
29866
+ * camera is touched rather than after. Capped by
29867
+ * {@link VIDEOCLIPS_MAX_OFFER_BYTES} whatever is passed; absent means
29868
+ * that ceiling.
29869
+ */
29870
+ maxBytes: number().int().positive().optional(),
29871
+ /**
29872
+ * The operator's authorisation to wake a sleeping camera for this
29873
+ * read. Absent — the default — means a sleeping standalone battery
29874
+ * camera is REFUSED by name, before any session is opened.
29875
+ */
29876
+ wake: ClipWakeSchema.optional()
29877
+ }), ClipBytesOfferSchema, {
29878
+ kind: "query",
29879
+ auth: "protected"
29880
+ }),
29881
+ /**
29624
29882
  * Where this clip's STREAM can be dialled (D597) — the forward-only
29625
29883
  * fMP4 the provider writes from the first muxed byte, for the broker to
29626
29884
  * play through the same WebRTC session as recorded footage, with the
@@ -29657,6 +29915,36 @@ var videoclipsCapability = {
29657
29915
  }), ClipStreamDialSchema, {
29658
29916
  kind: "query",
29659
29917
  auth: "protected"
29918
+ }),
29919
+ /**
29920
+ * What a surface may DRAW for this provider's clips: the rates it can be
29921
+ * played at, whether scrub is served, how far a position may be moved,
29922
+ * and whether a backward frame-step means anything (D612).
29923
+ *
29924
+ * **The only authority.** The per-clip `clipTransport` server message
29925
+ * that used to carry the same answer was removed: the broker's transport
29926
+ * choice reads nothing that varies per clip, so the clip level had no
29927
+ * information the provider does not already have, and two channels that
29928
+ * can disagree are worse than one (D62).
29929
+ *
29930
+ * Asked per camera and per provider, so it must stay CHEAP — it is a
29931
+ * statement about wiring, answered from a constant, never a call to the
29932
+ * camera. A provider answers with one of {@link CLIP_PLAYBACK_OPTIONS}
29933
+ * and never composes an envelope of its own.
29934
+ *
29935
+ * Optional, and absence is load-bearing: a provider that has not answered
29936
+ * has not restricted anything, and a viewer reads it as the freedom it
29937
+ * always had. See D612 on the rollout order that absence implies.
29938
+ */
29939
+ getPlaybackOptions: optionalMethod(object({
29940
+ deviceId: number(),
29941
+ /** WHICH provider to ask — the `addonId` a {@link ClipSourceSchema}
29942
+ * row carries. Required for the same reason `listClips` requires it:
29943
+ * a collection cap has no "the bound one" to resolve to (D554). */
29944
+ provider: string().min(1)
29945
+ }), ClipPlaybackOptionsSchema, {
29946
+ kind: "query",
29947
+ auth: "protected"
29660
29948
  })
29661
29949
  }
29662
29950
  };
@@ -32203,6 +32491,346 @@ var dayNightCapability = {
32203
32491
  volatileStateFields: ["lastFetchedAt"]
32204
32492
  };
32205
32493
  /**
32494
+ * Vendor-neutral **onboard** recording + storage cap — what the CAMERA
32495
+ * writes to the CAMERA's own card, on the camera's own schedule.
32496
+ *
32497
+ * This is NOT `recording.cap.ts`. That one is CamStack's recorder: our
32498
+ * footage ledger, our storage locations, our retention. This one has a
32499
+ * different authority — the camera's firmware — and per D62 it stores
32500
+ * nothing of its own. Every value here is read from the camera and every
32501
+ * write goes back to the camera; there is no CamStack-side mirror that
32502
+ * could disagree with the device.
32503
+ *
32504
+ * ## One shape, two firmwares
32505
+ *
32506
+ * Measured 2026-09-22 against the live fleet:
32507
+ *
32508
+ * | fact | Hikvision (ISAPI) | Reolink (Baichuan) |
32509
+ * | --- | --- | --- |
32510
+ * | storage | `ContentMgmt/Storage` `<hdd>` rows: status, capacity, freeSpace (MB) | `getHddInfoList` (cmd 102): `mount`, `format`, `capacity` GB + `capacityM` MB remainder |
32511
+ * | tracks | several (101 **and** 103 on both 1436 and 3833), each with its own schedule | one per channel |
32512
+ * | schedule | per track, 7 `ScheduleAction` blocks: DayOfWeek + TimeOfDay range + ONE `ActionRecordingMode` | per trigger type, a 168-char weekly HOUR mask |
32513
+ * | triggers | `CMR`, `MOTION` | `Normal`, `MD`, `people`, `vehicle`, `dog_cat`, `crossline`, `intrude`, `loitering` |
32514
+ * | pre-record | `PreRecordTimeSeconds` | `preRecordTime` |
32515
+ * | post-record | `PostRecordTimeSeconds` | `recordDelayTime` |
32516
+ * | overwrite | per track `LoopEnable` | `cycle`, with `cycleList` enumerating the accepted values |
32517
+ * | segment length | not exposed on V5.7.1 | `packageTime` (minutes) |
32518
+ *
32519
+ * The two schedule models look different and are the same thing in
32520
+ * different coordinates: both answer "for this trigger, during which
32521
+ * weekly windows does the camera record". {@link RecordWindow} is that
32522
+ * question in one shape — Hikvision's ranges map straight onto it,
32523
+ * Reolink's mask expands into hour-aligned windows.
32524
+ *
32525
+ * ## Union, not intersection
32526
+ *
32527
+ * **The same fields exist on every camera.** What differs per device is
32528
+ * which VALUES that device accepts, and that is what {@link
32529
+ * RecordingOnboardOptions} reports — a `{ readable, writable, reason }`
32530
+ * per field plus the schedule's own limits. A control a camera cannot
32531
+ * honour is rendered DISABLED WITH ITS REASON, never missing and never
32532
+ * dead: disabled must not look like broken.
32533
+ *
32534
+ * ## Refusal by name
32535
+ *
32536
+ * A write a camera cannot honour is refused with a sentence the operator
32537
+ * can read — never accepted and dropped. Both providers refuse through
32538
+ * {@link describeOnboardRefusal}, so the vocabulary is one function and
32539
+ * one test, not two hand-written vendor opinions.
32540
+ *
32541
+ * Follows the D14 `deviceConfig` archetype (see `stream-params.cap.ts`):
32542
+ * `getOptions` advertises per-camera availability, `getStatus` (auto-
32543
+ * injected from `status`) reports the live values, and a single
32544
+ * `setSettings` mutation applies a partial change. No hand-written
32545
+ * settings-contribution methods.
32546
+ */
32547
+ /**
32548
+ * What makes the camera start recording during a window.
32549
+ *
32550
+ * The union of both vendors' vocabularies. `continuous` is Hikvision's
32551
+ * `CMR` and Reolink's `Normal`; `motion` is `MOTION` / `MD`. The
32552
+ * object-class triggers are Reolink-only today and the smart-event ones
32553
+ * (`lineCrossing`, `intrusion`, `loitering`) are Reolink-only on the
32554
+ * firmwares measured — a camera that cannot record on a trigger simply
32555
+ * does not list it in `options.schedule.triggers`, and a window naming
32556
+ * it is REFUSED, not dropped.
32557
+ */
32558
+ var RecordTriggerSchema = _enum([
32559
+ "continuous",
32560
+ "motion",
32561
+ "person",
32562
+ "vehicle",
32563
+ "animal",
32564
+ "lineCrossing",
32565
+ "intrusion",
32566
+ "loitering",
32567
+ "alarmInput"
32568
+ ]);
32569
+ /**
32570
+ * One weekly recording window: "on `day`, from `startMinute` to
32571
+ * `endMinute`, record on `trigger`".
32572
+ *
32573
+ * `day` is 0 = Monday … 6 = Sunday (ISO order, which is also the order
32574
+ * both firmwares enumerate). Minutes are local camera time since
32575
+ * midnight; `endMinute` may be 1440, meaning end of day — that is
32576
+ * Hikvision's literal `24:00` and Reolink's 24th mask slot, and
32577
+ * collapsing it to 0 would turn a whole-day window into an empty one.
32578
+ */
32579
+ var RecordWindowSchema = object({
32580
+ trigger: RecordTriggerSchema,
32581
+ day: number().int().min(0).max(6),
32582
+ startMinute: number().int().min(0).max(1439),
32583
+ endMinute: number().int().min(1).max(1440)
32584
+ });
32585
+ /** Status of one physical volume, as the camera itself describes it. */
32586
+ var OnboardStorageVolumeSchema = object({
32587
+ /** The camera's own id for the volume (`hdd/id`, Reolink `HddInfo/number`). */
32588
+ id: string(),
32589
+ /** The camera's own name for it, when it gives one (`hddName`). */
32590
+ label: string().optional(),
32591
+ status: _enum([
32592
+ "ok",
32593
+ "unformatted",
32594
+ "error",
32595
+ "offline",
32596
+ "unknown"
32597
+ ]),
32598
+ /**
32599
+ * Total size in MB, or **null when the camera did not say**.
32600
+ *
32601
+ * Never 0 for an unreadable value: a measurement that failed is not a
32602
+ * measurement (D393), and a card whose size is unknown must not be
32603
+ * rendered as a card of size zero.
32604
+ */
32605
+ capacityMb: number().nullable(),
32606
+ /**
32607
+ * Free space in MB, or null when unknown.
32608
+ *
32609
+ * **Not a proxy for "has footage".** Measured 2026-09-22: 1436 and
32610
+ * 1439 both report exactly 11776 MB free — the fixed reserve a looping
32611
+ * card converges on once it has wrapped. At loop steady state the
32612
+ * number is identical whether the camera recorded yesterday or stopped
32613
+ * a month ago.
32614
+ */
32615
+ freeMb: number().nullable(),
32616
+ /** True when the camera reports the volume writable (`property` RW). */
32617
+ writable: boolean().optional()
32618
+ });
32619
+ /**
32620
+ * What the camera is doing with its own storage, right now.
32621
+ *
32622
+ * Every scalar is nullable and **null means the camera did not answer**,
32623
+ * never a default. A form that seeds `0` from an unanswered read invites
32624
+ * the operator to save that 0 back onto the camera.
32625
+ */
32626
+ var RecordingOnboardStatusSchema = object({
32627
+ storage: discriminatedUnion("kind", [
32628
+ object({
32629
+ kind: literal("present"),
32630
+ volumes: array(OnboardStorageVolumeSchema)
32631
+ }),
32632
+ object({
32633
+ kind: literal("absent"),
32634
+ reason: string()
32635
+ }),
32636
+ object({
32637
+ kind: literal("unknown"),
32638
+ reason: string()
32639
+ })
32640
+ ]),
32641
+ tracks: array(object({
32642
+ id: string(),
32643
+ enabled: boolean(),
32644
+ isVideo: boolean(),
32645
+ /** From the camera's own track description. Null when it does not say. */
32646
+ codec: string().nullable(),
32647
+ resolution: string().nullable(),
32648
+ /** Per-track overwrite flag, where the firmware keeps it per track. */
32649
+ overwriteWhenFull: boolean().nullable()
32650
+ })),
32651
+ /**
32652
+ * The track the write path targets — the enabled VIDEO one. Null when
32653
+ * no track could be identified, which is itself a refusal reason.
32654
+ */
32655
+ primaryTrackId: string().nullable(),
32656
+ /** Master "record to the card at all" switch. */
32657
+ enabled: boolean().nullable(),
32658
+ overwriteWhenFull: boolean().nullable(),
32659
+ preRecordSec: number().nullable(),
32660
+ postRecordSec: number().nullable(),
32661
+ /** Length of one recorded file, in minutes. */
32662
+ segmentMinutes: number().nullable(),
32663
+ /** The primary track's weekly windows, flattened. */
32664
+ windows: array(RecordWindowSchema),
32665
+ /**
32666
+ * How many windows the camera described that CamStack could NOT read —
32667
+ * an unrecognised trigger, an unparseable clock, a weekday it does not
32668
+ * name.
32669
+ *
32670
+ * A dropped window is work the reader threw away, and a schedule that
32671
+ * silently shows fewer rows than the camera holds is how an operator
32672
+ * saves back a schedule shorter than the one they were looking at
32673
+ * (D391). Non-zero means the window list is INCOMPLETE and a write
32674
+ * that replaces it would delete what was not shown — which is why a
32675
+ * provider reporting a non-zero count also reports the schedule as not
32676
+ * writable.
32677
+ */
32678
+ unreadableWindows: number(),
32679
+ /**
32680
+ * The camera is scheduled to record and has NO usable storage.
32681
+ *
32682
+ * A first-class fact because it is the fleet's most common silent
32683
+ * defect: measured 2026-09-22, 1441 and 3831 are both motion-recording
32684
+ * to a card that is not there. Neither the schedule nor the storage
32685
+ * read says anything wrong on its own; only the pair does.
32686
+ */
32687
+ recordingToNowhere: boolean(),
32688
+ lastFetchedAt: number()
32689
+ });
32690
+ /** Numeric range descriptor — `{ min, max, step }` per the getOptions convention. */
32691
+ var RangeSchema = object({
32692
+ min: number(),
32693
+ max: number(),
32694
+ step: number()
32695
+ });
32696
+ /**
32697
+ * The values a camera actually takes for a numeric field, when they are a SET
32698
+ * rather than a range.
32699
+ *
32700
+ * `{min,max,step}` cannot say what these two firmwares do. Measured on 1436
32701
+ * (I91DN) on 2026-09-22 by writing each value and reading it back:
32702
+ *
32703
+ * - pre-record: `0, 5, 10, 15, 20, 25, 30` and `2147483647` (INT32_MAX, the
32704
+ * camera's "no limit" — `-1` and `4294967295` both land on it);
32705
+ * - post-record: `5, 10, 30, 60, 120, 300, 600`.
32706
+ *
32707
+ * Neither is expressible as a step: the first has a sentinel two billion away
32708
+ * from its neighbours, the second doubles and then jumps. A range that tried
32709
+ * would forbid values the camera takes AND permit values it silently replaces
32710
+ * with 5 — wrong in both directions at once.
32711
+ *
32712
+ * `sentinel` names the member that is not a duration, so a surface can render
32713
+ * "no limit" instead of `2147483647` seconds.
32714
+ */
32715
+ var AllowedValuesSchema = object({
32716
+ values: array(number()).min(1),
32717
+ sentinel: object({
32718
+ value: number(),
32719
+ meaning: _enum(["no-limit", "disabled"])
32720
+ }).optional()
32721
+ });
32722
+ /**
32723
+ * Per-field availability on ONE camera.
32724
+ *
32725
+ * The field exists on every camera — this says whether this one can be
32726
+ * read and whether it can be written, and `reason` says why not when
32727
+ * either is false. The UI renders the control DISABLED with the reason
32728
+ * rather than hiding it, so a limitation is legible instead of looking
32729
+ * like a missing feature.
32730
+ */
32731
+ var OnboardFieldSupportSchema = object({
32732
+ readable: boolean(),
32733
+ writable: boolean(),
32734
+ /** Required whenever `readable` or `writable` is false. */
32735
+ reason: string().optional()
32736
+ });
32737
+ /** What this camera's schedule model can express. */
32738
+ var OnboardScheduleSupportSchema = object({
32739
+ support: OnboardFieldSupportSchema,
32740
+ /**
32741
+ * The smallest time step the camera can express, in minutes.
32742
+ *
32743
+ * Hikvision takes arbitrary minutes (`00:05:00`–`23:57:00` observed on
32744
+ * 1436's track 103). Reolink's schedule is a 7×24 HOUR mask, so 60. A
32745
+ * window whose edges are not a multiple of this is REFUSED rather than
32746
+ * quietly rounded — rounding is how an operator's 06:30 becomes 06:00
32747
+ * and nothing says so.
32748
+ */
32749
+ granularityMinutes: number(),
32750
+ /** Triggers this camera can record on. A window naming another is refused. */
32751
+ triggers: array(RecordTriggerSchema),
32752
+ /**
32753
+ * False when the camera stores ONE trigger per time range, so two
32754
+ * windows overlapping on the same day cannot carry different triggers.
32755
+ * True on Reolink, whose mask is per-trigger and independent.
32756
+ */
32757
+ supportsOverlappingTriggers: boolean()
32758
+ });
32759
+ var RecordingOnboardOptionsSchema = object({
32760
+ enabled: OnboardFieldSupportSchema,
32761
+ overwriteWhenFull: OnboardFieldSupportSchema,
32762
+ preRecordSec: OnboardFieldSupportSchema,
32763
+ preRecordSecRange: RangeSchema.optional(),
32764
+ /** Preferred over the range when the camera takes a SET, not a span. */
32765
+ preRecordSecAllowed: AllowedValuesSchema.optional(),
32766
+ postRecordSec: OnboardFieldSupportSchema,
32767
+ postRecordSecRange: RangeSchema.optional(),
32768
+ /** Preferred over the range when the camera takes a SET, not a span. */
32769
+ postRecordSecAllowed: AllowedValuesSchema.optional(),
32770
+ segmentMinutes: OnboardFieldSupportSchema,
32771
+ segmentMinutesRange: RangeSchema.optional(),
32772
+ /** Preferred over the range when the camera takes a SET, not a span. */
32773
+ segmentMinutesAllowed: AllowedValuesSchema.optional(),
32774
+ schedule: OnboardScheduleSupportSchema
32775
+ });
32776
+ /**
32777
+ * A partial change. Every field optional.
32778
+ *
32779
+ * Unlike the other `deviceConfig` caps, a provider here does **NOT**
32780
+ * silently ignore a field it cannot support — it refuses, by name,
32781
+ * through {@link describeOnboardRefusal}. Silence on a recording setting
32782
+ * is the failure D62 exists to prevent: the operator believes the camera
32783
+ * is recording the way the form says, and it is not.
32784
+ */
32785
+ var RecordingOnboardPatchSchema = object({
32786
+ enabled: boolean().optional(),
32787
+ overwriteWhenFull: boolean().optional(),
32788
+ preRecordSec: number().optional(),
32789
+ postRecordSec: number().optional(),
32790
+ segmentMinutes: number().optional(),
32791
+ /** The complete new window set for the primary track — not a delta. */
32792
+ windows: array(RecordWindowSchema).optional()
32793
+ });
32794
+ var recordingOnboardCapability = {
32795
+ name: "recording-onboard",
32796
+ scope: "device",
32797
+ deviceNative: true,
32798
+ mode: "singleton",
32799
+ deviceTypes: [DeviceType.Camera],
32800
+ deviceConfig: { ui: {
32801
+ kind: "derived-form",
32802
+ builderId: "recording-onboard",
32803
+ tab: "recording"
32804
+ } },
32805
+ methods: {
32806
+ getOptions: method(object({ deviceId: number() }), RecordingOnboardOptionsSchema),
32807
+ setSettings: method(object({
32808
+ deviceId: number(),
32809
+ settings: RecordingOnboardPatchSchema
32810
+ }), _void(), {
32811
+ kind: "mutation",
32812
+ auth: "admin"
32813
+ })
32814
+ },
32815
+ status: {
32816
+ schema: RecordingOnboardStatusSchema,
32817
+ kind: "poll"
32818
+ },
32819
+ runtimeState: RecordingOnboardStatusSchema,
32820
+ /**
32821
+ * Runtime-state durability: **restored** — operator-set camera-side
32822
+ * recording config; mutation-driven, and the storage half is the last
32823
+ * thing the camera said about its own card.
32824
+ *
32825
+ * See `RuntimeStateDurability`. Enforced by
32826
+ * `scripts/check-runtime-state-durability.ts`.
32827
+ */
32828
+ durability: "restored",
32829
+ /** Clock fields: written, but excluded from the compare that decides
32830
+ * whether persisting is worth a SQLite commit. */
32831
+ volatileStateFields: ["lastFetchedAt"]
32832
+ };
32833
+ /**
32206
32834
  * Generic device-level status snapshot. Auto-registered by `BaseDevice`
32207
32835
  * for every device, regardless of provider — the kernel needs a uniform
32208
32836
  * cap-keyed slice for the basic device flags every consumer expects to
@@ -42942,6 +43570,7 @@ var ALL_CAPABILITY_DEFINITIONS = [
42942
43570
  dayNightCapability,
42943
43571
  decoderCapability,
42944
43572
  detectionPipelineCapability,
43573
+ deviceAdminLinkCapability,
42945
43574
  deviceAdoptionCapability,
42946
43575
  deviceDiscoveryCapability,
42947
43576
  deviceExportCapability,
@@ -43016,6 +43645,7 @@ var ALL_CAPABILITY_DEFINITIONS = [
43016
43645
  rebootCapability,
43017
43646
  recordingCapability,
43018
43647
  recordingExportCapability,
43648
+ recordingOnboardCapability,
43019
43649
  recordingSignalCapability,
43020
43650
  sceneMonitorCapability,
43021
43651
  scriptRunnerCapability,
@@ -44360,6 +44990,12 @@ Object.freeze({
44360
44990
  addonId: null,
44361
44991
  access: "view"
44362
44992
  },
44993
+ "deviceAdminLink.getAdminLink": {
44994
+ capName: "device-admin-link",
44995
+ capScope: "device",
44996
+ addonId: null,
44997
+ access: "view"
44998
+ },
44363
44999
  "deviceAdoption.adopt": {
44364
45000
  capName: "device-adoption",
44365
45001
  capScope: "system",
@@ -48398,6 +49034,24 @@ Object.freeze({
48398
49034
  addonId: null,
48399
49035
  access: "view"
48400
49036
  },
49037
+ "recordingOnboard.getOptions": {
49038
+ capName: "recording-onboard",
49039
+ capScope: "device",
49040
+ addonId: null,
49041
+ access: "view"
49042
+ },
49043
+ "recordingOnboard.getStatus": {
49044
+ capName: "recording-onboard",
49045
+ capScope: "device",
49046
+ addonId: null,
49047
+ access: "view"
49048
+ },
49049
+ "recordingOnboard.setSettings": {
49050
+ capName: "recording-onboard",
49051
+ capScope: "device",
49052
+ addonId: null,
49053
+ access: "create"
49054
+ },
48401
49055
  "recordingSignal.getStatus": {
48402
49056
  capName: "recording-signal",
48403
49057
  capScope: "device",
@@ -49862,6 +50516,12 @@ Object.freeze({
49862
50516
  addonId: null,
49863
50517
  access: "view"
49864
50518
  },
50519
+ "videoclips.getPlaybackOptions": {
50520
+ capName: "videoclips",
50521
+ capScope: "device",
50522
+ addonId: null,
50523
+ access: "view"
50524
+ },
49865
50525
  "videoclips.listClips": {
49866
50526
  capName: "videoclips",
49867
50527
  capScope: "device",
@@ -49874,6 +50534,12 @@ Object.freeze({
49874
50534
  addonId: null,
49875
50535
  access: "view"
49876
50536
  },
50537
+ "videoclips.offerClipBytes": {
50538
+ capName: "videoclips",
50539
+ capScope: "device",
50540
+ addonId: null,
50541
+ access: "view"
50542
+ },
49877
50543
  "videoclips.readClipBytes": {
49878
50544
  capName: "videoclips",
49879
50545
  capScope: "device",
@@ -50284,6 +50950,11 @@ Object.freeze({
50284
50950
  form: "single",
50285
50951
  optional: true
50286
50952
  }],
50953
+ "deviceAdminLink.getAdminLink": [{
50954
+ name: "deviceId",
50955
+ form: "single",
50956
+ optional: false
50957
+ }],
50287
50958
  "deviceAdoption.release": [{
50288
50959
  name: "camDeviceId",
50289
50960
  form: "single",
@@ -51669,6 +52340,16 @@ Object.freeze({
51669
52340
  form: "single",
51670
52341
  optional: true
51671
52342
  }],
52343
+ "recordingOnboard.getOptions": [{
52344
+ name: "deviceId",
52345
+ form: "single",
52346
+ optional: false
52347
+ }],
52348
+ "recordingOnboard.setSettings": [{
52349
+ name: "deviceId",
52350
+ form: "single",
52351
+ optional: false
52352
+ }],
51672
52353
  "recordingSignal.getStatus": [{
51673
52354
  name: "deviceId",
51674
52355
  form: "single",
@@ -51905,6 +52586,11 @@ Object.freeze({
51905
52586
  form: "single",
51906
52587
  optional: false
51907
52588
  }],
52589
+ "videoclips.getPlaybackOptions": [{
52590
+ name: "deviceId",
52591
+ form: "single",
52592
+ optional: false
52593
+ }],
51908
52594
  "videoclips.listClips": [{
51909
52595
  name: "deviceId",
51910
52596
  form: "single",
@@ -51915,6 +52601,11 @@ Object.freeze({
51915
52601
  form: "single",
51916
52602
  optional: false
51917
52603
  }],
52604
+ "videoclips.offerClipBytes": [{
52605
+ name: "deviceId",
52606
+ form: "single",
52607
+ optional: false
52608
+ }],
51918
52609
  "videoclips.readClipBytes": [{
51919
52610
  name: "deviceId",
51920
52611
  form: "single",