Warnung, wenn interval < 10 sekunden

[VolkerK62]

Manchmal kommt es zu Problemen, weil das Interval sehr kurz eingestellt wird.
Nach dem Motto, je schneller, desto besser.
Zusätzlich zu einem Hinweis in der Doku, sollte evtl auch noch eine Warnung im Log ausgegeben werden.

[mdkeil]

Und um welche Probleme handelt es sich.. ? Ich habe z.B. 6 Sekunden und konnte noch keine Fehler feststellen.

[andig]

Die Regelung schwingt...

[VolkerK62]

Es ist situations- und/oder komponentenabhängig. Es KANN zu Problemen führen, muss aber nicht.
Gerade bei ständig wechselnden Bedingungen können die Änderungen dann die Ausführung der vorherigen Vorgabe überholen. Das führt dann zu unerwünschtem Verhalten.
Es ist als reine Vorsichts-Warnung gedacht, so wie bei soc.poll.always.

[andig]

So? Eigentlich sollten wir unter 30s immer warnen?

if interval < 10*time.Second {
	site.log.WARN.Printf("interval should not be shorter than 10s")
}

/cc @premultiply

[VolkerK62]

30s finde ich für den allgemeinen Normalfall etwas hochgegriffen.
("interval should usually not be shorter than 10s")

[premultiply]

Würde es etwas anders formulieren.
So nach der Art: WARNING interval is shorter than 10s. This may lead to strange issues if not tested and measured very properly.

[OneLineTwoBugs]

Hier etwas Senf dazu, darf man gerne ignorieren, das ja nur um eine Warning geht :)

