From 45e19abf5c5347cfc2e95e18e822f8676eb01124 Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sat, 20 Jun 2026 18:39:38 +0200
Subject: [PATCH 1/7] docs: document loadpoint priorityStrategy and
 priorityHysteresis

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../en/reference/configuration/loadpoints.md  | 40 +++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/src/content/docs/en/reference/configuration/loadpoints.md b/src/content/docs/en/reference/configuration/loadpoints.md
index 57f4fc74a..e0b8448a6 100644
--- a/src/content/docs/en/reference/configuration/loadpoints.md
+++ b/src/content/docs/en/reference/configuration/loadpoints.md
@@ -358,3 +358,43 @@ priority: 2
 ```
 
 ---
+
+### `priorityStrategy`
+
+Determines how loadpoints that share the same integer `priority` are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
+
+Possible values:
+
+- `static`: Rank by `priority` only. This is the current default behaviour and keeps the order between equal-priority loadpoints unchanged.
+- `soc`: Among equal-priority loadpoints, prefer the one whose vehicle has the **lower** soc, i.e. charge the emptier car first. Only applies when a positive vehicle soc is known.
+- `deficit`: Among equal-priority loadpoints, prefer the one with the **larger** gap between vehicle soc and its limit soc (`limitSoc − soc`), i.e. the one furthest from its target.
+
+The default is `static`, so existing configurations are unaffected unless this option is set explicitly.
+
+**Default value:** `static`
+
+**For example**:
+
+```yaml
+priorityStrategy: soc
+```
+
+---
+
+### `priorityHysteresis`
+
+A deadband (in soc-%) for the `soc` and `deficit` sub-ordering selected via `priorityStrategy`. A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this many soc-%. This prevents two near-equal loadpoints from leapfrogging each other (swapping priority every time their soc crosses); instead they tie and share the available surplus.
+
+Valid values range from `0` to `99`. The default `0` disables the deadband. Values around `5`–`10` are a good starting point.
+
+This option has no effect with `priorityStrategy: static`, and it never affects the ordering between loadpoints of different `priority`.
+
+**Default value:** `0`
+
+**For example**:
+
+```yaml
+priorityHysteresis: 5
+```
+
+---

From 5e426dd3598a16fc029adb84dc079ea2f9ca96e8 Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sun, 21 Jun 2026 06:40:48 +0200
Subject: [PATCH 2/7] docs: document loadpoint priorityBasis (percent/energy)

Add a priorityBasis section covering the percent (default) and energy
bases for the soc/deficit priority strategies, including the capacity
fallback, and note that the priorityHysteresis unit follows the basis
(soc-% or kWh).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 .../en/reference/configuration/loadpoints.md  | 27 ++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/content/docs/en/reference/configuration/loadpoints.md b/src/content/docs/en/reference/configuration/loadpoints.md
index e0b8448a6..414fccb78 100644
--- a/src/content/docs/en/reference/configuration/loadpoints.md
+++ b/src/content/docs/en/reference/configuration/loadpoints.md
@@ -381,9 +381,34 @@ priorityStrategy: soc
 
 ---
 
+### `priorityBasis`
+
+Determines whether the `soc` and `deficit` sub-ordering selected via `priorityStrategy` compares loadpoints by charge level percentage or by absolute energy. This avoids over-prioritizing a smaller battery just because its percentage is lower even though it needs less energy (e.g. a 25 kWh second car at 40 % needs less energy than a 75 kWh car at 50 %).
+
+Possible values:
+
+- `percent`: Rank by the soc-% gap (`100 − soc` for `soc`, `limitSoc − soc` for `deficit`). This is the default behaviour.
+- `energy`: Scale the soc-% gap by the vehicle [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are ranked by **absolute energy (kWh)** rather than percentage — the loadpoint that needs the most energy is charged first.
+
+When a vehicle's capacity is unknown, the `energy` basis falls back to the percentage gap for that loadpoint, so a missing `capacity` does not break the ordering.
+
+This option has no effect with `priorityStrategy: static`.
+
+**Default value:** `percent`
+
+**For example**:
+
+```yaml
+priorityBasis: energy
+```
+
+---
+
 ### `priorityHysteresis`
 
-A deadband (in soc-%) for the `soc` and `deficit` sub-ordering selected via `priorityStrategy`. A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this many soc-%. This prevents two near-equal loadpoints from leapfrogging each other (swapping priority every time their soc crosses); instead they tie and share the available surplus.
+A deadband for the `soc` and `deficit` sub-ordering selected via `priorityStrategy`. A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this amount. This prevents two near-equal loadpoints from leapfrogging each other (swapping priority every time their soc crosses); instead they tie and share the available surplus.
+
+The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis.
 
 Valid values range from `0` to `99`. The default `0` disables the deadband. Values around `5`–`10` are a good starting point.
 

From d2be3e483071fb07d1962368366b73bd590a8e82 Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sun, 12 Jul 2026 17:59:25 +0200
Subject: [PATCH 3/7] docs: move priority strategy options to site level

priorityStrategy, priorityBasis and priorityHysteresis are now global
site options in evcc-io/evcc#31072 instead of per-loadpoint options.
Move their reference sections from loadpoints.md to site.mdx, rename
the default strategy from 'static' to 'none', and leave a pointer in
the loadpoint priority section.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .../en/reference/configuration/loadpoints.md  | 67 +------------------
 .../docs/en/reference/configuration/site.mdx  | 65 ++++++++++++++++++
 2 files changed, 67 insertions(+), 65 deletions(-)

diff --git a/src/content/docs/en/reference/configuration/loadpoints.md b/src/content/docs/en/reference/configuration/loadpoints.md
index 414fccb78..363f727fd 100644
--- a/src/content/docs/en/reference/configuration/loadpoints.md
+++ b/src/content/docs/en/reference/configuration/loadpoints.md
@@ -349,77 +349,14 @@ This prioritisation works in `pv` and `minpv` modes. In `minpv` mode, charging i
 If a vehicle has a priority defined, it overrides the priority of the loadpoint it is connected to.
 :::
 
-**Default value:** `0`
-
-**For example**:
-
-```yaml
-priority: 2
-```
-
----
-
-### `priorityStrategy`
-
-Determines how loadpoints that share the same integer `priority` are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
-
-Possible values:
-
-- `static`: Rank by `priority` only. This is the current default behaviour and keeps the order between equal-priority loadpoints unchanged.
-- `soc`: Among equal-priority loadpoints, prefer the one whose vehicle has the **lower** soc, i.e. charge the emptier car first. Only applies when a positive vehicle soc is known.
-- `deficit`: Among equal-priority loadpoints, prefer the one with the **larger** gap between vehicle soc and its limit soc (`limitSoc − soc`), i.e. the one furthest from its target.
-
-The default is `static`, so existing configurations are unaffected unless this option is set explicitly.
-
-**Default value:** `static`
-
-**For example**:
-
-```yaml
-priorityStrategy: soc
-```
-
----
-
-### `priorityBasis`
-
-Determines whether the `soc` and `deficit` sub-ordering selected via `priorityStrategy` compares loadpoints by charge level percentage or by absolute energy. This avoids over-prioritizing a smaller battery just because its percentage is lower even though it needs less energy (e.g. a 25 kWh second car at 40 % needs less energy than a 75 kWh car at 50 %).
-
-Possible values:
-
-- `percent`: Rank by the soc-% gap (`100 − soc` for `soc`, `limitSoc − soc` for `deficit`). This is the default behaviour.
-- `energy`: Scale the soc-% gap by the vehicle [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are ranked by **absolute energy (kWh)** rather than percentage — the loadpoint that needs the most energy is charged first.
-
-When a vehicle's capacity is unknown, the `energy` basis falls back to the percentage gap for that loadpoint, so a missing `capacity` does not break the ordering.
-
-This option has no effect with `priorityStrategy: static`.
-
-**Default value:** `percent`
-
-**For example**:
-
-```yaml
-priorityBasis: energy
-```
-
----
-
-### `priorityHysteresis`
-
-A deadband for the `soc` and `deficit` sub-ordering selected via `priorityStrategy`. A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this amount. This prevents two near-equal loadpoints from leapfrogging each other (swapping priority every time their soc crosses); instead they tie and share the available surplus.
-
-The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis.
-
-Valid values range from `0` to `99`. The default `0` disables the deadband. Values around `5`–`10` are a good starting point.
-
-This option has no effect with `priorityStrategy: static`, and it never affects the ordering between loadpoints of different `priority`.
+How loadpoints with the **same** priority are sub-ordered can be configured via the site options [`priorityStrategy`](/en/reference/configuration/site#prioritystrategy), [`priorityBasis`](/en/reference/configuration/site#prioritybasis) and [`priorityHysteresis`](/en/reference/configuration/site#priorityhysteresis).
 
 **Default value:** `0`
 
 **For example**:
 
 ```yaml
