Run your first test

Start here after installing and booting the agent. Keep the booter terminal visible and open a second terminal for the checks below.

Commands use the default ports. Check healthcam-agent/runtime/service-registry.json if your assignments differ. In Windows PowerShell, use curl.exe instead of curl to avoid its legacy alias.

1. Verify service readiness

Check the orchestrator, camera, and app tracker:

curl http://127.0.0.1:8008/health
curl http://127.0.0.1:8008/services_status
curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8002/health
curl http://127.0.0.1:8002/context

The orchestrator health response should contain status: "success". Its service listing should show the enabled capture/context/analyzer services as available. Check individual health results for missing camera access, dependencies, or desktop permissions. App context should identify the focused application.

For your enabled analyzer, run the corresponding check:

# Blink analyzer
curl http://127.0.0.1:8039/health

# BPM analyzer, only if enabled
curl http://127.0.0.1:8009/health

BPM health should report working GPU dependencies rather than no_cuda or a degraded status. Blink health checks OpenCV availability; it does not prove that MediaPipe inference or landmark detection will succeed. The short recording below is the actual integration check.

2. Start a short recording

Use a non-sensitive desktop window, place your face in view, and use steady lighting. Start capture explicitly:

curl -X POST http://127.0.0.1:8008/start
curl http://127.0.0.1:8008/status

Expect a successful start response and a running phase. The web dashboard's Start New Recording control calls the same local endpoint, if the browser permits the connection.

Allow at least two configured segment intervals, plus inference and upload time. At the default 20 seconds per segment, this means at least 40 seconds before evaluating the result; slow machines or GPU initialization can take longer.

3. Follow the segment through the pipeline

Video files and JSON sidecars appear under healthcam-agent/services/camera-capture/segments/. The orchestrator waits for a sidecar and a minimum file age before processing a segment. A successful upload can delete files quickly, so an empty directory alone does not mean capture failed.

Read the orchestrator log in another terminal:

docker logs --tail 100 orchestrator

For a successful run, look for these stages:

Inspect only the analyzer you enabled:

docker logs --tail 100 blink-dt-0-0-1

docker logs --tail 100 diego-turri-bpm-estimator-pyvhr-v-0-0-1

For blink, look for the returned metric object, blink events, and quality fields. NO_EYES_DETECTED or INSUFFICIENT_EYE_VISIBILITY is a no-result outcome, not a measured blink rate of zero. An upload succeeding does not guarantee usable measurements.

Logs can contain application/window details, file paths, and result payloads. Redact them before sharing diagnostics.

4. Verify the cloud result

Sign in to the same personal workspace whose key you configured. A successful upload should appear in Recordings. The current recordings view is BPM-oriented: blink-only records can show a zero BPM fallback rather than blink metrics. Use the analyzer logs to inspect blink results; a full blink dashboard is not implemented yet.

For a BPM run, add the BPM & App Context dashboard from the Store. Its derived data is updated by a workflow scheduled every five minutes, so a new upload is not immediately visible in charts. Scheduled jobs can be delayed.

The per-application charts currently filter out applications with 30 minutes or less of tracked data. A short smoke test can verify ingestion without filling those charts. Use Recordings and upload logs as the immediate acceptance checks.

For your own local web/database setup, aggregation is manual until you configure scheduling. See Run the web app locally.

5. Stop capture and drain pending work

To let completed segments finish before stopping the pipeline, stop the camera first:

curl -X POST http://127.0.0.1:8000/stop

Wait for pending analysis/upload logs to finish. Then stop the orchestrator pipeline:

curl -X POST http://127.0.0.1:8008/stop
curl http://127.0.0.1:8008/status

Expect the orchestrator to return to idle. Press Ctrl+C in the booter terminal to shut down the services. The dashboard's stop control stops the whole pipeline immediately, so it can interrupt in-flight work.

The dispatcher is an in-memory queue. Failed analysis, interrupted work, or rejected uploads can leave video locally. Inspect the segments directory after shutdown and remove only test files you no longer need. Do not assume that stopping the agent clears them.

Acceptance checklist

• The enabled services respond and report usable dependencies.
• Capture produces a video segment and timestamp sidecar.
• The chosen analyzer returns either measurements or an explicit no-result reason.
• The orchestrator reports successful cloud upload and the personal workspace shows a record.
• Successfully uploaded segments are cleaned up.
• Capture stops and the pipeline returns to idle.

This verifies the installation and transport path. Scientific accuracy needs a separate reference-device experiment; it is not established by a green health endpoint or populated chart.