> For the complete documentation index, see [llms.txt](https://docs.voltmasters.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voltmasters.io/dso-rtu/grid-operators/fluvius.md).

# Fluvius

Fluvius operates telecontrole through its **Netflex** interface, based on **IEC 60870-5-104** (IEC-104). The Voltmasters EMS implements the Netflex client interface and is certified per the Fluvius Netflex specification (interface data model version **1.0**, Annex B).

To use it, set the telecontrole provider to **Fluvius** under **Project settings → Telecontrol**.

### Connection

* **Physical link:** the Fluvius RTU connects to the controller with a network (Ethernet) cable through an **Ethernet-to-USB adapter** on the controller. Any USB port can be used.
* **Protocol:** IEC 60870-5-104.
* **Role:** the EMS is the **server**; the Fluvius RTU connects to it as the client.
* **Port:** TCP `2404` (standard IEC-104).
* **Common address (ASDU):** `100`. General interrogation is also accepted on the broadcast common address.
* **Initialization:** after connect, the link is initialized (*end of initialization*), Fluvius performs a **general interrogation**, and the **clock is synchronized** from the Fluvius side.

See [RTU connection](/dso-rtu/rtu-connection.md) for the on-site physical connection and network requirements.

### Control direction (Fluvius → EMS)

The grid operator sends the following. Names follow the Netflex specification.

#### Commands

| Function                       | Type           | Description                                           |
| ------------------------------ | -------------- | ----------------------------------------------------- |
| **Emergency stop production**  | Single command | Stop all injection (PV off, battery discharge off).   |
| **Emergency stop consumption** | Single command | Stop all consumption (battery charge off, loads off). |
| **Test**                       | Single command | Test operation, used during certification.            |
| **Q control mode**             | Double command | Select *local* or *remote* reactive-power control.    |

#### Setpoints (short floating point)

| Function                            | Spec name  | Description                                             |
| ----------------------------------- | ---------- | ------------------------------------------------------- |
| Max production at connection point  | `MINSETP`  | Max injection, as % of contractual grid capacity.       |
| Max consumption at connection point | `MAXSETP`  | Max consumption, as % of contractual grid capacity.     |
| Max asset production                | `MAXSETAP` | Max production, as % of installed asset power (0–100).  |
| Max asset consumption               | `MINSETAP` | Max consumption, as % of installed asset power (0–100). |
| Min reactive power                  | `MINSETQ`  | Lower bound of the reactive-power band.                 |
| Max reactive power                  | `MAXSETQ`  | Upper bound of the reactive-power band.                 |
| Reason P                            | `REDENP`   | Reason code for the active-power control.               |
| Reason Q                            | `REDENQ`   | Reason code for the reactive-power control.             |

#### Reason codes

| Code | Meaning                          |
| ---- | -------------------------------- |
| `0`  | Normal operation                 |
| `1`  | Grid congestion                  |
| `99` | Test (used during certification) |

### Monitor direction (EMS → Fluvius)

The EMS continuously reports back:

* **Feedback** mirroring every command and setpoint (emergency-stop states, Q mode, the active P/Q limits, asset setpoints) and the **interface version**.
* **Periodic measurements** every **30 seconds** of actual active power (P) and reactive power (Q), grouped per asset category.

#### Asset categories

The Netflex data model defines the following measurement categories:

| Category             | Reported from      |
| -------------------- | ------------------ |
| Solar                | PV inverters       |
| Wind                 | —                  |
| CHP                  | —                  |
| Storage              | Batteries / ESS    |
| EV                   | EV charging        |
| Flexible consumption | Controllable loads |
| Other production     | —                  |

The EMS populates the categories that correspond to the assets present in your installation (typically Solar, Storage and EV); categories without matching assets are reported as zero.

### Emergency stop

Fluvius can stop production and/or consumption independently. In addition to the software stop, the production and consumption emergency stops can each drive a physical relay through a [Moxa IO module](/dso-rtu/io-module-emergency-stop.md) (`Injection` action → emergency stop production; `Consumption` action → emergency stop consumption).

### Certification

The Fluvius telecontrole installation must pass a **certification** before it is approved. Voltmasters validates the full interface at commissioning and assists **remotely during the Fluvius certification**, using the **test** reason code to exercise limits and emergency stops in a controlled way. See [Commissioning & certification](/dso-rtu/commissioning-and-certification.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.voltmasters.io/dso-rtu/grid-operators/fluvius.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