-priorityHysteresis: 5
+priority: 2
 ```
 
 ---
diff --git a/src/content/docs/en/reference/configuration/site.mdx b/src/content/docs/en/reference/configuration/site.mdx
index cff893046..fd86a5d6a 100644
--- a/src/content/docs/en/reference/configuration/site.mdx
+++ b/src/content/docs/en/reference/configuration/site.mdx
@@ -232,3 +232,68 @@ See also the [alternative using enable/disable to allow proportional PV and grid
 ```yaml
 residualPower: -690
 ```
+
+---
+
+### `priorityStrategy`
+
+Determines how loadpoints that share the same [`priority`](/en/reference/configuration/loadpoints#priority) are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
+
+**Possible values**:
+
+- `none`: Rank by `priority` only. Equal-priority loadpoints keep their existing order. This is the default behaviour.
+- `soc`: Among equal-priority loadpoints, prefer the one whose vehicle has the **lower** charge level, i.e. charge the emptier vehicle first.
+- `deficit`: Among equal-priority loadpoints, prefer the one with the **larger** gap between the vehicle's charge level and its charging limit (`limitSoc − soc`), i.e. the one furthest from its target.
+
+The default is `none`, so existing configurations are unaffected unless this option is set explicitly.
+
+**Default value:** `none`
+
+**For example**:
+
+```yaml
+priorityStrategy: soc
+```
+
+---
+
+### `priorityBasis`
+
+Determines whether the sub-ordering selected via [`priorityStrategy`](#prioritystrategy) measures the gap by charge level percentage or by absolute energy.
+
+**Possible values**:
+
+- `percent`: Compare by the soc-% gap. This is the default behaviour.
+- `energy`: Scale the soc-% gap by the vehicle [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are compared by **absolute energy (kWh)**. This avoids over-prioritizing a small second battery just because its percentage is lower, even though it needs less energy than a larger one (e.g. a 25 kWh car at 40 % needs less energy than a 75 kWh car at 50 %).
+
+When the capacity of any compared vehicle is unknown, the `energy` basis falls back to the percentage comparison.
+
+This option has no effect with `priorityStrategy: none`.
+
+**Default value:** `percent`
+
+**For example**:
+
+```yaml
+priorityBasis: energy
+```
+
+---
+
+### `priorityHysteresis`
+
+A deadband for the sub-ordering selected via [`priorityStrategy`](#prioritystrategy). A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this amount. This prevents two near-equal vehicles from leapfrogging each other (swapping rank every time their charge levels cross); instead they tie and share the available surplus.
+
+The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis.
+
+Valid values range from `0` to `99`. The default `0` disables the deadband.
+
+This option has no effect with `priorityStrategy: none`, and it never affects the ordering between loadpoints of different `priority`.
+
+**Default value:** `0`
+
+**For example**:
+
+```yaml
+priorityHysteresis: 5
+```

From 486a8a3b2a05fe8384cc29608fbdc882e4d6fe8d Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sun, 16 Aug 2026 11:50:22 +0200
Subject: [PATCH 4/7] docs: document experimental flag and heating exclusion
 for priority strategy

- priorityStrategy/priorityBasis/priorityHysteresis are experimental (UI gated by experimental mode, config works without it)
- heating loadpoints are excluded from priority sub-ordering entirely (EN + DE)
- heating loadpoints don't force the energy basis fallback (EN + DE)
---
 .../docs/de/reference/configuration/site.mdx  | 71 +++++++++++++++++++
 .../docs/en/reference/configuration/site.mdx  |  9 +++
 2 files changed, 80 insertions(+)

diff --git a/src/content/docs/de/reference/configuration/site.mdx b/src/content/docs/de/reference/configuration/site.mdx
index 4d8a7e89f..4d620ea6c 100644
--- a/src/content/docs/de/reference/configuration/site.mdx
+++ b/src/content/docs/de/reference/configuration/site.mdx
@@ -234,3 +234,74 @@ Mindestladeleistung: 1 Phase _ 6A _ 230V = 1380 W, davon 50%: 690 W. Siehe auch
 ```yaml
 residualPower: -690
 ```
+### `priorityStrategy`
+
+Legt fest, wie Ladepunkte mit gleichem [`priority`](/de/reference/configuration/loadpoints#priority) bei der Verteilung des PV-Überschusses untereinander gereiht werden. Dies betrifft nur die Reihenfolge innerhalb derselben Prioritätsstufe; die Rangordnung zwischen unterschiedlichen `priority`-Stufen bleibt unverändert.
+
+Diese Optionen sind experimentell. In der UI erscheint der Priority-Dialog (gekennzeichnet mit 🧪) nur, wenn experimentelle Funktionen unter **Konfiguration → Experimentell** aktiviert sind. Die Einstellungen können auch in der `evcc.yaml` vorgenommen werden; die Konfiguration funktioniert ohne experimentellen Modus.
+
+:::note[Heizung]
+Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausgeschlossen. Sie behalten stets die reine `priority`-Einstufung, sodass sie innerhalb einer Stufe hinter Fahrzeugen zurückstehen. Prioritäten über verschiedene Stufen hinweg werden weiterhin angewendet.
+:::
+
+**Mögliche Werte**:
+
+- `none`: Nur nach `priority` ordnen. Gleichrangige Ladepunkte behalten ihre bisherige Reihenfolge. Das ist das Standardverhalten.
+- `soc`: Von gleichrangigen Ladepunkten wird der mit dem niedrigeren Ladestand bevorzugt, d. h. das leerere Fahrzeug wird zuerst geladen.
+- `deficit`: Von gleichrangigen Ladepunkten wird der mit dem größeren Abstand zwischen Ladestand und Ladegrenze (`limitSoc − soc`) bevorzugt, d. h. das Fahrzeug, das am weitesten von seinem Ziel entfernt ist.
+
+Der Standardwert ist `none`, bestehende Konfigurationen sind daher nicht betroffen.
+
+**Standardwert:** `none`
+
+**Beispiel**:
+
+```yaml
+priorityStrategy: soc
+```
+
+---
+
+### `priorityBasis`
+
+Legt fest, ob die über [`priorityStrategy`](#prioritystrategy) gewählte Unterordnung den Abstand als Ladezustandsprozentsatz oder als absolute Energie misst.
+
+**Mögliche Werte**:
+
+- `percent`: Vergleich anhand der soc-%-Differenz. Das ist das Standardverhalten.
+- `energy`: Skaliert die soc-%-Differenz mit der Fahrzeug-[`capacity`](/de/reference/configuration/vehicles#capacity), sodass Ladepunkte nach **absoluter Energie (kWh)** verglichen werden. Dies verhindert, dass ein kleiner zweiter Akku allein aufgrund seines niedrigeren Prozentsatzes bevorzugt wird, obwohl er weniger Energie benötigt als ein größerer (z. B. ein 25‑kWh‑Auto bei 40 % braucht weniger Energie als ein 75‑kWh‑Auto bei 50 %).
+
+Wenn die Kapazität eines verglichenen Fahrzeugs unbekannt ist, fällt die `energy`-Basis auf den Prozentvergleich zurück.
+Heizungs-Ladepunkte nehmen an diesem Vergleich nicht teil und erzwingen auch keinen Rückfall auf `percent`.
+
+Diese Option hat keine Wirkung bei `priorityStrategy: none`.
+
+**Standardwert:** `percent`
+
+**Beispiel**:
+
+```yaml
+priorityBasis: energy
+```
+
+---
+
+### `priorityHysteresis`
+
+Eine Totband für die über [`priorityStrategy`](#prioritystrategy) gewählte Unterordnung. Ein Ladepunkt übertrifft einen anderen derselben `priority` nur dann, wenn er um **mehr** als diesen Betrag voraus ist. Dies verhindert, dass zwei nahezu gleich geladene Fahrzeuge ständig die Plätze tauschen (Rangwechsel bei jeder Ladestandsänderung); stattdessen bleiben sie gleichauf und teilen sich den verfügbaren Überschuss.
+
+Die Einheit folgt [`priorityBasis`](#prioritybasis): soc-%-Punkte bei der `percent`-Basis (Standard) und kWh bei der `energy`-Basis.
+
+Gültige Werte reichen von `0` bis `99`. Der Standardwert `0` deaktiviert die Totband.
+
+Die Totband gilt nicht für Heizungs-Ladepunkte, da diese von der Unterordnung vollständig ausgeschlossen sind.
+
+Diese Option hat keine Wirkung bei `priorityStrategy: none` und beeinflusst nie die Rangordnung zwischen Ladepunkten unterschiedlicher `priority`.
+
+**Standardwert:** `0`
+
+**Beispiel**:
+
+```yaml
+priorityHysteresis: 5
+```
\ No newline at end of file
diff --git a/src/content/docs/en/reference/configuration/site.mdx b/src/content/docs/en/reference/configuration/site.mdx
index fd86a5d6a..b396542eb 100644
--- a/src/content/docs/en/reference/configuration/site.mdx
+++ b/src/content/docs/en/reference/configuration/site.mdx
@@ -239,6 +239,12 @@ residualPower: -690
 
 Determines how loadpoints that share the same [`priority`](/en/reference/configuration/loadpoints#priority) are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
 
+These options are experimental. In the UI, the Priority dialog (marked 🧪) only appears when you enable experimental features under **Configuration → Experimental**. You can also set them in `evcc.yaml`; the configuration works without experimental mode.
+
+:::note[Heating]
+Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. They always keep the plain `priority` ranking, so within a tier they rank below vehicles. Cross-tier integer priorities still apply to them.
+:::
+
 **Possible values**:
 
 - `none`: Rank by `priority` only. Equal-priority loadpoints keep their existing order. This is the default behaviour.
@@ -267,6 +273,7 @@ Determines whether the sub-ordering selected via [`priorityStrategy`](#prioritys
 - `energy`: Scale the soc-% gap by the vehicle [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are compared by **absolute energy (kWh)**. This avoids over-prioritizing a small second battery just because its percentage is lower, even though it needs less energy than a larger one (e.g. a 25 kWh car at 40 % needs less energy than a 75 kWh car at 50 %).
 
 When the capacity of any compared vehicle is unknown, the `energy` basis falls back to the percentage comparison.
+Heating loadpoints don't take part in this comparison, and they don't force a fallback to `percent`.
 
 This option has no effect with `priorityStrategy: none`.
 
@@ -288,6 +295,8 @@ The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` bas
 
 Valid values range from `0` to `99`. The default `0` disables the deadband.
 
