Phase Switching

Phase switching (1-phase ↔ 3-phase) is a critical operation with specific timing constraints. See the detailed workflow description in the endpoint documentation.

Detecting whether phase switching is available

Phase switching is not supported on all hardware configurations, and may also be disabled in the station's configuration even on capable hardware. When unavailable, the station does not publish any of the phase_switching/* MQTT topics at all — which means the entire phase_switching subtree is absent from the snapshot, rather than being present with some "disabled" marker value. There is no dedicated "is phase switching available" flag.

The canonical detection pattern is to check the snapshot for the presence of the subtree before issuing any phase-switching call:

Code
GET /api/?reset
→ check: response.secc.port0.salia.phase_switching  exists?
   - exists  → phase switching is available; all endpoints below are usable.
   - missing → not available; do NOT call setphase (the write is silently
               accepted by the REST layer but the station will ignore it).

Equivalent one-shot check against a specific sub-key:

Code
GET /api/?path=secc/port0/salia/phase_switching/status
→ returns "idle" or "progress"  → available
→ returns null / missing        → not available

Do not confuse phase_switching/actual (current 1- or 3-phase selection — only present if switching is available) with ci/evse/basic/phase_count (how many phases the station is wired for — always present, static hardware property). A station can be wired for 3 phases but have switching disabled; in that case phase_count is "3" and the phase_switching object is still absent.

If phase switching is not available:

• The physical phase configuration is fixed by wiring.
• setphase writes are accepted by the REST layer but discarded internally with no effect.
• Switching into power charge mode does not force 3-phase (the automatic setphase=3 side effect is gated on the same availability flag).

Dual-pole stations (Doppellader)

Dual-pole Salia stations ship as a Salia PLCC Master (product 2310006) paired with a Salia PLCC Slave (product 2310007). The two poles do not have symmetric phase-switching capabilities out of the box:

• Slave pole — phase switching is enabled by factory default. The phase_switching subtree is present in the snapshot and setphase works.
• Master pole — phase switching is disabled by factory default. The phase_switching subtree is therefore absent from the snapshot, and the canonical detection check above will (correctly) report "not available". On a typical Doppellader installation, only the slave pole is intended to perform 1↔3 phase switching.

Implication for integrators: when a single physical station exposes two poles, run the canonical detection check per pole / per REST endpoint — do not assume both poles share the same capability based on one query.

As a secondary hardware-level signal you may cross-check GET /api/device/modelname ("Salia PLCC Master" vs "Salia PLCC Slave") or GET /api/device/product ("2310006" vs "2310007"), but the presence of the phase_switching subtree remains the authoritative runtime test — the field configuration can be changed in the field and the subtree reflects the live state, while the model / product strings reflect only the hardware variant.

Note: this hardware "Master / Slave" distinction refers to the two physical poles of a dual-pole station and is unrelated to the cluster role (standalone / master / slave) configured via salia/setmasterip — see Load Management → Station role. The two concepts share a name but are orthogonal.

Sequencing rule

After triggering a phase switch, you must poll phase_switching/status until it returns "idle" before setting grid_current_limit or other current limits. Failing to wait will block charging.