Decoding integer fields in Alerts\OnTrigger registry — does a community reference exist?

I've been building an MCP server (bi-mcp) that lets an AI agent read Blue Iris config from the camera .reg exports,
including the per-camera action sets under Alerts\OnTrigger\<N> and Alerts\OnReset\<N>. Most of the schema is
self-explanatory once you've seen a few exports — web_path, soundPath, camname, descript, etc. — but a few fields are
integer-coded and I haven't found public documentation:

- type — the action kind. In my install I only see type=3 (Web/MQTT) and type=12 (Do Command). The other 12 BI action kinds
(Sound, Push, Email, SMS, Phone, Run Program, DIO Bits, Popup, FTP Upload, Change Shield, Change Schedule/Profile, Wait)
must each have their own integer, but I haven't toggled them in the UI yet to see what they serialize to.
- command — for type=12 Do Command actions. I see 2200..2299 for PTZ-preset recall (command=2202 = "call PTZ preset 2"),
and the manual lists ~30 do-commands in the dropdown (snapshot, profile change, /admin?, etc.) but I don't have their
integer codes.
- web_proto1 — protocol enum for type=3. I see 2 = MQTT; the UI offers HTTP-GET, HTTP-POST, MQTT, and TCP, so there are
presumably 3 more values.
- trig_source — looks like a wider bitmask (I see 132, 16514, 16516, 16518, 16522; bit 14 = 16384 seems to correlate with
AI confirmation). I haven't worked out the full bit layout.

I've already searched the forum (trig_source returns zero hits forum-wide; OnTrigger returns one on-topic post about a V6
upgrade) and the obvious GitHub projects (bp2008/BlueIrisRegistryReader, VorlonCD/bi-aidetection, magapp/blueiriscmd) —
none of them touch the action-set blobs. I half-remember someone (maybe @jaydeel ?) doing systematic .reg diffs across BI
versions to catch undocumented additions. If that's you, or you've seen the work, I'd love a pointer.

Worst case I just toggle each option in the UI on a throwaway camera and diff the exports — but if someone's already done
this, I'd rather build on top of it than redo it. Happy to publish whatever decoder tables I end up with back to the
community.

Thanks!

I'm kind of excited about this MCP server, I would have it finished, but I have to build it in stages because I'm not paying for extra usage credits for this. I'm obviously running this thing in Claude Code. I believe this thing is going to be POWERFUL, its hard at this point to imagine all the use cases but for example, I recently got a PTZ5A4M-25X. I was having an issue with a race condition from my spotter cams pulling my PTZ away to preset while tracking. For a week I went back and forth with having a clone for AI confirmation, and "skip alerts when this preset is active" on the master vs. just using the PTZ for everything with "skip alerts when this preset is active" disabled. Watching days worth of clips trying to analyze the results myself. Yesterday I ran a test without the clone and had Claude do an analysis using the MCP server... Here is how it went down all from one prompt.

Question: does the SecCam_11AI clone actually do work, or was periodic-scan-only on the master enough to suppress the
spotter-pull race?

Tools used for the clone A/B analysis

1. bi_list_log (admin) — the keystone tool
- Pulled the BI system log to find Alert skipped (PTZ preset N) events across the 4-day window
- This is what produced the 28-event count and the zero-on-2026-05-16 finding
- Requires the claude-admin BI user (admin-gated cmd)

2. bi_list_alerts — per-camera alert correlation
- Listed alerts on the spotter cameras (SecCam_1/3/4) and the PTZ clone in the test window
- Used to find the ±5s context around each Alert skipped log line — i.e., which spotter was triggering at the moment the
master was locked to a different preset

3. bi_get_alert_tracks + bi_get_clip_info — to verify individual race events
- Pulled tracks/clip metadata on the suspect alerts to confirm the person was actually in-frame on the spotter while the
PTZ held its lock elsewhere

4. bi_list_cameras — to confirm clone visibility state
- Verified SecCam_11 was hidden: true and SecCam_11AI was hidden: false after the rebuild

5. bi_get_reg + bi_get_actionset — to audit the actual on-disk config
- Inspected Alerts\OnTrigger on the spotters to confirm the type=12 PTZ-call actions were the source of the pull
- Inspected the PTZ master's skip-alerts flags per preset

6. The human side
- You were the one who deleted the clone on 2026-05-16 and rebuilt it on 2026-05-17 night; I didn't drive that. The MCP
read-tools just measured the result.

Method: A/B test over ~36h.
- 2026-05-16: clone deleted, ran periodic-scan-only on the PTZ master for ~1 day
- 2026-05-17 night: clone rebuilt
- 2026-05-18 17:34: audited the BI log

Evidence in the log (4-day window):
- 28 Alert skipped (PTZ preset N) events across presets 1, 2, 3, 4, 6
- Zero on 2026-05-16 — the day the clone was absent
- 13 race-condition saves in the first ~19h post-rebuild, several with ±5s context showing a spotter (SecCam_1/3/4)
triggering on a person while the PTZ held a different preset, and being suppressed

Conclusion: the clone's priority lock is what's doing the work, not periodic-scan timing. Do NOT propose deleting the clone
again.

The architecture it locked in

- SecCam_11 — hidden master, all tracking presets have skip-alerts ON, holds the priority lock so spotters can't yank it
mid-track. Produces no Person-alert clips.
- SecCam_11AI — visible clone of the same physical camera, no skip-alerts, runs the AI scan and produces the Person-alert
clips.

This is the documented community workaround for the "want priority lock AND want alert images" conflict — you can't get
both from a single camera definition because skip-alerts kills the alert pipeline on the same camera that owns the lock.

Stored in:
- project_ptz_alert_pipeline.md — full A/B test result and configuration
- project_camera_roster.md — both camera entries flagged with the test outcome
- Do-not-delete-the-clone warning lives in both

The reason I started playing around with this is because I'm running a MCP server for HomeAssistant, along side Googles MCP server for chrome, and also giving Claude ssh access to my HomeAssistant box running HAOS. There is nothing I cant do with this thing. It has a full feedback loop. Its so powerful I cant even begin to put it into words... I just tell it what i want like its a magic genie and it builds it. I'm now only limited by imagination on building dashboards. I don't know HTML or CSS but if i can explain it or give Claude an example it will build - test - and verify by inspecting the webpage in chrome dev tools and looking at screenshots until it gets it right. I hope I don't sound crazy. But I don't think most people can even imagine. Vibe coding is cool... but when you have a complete feedback loop this thing is crazy powerful. The people that think they are using AI by using it like a google search in web are going to be so far behind. This space is changing daily, it'll be impossible to catch up. I haven't been this excited about something since 2016 going into 17 with crypto. I was impressed last year with copy and pasting code into web chats but it was no where near "there" yet. Now its there, and it will only get more powerful at insane pace.