+The deadband doesn't apply to heating loadpoints, which are excluded from the sub-ordering entirely.
+
 This option has no effect with `priorityStrategy: none`, and it never affects the ordering between loadpoints of different `priority`.
 
 **Default value:** `0`

From 4a5028b9d378cfcd8050525f63fe5478dc4d60a8 Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Mon, 24 Aug 2026 10:32:34 +0200
Subject: [PATCH 5/7] docs: document which loadpoints the priority strategy
 skips

Heating loadpoints and loadpoints without a known vehicle charge level keep
their plain priority rank. naltatis asked for the heating behaviour to be
written down when he excluded it in 60314ef; the unknown-soc case follows the
same code path. Also notes that the energy basis saturates above 99 kWh.
---
 src/content/docs/en/reference/configuration/site.mdx | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/content/docs/en/reference/configuration/site.mdx b/src/content/docs/en/reference/configuration/site.mdx
index b396542eb..2fcd6188f 100644
--- a/src/content/docs/en/reference/configuration/site.mdx
+++ b/src/content/docs/en/reference/configuration/site.mdx
@@ -253,6 +253,13 @@ Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. They
 
 The default is `none`, so existing configurations are unaffected unless this option is set explicitly.
 
+Two kinds of loadpoint are never sub-ordered and keep their plain `priority` rank:
+
+- Heating loadpoints. Their soc value holds a temperature rather than a charge level, so "charge the emptier one first" would compare unrelated quantities. Within the same `priority` a heater therefore loses against a vehicle that has a charge level. Put heaters in their own `priority` if you want them ahead of, or behind, your vehicles.
+- Loadpoints whose vehicle charge level is unknown.
+
+The ordering between different `priority` values is unaffected in both cases.
+
 **Default value:** `none`
 
 **For example**:
