# Mock Devices > [!note] Esta página aún no está traducida y se muestra en inglés. 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](rhopoint-elements-hub-endpoints-functionality-device-scans.md), [connect/disconnect](rhopoint-elements-hub-endpoints-functionality-connected-devices.md), [measurements](rhopoint-elements-hub-endpoints-functionality-measurement-triggers.md) and [image streams](rhopoint-elements-hub-endpoints-functionality-image-streams.md). ### 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 | Device class | Backed by | Behaviour | | --- | --- | --- | | `aesthetix-mock` | `AesthetixMockDevice` | Simulates an Aesthetix; loads measurement data from a `.rae` file (see [Mock data file](#mock-data-file) below); fixed serial number `AEX8000000`. | | `aesthetix-inline-mock` | `AesthetixMockDevice` (alias) | Identical to `aesthetix-mock` — same implementation, exposed under the inline class name for client code that scans by device class. | | `id-inline-mock` | `IdInlineMockDevice` | Simulates an ID Inline; returns predefined inspection metrics and procedurally generated test images; fixed serial number `12345`. | 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](rhopoint-elements-hub-endpoints-functionality-device-scans.md): ```http POST /v1/device-scans Content-Type: application/json { "deviceClass": "aesthetix-mock" } ``` ```bash 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: ```bash # 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": "" }' # Trigger a measurement — same payload as for a real device curl -X POST http://localhost:42042/v1/devices//measurement-triggers \ -H "Content-Type: application/json" \ -d '{ "measurementKey": "measure", "containerFormat": "raeBinary" }' \ --output measurement.rae ``` The `` 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](rhopoint-elements-hub-instruments-aesthetix-calibration.md)) but with simulated execution. - **Measurements**: the hub reads a pre-recorded `.rae` file from disk and returns its first measurement (see [Mock data file](#mock-data-file)). If the file is missing, `POST /measurement-triggers` fails with [`E20UnableToFindMockFile`](rhopoint-elements-hub-error-handling.md). - **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`](rhopoint-elements-hub-endpoints-functionality-lifecycle.md). 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. > [!tip] > 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 | Aspect | Mock device | Real device | | --- | --- | --- | | Scanning | Instant discovery | Hardware-dependent timing | | Connection | Always succeeds | May fail; see [`E8`](rhopoint-elements-hub-error-handling.md) | | Calibrations | Simulated, no physical target needed | Requires the physical reference target | | Measurements | File-replay (Aesthetix) or fixed data (ID Inline) | Live sensor readings | | Images | Generated grid patterns | Camera captures | | Streams | Same SSE protocol, generated frames | Real-time camera frames | | Performance | Deterministic | Variable | ### 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](rhopoint-elements-hub-endpoints-functionality-device-scans.md) — scan request shape and response format - [Connected Devices](rhopoint-elements-hub-endpoints-functionality-connected-devices.md) — connect/disconnect lifecycle - [Measurement Triggers](rhopoint-elements-hub-endpoints-functionality-measurement-triggers.md) — measurement payload - [Error Handling](rhopoint-elements-hub-error-handling.md) — `ErrorInfo` schema and error codes