From df6a1ca63abd2b985a108a4d4d212098b9fc8b45 Mon Sep 17 00:00:00 2001 From: Julian Cuni Date: Mon, 22 Jun 2026 16:53:22 +0200 Subject: [PATCH] =?UTF-8?q?docs(camera):=20correct=20the=20"dead=20camera"?= =?UTF-8?q?=20conclusion=20=E2=80=94=20root=20cause=20was=20undrawn=20dete?= =?UTF-8?q?ction=20area?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 71 +++++++++++++++++++++++++------------ wiki/log.md | 14 ++++++++ 2 files changed, 62 insertions(+), 23 deletions(-) diff --git a/wiki/entities/lpr-camera.md b/wiki/entities/lpr-camera.md index ec1139e..02ffaf7 100644 --- a/wiki/entities/lpr-camera.md +++ b/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 `false`). - **"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: + - `VMD` (Video Motion Detection) + `active` + - **`vehicle`** — 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. + - `` with normalized `X/Y/width/height` (0–1) — the **bounding box**. + - ``, `` (provenance), `` — **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 `` — 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. diff --git a/wiki/log.md b/wiki/log.md index 9adc73a..691ca9a 100644 --- a/wiki/log.md +++ b/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).