unsolicited advice: 10 Sekunden sind definitiv zu lange, wenns ins Lastmanagement geht (#8427).

unsolicited idea (nicht dringend, aber ggf. nett): Zwei neue Settings, defaultUpdateInterval und maxDeltaTolerance. Ziel-Wert wird alle interval Sekunden berechnet. Standardmässig wird nur alle defaultUpdateInterval Sekunden ein neuer Wert an die Loadpoints geschickt, ausser der neue Wert weicht um mehr als maxDeltaTolerance vom aktuellen Wert der Loadpoints ab, dann wird der neue Wert sofort gesendet. Sofort-Updates brauchts nur dann, wenn der Loadpoints zuviel Strom saugt, bei zu wenig kann man warten, bis interval Sekunden um sind.

So kann man das Schwingen der Regelung stark reduzieren und regelt in "Notfällen" immernoch schnell, was ja das eigentliche Ziel von einem tiefen interval-Wert ist.

[andig]

unsolicited advice: 10 Sekunden sind definitiv zu lange, wenns ins Lastmanagement geht (#8427).

Nein, ist es nicht. Schmelzsicherungen sind träge! Unabhängig davon kann das Regelintervall nur so kurz sein wie die Geräte schnell sind und da sind 10s oft schon zu kurz.

[OneLineTwoBugs]

Nein, ist es nicht. Schmelzsicherungen sind träge!

Es geht ja nicht nur um Schmelzsicherungen. Auch das Auslösen von LS-Automaten ist unschön. Bei zwei Wallboxen hinter einem LS hätten wir 10 Sekunden lang 2-facher Nennstrom, was für eine Auslösung reichen kann. Das gitl insbesondere dann, wenn die Wallbox ja - wie ihr sagt - so langsam regelt, dass man ihr noch mehr Zeit geben muss. Ggf. dauerts dann ja sogar 20 Sekunden, bis sie den Strom wirklich reduziert.

Es mag Hardware geben, die nicht so schnell regelt. Aber es gibt auch genug, die so schnell regeln kann. Meine E3DC-Wallbox regelt ungefähr im Sekundentakt, die Alfen die ich mit evcc betreibe schafft 2-Sekunden Takt, drunter bin ich nicht gegangen. Warum also pauschal allen eine 10s Warnung aufs Auge drücken?

edit: Referenz Auslösecharateristik von Hager Ls-Automaten. Bei 10s 2-fachem Nennstrom sind wir im Bereich des thermischen Auslösers: https://www.hager.de/files/download/0/24101272_1/0/DE_20DE0001_TECHNIK_LEITUNGSSCHUTZSCHALTER.PDF

[andig]

Warum also pauschal allen eine 10s Warnung aufs Auge drücken?

Weil sinnlos kurze Regelintervalle bei uns immer wieder Supportaufwand verursachen. Lange Intervalle tun das nie und LM ist ein anderes Thema.

[premultiply]

Die Regelschleife ist über grid-Meter, charger, Auto, grid-meter erheblich länger.
Da ist die Reaktionzeit des Chargers schon fast irrelevant.
Deutlich weniger als 10s schaffen nur sehr ausgewählte Kombinationen.
Und nein, in so kurzer Zeit bei so wenig mehr Strom löst kein LS aus.
Da geht es um Kurzschlussströme in x-facher Höhe.
Das hier geht aber höchstens auf die thermische Auslösung und die ist SEHR träge.
30s sind da auch nix.

[OneLineTwoBugs]

Die Regelschleife ist über grid-Meter, charger, Auto, grid-meter erheblich länger.

Genau darum ist so wichtig, dass man möglichst früh regelt. evcc ist nicht die einzige Komponente im System, die Delay hat. Ich lese meinen grid-meter alle 500ms aus.

Das hier geht aber höchstens auf die thermische Auslösung und die ist SEHR träge.
30s sind da auch nix.

Anbei die Auslösecharakteristik von LS-Automaten als Screenshot (Quelle: Hager, Link siehe oben):

Der thermische Auslöser löst bei 2-fachem Nennstrom in 10 Sekunden aus.
Bei 30 Sekunden bist du irgendwo im Bereich 1.7.
Wenn wir nun den Komponenten Meter / Charger / Auto auch noch 10 Sekunden Delay zugestehen, haben wir bei 1.5-fachem Nennstrom ein Problem.

Relevant ist das v.a. fürs Lastmanagement, das ja genau dann greifen soll, wenn man ein System betreibt, das bereits am maximum ist. Für den PV-Regler kostets nur ein bisschen Geld. 30 Sekunden laden mit 11kW bei 35ct/kWh aus Netz statt Solar kostet dann 3.2 cent. Der Fall ist etwas gesucht weil die Sonne ja selten von 100 auf 0 runtergeht, aber an sehr wechselhaften Tagen muss man schon davon ausgehen, dass man zu 50% der Zeit 1kW zu viel aus dem Netz zieht. Bei einer Ladesession von 4h sind das dann 70 cent Netzstrom.

[VolkerK62]

ich denke, das geht hier Richtung off topic.

Hier geht es darum, "Unkundigen" einen Hinweis zu geben, dass kürzer nicht unbedingt besser ist.
This may lead to strange issues if not tested and measured very properly.

Es wird ja dadurch nicht verhindert, ein ms-Intervall einzustellen.

[StefanSchoof]

Wenn ich die Warnung lese, Frage ich mich wie ich testen und messen müsste, wenn ich meinen Intervall niedriger setzen will. Ich vermute, die Frage wir dann früher oder später kommen. Sollte da gleich ein Eintrag blin der Dokumentation angelegt werden?

[VolkerK62]

ist schon https://docs.evcc.io/docs/reference/configuration/interval

[StefanSchoof]

Da steht nicht was ich genau tun muss, um Probleme bei einem niedrigeren Intervall zu vermeiden.

[andig]

Höheres Intervall? Ist ja keine Diplomarbeit ;)

[StefanSchoof]

Dann würde ich vorschlagen, die Warnung ähnlich wie in den Docs zu formulieren und das Testing und messen nicht zu erwähnen.

Ein zu kurzes Interval ( < 10s ) kann zu unerwünschtem Verhalten führen, da die beteiligten Komponenten dann nicht genug Reaktionszeit haben, bevor der nächste Regelzyklus beginnt.

(Mein Intervall ist bei 30 Sekunden und habe keinen Plan den gerade zu verringern)

[RTTTC]

My interval: 15s and it is perfectly fine in all regards.
Usually it's the newbies who want to have interval as short as possible .. :) (Been there, done that!)

[andig]

Ein zu kurzes Interval ( < 10s ) kann zu unerwünschtem Verhalten führen, da die beteiligten Komponenten dann nicht genug Reaktionszeit haben, bevor der nächste Regelzyklus beginnt.

Interval <30s can lead to unexpected behaviour, see https://docs.evcc.io/docs/reference/configuration/interval.

[andig]

Closed in 2702661

[StefanSchoof]

Sollte dann der Wert in der Beispiel yaml auch auf 30s erhöht werden. Eine Beispielconfig die gleich zu einer Warnung führt klingt für mich nicht optimal

https://github.com/evcc-io/evcc/blob/270266189c5a7debcadcf2fb32da7117962f255d/evcc.dist.yaml#L13C11-L13C11

[ChrisBGL]

Hier etwas Senf dazu, darf man gerne ignorieren, das ja nur um eine Warning geht :)

unsolicited advice: 10 Sekunden sind definitiv zu lange, wenns ins Lastmanagement geht (#8427).

unsolicited idea (nicht dringend, aber ggf. nett): Zwei neue Settings, defaultUpdateInterval und maxDeltaTolerance. Ziel-Wert wird alle interval Sekunden berechnet. Standardmässig wird nur alle defaultUpdateInterval Sekunden ein neuer Wert an die Loadpoints geschickt, ausser der neue Wert weicht um mehr als maxDeltaTolerance vom aktuellen Wert der Loadpoints ab, dann wird der neue Wert sofort gesendet. Sofort-Updates brauchts nur dann, wenn der Loadpoints zuviel Strom saugt, bei zu wenig kann man warten, bis interval Sekunden um sind.

So kann man das Schwingen der Regelung stark reduzieren und regelt in "Notfällen" immernoch schnell, was ja das eigentliche Ziel von einem tiefen interval-Wert ist.

Genau sowas fehlt bislang!

[andig]

Das Issue hier ist geschlossen, bitte neue Diskussion.