Salia REST API

REST API for integrating with Salia AC charging stations by eCharge Hardy Barth.

Overview

The Salia REST API provides a unified HTTP interface for reading charging station state and controlling charging behavior. All state is backed by an internal MQTT broker — the REST API acts as a bridge that translates HTTP requests into MQTT topic reads and writes.

How It Works

Reading data: Send a GET request to /api/ to retrieve the full station snapshot, or use the ?path= query parameter to navigate to a specific value (e.g., GET /api/?path=secc/port0/salia/chargemode returns just the charge mode). Individual sub-path endpoints (e.g., /api/secc/port0/salia/chargemode) also work and return the value at that position in the JSON tree.

Writing data: All writes go to the single endpoint PUT /api/ (or POST /api/). The body is a JSON object whose keys are MQTT topic paths (without the port0/ prefix) and whose values are the settings to publish. Multiple topics can be set in a single request.

Important: Sub-path URLs like PUT /api/secc/port0/salia/chargemode are not real endpoints on the server. The per-endpoint put: blocks documented below are a catalog of accepted topics and expected value shapes — they describe what to put in the body of PUT /api/, not separate routes. Writing to a sub-path URL will either be routed equivalently by path normalization or silently have no effect, depending on the web-server configuration.

Example:

Code
PUT /api/
{
  "salia/chargemode": "eco",
  "salia/phase_switching/setphase": "3"
}

Unknown or non-whitelisted topics in the body are silently ignored; the response is still {"result":"ok"}. If the body is not valid JSON, the server returns HTTP 200 with {"error":1, "result":"no valid JSON string"}.

Cache behavior: By default, GET /api/ returns a cached snapshot from the last read. To force a fresh read from the MQTT broker, add ?reset (e.g., GET /api/?reset). The fresh read has a 2-second timeout, so it is slower but guarantees up-to-date data.

Authentication

Write operations (PUT/POST) require authentication via an API key passed in the Apikey HTTP header. Requests originating on the device itself (where the client IP matches the server's own bind address — typically 127.0.0.1) bypass authentication. Read operations (GET) do not require authentication.

Firmware compatibility: The Apikey header is only enforced on firmware 2.3.81 and newer. On older firmware versions, write operations are accepted without any authentication header — the Apikey field is simply ignored. Integrators targeting a mixed fleet should always send the header (it is harmless on older firmware) and should detect the firmware version via GET /api/device/software_version if they need to condition behavior on it. Deployments still running pre-2.3.81 should plan to upgrade, as they are effectively unauthenticated.

Important Notes

• All values are returned and accepted as strings, even when representing numbers or booleans.
• Current values in Amperes are integers (e.g., "16", not "16.0"), except for offered_current_limit which uses one decimal (e.g., "6.0").
• Temperature values are in millidegrees Celsius (e.g., "49896" = 49.896°C).

Metering units

Metering values are not uniformly scaled. Each topic uses the unit documented on its endpoint. Summary:

¹ Voltage and power-factor topics are passed through from the MQTT publisher without scaling in the REST layer; the units listed are the observed raw values. Confirm with your specific meter model if in doubt.