docs(camera): correct the "dead camera" conclusion — root cause was undrawn detection area

The Hik DS-2CD1043G2-LIU was NOT defective. An earlier wiki entry wrongly
concluded it needed RMA (dead event engine) based on a silent alertStream
+ diskfull/EventScribe:except + dead RTC surviving a full factory reset.

Real cause: no detection AREA was drawn on the frame. With no region, the
camera detects nothing -> generates no event -> posts nothing. The instant
an area was drawn, the first vehicle produced a clean POST.

- Flag "draw the detection area" as the FIRST thing to check.
- Document the confirmed real payload: multipart/form-data (MoveDetection.xml),
  EventNotificationAlert with eventType=VMD, eventState=active,
  targetType=vehicle (vehicle/human classified on-device), targetRect bbox.
  Note the dateTime is garbage (dead RTC) -> use our own receive time.
- Reframe the SSH diagnostics: diskfull/EventScribe/RTC are RED HERRINGS,
  not proof of a dead camera; don't escalate to hardware fault while a basic
  config precondition is unmet.
- Append a log correction (append-only) superseding the earlier conclusion.

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

wiki/entities/lpr-camera.md

@@ -106,30 +106,55 @@ Several traps surfaced trying to get a real camera to push. In order of how long
   it stays `true` across reboots and won't retry. Clear it by **re-PUTting** the httpHost config
   (`PUT /ISAPI/Event/notification/httpHosts/1` with `<httpBroken>false</httpBroken>`).
 - **"Notify Surveillance Center" ≠ the HTTP Alarm Server** on some firmware (separate upload
-  channels); and **basic Motion Detection may not POST to the httpHost** while smart/VCA events do.
-  Always confirm the **Arming Schedule** covers the test time, too (a silent killer).
+  channels). Always confirm the **Arming Schedule** covers the test time, too (a silent killer).
+- **⭐ THE ROOT CAUSE (2026-06-22): no detection AREA drawn.** This is what actually defeated us for
+  most of a day. On the motion/smart-detection page there's a **Draw Area** step — if **no region is
+  drawn on the frame, the camera detects nothing, generates NO event, and therefore posts nothing**
+  anywhere (httpHost, FTP, alarm stream all stay silent because there's no event upstream). Enabling
+  the detection + ticking Notify Surveillance Center is **not enough** — you must draw the region.
+  Once an area was drawn, the very first vehicle produced a clean POST. **Check this FIRST.**
 
-### Diagnosing a non-pushing camera — read its OWN state, don't guess
+### Confirmed real payload (DS-2CD1043G2-LIU, V5.8.10, 2026-06-22)
 
-Status APIs lie (a `diskfull` error on a camera with **no disk** is a misleading label). The decisive
-checks, in order — they need no cooperation from our server:
+What this camera actually POSTs on a motion event with a target — captured end-to-end:
 
-1. **`GET /ISAPI/Event/notification/alertStream`** (Digest) — the camera's live event bus. A HEALTHY
-   camera streams periodic multipart heartbeat frames even when idle, and an event line when one
-   fires. **Total silence (no heartbeat) for 20s = the event subsystem is producing nothing** — the
-   fault is internal, upstream of any linkage (HTTP host, FTP, alarm stream all die together).
-2. **SSH into the camera** (BusyBox "psh" restricted shell; default creds work): `showStatus` →
-   look for **`EventScribe: except`** (event subsystem in an exception state); `dmesg` → UBIFS
-   "recovery needed" on every volume (unclean flash) and **`fh rtc get time error ffffffff`** (dead
-   RTC — a hardware fault; the clock reads 1970, which wedges time-keyed event logic). `ps` shows the
-   `davinci` app. `df`/`printPart` are NOT available; partition sizes via the UBIFS lines in `dmesg`.
-3. **`netstat` on the camera** while triggering — watch for an OUTBOUND line `cam:port → server:3000`.
-   None appearing = the camera never even attempts the POST.
+- **`Content-Type: multipart/form-data; boundary=boundary`**, one XML part named `MoveDetection.xml`
+  (`Content-Type: application/xml`). A real frame/JPEG *may* be attached as a second part on other
+  event types — our endpoint stores the readable head; splitting an image part to `snapshots` is a
+  forward step (not needed for plain motion).
+- The XML is an `EventNotificationAlert` with the fields we care about:
+  - `<eventType>VMD</eventType>` (Video Motion Detection) + `<eventState>active</eventState>`
+  - **`<targetType>vehicle</targetType>`** — the camera classifies **vehicle vs human ON-DEVICE**.
+    (Field is `targetType`, NOT `detectionTarget`.) This means simple presence + class comes for
+    free, no vision model needed for that part.
+  - `<targetInfo><targetRect>` with normalized `X/Y/width/height` (0–1) — the **bounding box**.
+  - `<channelID>`, `<macAddress>` (provenance), `<dateTime>` — **but the dateTime is GARBAGE**
+    (`2032-…`) because this unit's **RTC is dead** (see below); we use our own server receive time,
+    never the camera's. (No `<plateNumber>` — this is a motion event, not an ANPR camera.)
 
-> **Verified-dead unit (2026-06-22):** a `DS-2CD1043G2-LIU` (V5.8.10, 8 months old) failed all three:
-> silent alertStream, `EventScribe: except`, `diskfull` on `Event/triggers`, dead RTC, and **zero
-> outbound to `:3000`** across a 3-minute netstat watch — through reboot, basic reset, AND full
-> factory reset. Conclusion: **defective event engine (RMA)**, not our integration. Our endpoint was
-> verified correct throughout (it accepts + records a POST the instant one actually arrives). When a
-> camera's event push is dead, fall back to the **pull + [[opencv-anpr-service|vision]]** path, which
-> works with the same camera (it still serves snapshots fine).
+### If a camera still won't push — diagnostics (read its OWN state)
+
+Only after confirming the **detection area is drawn** + arming schedule covers now + Notify
+Surveillance Center is on. These read the camera directly (no cooperation from our server):
+
+1. **`netstat` on the camera (via SSH) while you trigger** — watch for an OUTBOUND line
+   `cam:port → server:3000`. It appearing = the camera fired and is delivering (then check our
+   `/api/devices/hikvision/alarms`). None = no event was generated (almost always: **no area drawn**).
+2. **`GET /ISAPI/Event/notification/alertStream`** (Digest, needs a clean handshake) — the live event
+   bus. NB: a `curl --digest` tap that fails the handshake returns empty and looks like "no events"
+   — don't over-read silence here (this misled us); the netstat watch above is more reliable.
+3. **SSH `showStatus` / `dmesg`** expose internal state. ⚠ **Caveat learned the hard way:** these
+   surface scary-looking strings that are **red herrings** — `EventScribe: except`, a `diskfull`
+   error on `Event/triggers` (on a camera with **no disk**), and `fh rtc get time error` / a 1970
+   clock. On our unit ALL of these were present **and the camera worked fine** once an area was
+   drawn. The dead RTC is real (hence the bogus `dateTime`) but **harmless** to event push. **Do NOT
+   conclude "dead camera / RMA" from these** — they are not proof of a broken event engine.
+
+> **Correction (2026-06-22):** an earlier version of this page concluded this DS-2CD1043G2-LIU was a
+> **defective unit needing RMA**, based on the silent alertStream + `diskfull`/`EventScribe:except` +
+> dead RTC surviving a full factory reset. **That was WRONG.** The camera was healthy; the real cause
+> was simply **no detection area drawn**, so no event was ever generated. The `diskfull`/RTC findings
+> were unrelated quirks (RTC genuinely dead, but it doesn't block event push). Lesson: don't
+> escalate to "hardware fault" while a basic config precondition (the drawn region) is unmet — and
+> treat vendor status-API error strings as unreliable. The pull + [[opencv-anpr-service|vision]] path
+> remains a valid fallback, but it was not needed here.

wiki/log.md

@@ -1398,3 +1398,17 @@ error / clock at 1970), and ZERO outbound to :3000 over a 3-min netstat watch, s
 basic reset + FULL factory reset. Verdict: defective camera (RMA), not our code. Captured the
 diagnostic method (alertStream silence / SSH showStatus / netstat) in [[lpr-camera]]. Fallback for a
 dead-push camera: pull + [[opencv-anpr-service|vision]] (the same camera still serves snapshots).
+
+## [2026-06-22] CORRECTION | Hik camera was NOT defective — the cause was an undrawn detection area
+Supersedes the earlier "[2026-06-22] debug" entry's conclusion that the DS-2CD1043G2-LIU had a dead
+event engine needing RMA. WRONG. The camera is healthy; it pushed a clean event the instant a
+detection AREA was drawn on the frame (the "Draw Area" step). With no region drawn, the camera
+detects nothing → generates no event → posts nothing anywhere — which produced all the symptoms
+(silent alertStream, zero outbound to :3000). The diskfull / EventScribe:except / dead-RTC findings
+were red herrings (the RTC is genuinely dead, hence a bogus 2032 dateTime in the payload, but it does
+NOT block event push). Lesson: don't escalate to "hardware fault" while a basic config precondition
+is unmet; vendor status-API error strings are unreliable. Confirmed real payload: multipart/form-data
+(MoveDetection.xml) with EventNotificationAlert -> eventType=VMD, eventState=active,
+targetType=vehicle (vehicle/human classified ON-DEVICE), targetRect bounding box. The push endpoint +
+all-methods + skipSourceIpCheck + rejection-recording are all validated against the real device now.
+See [[lpr-camera]] (corrected).