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
2026-06-22 16:53:22 +02:00
parent 547061edf9
commit df6a1ca63a
2 changed files with 62 additions and 23 deletions
@@ -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.
+  channels). Always confirm the **Arming Schedule** covers the test time, too (a silent killer).
-  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
+What this camera actually POSTs on a motion event with a target — captured end-to-end:
 checks, in order — they need no cooperation from our server:
-1. **`GET /ISAPI/Event/notification/alertStream`** (Digest) — the camera's live event bus. A HEALTHY
+- **`Content-Type: multipart/form-data; boundary=boundary`**, one XML part named `MoveDetection.xml`
-   camera streams periodic multipart heartbeat frames even when idle, and an event line when one
+  (`Content-Type: application/xml`). A real frame/JPEG *may* be attached as a second part on other
-   fires. **Total silence (no heartbeat) for 20s = the event subsystem is producing nothing** — the
+  event types — our endpoint stores the readable head; splitting an image part to `snapshots` is a
-   fault is internal, upstream of any linkage (HTTP host, FTP, alarm stream all die together).
+  forward step (not needed for plain motion).
-2. **SSH into the camera** (BusyBox "psh" restricted shell; default creds work): `showStatus` →
+- The XML is an `EventNotificationAlert` with the fields we care about:
-   look for **`EventScribe: except`** (event subsystem in an exception state); `dmesg` → UBIFS
+  - `<eventType>VMD</eventType>` (Video Motion Detection) + `<eventState>active</eventState>`
-   "recovery needed" on every volume (unclean flash) and **`fh rtc get time error ffffffff`** (dead
+  - **`<targetType>vehicle</targetType>`** — the camera classifies **vehicle vs human ON-DEVICE**.
-   RTC — a hardware fault; the clock reads 1970, which wedges time-keyed event logic). `ps` shows the
+    (Field is `targetType`, NOT `detectionTarget`.) This means simple presence + class comes for
-   `davinci` app. `df`/`printPart` are NOT available; partition sizes via the UBIFS lines in `dmesg`.
+    free, no vision model needed for that part.
-3. **`netstat` on the camera** while triggering — watch for an OUTBOUND line `cam:port → server:3000`.
+  - `<targetInfo><targetRect>` with normalized `X/Y/width/height` (0–1) — the **bounding box**.
-   None appearing = the camera never even attempts the POST.
+  - `<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:
+### If a camera still won't push — diagnostics (read its OWN state)
-> 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
+Only after confirming the **detection area is drawn** + arming schedule covers now + Notify
-> factory reset. Conclusion: **defective event engine (RMA)**, not our integration. Our endpoint was
+Surveillance Center is on. These read the camera directly (no cooperation from our server):
-> 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
+1. **`netstat` on the camera (via SSH) while you trigger** — watch for an OUTBOUND line
-> works with the same camera (it still serves snapshots fine).
+   `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.
@@ -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).