Retrieve data and start measurements with GraphQL

The documented local endpoint is http://<gateway-ip>:8000/graphql. With the earlier hotspot configuration it is http://192.168.42.1:8000/graphql. Replace the gateway address with the one reachable from your computer.

Open Docs in that version’s GraphQL interface to inspect available queries, mutations, argument names and types. The original interface needed an internet connection to load browser libraries from a CDN. That was a requirement of the documented interface, not proof that the current gateway needs internet access for local API requests.

The public Python client first obtains a csrftoken cookie, then sends it as both a cookie and an x-csrftoken header using RequestsHTTPTransport. This describes that example’s request handling; it is not a replacement for the access requirements of your installation.

Start with the device list and copy the macId of the intended sensor. The examples use the exact device identity, not its editable tag. All sensor IDs and dates shown below are illustrative source examples; replace them with values from your gateway.

For a GrapheneVibrationCombo device, first request vibrationTimestampHistory. Keep each returned timestamp exactly, including fractional seconds and its time-zone offset. The limit restricts the number of returned measurement timestamps, not the number of samples inside a vibration array.

The public Python example also supplies start, end and axis filters. Choose a bounded interval containing your measurements and inspect __typename before using a device-specific fragment. This example does not define a pagination cursor or guarantee that one limited response contains the whole history.

Pass an exact returned timestamp to vibrationArray(isoDate: ...). The date below is retained from the original example and is not a measurement that will exist on your gateway. Request the capture metadata together with the sample array so the result can be interpreted correctly.

For the legacy AccelerationPack format in this guide, divide each raw sample by 512.0 and multiply by the returned formatRange to obtain acceleration in g. Sample times are relative to the start of the array, in seconds. The last sample is at (numSamples - 1) / sampleRate.

This conversion is specific to the documented raw format. Do not apply it to already processed vibration values or to a different sensor format such as ModVibe without that format’s own definition. A capture’s recorded timestamp and the relative sample-time vector have different meanings.

Queries above retrieve stored information. The mutation below changes acquisition state and starts a measurement on the selected sensor. It is the original article’s vibration example, with line breaks added for readability. Its numeric settings are illustrative, not recommended defaults for every machine.

The later public mutation script additionally supplies hpf and prefetch. Whether those arguments are present or required must be checked in the installed schema. An ok response is not the downloaded vibration array; use the history and array queries to retrieve a completed measurement.

setQueueInterval sets the automatic measurement interval in seconds. setQueueEnabled enables or disables automatic measurements for the specified sensor. These are separate mutations, so submit only the operation you intend after checking the sensor and its existing configuration.

The source example uses 120 seconds and enabled: true. Use enabled: false to disable automatic measurements. These commands do not describe every device’s internal continuous-sampling or peak-selection behavior.

The original acquisition article also names hallRunSetup for proximity, tiltRunSetup for inclination and reedRunSetup for the proximity switch. These are different operations for different sensor families, not aliases for vibrationRunSetup.

In the original reed-switch example, numSamples is the number of transmissions before the sensor returns to sleep. The example below requests 31 transmissions. Check the installed schema and choose a count appropriate for the sensor before triggering it.

Some argument lists in that article disagree with its code: the proximity list mentions numSamples although its example omits it, and the inclination list uses tilt-prefixed names while its mutation uses threshold, numSamples and guardRoll. Check the actual installed schema instead of treating those lists as a validated current contract.

The linked Python programs include transport, plotting and mutation examples. Check their dependencies against your client environment and choose settings appropriate for your sensor.