IvedaAI: configure and test alert-routing integrations

Configures and tests AlertRule.trigger — the mechanism that routes IvedaAI alerts to external systems (generic HTTP webhooks, named VMS/PSIM platforms, email, Immix, mobile push). The raw API schema here is deeply nested and has undocumented gotchas (see below), confirmed by live testing rather than the spec alone.

Actions: list_types — no API call; returns this same type/testability reference as JSON. test — builds the correct trigger payload for type+config and calls POST /api/alertTriggers to live-test it, returning a plain-language verdict (success / unsupported / invalid_config / connection_failed). Only 'request', 'mobile', and the 13 VMS types are testable — 'mail'/'immix' always return 'unsupported' (confirmed against a real server). How long a VMS connection failure takes to report is unpredictable — repeated tests against the same unreachable address ranged from under a second to ~24s in testing, not tied to any particular vendor — the default 60000ms timeout is meant to cover the slow case regardless of which VMS type you're testing; override via timeoutMs if you need even more headroom. apply — attaches the built trigger to an existing alert rule (alertRuleId, its UUID). Does not require having called 'test' first, but doing so is recommended. It reads the rule first and re-sends everything the read exposes alongside the new trigger: name (returned as alertName), alertType, description, isEnabled, plus weekdays/enableForever from schedule and roiIds/cameraIds/hashtags/typeLogic/cooldownInterval parsed out of the condition JSON string. It refuses to write if that read fails or lacks the required fields. This is precaution rather than repair — PATCH /api/alertRules/{alertRuleId} was live-tested and merges, leaving omitted fields alone, so applying a trigger does not wipe the rule. (PUT on the same path is different: it rejects a partial body with a 500, so send the full object there.)

Config shape by category: webhook (request): { method, url, headers?, params?, authorization?, httpBody? } — authorization/httpBody default to {auth:"NONE"}/{type:"NONE"} automatically; the server requires them present even when unused, despite the spec marking them optional. vms (13 named platforms): { ip, port, username?, password?, protocol?, severity?, cameraIds?, ... } — see ivedaai_get_schema("AlertTriggerNvr") for the full field list. mail/immix: { emails: [{mailIds?, subject?, content?}], smtpServer, port } mobile: { enableCriticalAlertNotice? } (all fields optional)

Type reference: WEBHOOK: request — testable — Generic outbound HTTP webhook — POST/GET/etc. to any URL. MOBILE: mobile — testable — Push notification to the IvedaAI mobile app. VMS: milestone — testable — Milestone VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. genetec — testable — Genetec VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. nx — testable — Nx VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. dw — testable — Dw VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. lux — testable — Lux VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. salient — testable — Salient VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. axis — testable — Axis VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. ocularis — testable — Ocularis VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. digifort — testable — Digifort VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. avigilon — testable — Avigilon VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. hanwha — testable — Hanwha VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. amag — testable — Amag VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. idis — testable — Idis VMS/PSIM integration. Live-testable, but how long a failed connection takes to report back is unpredictable — repeated tests against the same unreachable address varied from under a second to ~24 seconds in testing, seemingly based on real-time network conditions (immediate rejection vs. a silent connect timeout) rather than being a fixed property of any one vendor. Use a generous timeout regardless of which VMS type you're testing. MAIL: mail — NOT testable via 'test' — SMTP email notification. Not live-testable via POST /api/alertTriggers (confirmed: returns "Unsupported check connection alert trigger type"). immix — NOT testable via 'test' — Immix alarm-monitoring-station notification. Shares mail's underlying type; not live-testable either (confirmed).