Mock Devices

Mock devices in Elements Hub provide simulated device behaviour for development, testing and demonstration. They implement the same interfaces as real devices but return predictable, simulated data without requiring physical hardware. Every endpoint described in this manual works against a mock device — including scans, connect/disconnect, measurements and image streams.

When to Use Mock Devices

• Development: build and test integrations without physical instruments.
• CI / automated tests: deterministic, hardware-free test runs.
• Demonstrations: show the API surface without a hardware setup.
• Training: learn the workflow before touching real equipment.

Available Mock Device Classes

Apart from the device class, mock devices are addressed and used exactly like real devices — there is no separate URL prefix or parameter.

Using a Mock Device

Just substitute the device class in a regular scan request:

POST /v1/device-scans
Content-Type: application/json

{
  "deviceClass": "aesthetix-mock"
}

curl -X POST http://localhost:42042/v1/device-scans \
  -H "Content-Type: application/json" \
  -d '{ "deviceClass": "aesthetix-mock" }'

Then poll for the discovered device, connect, and use it as documented for the real variant:

# Wait for discovery
curl http://localhost:42042/v1/available-devices

# Connect using the identifier from the response
curl -X POST http://localhost:42042/v1/devices \
  -H "Content-Type: application/json" \
  -d '{ "deviceIdentifier": "<identifier-from-above>" }'

# Trigger a measurement — same payload as for a real device
curl -X POST http://localhost:42042/v1/devices/<identifier>/measurement-triggers \
  -H "Content-Type: application/json" \
  -d '{ "measurementKey": "measure", "containerFormat": "raeBinary" }' \
  --output measurement.rae

The <identifier> is returned by GET /v1/available-devices and is a hex string generated by the hub at scan time — it is not derived from the device class or serial number.

What the Mocks Actually Return

aesthetix-mock / aesthetix-inline-mock

• Connect: succeeds instantly, no hardware initialisation.
• Calibrations: same set as the real device (see Calibration) but with simulated execution.
• Measurements: the hub reads a pre-recorded .rae file from disk and returns its first measurement (see Mock data file). If the file is missing, POST /measurement-triggers fails with `E20UnableToFindMockFile`.
• Images: procedurally generated colour-grid patterns, PNG-encoded, with the source-key label overlaid.

id-inline-mock

• Connect: succeeds instantly. Accepts the real device's flipX / flipY parameters but does not act on them.
• Measurements: returns a small fixed set of metrics (haze, sharpness, clarity, waviness, transmission) plus a generated sample image.
• Images: procedurally generated 1280 × 1024 BMP patterns, returned with MIME type image/bmp.

Mock Data File

The Aesthetix mock devices need a real .rae file on disk to return measurement data. The path is fixed:

{dataDirectory}/aesthetix-mock.rae

{dataDirectory} is the dataDirectory passed to `POST /v1/lifecycle/initialize`. If the file is missing, every measurement request fails with E20UnableToFindMockFile. There is no appsettings.json switch to point the mock at a different file — drop a recorded .rae at the path above instead.

A working starting point is any RAE file produced by a real Aesthetix measurement. Copy it to {dataDirectory}/aesthetix-mock.rae once and every subsequent mock measurement replays it.

Mock vs Real Devices

Best Practices

• Develop and CI-test against the mock; switch to the real device only for final validation.
• Pin the test .rae file in version control alongside the integration tests that consume it.
• Keep mock-only assumptions out of integration tests — the workflow should be identical to the real-device path, only the device class changes.
• For tests that exercise the failure path, deliberately omit the mock .rae file and assert on E20UnableToFindMockFile.

Related Pages

• Device Scans — scan request shape and response format
• Connected Devices — connect/disconnect lifecycle
• Measurement Triggers — measurement payload
• Error Handling — ErrorInfo schema and error codes