Connect Your Devices to FYXO
Two ways to get your field device data into FYXO: deploy our Gateway Driver on-site to poll devices directly, or use our REST API to read data from devices already connected to your account.
FYXO's connectivity layer abstracts away protocol complexity. Any field device — regardless of manufacturer or protocol — is normalised into a canonical asset model that feeds into AI-powered optimisation and bidirectional control.
Physical assets on-site — any device with a supported industrial protocol.
FYXO Gateway translates each protocol into a unified reading format — one adapter per protocol, all running in parallel.
Raw register values are normalised into standard fields (power_kw, voltage_v, soc_percent, etc.) — the "Stripe for Energy Devices" abstraction.
Authenticated ingestion via Bearer token. Auto-registers new devices, stores telemetry, and makes data available instantly in the Portal.
Claude AI analyses prices, device state, and user preferences to generate optimal dispatch schedules — shifting load to the cheapest hours.
Bidirectional: cloud sends commands back through the gateway to devices. Every command passes through safety validation, drift detection, and conflict locks before execution.
Regardless of the underlying protocol, every device reading is normalised into standard fields. This is the core abstraction — your application code never needs to know whether data came from a Modbus register, a DLMS OBIS code, or an M-Bus VIF.
| Field | Type | Description | Protocol Sources |
|---|---|---|---|
power_kw | float | Active power in kilowatts | Modbus, SunSpec, DLMS, DL/T645, MQTT |
voltage_v | float | Line voltage in volts | Modbus, DLMS, DL/T645 |
current_a | float | Line current in amperes | Modbus, DLMS, DL/T645 |
energy_kwh | float | Cumulative energy in kWh | All protocols |
soc_percent | float | State of charge (batteries) | Modbus, SunSpec |
temperature_c | float | Device temperature in °C | Modbus, M-Bus, SunSpec |
status | enum | online | offline | fault | standby | All protocols |
fault_code | uint16 | Manufacturer fault/alarm code | Modbus, SunSpec |
frequency_hz | float | Grid frequency in Hz | Modbus, SunSpec, DLMS |
power_factor | float | Power factor (0–1) | Modbus, DLMS, DL/T645 |
flow_rate | float | Volume flow (L/h or m³/h) | M-Bus |
pressure_bar | float | Discharge pressure in bar | Modbus (compressors) |
// Every device produces this shape — protocol details are abstracted away
{
"deviceId": "meter-sdm630",
"protocol": "modbus_tcp", // or "dlms", "dlt645", "mbus", "sunspec"
"deviceType": "meter",
"name": "Main Power Meter",
"data": {
"power_kw": 8.42,
"voltage_v": 231.4,
"current_a": 12.1,
"energy_kwh": 14523.7,
"power_factor": 0.98,
"frequency_hz": 50.01,
"status": "online"
},
"readAt": "2026-06-24T14:30:00Z"
}The connectivity layer is bidirectional. Reading telemetry is only half the story — FYXO also dispatches optimisation commands back to devices, with a full safety chain that prevents AI from taking harmful actions.
Gateway polls devices at configurable intervals (default 5–15s), batches readings, and POST to /api/gateway/telemetry with Bearer fgw_ token. Auto-registers unknown devices.
Pending commands are returned in telemetry responses. Gateway maps command actions (set_power, set_soc, charge) to protocol-specific register writes.
After execution, gateway reports success/failure back to cloud. Prevents re-execution of completed commands on subsequent telemetry cycles.
Every write command passes through multiple safety layers before reaching the device. AI decisions cannot override safety validation.