@@ -275,6 +282,8 @@ Determines whether the sub-ordering selected via [`priorityStrategy`](#prioritys
 When the capacity of any compared vehicle is unknown, the `energy` basis falls back to the percentage comparison.
 Heating loadpoints don't take part in this comparison, and they don't force a fallback to `percent`.
 
+The comparison saturates above 99 kWh, so two loadpoints that both need more than that rank equal and share the surplus.
+
 This option has no effect with `priorityStrategy: none`.
 
 **Default value:** `percent`

From 42a73f550e4c42e827122a66f0f17b1a80c5176f Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sat, 29 Aug 2026 16:11:30 +0200
Subject: [PATCH 6/7] docs: correct the priority strategy fallback and unit
 wording

The energy basis is vetoed by any loadpoint that reports a charge level
without a known vehicle capacity, which includes chargers reporting soc
themselves, not only loadpoints without a vehicle. evcc now logs that and
publishes the basis in use, so document the fallback and that the deadband
is then read in soc-%.

Drops the 99 kWh saturation note: the gap is normalised against the largest
capacity in scope, so it no longer saturates. Folds the duplicated heating
wording into the existing note and mirrors everything into the German page.
---
 .../docs/de/reference/configuration/site.mdx      | 15 ++++++++++-----
 .../docs/en/reference/configuration/site.mdx      | 13 ++++---------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/content/docs/de/reference/configuration/site.mdx b/src/content/docs/de/reference/configuration/site.mdx
index 4d620ea6c..4aa3348a8 100644
--- a/src/content/docs/de/reference/configuration/site.mdx
+++ b/src/content/docs/de/reference/configuration/site.mdx
@@ -234,14 +234,17 @@ Mindestladeleistung: 1 Phase _ 6A _ 230V = 1380 W, davon 50%: 690 W. Siehe auch
 ```yaml
 residualPower: -690
 ```
+
+---
+
 ### `priorityStrategy`
 
 Legt fest, wie Ladepunkte mit gleichem [`priority`](/de/reference/configuration/loadpoints#priority) bei der Verteilung des PV-Überschusses untereinander gereiht werden. Dies betrifft nur die Reihenfolge innerhalb derselben Prioritätsstufe; die Rangordnung zwischen unterschiedlichen `priority`-Stufen bleibt unverändert.
 
-Diese Optionen sind experimentell. In der UI erscheint der Priority-Dialog (gekennzeichnet mit 🧪) nur, wenn experimentelle Funktionen unter **Konfiguration → Experimentell** aktiviert sind. Die Einstellungen können auch in der `evcc.yaml` vorgenommen werden; die Konfiguration funktioniert ohne experimentellen Modus.
+Diese Optionen sind experimentell. In der UI erscheint der Priority-Dialog (gekennzeichnet mit 🧪) nur, wenn experimentelle Funktionen unter **Konfiguration → Experimentell** aktiviert sind und mindestens zwei Ladepunkte konfiguriert sind. Die Einstellungen können auch in der `evcc.yaml` vorgenommen werden; die Konfiguration funktioniert ohne experimentellen Modus.
 
 :::note[Heizung]
-Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausgeschlossen. Sie behalten stets die reine `priority`-Einstufung, sodass sie innerhalb einer Stufe hinter Fahrzeugen zurückstehen. Prioritäten über verschiedene Stufen hinweg werden weiterhin angewendet.
+Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausgeschlossen. Ihr soc-Wert enthält eine Temperatur statt eines Ladestands, ein "das leerere zuerst" würde also nicht vergleichbare Größen gegenüberstellen. Sie behalten die reine `priority`-Einstufung und stehen damit innerhalb einer Stufe hinter Fahrzeugen zurück. Wer Heizungen vor oder hinter den Fahrzeugen haben will, gibt ihnen eine eigene `priority`. Prioritäten über verschiedene Stufen hinweg werden weiterhin angewendet.
 :::
 
 **Mögliche Werte**:
@@ -252,6 +255,8 @@ Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausg
 
 Der Standardwert ist `none`, bestehende Konfigurationen sind daher nicht betroffen.
 
+Ein Ladepunkt mit unbekanntem Fahrzeug-Ladestand behält ebenfalls seine reine `priority`-Einstufung. Ein Fahrzeug, das 0 % meldet, gilt hier als unbekannt und liegt damit gleichauf mit einem vollen Fahrzeug, statt zuerst geladen zu werden.
+
 **Standardwert:** `none`
 
 **Beispiel**:
@@ -271,7 +276,7 @@ Legt fest, ob die über [`priorityStrategy`](#prioritystrategy) gewählte Untero
 - `percent`: Vergleich anhand der soc-%-Differenz. Das ist das Standardverhalten.
 - `energy`: Skaliert die soc-%-Differenz mit der Fahrzeug-[`capacity`](/de/reference/configuration/vehicles#capacity), sodass Ladepunkte nach **absoluter Energie (kWh)** verglichen werden. Dies verhindert, dass ein kleiner zweiter Akku allein aufgrund seines niedrigeren Prozentsatzes bevorzugt wird, obwohl er weniger Energie benötigt als ein größerer (z. B. ein 25‑kWh‑Auto bei 40 % braucht weniger Energie als ein 75‑kWh‑Auto bei 50 %).
 
-Wenn die Kapazität eines verglichenen Fahrzeugs unbekannt ist, fällt die `energy`-Basis auf den Prozentvergleich zurück.
+Meldet ein Ladepunkt einen Ladestand ohne bekannte Fahrzeug-Kapazität, kann die `energy`-Basis nicht angewendet werden und alle Ladepunkte werden stattdessen nach Prozent gereiht. Das betrifft neben Ladepunkten ohne Fahrzeug auch Wallboxen, die den Ladestand selbst melden (integrierte Geräte). evcc protokolliert den Rückfall und veröffentlicht die tatsächlich verwendete Basis, sodass das Hysterese-Feld in der UI mit der jeweils gültigen Einheit beschriftet wird.
 Heizungs-Ladepunkte nehmen an diesem Vergleich nicht teil und erzwingen auch keinen Rückfall auf `percent`.
 
 Diese Option hat keine Wirkung bei `priorityStrategy: none`.
@@ -290,7 +295,7 @@ priorityBasis: energy
 
 Eine Totband für die über [`priorityStrategy`](#prioritystrategy) gewählte Unterordnung. Ein Ladepunkt übertrifft einen anderen derselben `priority` nur dann, wenn er um **mehr** als diesen Betrag voraus ist. Dies verhindert, dass zwei nahezu gleich geladene Fahrzeuge ständig die Plätze tauschen (Rangwechsel bei jeder Ladestandsänderung); stattdessen bleiben sie gleichauf und teilen sich den verfügbaren Überschuss.
 
-Die Einheit folgt [`priorityBasis`](#prioritybasis): soc-%-Punkte bei der `percent`-Basis (Standard) und kWh bei der `energy`-Basis.
+Die Einheit folgt [`priorityBasis`](#prioritybasis): soc-%-Punkte bei der `percent`-Basis (Standard) und kWh bei der `energy`-Basis. Fällt die `energy`-Basis auf den Prozentvergleich zurück (siehe oben), wird auch das Totband in soc-%-Punkten gelesen.
 
 Gültige Werte reichen von `0` bis `99`. Der Standardwert `0` deaktiviert die Totband.
 
@@ -304,4 +309,4 @@ Diese Option hat keine Wirkung bei `priorityStrategy: none` und beeinflusst nie
 
 ```yaml
 priorityHysteresis: 5
-```
\ No newline at end of file
+```
diff --git a/src/content/docs/en/reference/configuration/site.mdx b/src/content/docs/en/reference/configuration/site.mdx
index 2fcd6188f..fb70010bb 100644
--- a/src/content/docs/en/reference/configuration/site.mdx
+++ b/src/content/docs/en/reference/configuration/site.mdx
@@ -239,10 +239,10 @@ residualPower: -690
 
 Determines how loadpoints that share the same [`priority`](/en/reference/configuration/loadpoints#priority) are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
 
-These options are experimental. In the UI, the Priority dialog (marked 🧪) only appears when you enable experimental features under **Configuration → Experimental**. You can also set them in `evcc.yaml`; the configuration works without experimental mode.
+These options are experimental. In the UI, the Priority dialog (marked 🧪) only appears when you enable experimental features under **Configuration → Experimental** and at least two loadpoints are configured. You can also set them in `evcc.yaml`; the configuration works without experimental mode.
 
 :::note[Heating]
-Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. They always keep the plain `priority` ranking, so within a tier they rank below vehicles. Cross-tier integer priorities still apply to them.
+Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. Their soc value holds a temperature rather than a charge level, so "charge the emptier one first" would compare unrelated quantities. They keep the plain `priority` ranking and therefore rank below vehicles within the same tier. Put heaters in their own `priority` if you want them ahead of, or behind, your vehicles. Cross-tier priorities still apply to them.
 :::
 
 **Possible values**:
@@ -253,12 +253,7 @@ Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. They
 
 The default is `none`, so existing configurations are unaffected unless this option is set explicitly.
 
-Two kinds of loadpoint are never sub-ordered and keep their plain `priority` rank:
-
-- Heating loadpoints. Their soc value holds a temperature rather than a charge level, so "charge the emptier one first" would compare unrelated quantities. Within the same `priority` a heater therefore loses against a vehicle that has a charge level. Put heaters in their own `priority` if you want them ahead of, or behind, your vehicles.
-- Loadpoints whose vehicle charge level is unknown.
-
-The ordering between different `priority` values is unaffected in both cases.
+A loadpoint whose vehicle charge level is unknown keeps its plain `priority` rank as well. A vehicle reporting 0 % counts as unknown here, so it ties with a fully charged one instead of being charged first.
 
 **Default value:** `none`
 
@@ -300,7 +295,7 @@ priorityBasis: energy
 
 A deadband for the sub-ordering selected via [`priorityStrategy`](#prioritystrategy). A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this amount. This prevents two near-equal vehicles from leapfrogging each other (swapping rank every time their charge levels cross); instead they tie and share the available surplus.
 
-The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis.
+The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis. When the `energy` basis falls back to the percentage comparison (see above), the deadband is read in soc-% too.
 
 Valid values range from `0` to `99`. The default `0` disables the deadband.
 

From 9e91e581f63398514b7133e25f859a9746dcee6b Mon Sep 17 00:00:00 2001
From: Alexander Herold <alexander@herold.hn>
Date: Sat, 12 Sep 2026 19:44:11 +0200
Subject: [PATCH 7/7] docs: rework priority strategy for UI/API-only settings

The evcc implementation dropped the evcc.yaml fields (priorityStrategy,
priorityBasis, priorityHysteresis) in favor of UI/API-only settings.
Remove the yaml reference sections from site.mdx (en/de) and document
the feature where it semantically belongs: the loadpoints priority
section (en/de). Covers the experimental Priorities dialog, strategy
(none/soc/deficit), basis (percent/energy) with fallback behavior,
hysteresis deadband, heating exclusion, unknown-soc handling, and the
API/MQTT surface.
---
 .../de/reference/configuration/loadpoints.md  |  37 +++++++
 .../docs/de/reference/configuration/site.mdx  | 100 ++++--------------
 .../en/reference/configuration/loadpoints.md  |  37 ++++++-
 .../docs/en/reference/configuration/site.mdx  | 100 ++++--------------
 4 files changed, 112 insertions(+), 162 deletions(-)

diff --git a/src/content/docs/de/reference/configuration/loadpoints.md b/src/content/docs/de/reference/configuration/loadpoints.md
index b49369df3..3a81d9c86 100644
--- a/src/content/docs/de/reference/configuration/loadpoints.md
+++ b/src/content/docs/de/reference/configuration/loadpoints.md
@@ -357,6 +357,43 @@ Die Priorisierung wirkt in den Modi `pv` und `minpv`. Bei `minpv` wird die Ladun
 Eine evtl. beim Fahrzeug konfigurierte Priorität ersetzt die Priorität des Loadpoints, mit dem das Fahrzeug verbunden ist.
 :::
 
+Loadpoints mit der **gleichen** Priorität können zusätzlich untereinander gereiht werden 🧪.
+Die Konfiguration erfolgt in der UI unter **Konfiguration → Ladepunkte → Prioritäten**.
+Der Dialog erscheint nur, wenn unter **Konfiguration → Experimentell** die experimentellen Funktionen aktiviert sind und mindestens zwei Ladepunkte konfiguriert sind.
+Diese Einstellungen sind nicht in der `evcc.yaml` verfügbar; sie werden intern gespeichert und bleiben über Neustarts erhalten.
+
+**Strategie** bestimmt, welcher gleichrangige Ladepunkt den Überschuss zuerst erhält:
+
+- `none` – "Wer zuerst kommt" (Standard): keine Unterordnung, wer zuerst mit dem Laden beginnt, behält den Überschuss.
+- `soc` – "Leerstes zuerst": das Fahrzeug mit dem niedrigsten Ladestand wird bevorzugt.
+- `deficit` – "Größter Bedarf zuerst": das Fahrzeug mit dem größten Abstand zum Ladeziel (`limitSoc − soc`) wird bevorzugt.
+
+**Basis** legt fest, wie der Abstand zwischen den Fahrzeugen gemessen wird:
+
+- `percent` (Standard): Vergleich anhand des Ladestands in Prozent.
+- `energy`: Skaliert den Prozent-Abstand mit der Fahrzeug-[`capacity`](/de/reference/configuration/vehicles#capacity), sodass Ladepunkte nach **absolutem Energiebedarf (kWh)** verglichen werden. Dies verhindert, dass ein kleiner zweiter Akku allein aufgrund seines niedrigeren Prozentsatzes bevorzugt wird, obwohl er weniger Energie benötigt als ein größerer (ein 25-kWh-Auto bei 40 % braucht weniger Energie als ein 75-kWh-Auto bei 50 %). Hat ein verglichenes Fahrzeug keine bekannte Kapazität – etwa Ladepunkte ohne Fahrzeug oder Wallboxen, die den Ladestand selbst melden – werden stattdessen alle Ladepunkte nach Prozent verglichen. evcc protokolliert diesen Rückfall und veröffentlicht die tatsächlich verwendete Basis, damit das Hysterese-Feld in der UI mit der richtigen Einheit beschriftet ist.
+
+**Hysterese** ist eine Totband von `0` bis `99`.
+Ein gleichrangiger Ladepunkt überholt einen anderen nur, wenn er um **mehr** als diesen Wert voraus ist.
+Dies verhindert, dass zwei nahezu gleich geladene Fahrzeuge ständig die Plätze tauschen; stattdessen gelten sie als gleichauf und teilen sich den verfügbaren Überschuss.
+Die Einheit folgt der Basis: soc-Prozentpunkte bei `percent` (Standard) und kWh bei `energy`.
+Fällt die `energy`-Basis auf den Prozentvergleich zurück (siehe oben), wird auch das Totband in Prozentpunkten gelesen.
+`0` (Standard) deaktiviert das Totband.
+Basis und Hysterese haben bei der Strategie `none` keine Wirkung.
+
+:::note[Heizung]
+Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausgeschlossen.
+Ihr soc-Wert enthält eine Temperatur, keinen Ladestand – "das Leerste zuerst" würde also unvergleichbare Größen gegenüberstellen.
+Sie behalten ihre reine `priority`-Einstufung.
+Gib Heizungen eine eigene `priority`, wenn sie vor oder hinter den Fahrzeugen liegen sollen; Prioritäten über verschiedene Stufen hinweg bleiben von dieser Unterordnung unberührt.
+:::
+
+Ein Ladepunkt mit unbekanntem Fahrzeug-Ladestand behält ebenfalls seine reine `priority`-Einstufung.
+Ein Fahrzeug, das 0 % meldet, gilt hier als unbekannt und liegt damit gleichauf mit einem vollen Fahrzeug, statt zuerst geladen zu werden.
+
+Die Werte können auch über die API gesetzt werden: `POST /api/prioritystrategy/{none|soc|deficit}`, `POST /api/prioritybasis/{percent|energy}` und `POST /api/priorityhysteresis/{0..99}`.
+Dieselben Topics stehen per MQTT zur Verfügung (`priorityStrategy`, `priorityBasis`, `priorityHysteresis`); die aktiven Werte werden im State veröffentlicht.
+
 **Standardwert:** `0`
 
 **Beispiel**:
diff --git a/src/content/docs/de/reference/configuration/site.mdx b/src/content/docs/de/reference/configuration/site.mdx
index 4aa3348a8..505c1406b 100644
--- a/src/content/docs/de/reference/configuration/site.mdx
+++ b/src/content/docs/de/reference/configuration/site.mdx
@@ -30,6 +30,8 @@ site:
       - myconsumer1 # regular consumer, recorded for consumption statistics
     ext:
       - myext1 # for data logging, load management, etc.
+  curtailers:
+    - my_curtailer # curtailment device reference
   residualPower: 100
 ```
 
@@ -51,7 +53,7 @@ title: Zuhause
 
 ### `meters`
 
-Definiert welche konfigurierten [`meter`](meters) (Strommessgeräte) als welche Art Messpunkt verwendet werden sollen.
+Definiert welche konfigurierten [`meter`](/de/reference/configuration/meters) (Strommessgeräte) als welche Art Messpunkt verwendet werden sollen.
 Hier erfolgt somit die logische Verknüpfung der Gerätedefiniton mit dem Verwendungszweck.
 Ein zunächst universeller Zähler bekommt somit entsprechend seines Einbauortes in der Hausinstallation einen Zweck zugewiesen.
 
@@ -78,7 +80,7 @@ site:
 
 ### `meters.grid`
 
-Definiert das [`meter`](meters) (Strommessgerät), welches die Messwerte des Netzanschlusspunktes liefert.
+Definiert das [`meter`](/de/reference/configuration/meters) (Strommessgerät), welches die Messwerte des Netzanschlusspunktes liefert.
 
 **Mögliche Werte**: Wert eines `name` Parameters in der [`meters`](#meters) Konfiguration.
 
@@ -92,7 +94,7 @@ grid: mygridmeter # grid meter reference
 
 ### `meters.pv`
 
-Definiert die [`meter`](meters) (Strommessgeräte), welche die PV-Erzeugungswerte liefern.
+Definiert die [`meter`](/de/reference/configuration/meters) (Strommessgeräte), welche die PV-Erzeugungswerte liefern.
 Es können mehrere Geräte angegeben werden. Die Leistungsdaten werden automatisch addiert.
 
 **Mögliche Werte**: Ein Wert oder eine Liste von Werten eines `name` Parameters in der [`meters`](#meters) Konfiguration. Wobei die Listenversion auch bei Einzelwerten genutzt werden kann.
@@ -115,7 +117,7 @@ pv: # (pvs = veraltet)
 
 ### `meters.battery`
 
-Definiert die [`meter`](meters) (Strommessgeräte), welche die Messdaten des/der Batteriespeicher(s) liefern.
+Definiert die [`meter`](/de/reference/configuration/meters) (Strommessgeräte), welche die Messdaten des/der Batteriespeicher(s) liefern.
 Es können mehrere Geräte angegeben werden. Die Leistungsdaten werden automatisch addiert und aus den Speicherfüllständen wird ein Mittelwert gebildet.
 
 **Mögliche Werte**: Ein Wert oder eine Liste von Werten eines `name` Parameters in der [`meters`](#meters) Konfiguration. Wobei die Listenversion auch bei Einzelwerten genutzt werden kann.
@@ -194,6 +196,20 @@ ext:
   - myext2 # second ext meter reference
 ```
 
+### `curtailers`
+
+Einspeisebegrenzer aus der [`curtailers`](/de/reference/configuration/curtailers)-Konfiguration, die die Einspeisung auf Anforderung des Netzbetreibers begrenzen (§ 9 EEG).
+Sie werden zusammen mit den abregelbaren `pv`-Zählern angesteuert, wenn die [`hems`](/de/reference/configuration/hems)-Integration ein Limit signalisiert.
+
+**Mögliche Werte**: Eine Liste von Werten eines `name` Parameters in der [`curtailers`](/de/reference/configuration/curtailers) Konfiguration.
+
+**Beispiel**:
+
+```yaml
+curtailers:
+  - my_curtailer # curtailment device reference
+```
+
 ### `residualPower`
 
 Legt den Soll-Arbeitspunkt der Überschussregelung am Netzübergang (Gridmeter) fest. Der Standardwert ist 0 (Watt).
@@ -234,79 +250,3 @@ Mindestladeleistung: 1 Phase _ 6A _ 230V = 1380 W, davon 50%: 690 W. Siehe auch
 ```yaml
 residualPower: -690
 ```
-
----
-
-### `priorityStrategy`
-
-Legt fest, wie Ladepunkte mit gleichem [`priority`](/de/reference/configuration/loadpoints#priority) bei der Verteilung des PV-Überschusses untereinander gereiht werden. Dies betrifft nur die Reihenfolge innerhalb derselben Prioritätsstufe; die Rangordnung zwischen unterschiedlichen `priority`-Stufen bleibt unverändert.
-
-Diese Optionen sind experimentell. In der UI erscheint der Priority-Dialog (gekennzeichnet mit 🧪) nur, wenn experimentelle Funktionen unter **Konfiguration → Experimentell** aktiviert sind und mindestens zwei Ladepunkte konfiguriert sind. Die Einstellungen können auch in der `evcc.yaml` vorgenommen werden; die Konfiguration funktioniert ohne experimentellen Modus.
-
-:::note[Heizung]
-Heizungs-Ladepunkte (z. B. eine Wärmepumpe) sind von dieser Unterordnung ausgeschlossen. Ihr soc-Wert enthält eine Temperatur statt eines Ladestands, ein "das leerere zuerst" würde also nicht vergleichbare Größen gegenüberstellen. Sie behalten die reine `priority`-Einstufung und stehen damit innerhalb einer Stufe hinter Fahrzeugen zurück. Wer Heizungen vor oder hinter den Fahrzeugen haben will, gibt ihnen eine eigene `priority`. Prioritäten über verschiedene Stufen hinweg werden weiterhin angewendet.
-:::
-
-**Mögliche Werte**:
-
-- `none`: Nur nach `priority` ordnen. Gleichrangige Ladepunkte behalten ihre bisherige Reihenfolge. Das ist das Standardverhalten.
-- `soc`: Von gleichrangigen Ladepunkten wird der mit dem niedrigeren Ladestand bevorzugt, d. h. das leerere Fahrzeug wird zuerst geladen.
-- `deficit`: Von gleichrangigen Ladepunkten wird der mit dem größeren Abstand zwischen Ladestand und Ladegrenze (`limitSoc − soc`) bevorzugt, d. h. das Fahrzeug, das am weitesten von seinem Ziel entfernt ist.
-
-Der Standardwert ist `none`, bestehende Konfigurationen sind daher nicht betroffen.
-
-Ein Ladepunkt mit unbekanntem Fahrzeug-Ladestand behält ebenfalls seine reine `priority`-Einstufung. Ein Fahrzeug, das 0 % meldet, gilt hier als unbekannt und liegt damit gleichauf mit einem vollen Fahrzeug, statt zuerst geladen zu werden.
-
-**Standardwert:** `none`
-
-**Beispiel**:
-
-```yaml
-priorityStrategy: soc
-```
-
----
-
-### `priorityBasis`
-
-Legt fest, ob die über [`priorityStrategy`](#prioritystrategy) gewählte Unterordnung den Abstand als Ladezustandsprozentsatz oder als absolute Energie misst.
-
-**Mögliche Werte**:
-
-- `percent`: Vergleich anhand der soc-%-Differenz. Das ist das Standardverhalten.
-- `energy`: Skaliert die soc-%-Differenz mit der Fahrzeug-[`capacity`](/de/reference/configuration/vehicles#capacity), sodass Ladepunkte nach **absoluter Energie (kWh)** verglichen werden. Dies verhindert, dass ein kleiner zweiter Akku allein aufgrund seines niedrigeren Prozentsatzes bevorzugt wird, obwohl er weniger Energie benötigt als ein größerer (z. B. ein 25‑kWh‑Auto bei 40 % braucht weniger Energie als ein 75‑kWh‑Auto bei 50 %).
-
-Meldet ein Ladepunkt einen Ladestand ohne bekannte Fahrzeug-Kapazität, kann die `energy`-Basis nicht angewendet werden und alle Ladepunkte werden stattdessen nach Prozent gereiht. Das betrifft neben Ladepunkten ohne Fahrzeug auch Wallboxen, die den Ladestand selbst melden (integrierte Geräte). evcc protokolliert den Rückfall und veröffentlicht die tatsächlich verwendete Basis, sodass das Hysterese-Feld in der UI mit der jeweils gültigen Einheit beschriftet wird.
-Heizungs-Ladepunkte nehmen an diesem Vergleich nicht teil und erzwingen auch keinen Rückfall auf `percent`.
-
-Diese Option hat keine Wirkung bei `priorityStrategy: none`.
-
-**Standardwert:** `percent`
-
-**Beispiel**:
-
-```yaml
-priorityBasis: energy
-```
-
----
-
-### `priorityHysteresis`
-
-Eine Totband für die über [`priorityStrategy`](#prioritystrategy) gewählte Unterordnung. Ein Ladepunkt übertrifft einen anderen derselben `priority` nur dann, wenn er um **mehr** als diesen Betrag voraus ist. Dies verhindert, dass zwei nahezu gleich geladene Fahrzeuge ständig die Plätze tauschen (Rangwechsel bei jeder Ladestandsänderung); stattdessen bleiben sie gleichauf und teilen sich den verfügbaren Überschuss.
-
-Die Einheit folgt [`priorityBasis`](#prioritybasis): soc-%-Punkte bei der `percent`-Basis (Standard) und kWh bei der `energy`-Basis. Fällt die `energy`-Basis auf den Prozentvergleich zurück (siehe oben), wird auch das Totband in soc-%-Punkten gelesen.
-
-Gültige Werte reichen von `0` bis `99`. Der Standardwert `0` deaktiviert die Totband.
-
-Die Totband gilt nicht für Heizungs-Ladepunkte, da diese von der Unterordnung vollständig ausgeschlossen sind.
-
-Diese Option hat keine Wirkung bei `priorityStrategy: none` und beeinflusst nie die Rangordnung zwischen Ladepunkten unterschiedlicher `priority`.
-
-**Standardwert:** `0`
-
-**Beispiel**:
-
-```yaml
-priorityHysteresis: 5
-```
diff --git a/src/content/docs/en/reference/configuration/loadpoints.md b/src/content/docs/en/reference/configuration/loadpoints.md
index 363f727fd..abc41d19d 100644
--- a/src/content/docs/en/reference/configuration/loadpoints.md
+++ b/src/content/docs/en/reference/configuration/loadpoints.md
@@ -349,7 +349,42 @@ This prioritisation works in `pv` and `minpv` modes. In `minpv` mode, charging i
 If a vehicle has a priority defined, it overrides the priority of the loadpoint it is connected to.
 :::
 
-How loadpoints with the **same** priority are sub-ordered can be configured via the site options [`priorityStrategy`](/en/reference/configuration/site#prioritystrategy), [`priorityBasis`](/en/reference/configuration/site#prioritybasis) and [`priorityHysteresis`](/en/reference/configuration/site#priorityhysteresis).
+Loadpoints that share the **same** priority can be further sub-ordered 🧪.
+This is configured in the UI under **Configuration → Loadpoints → Priorities**.
+The dialog only appears when experimental features are enabled under **Configuration → Experimental** and at least two loadpoints are configured.
+These settings are not available in `evcc.yaml`; they are stored internally and survive restarts.
+
+**Strategy** decides which equal-priority loadpoint receives surplus power first:
+
+- `none` – "First wins" (default): no sub-ordering, whoever started charging first keeps the surplus.
+- `soc` – "Emptiest first": the vehicle with the lowest charge level is preferred.
+- `deficit` – "Biggest need first": the vehicle furthest from its charging limit (`limitSoc − soc`) is preferred.
+
+**Basis** determines how the gap between vehicles is measured:
+
+- `percent` (default): compare by charge level in percent.
+- `energy`: scale the percentage gap by the vehicle's [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are compared by **absolute energy demand (kWh)**. This avoids preferring a small second battery just because its percentage is lower, even though it needs less energy than a larger one (a 25 kWh car at 40 % needs less energy than a 75 kWh car at 50 %). When any compared vehicle has no known capacity – including loadpoints without a vehicle or chargers reporting the charge level themselves – all loadpoints are compared by percent instead. evcc logs this fallback and publishes the basis actually in use, so the UI labels the hysteresis field with the correct unit.
+
+**Hysteresis** is a deadband from `0` to `99`.
+An equal-priority loadpoint only overtakes another when it is ahead by **more** than this value.
+This prevents two nearly equally charged vehicles from constantly swapping ranks; instead they tie and share the available surplus.
+The unit follows the basis: soc percentage points with `percent` (default) and kWh with `energy`.
+When the `energy` basis falls back to the percent comparison (see above), the deadband is read in percentage points as well.
+`0` (default) disables the deadband.
+Basis and hysteresis have no effect with strategy `none`.
+
+:::note[Heating]
+Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering.
+Their soc value holds a temperature, not a charge level, so "emptiest first" would compare unrelated quantities.
+They keep their plain `priority` ranking.
+Put heaters on their own `priority` if you want them ahead of or behind your vehicles; priorities across tiers are unaffected by this sub-ordering.
+:::
+
+A loadpoint whose vehicle charge level is unknown also keeps its plain `priority` rank.
+A vehicle reporting 0 % counts as unknown here, so it ties with a fully charged one instead of being charged first.
+
+These values can also be set via the API: `POST /api/prioritystrategy/{none|soc|deficit}`, `POST /api/prioritybasis/{percent|energy}` and `POST /api/priorityhysteresis/{0..99}`.
+The same topics are available via MQTT (`priorityStrategy`, `priorityBasis`, `priorityHysteresis`) and the active values are published in the state.
 
 **Default value:** `0`
 
diff --git a/src/content/docs/en/reference/configuration/site.mdx b/src/content/docs/en/reference/configuration/site.mdx
index fb70010bb..555a1ea9a 100644
--- a/src/content/docs/en/reference/configuration/site.mdx
+++ b/src/content/docs/en/reference/configuration/site.mdx
@@ -30,6 +30,8 @@ site:
       - myconsumer1 # regular consumer, recorded for consumption statistics
     ext:
       - myext1 # for data logging, load management, etc.
+  curtailers:
+    - my_curtailer # curtailment device reference
   residualPower: 100
 ```
 
@@ -76,7 +78,7 @@ site:
 
 ### `meters.grid`
 
-Defines the [`meter`](meters) (current measurement device) that provides the measurements of the grid connection point.
+Defines the [`meter`](/en/reference/configuration/meters) (current measurement device) that provides the measurements of the grid connection point.
 
 **Possible values**: Value of a `name` parameter in the [`meters`](#meters) configuration.
 
@@ -90,7 +92,7 @@ grid: mygridmeter # grid meter reference
 
 ### `meters.pv`
 
-Defines [`meter`](meters) (current measurement devices), from which evcc fetches PV generation measurements.
+Defines [`meter`](/en/reference/configuration/meters) (current measurement devices), from which evcc fetches PV generation measurements.
 Multiple devices can be specified. Power data is automatically added.
 
 **Possible values**: A single value or a list of values of a name parameter in the [`meters`](#meters) configuration. The list version can also be used with single values.
@@ -113,7 +115,7 @@ pv: # (pvs = deprecated)
 
 ### `meters.battery`
 
-Defines the [`meter`](meters) (current measurement devices) that provide measurement data from the battery(ies).
+Defines the [`meter`](/en/reference/configuration/meters) (current measurement devices) that provide measurement data from the battery(ies).
 Multiple devices can be specified. Power data is automatically added, and an average is calculated from the battery state of charge.
 
 **Possible values**: A single value or a list of values of a `name` parameter in the [`meters`](#meters) configuration. The list version can also be used with single values.
@@ -192,6 +194,20 @@ ext:
   - myext2 # second ext meter reference
 ```
 
+### `curtailers`
+
+Curtailment devices from the [`curtailers`](/en/reference/configuration/curtailers) configuration that limit feed-in on request of the grid operator (§ 9 EEG).
+They are applied together with the curtailable `pv` meters when the [`hems`](/en/reference/configuration/hems) integration signals a limit.
+
+**Possible values**: A list of values of a `name` parameter in the [`curtailers`](/en/reference/configuration/curtailers) configuration.
+
+**Example**:
+
+```yaml
+curtailers:
+  - my_curtailer # curtailment device reference
+```
+
 ### `residualPower`
 
 Sets the target operating point of the surplus regulation at the grid connection (grid meter). The default value is 0 W.
@@ -232,81 +248,3 @@ See also the [alternative using enable/disable to allow proportional PV and grid
 ```yaml
 residualPower: -690
 ```
-
----
-
-### `priorityStrategy`
-
-Determines how loadpoints that share the same [`priority`](/en/reference/configuration/loadpoints#priority) are sub-ordered when PV surplus is distributed. This only breaks ties between equal-priority loadpoints; it never changes the ordering between loadpoints of different `priority`.
-
-These options are experimental. In the UI, the Priority dialog (marked 🧪) only appears when you enable experimental features under **Configuration → Experimental** and at least two loadpoints are configured. You can also set them in `evcc.yaml`; the configuration works without experimental mode.
-
-:::note[Heating]
-Heating loadpoints (e.g. a heat pump) are excluded from this sub-ordering. Their soc value holds a temperature rather than a charge level, so "charge the emptier one first" would compare unrelated quantities. They keep the plain `priority` ranking and therefore rank below vehicles within the same tier. Put heaters in their own `priority` if you want them ahead of, or behind, your vehicles. Cross-tier priorities still apply to them.
-:::
-
-**Possible values**:
-
-- `none`: Rank by `priority` only. Equal-priority loadpoints keep their existing order. This is the default behaviour.
-- `soc`: Among equal-priority loadpoints, prefer the one whose vehicle has the **lower** charge level, i.e. charge the emptier vehicle first.
-- `deficit`: Among equal-priority loadpoints, prefer the one with the **larger** gap between the vehicle's charge level and its charging limit (`limitSoc − soc`), i.e. the one furthest from its target.
-
-The default is `none`, so existing configurations are unaffected unless this option is set explicitly.
-
-A loadpoint whose vehicle charge level is unknown keeps its plain `priority` rank as well. A vehicle reporting 0 % counts as unknown here, so it ties with a fully charged one instead of being charged first.
-
-**Default value:** `none`
-
-**For example**:
-
-```yaml
-priorityStrategy: soc
-```
-
----
-
-### `priorityBasis`
-
-Determines whether the sub-ordering selected via [`priorityStrategy`](#prioritystrategy) measures the gap by charge level percentage or by absolute energy.
-
-**Possible values**:
-
-- `percent`: Compare by the soc-% gap. This is the default behaviour.
-- `energy`: Scale the soc-% gap by the vehicle [`capacity`](/en/reference/configuration/vehicles#capacity), so loadpoints are compared by **absolute energy (kWh)**. This avoids over-prioritizing a small second battery just because its percentage is lower, even though it needs less energy than a larger one (e.g. a 25 kWh car at 40 % needs less energy than a 75 kWh car at 50 %).
-
-When the capacity of any compared vehicle is unknown, the `energy` basis falls back to the percentage comparison.
-Heating loadpoints don't take part in this comparison, and they don't force a fallback to `percent`.
-
-The comparison saturates above 99 kWh, so two loadpoints that both need more than that rank equal and share the surplus.
-
-This option has no effect with `priorityStrategy: none`.
-
-**Default value:** `percent`
-
-**For example**:
-
-```yaml
-priorityBasis: energy
-```
-
----
-
-### `priorityHysteresis`
-
-A deadband for the sub-ordering selected via [`priorityStrategy`](#prioritystrategy). A loadpoint only outranks another of the same `priority` when it is ahead by **more** than this amount. This prevents two near-equal vehicles from leapfrogging each other (swapping rank every time their charge levels cross); instead they tie and share the available surplus.
-
-The unit follows [`priorityBasis`](#prioritybasis): soc-% with the `percent` basis (the default) and kWh with the `energy` basis. When the `energy` basis falls back to the percentage comparison (see above), the deadband is read in soc-% too.
-
-Valid values range from `0` to `99`. The default `0` disables the deadband.
-
-The deadband doesn't apply to heating loadpoints, which are excluded from the sub-ordering entirely.
-
-This option has no effect with `priorityStrategy: none`, and it never affects the ordering between loadpoints of different `priority`.
-
-**Default value:** `0`
-
-**For example**:
-
-```yaml
-priorityHysteresis: 5
-```