Idee: sunrise blocker (niedrige PV-Leistung zur Grundlastdeckung am Morgen) und akkuschonendes Entladen

[Dino0811]

Hi,

Ich nutze selbst keinen dynamischen Strompreis. BF Ai regelt quasi nur den PV-Strom und Akku bei mir.
Daher nach Beobachtung der letzten Tage 2 Ideen zur Diskussion:

Früh morgens laufen meine (2x Süd und 2x West) Module sanft an. Die Automation pumpt dann 20-30W langsam steigend in den Speicher statt ins Haus.
Das bringt allerdings fast nichts, weil die Ladung in dem Segment sehr ineffizient ist - hier wäre es sinnvoller die kleinen Beträge im Haus zu verwenden statt in den Akku zu laden.

1. Könnte man hier sowas wie einen "sunrise_block" integrieren? wenn SOC < 15% & PV < 150W (einstellbar) dann decke Hausgrundlast statt Akku zu laden. Im Wintermode kann das ja gern zum Akkuschutz auch inaktiv sein

2. akkuschonendes Entladen: z.B. Max Werte für entsprechende SOC --> 2kw sind am Abend schnell leer und dann wäre eine langsamere Entladung über die Nacht sicherlich förderlicher für den Akku als wenn er sich mit dem Rest der drin ist bei Abruf hoher Leistung (Herd, Ofen, Fön, ...) zugig entleert und danach ist voller Netzbezug
   {% if soc <= soc_min %} 0 {% elif soc <= 15 %} 50 {% elif soc <= 25 %} 150 {% elif soc <= 40 %} 300 {% else %} 800 {% endif %}

[Dino0811]

PS: für 2. sehe ich gerade würde ja auch die neue "manuelle Konstantentladung" praktikabel sein. - greift dann natürlich nur bei manuellem Modus und nicht Automatik oder Sommerlogik. Damit wäre es auch nicht abhängig vom SOC oder der Uhrzeit und tagsüber hätte man die selben Effekte. Wenn man z.B. dann Wäsche waschen will wird ggf. nicht mit 800W unterstützt - oder habe ich den Punkt der Uhrzeit nicht gefunden ab wann diese Regel (z.B. ab 19:00) greift?

Frage: muss die manuelle Konstantentladung entsprechend inkl. Sicherheitsreserve unterhalb der durchschnittlichen Hausgrundlast gesetzt werden um eine Einspeisung zu verhindern oder wird das mit gegengecheckt?

[PalmManiac]

Um die neue Funktion zu nutzen, mußt du dir eine Automation bauen. Ein Beispiel ist in der Anleitung drin. Damit kann man dann per Uhrzeit steuern.

[PalmManiac]

Zu 1.) Eigentlich ist da ein Puffer eingebaut, der erst ab etwa 80Watt Überschuss die Ladung starten sollte. Ich mach mir aber mal Gedanken über die Idee, klingt sinnvoll.

[Dino0811]

ja, das wäre super!
denn wie du siehst, tut er das gar nicht:

[JackONeill199]

ja, das wäre super! denn wie du siehst, tut er das gar nicht:

Was ist das für eine coole Karte die du da nutzt?

[Dino0811]

Power Flux Card
https://github.com/jayjojayson/power-flux-card

[PalmManiac]

Also nochmal zu 1.: Das Ziel des Sommer-Modus ist primär die Autarkie zu maximieren der Netzunabhängigkeit. Dabei ist es wichtig bei Überschuss zu laden. Wegen eines anderen Fehlers ist jetzt aber ein Puffer reingewandert, ab 80Watt wird geladen. Reicht das?

[PalmManiac]

Gerade habe ich nochmal gelesen. Du hast bedenken, dass morgens die Grundlast nicht gedeckt wird, weil der Akku schon anspringt zum laden. Die Ladesteuerung greift sich den Überschuss ab der ins Netz gehen soll. Wenn nun die Grundlast steigt, weil die Kaffeemaschine eingeschaltet wird oder andere Geräte, dann regelt das System runter oder schaltet wieder ab, da dann ja wieder kein Einspeiseüberschuss vorhanden ist. Das wird schon alles beachtet. :)

[Dino0811]

Ich möchte möglichst verhindern, dass er morgens, wenn es noch diffus ist und nur geringe Leistung erzeugt wird die paar Watt in den Speicher gehen - sondern noch ins Haus.
Da diese geringe Leistung ja quasi in wandlugsverlust verpufft und es sinnvoller wäre das dem Netzbezug gegenzurechnen.
Wenn er jetzt erst später anfängt. Zu laden und bis dahin das Haus deckt ist alles ok :)
Bisher hat er ja schon quasi 9 Watt versucht in den Speicher zu bringen

[PalmManiac]

Hast du schon die neue V3.5.1 laufen, da ist ein erster Puffer drin wegen eines anderen Fehlers, der bei so geringen Ladelasten zum Aufschwingen führte. Mit demPuffer wird erst ab >= 80Watt mit dem Laden begonnen.

[Dino0811]

Habe sie vor 1h installiert, mal schauen wie es morgen läuft :) - vielen Dank für deine Arbeit und die schnellen Reaktionen!

[Dino0811]

Also auch die 3.5.1 fängt am Morgen direkt an die minimalen Leistungen in den Speicher statt ins Haus zu drücken:

Greift da vllt. noch eine Logik die bei erreichte soc_min (was bei mir 10% sind) versucht auf Krampf bis auf den Hysteresewert / Hysteresespannung bis zum Wiederentladen voll zu machen?

[PalmManiac]

Das ist was anderes. Du hast eigentlich keinen Überschuss, also sollte die Integration garnichts machen. Irgendwo ist bei dir noch was falsch konfiguriert, ein Sensor liefert da andere Daten als erwartet. Schick mir doch mal Screenshots von der Konfig von BSFAI, da müssen wir mal drüber schauen. Parallel schaue ich aber nochmal im Code nach, aber dann würde dieser Effekt auch bei mir und anderen auftreten... Hmmm....

[Dino0811]

BFAI_Einstellungen.pdf

[Dino0811]

Andersherum klappt es, am Abend wenn was im Speicher ist - läuft alles korrekt wie es soll

[PalmManiac]

Also in deiner Konfig sieht alles gut aus. Hmmm..... Dann muß ich nochmal über den Code schauen...

[PalmManiac]

Also, im Code gibt es keine Logikfehler zu entdecken. Er darf eigentlich erst anfangen zu laden, wenn mind. 80Watt ins Netz eingespeist werden und nicht schon ab PV-Leistung.

Wenn dieser Fall wieder auftritt, dann mach mal folgendes:

Geh ins Entwicklerwerkzeug - Zustände. Gib im Suchfeld Battery ein und suche in der Liste nach dem Sensor für Aktives Geräteprofil. Von dem schickst du mir dann genau von diesem Zeitpunkt Screenshots aller Attribute. Falls ein zugewiesener Sensor Mist baut, dann sehen wir das dort.

Bist du auch sicher, dass du das Dashboard, den Teil für die Batterie richtig konfiguriert hast? ;)

Schau dir auch mal die PV-Leistungskurve am Morgen an. Ursächlich könnte auch ein Peak sein beim Sonnenaufgang, der dann den Lade-Impuls auslöst.

[Dino0811]

Guten Morgen,

es wird wieder der Akku geladen (von 10 (soc_min) auf 16% (Wiederentladeschwelle), danach wird wie die letzten Tage wieder entladen bis die Hauslast gedeckt werden kann).

das ist aktuell der Fall:

und hier der Zustand:
sensor.battery_smartflow_ai_aktives_gerateprofil

options: SF800Pro, SF2400AC, SF1600AC, Hyper 2000, HUB 2000
soc: 12
pv_w: 34
deficit: 244.049987792969
surplus: 0
house_load: 278
price_now: null
avg_charge_price: 0
economic_discharge_threshold: 0
effective_discharge_threshold: null
profit_eur: 0
delta_kwh: 0
is_grid_charge: false
charge_source: no_charge_delta
charge_price_applied: null
battery_ac_power_raw: -34
battery_charge_w_est: 34
battery_discharge_w_est: 0
discharge_blocked_by_soc_min: true
discharge_resume_soc: 16
soc_discharge_resume_margin: 6
max_charge: 800
max_discharge: 800
set_mode: output
set_input_w: 0
set_output_w: 0
ai_mode: summer
manual_action: standby
decision_reason: soc_min_resume_block
adaptive_peak_active: false
device_profile: SF800Pro
profile_max_input_w: 1000
profile_max_output_w: 800
soc_limit: 0
additional_battery_charge_w: 0
installed_pv_wp: 1800
soc_limit_status: no_limit
effective_target_import_w: 10
effective_deadband_w: 15
effective_export_guard_w: 20
effective_kp_up: 0.4
effective_kp_down: 0.75
effective_max_step_up: 250
effective_max_step_down: 400
effective_keepalive_min_deficit_w: 15
effective_keepalive_min_output_w: 60
effective_soc_discharge_resume_margin: 6
expert_mode_enabled: true
cell_voltage_protection_enabled: true
configured_lowest_cell_voltage_sensor_count: 1
global_lowest_cell_voltage: 3.25
cell_voltage_status: normal
cell_voltage_soc_plausibility: normal
cell_voltage_soc_warning_threshold: 20
cell_voltage_soc_critical_threshold: 30
cell_voltage_warning: 3.1
cell_voltage_cutoff: 3
cell_voltage_resume: 3.3
cell_voltage_discharge_blocked: false
cell_voltage_resume_threshold: 3.3
cell_voltage_emergency_active: false
base_profile: SF800Pro
profile_overrides_active: true
profile_override_count: 15
season_summer_pv_threshold: 900
season_summer_export_threshold: 300
season_winter_pv_threshold: 450
season_winter_export_threshold: 120
season_counter: -124108
profile_overrides:
CHARGE_DEADBAND_W: 35
CHARGE_KP_DOWN: 0.75
CHARGE_KP_UP: 0.4
CHARGE_MAX_STEP_DOWN: 400
CHARGE_MAX_STEP_UP: 250
DEADBAND_W: 15
EXPORT_GUARD_W: 20
KEEPALIVE_MIN_DEFICIT_W: 15
KEEPALIVE_MIN_OUTPUT_W: 60
KP_DOWN: 0.75
KP_UP: 0.4
MAX_STEP_DOWN: 400
MAX_STEP_UP: 250
SOC_DISCHARGE_RESUME_MARGIN: 6
TARGET_IMPORT_W: 10

device_class: enum
icon: mdi:battery-outline
friendly_name: ZendureAI Aktives Geräteprofil

[Dino0811]

PS: die neue BF-Ai Version habe ich erst später gesehen. Habe sie jetzt installiert und schaue mal was morgen mit der 3.6.0 passiert.

[PalmManiac]

Hi,

Die aufgezeichneten Attribute zeigen, dass Battery SmartFlow AI in diesem Moment keine Ladung gestartet hat. Es wurde kein Ladebefehl gesetzt (set_input_w: 0), kein PV-Überschuss erkannt (surplus: 0) und der Entscheidungsgrund war lediglich soc_min_resume_block. Das bedeutet: BSFAI hat nur die Entladung gesperrt, weil der Akku noch unterhalb der Wiederfreigabe-Schwelle lag.

Dass der Akku trotzdem mit ca. 34 W geladen wurde, kommt in diesem Moment nicht aus der BSFAI-Ladelogik, sondern sehr wahrscheinlich aus dem Verhalten der Hardware bzw. der Zendure-internen Regelung.

es sieht also so aus, als ob diese Ladung durch eine andere Regelung gestartet wurde, eventuell durch die Zendure-App. Das würde dann aber auch bedeuten, dass du da noch etwas drin hast, was nicht mehr drin sein oder aktiv sein sollte. Von BSFAI kommt es nicht.

[Dino0811]

puh, das lässt mich ratlos zurück.

1. ich habe im Homeassistant keine weitere Automation welche da dazwischen regeln könnte.
2. Also bleiben nur Zendure (Android App) / Zendure HA-integration

Da kann man aber fast nichts einstellen.
HEMS ist deaktiviert,
Akku steht hier auf SOC "5 bis 100%"
Netzausgang variiert --> wird vom BF-Ai gesteuert (passt mit dessen Werten überein)
Strategie der Leistungsverteilung: lässt sich nicht ändern, ist aber bei Zendure: 1 Nutzung im Haus; 2 Akkuspeicher; ins Netz einspeisen (das was ich will, aber was anscheinend morgens nicht passiert.) - er haut in den Speicher (egal bei welcher Lasst und PV Ertrag) bis die 16% des Akkus erreicht sind und BF-Ai die Entladung freigibt oder weitergeladen wird da die Hauslast abgedeckt ist.
Überschüssige Energie exportiern: zulassen

Und die Zendure HA-Integration lässt auch keine weiteren Einstellungen zu.

puh ...

[PalmManiac]

Wenn da wieder passiert, deaktiviere mal BSFAI, ob er dann noch weiter läd oder nicht.

[Dino0811]

Wirklich komisch, keine Ahnung wo ich noch was verstellen soll.

1. Er lädt mit 18W den Speicher (10%)
2. BSFAI deaktivieren - lädt weiter
3. Zendure Integration neustarten -> Laden unterbricht, nach Neustart wird wieder Speicher geladen

Dabei sagt die eigene (nicht änderbare) Zendurelogik in der App --> 1. Haus --> 2. Speicher --> 3. Netz

Bei 16% Speicherstand greift BSFAI dann ein und lässt den Akku wieder entladen wenn PV < Hauslast

[PalmManiac]

Damit haben wir den Übeltäter, ZHA. Zieh mal den Regler für die Ausgangsleistung auf 0 und schau mal ob er da bleibt. Wenn nicht, dann regelt bei dir noch was. Schick mir doch mal Screenshots von ZHA und dem Manager-Bereich, da muß der Grund zu finden sein.

[Dino0811]

gerade getestet (mit voller Deckung der Hauslast und Überschuss --> Speicher laden zu der Zeit natürlich)

1. BSFAI deaktiviert; Ausgangsleistung bleibt auf 0, nichts wird nachgeregelt. -->ok
2. BSFAI wieder aktiviert, Ausgangsleistung wird wieder hochgeregelt. -> soll es ja auch tun --> auch ok

Ausgangsleistung hier wieder hochgeregelt, da BSFAI aktuell wieder aktiv.

[Dino0811]

Als wenn es den SF 800 Pro nicht interessiert.
Zendure speist den Akku - in der App kann man das aber ja nirgends beeinflussen, Da wie gesagt die eigentliche Prio (Haus -> Speicher -> öffentl. Netz) fest gesetzt ist.

1. BSFAI aus --> Akku wird mit 30W gespeist
2. ZHA aus --> Akku wird laut Android app weiterhin gespeist.
   beides der Reihe nach wieder an, keine Änderung.

Bei 16% wir BSFAI dann wieder eingreifen und das Laden bei 16% stoppen und das Entladen freigeben, da die Grundlast von PV noch nicht gedeckt wird.

[PalmManiac]

Wenn in der APP HEMS aus ist und alles auf Lokale Kommunikation steht, dann ist das egal und hat keinen Einfluss. Es hört sich so an, als ob in der Handy-APP noch irgendwas nicht richtig konfiguriert oder abgeschaltet ist. Die Ladung wird aus der Cloud initialisiert und nicht durch ZHA oder BSFAI. Außerdem sehe ich gerade auf dem Screenshot, bei Verbindungsart steht noch Cloud. Das muß auf Lokal/ZenSDK gestellt werden!!!!

[Dino0811]

das stimmt - habe gestern von Cloud noch auch ZenSDK gewechselt...leider heute morgen das selbe Ergebnis, es gehen 19W in den Speicher.
In der App gibt es aber eigentlich nichts mehr zu steuern:

zendure.pdf

[Dino0811]

Hi,
also heute gibt's ja mal wieder Sonne.
Verhalten wie beschrieben. --> Speicher wird geladen, Haus wird nicht versorgt.

Heutiger Test:

1. BSFAI deaktiviert -> Speicher wird weiterhin geladen
   ABER dann: Zendure Integration von AC-Eingang auf AC-Ausgang gestellt, AC-Ausgangsleistung von 0 (regelt BSFAI ja runter) einfach auf 100W (aktuell 130W PV) gestellt --> PV speist mit 100W ins Haus und 30W in den Speicher. --> die 100W sollten natürlich im Idealfall durch BSFAI nach Hauslast geregelt werden.

2. Wenn BSFAI aktiv ist kann man natürlich in der Zendure-Integration nicht von AC-Eingang auf AC-Ausgang umstellen, da die BSFAI Logik immer wieder auf AC-Eingang zurückstellt und somit keine Hausspeisung erfolgt.

Der Zendure-Bypass zur Direktdurchleitung greift ja, so wie ich es verstanden habe, nur wenn der Speicher voll ist.

[PalmManiac]

Irgendwas ist bei dir noch falsch konfiguriert. Schick mir doch mal Screenshots von ZHA und von der Konfig von BSFAI, hinter den 3 Punkten. Außerdem, hast du schon die neuste Version laufen, V3.6.2?

[Dino0811]

Hi, ja - die v3.6.2 habe ich heute früh installiert.

Die BSFAI Config hatte ich ja hier schonmal: BSFAI_Einstellungen.pdf

Bei der Zendure gibt es in der Integration ja nur den Token und die Screenshots von oben. Hier habe ich die Verbindungsart von Cloud auf Lokal (zenSDK) geändert - was aber nichts für dieses Problem bewirkt.

Der Zendure an sich kann ja gar nichts mit der Hauslast steuern, da er ja weder in der App noch in HA (nur dummysensor) einen Zählersensor zur Verfügung hat. Ausgelesen wird mein Zähler ja per Hichi-Lesekopf in HA - worauf BSFAI zurückgreift.

nochmal ZHA:

[Dino0811]

Geräte-Sicherungsguppe auf "Hat einen eigenen Stromkreis..." - macht leider auch nichts. Ich werd hier noch verrückt.
Eigentlich gibt es keinen Schalter mehr den man umlegen kann.

[Dino0811]

Ich habe die Entladeschwelle mal auf 2% über SOC_min gestellt, dann gibt BSFAI die Entladung des Speichers bei 12% frei und die aktuelle PV-Produktion von ~90W geht direkt ins Haus (~270W Last), nach dem der Speicher wieder bei 10% angekommen war ging es wieder zu 100% in den Speicher.

[PalmManiac]

Da fällt mir gerade etwas ein. Schau doch mal, wo du SoC-Min in der App eingestellt hast. Wenn da der Wert über dem Soc-Min in BSFAI steht, dann kann das nix werden, dann regelt das BMS und die Zendure-Steuerung ab.

[Dino0811]

den SOC_Min hab ich in der Zendure_App/ZHA schon extra auf den kleinst möglichen Werte von 5% gestellt und in BSFAI auf 10%

[PalmManiac]

Ok, dann bleibt nur noch eins. Über das Zahnrad gibt es einen Experten-Modus, über den man die Sensoren der Zellspannungen der Batterien auswählen kann. Das BMS bei Zendure ist ein passives System. Der SoC wird geschätzt. Während des Betriebes, wenn der Akku nur selten wirklich komplett entladen wird, laufen so die Anzeige und die Wirklichkeit auseinander. Was aber immer stimmt ist die Zellspannung der Batterie. Und da greift wohl eine Sicherung bei dir. Die 10% laut SoC sind wahrscheinlich in Wirklichkeit weniger als 5%, also greift der BMS ein führt eine Schutzladung durch.

Wenn du nun diese Sensoren über den Expertenmodus in BSFAI einrichtest, dann wertet die Integration dieses mit aus als zusätzlichen Schutz und zeigt dir über die Status-Sensoren genau an was wirklich los ist. Du aktivierst über den Expertenmodus dann dadurch den Zellschutz in BSFAI.

[Dino0811]

Auch das Steuern über die Zellspannung hat das Verhalten nicht geändert.

Ich hab gestern zum Test mal etwas anderes gemacht:

1. ZendureHA den Leistungssensor statt des Dummy’s eingetragen und SOC_min von 5% auf 10% erhöht (der sollte vorher nur sicherheitshalber unter den 10% des BSFAI liegen)
2. BSFAI deaktiviert
3. Zendure Manager aktiviert, Betriebsmodus: „smarte Leistungsregelung“

Heute Morgen:
Er hat mit den anfänglichen 30W PV den Speicher von 9% auf 10% gebracht und danach die Anfangsleistung (60 W…70W…80W…etc.) ins Haus gesteckt und nicht den Speicher geladen (der wurde auf 10% gelassen).

Und so möchte ich das durch BSFAI auch, die Frage ist nur warum es partout nicht klappt, denn BSFAI entscheidet in dem Moment ja bei mir den Speicher bis 16% zu laden, dann wird das entladen wieder freigegeben und entweder PV+Speicher decken das Haus oder die Sonne ist schon über der Hauslast, dann wird (erst ab erreichen der 16%) die Hauslast gedeckt + Überschuss in den Speicher.
Dann: Hauslast ~220W, PV ~300W -> Hauslast wird weiter gedeckt und Speicher beginnt mit dem Überschuss (~80W] zu laden
Ziel ist es natürlich BSFAI zu nutzen, gerade wenn dann PV Forecast künftig mit betrachtet wird.

[PalmManiac]

Da haben wir deine 16%, die er immer aufladen will. An Hand deiner Konfig wird die Entladung erst ab 16% freigegeben und bis dahin eine Notladung durchgeführt. Zumindest das Problem ist jetzt klar.

[PalmManiac]

Mit der kommenden V4.0.0, die dann auch Solar-Prognose unterstützt, werde ich den Standby/Idle Modus umbauen und stabiler machen. Das sollte dann das Problem lösen. Wenn alles klappt, sollte sie zum Wochenende fertig sein.

[Dino0811]

Ich habe das bisher so verstanden, dass dies nur die "Wiederfreigabe" ist.
Die 6% hat er bei mir ja nicht erreicht, so dass eine Notladung initiiert werden dürfte. der SOC war nie unter 9 oder 8%
so hatte ich es auch die ganze Zeit.

Mein Verständnis:
Soc_Min 10% --> er entlädt bis 10%
Notladeschwelle 6% --> Wenn der Akku bis 10% entlädt...und weiter Kapazität/Spannung verliert --> Notladung wenn 6% erreicht wird (z.B. 2-3 schlechte Tage)
Wiederfreigabe 16% --> Wenn geladen wird, dann Entladung erst wenn 16% erreicht wurden. Ich dachte dies wurde eingebaut um den Akku zu schonen und ein Pink-Pong-Effekt zu unterbinden (Ansonsten lädt er bis 11%, PV noch kleiner Hauslast-> wieder 1% entladen, ab Soc_Min 10% wieder Akku laden).

Wenn er bei eingestellter Wiederfreigabe ab 16% standardmäßig erst bis 16% lädt, egal was an Hauslast und PV morgens da ist, dann beißt sich doch das gewollte Akkuschonen irgendwie. Da in dem Fall, egal mit welcher PV-Leistung, geladen wird (statt das Haus minimal zu versorgen) und erst später den Akku von den 10% an aufzuladen

Das könnte ich ja wieder nur vermeiden, wenn ich die Wiederentladeschwelle herabsetze auf 10 oder 11% - aber dann tritt wieder der Ping-Pong-Effekt auf.

--> das hat der Zendure-Manager beim heutigen Test nicht gemacht. der hat den Speicher nur kurz auf Soc_Min (9% auf 10%) gebracht, dann Haus mit geringem Ertrag versorgt - und dann erst später mit dem Überschuss geladen (PV - Hauslast = Rest zum Akku laden)

[EDIT]
unsere Posts haben sich überschnitten, dann warte ich mal ab! - Danke

[PalmManiac]

Vergiss die Zellspannungslimits nicht die bevorzugt werden, da sie realistischer sind als die passive rechnerische Ermittlung des SoC durch das BMS. Wenn der Akku zu lange nie richtig entladen wird, sollte ja die Kalibrierung anspringen, das bedeutet aber auch, dass bis dahin der SoC immer weniger realistisch ist und dann greift die Zellspannungsüberwachung.

Aber ja, warte erstmal auf die neue V4 und teste sie, dann sehen wir ja, ob sich damit dann auch bei dir alles richtig verhält.

[Dino0811]

die Notladeschwelle von 3,1V hatte ich jedoch auch nicht erreicht. Und die Tage zuvor gab es volle Lade-Entlade-Zyklen.

Dann warte ich mal auf die V4!

[PalmManiac]

V4.0.0-RC1 ist raus zum testen. Bitte Release-Note/Changelog lesen, da es einiges neues und viele Optimierungen gibt.

[PalmManiac]

Das ist ne gute Frage. Ich kann nur so viel sagen, daß es mit einem SF2400AC funktioniert.

Leider ist das Zeitfenster, wo das bei dir passiert, klein, sonst würde es sich anbieten genau wenn das auftritt mal diverse Einstellungen in ZHA zu ändern. Z.b die Einstellung Energie-Export mal von Erlaubt zu Deaktiviert ändern und schauen, oder die Sicherungsgruppe mal auf "Nicht verwendet..." oder auf "Hat eigenen Stromkreis.." ändern. Das hat bei mir zu Beginn unterschiedliches Verhalten ausgelöst.

@JackONeill199

Schick mir mal einen Screenshot von den Sensoren aus BSFAI, was melden die?

[JackONeill199]

Es gab wohl ein Update für die Zendure Integration, dabei sind Sensoren neu dazugekommen und alte wurden abgeschaltet, deshalb hat das BSFAI und auch meine Übersicht komplett durcheinander gebracht. Jetzt sieht soweit wieder alles gut aus, warte nun bis Morgen nochmal was er macht wenn noch nicht viel Sonne kommt und gebe dann Rückmeldung.

[PalmManiac]

An dem 800Pro sind die PV-Module ja direkt angeschlossen. Obwohl ihr vielleicht alles laut Anleitung eingestellt habt, entscheidet der 800Pro immer noch direkt, dass der anliegende PV-Strom zum Akku laden genutzt werden soll, BSFAI wird hier übergangen/überstimmt. Schaut euch bitte nochmal genau in der App jede Stelle in der Konfig, beim WR oder bei den Akkus an, ob dort irgendwo noch etwas aktiv ist, was dieses Verhalten erklären würde. Wenn nicht, dann spielt mal etwas mit den Einstellungen in ZHA rum, speziell die Sicherungs-Gruppen Einstellung und Energie-Export, ob sich durch die anderen Einstellungen das Verhalten irgendwie ändert.

Der 800Pro kennt intern ja nicht den Zustand, dass gerade kein Überschuss vorhanden ist und er kennt intern auch nicht den aktuellen Hausbedarf. Da greift dann intern wohl ein Standardmechanismus, der alles was von oben kommt in der Akku pumpt. Dieses Verhalten muß/müßte man abschalten.

Leider habe ich keinen physischen Zugriff auf ein 800Pro System, um mir mal alles per App anschauen zu können, sonst würde ich direkter helfen.

[PalmManiac]

Bitte testet mal folgendes:

In ZHA/Manager den Betriebsmodus von AUS auf Smarte Leistungsregelung stellen, aber ohne P1 Sensor, also den Dummy drin lassen.

Wie verhält es sich dann?

[faragot]

Puh, alles nicht so einfach bei den ganzen Einstellungsmöglichkeiten, aber mir ist folgendes aufgefallen:

Die Eingangsleistung in ZHA wird durch BSFAI sehr schön automatisch angepasst, die Ausgangsleistung nicht. Stelle ich Sie manuell richtig ein passt es:

Vielleicht hilft es ja irgendwie weiter. Das mit der Smarten Leistungsregelung ohne P1 Sensor hat anscheinend bei mir nichts bewirkt.

Und noch eine Auffälligkeit: Im manuellen Modus funktioniert Laden und Entladen wie es soll, allerdings springt er im Modus Standby ständig hin und her zwischen Eingangs- und Ausgangsmodus.

[faragot]

Hab es jetzt geschafft, den 800Pro in den Bypass zu zwingen, indem ich die Grundlast auf 500 W erhöht habe (eigentlich 200-300 W). Kann das irgendwie damit zusammenhängen? Warte jetzt mal ab was passiert, wenn die PV-Leistung steigt.

[PalmManiac]

Stell mal die Sicherungsgruppe auf "Hat eine eigene Phase..." oder so ähnlich und bei Energie Export auf Erlaubt.

[faragot]

Hab ich natürlich so gehabt und auch da ein wenig hin und her gespielt. Irgendwas aus der App funkt aber anscheinend immer irgendwie dazwischen und will den Akku voll machen. Dachte, wenn HEMS aus ist, ist es auch aus. Wenn es mal kurz funktioniert, wie der Bypass vorhin und man ändert auf Sommermodus und zurück auf Automatik geht es wieder nicht mehr. Ich gebe erstmal auf und warte ab.

[PalmManiac]

Folgende Vermutung für dieses Verhalten:

Ohne wirksame Zendure-interne Hausverbrauchsinformation
→ Gerät kennt die Hauslast nicht
→ PV wird bevorzugt in den Akku geladen
→ BSFAI "Bereit" reicht nicht aus, um PV ins Haus zu ziehen

Ein einfaches "Bereit", also Eingangs- oder Ausgangsleistung auf 0Watt, reicht da wohl nicht, da der 800Pro dann mangels Hauslast Info den Akku zum Schutz primär läd. Man muß ihm Bedarf vorgaukeln, damit er intern sperrt. Ich bau mal was ein, 800Pro spezifisch, also Profilabhängig.

[PalmManiac]

So, V4.0.1 ist raus mit besonderen Erweiterungen rund um den 800Pro. Im Changelog steht alles drin, bitte testen.

[JackONeill199]

Leider regelt er jetzt völlig wild seit dem Update:

Hab die Sensoren überprüft, das passt alles. Auch sonst wurden keine Änderungen gemacht außer das Update auf 4.0.1

[PalmManiac]

Die Regelung war wohl zu hart. V4.0.2 ist raus, da sollte es sehr viel besser laufen. Wenn nicht ganz, dann gibt es nun in den Attributen neue Sensoren zum Debuggen. Diese Infos brauche ich dann.

[JackONeill199]

Leider wieder das gleiche Problem:

Musste die Integration erstmal deaktivieren. Die Schaltvorgänge sind auch extrem in die höhe gegangen:

[JackONeill199]

Im Modus "Manuell" und "Entladen" funktioniert es, da springt er nicht hin und her.

[PalmManiac]

Durch deinen Test mit Manuell-Entladen sieht man, dass er stabil entladen kann. Die 4.0.3 ist raus mit harten Maßnahmen. Wenn es jetzt noch flattert, dann gehen mir langsam die Ideen aus. ;)

[JackONeill199]

Hi, leider fängt es jetzt schon wieder an, er wollte die batterie mit Netzstrom volladen obwohl genug PV da ist, habe dann die Ladebegrenzung auf 70% gestellt, nun wieder:

Mache ich hier was falsch?

[JackONeill199]

Ich habe jetzt auf Manuell Entladen gestellt, und dennoch passiert folgendes:

Ist das vielleicht ein Problem von Zendure? Das kann doch nicht sein das er so komisch regelt nur weil die PV Leistung um 100-200 Watt schwankt.

[JackONeill199]

Hier nochmal die Übersicht von der Zendure Integration, ist wohl wirklich so das Smartflow AI da versucht nachzuregeln, wieso ist mir fraglich, sobald BSFAI aus ist ist ruhe:

[PalmManiac]

Das sieht nicht mehr nur nach BSFAI aus. Wenn du wirklich auf Manuell → Entladen stehst und der Akku trotzdem mit PV massiv lädt bzw. die Ausgangsleistung so springt, dann arbeitet vermutlich eine interne Zendure-/SF800Pro-Logik dagegen. Bitte teste einmal mit komplett deaktivierter BSFAI-Integration: AC-Ausgangsmodus manuell setzen, Ausgangsleistung fest z. B. 300 W, AC-Eingangsgrenze 0 W. Wenn es dann weiterhin springt, ist es sehr wahrscheinlich ein Zendure-/Firmware-/Konfigurationsproblem. Wenn es dann stabil ist, müssen wir im BSFAI-Coordinator prüfen, ob trotz manuellem Entladen noch Modus/Limits überschrieben werden.

[PalmManiac]

Ok, also doch BSFAI. Der Passthrough regelt zu hart. Da muß ich nochmal ran.

[tanrai-72]

Ich habe auch den 800pro. Ganz so krass wie bei dir schaut's bei mir nicht aus. Bin aber auch nicht wirklich zum Testen gekommen in den letzten Tagen. Zudem hab ich dann noch manuell raumgespielt, um zu den Negativpreisphasen noch Platz im Akku zu haben.

[ff-81]

Habe ebenfalls den 800 pro und beobachte diese Auffälligkeit.

Solange die Module noch relativ wenig Leistung bringen (bei mir waren es heute Morgen z.B. 80 W, bei einer Hauslast vpn ca. 200W), wird die Hauslast komplett ignoriert. Das System geht einfach in eine Art Standby und drückt die ganzen 80 Watt in den Akku, bis der von 10 % auf die Hysterese-Grenze (12 %) geladen ist. Erst dann wird entladen – der Akku fällt anschließend wieder auf 10 %, und das Spiel beginnt von vorn. Erst als ich später stabile 130 Watt von den Modulen hatte, schaltete das System sauber auf den Bypass-Modus und hat primär das Haus versorgt.

In der Datei device_profiles.py steht beim SF800PRO_PROFILE Folgendes

"PV_HOUSELOAD_PASSTHROUGH_MIN_PV_W": 120.0, "PV_HOUSELOAD_PASSTHROUGH_MIN_HOUSE_LOAD_W": 120.0,

Könnte es sein, dass diese beiden festen Werte (120 Watt) die direkte Durchleitung bei Schwachlicht am Morgen einfach blockieren? Da der Akku bei 10 % "leer" ist (unterer SOC) und nicht entladen darf, der Bypass aber wegen der 120-Watt-Grenze noch zu bleibt, hat der Solarstrom ja eigentlich gar keinen anderen Weg, als in den Akku zu fließen, oder?

Ich habe das in meiner lokalen Datei heute testhalber mal auf 30.0 geändert und bin gespannt, wie sich das System morgen früh verhält.

[PalmManiac]

@ff-81 Du hast die neuste Version V4.0.7 installiert? Die 120Watt im Profil sind die Grenzen, wo noch nichts passieren sollte, also müßte er deine 80Watt blockieren durch die speziellen Routinen. Sag bescheid, ob sich das Verhalten ändert.

[ff-81]

ja, bin auf der neusten Version V4.0.7. Ich schau es mir morgen Vormittag nochmal mit dem Wert von 30 an.

Ich habe mich mit Hilfe vom Gemini durch die Regelung gearbeitet (sorry, ich bin kein Programmierer...)
Ergibt dieses Analyseergebnis für Dich einen Sinn, oder ist es weit von der Realität entfernt?

Zusammenfassung deines Systems am Morgen:

1. Morgens ist der Akku leer (10 %).

2. Der power_controller.py sagt: "Akku leer! Output auf 0 W, ich mache nichts!"

3. Die Passthrough-Logik sagt: "Ich könnte übernehmen und den Strom am Akku vorbei ins Haus leiten... aber die PV-Module liefern erst 80 Watt. Der Code verbietet mir die Arbeit unter 120 Watt!"

4. Das Resultat: Der Output bleibt bei 0 W. Da die Hardware aber 80 Watt PV-Strom produzieren muss, drückt sie diese mangels Alternative zwangsweise in den Akku, bis deine 12 % Hysterese erreicht sind.

Fazit: Die power_controller.py arbeitet fehlerfrei, ist aber morgens durch den leeren Akku deaktiviert. Die Ursache deines Problems bleibt exakt bei den fest codierten 120 Watt für das SF800Pro-Profil in der Datei device_profiles.py. Wenn du diese Zahl in der Datei auf z.B. 30.0 änderst, ist dein Problem sofort gelöst.

[JackONeill199]

ja, bin auf der neusten Version V4.0.7. Ich schau es mir morgen Vormittag nochmal mit dem Wert von 30 an.

Ich habe mich mit Hilfe vom Gemini durch die Regelung gearbeitet (sorry, ich bin kein Programmierer...) Ergibt dieses Analyseergebnis für Dich einen Sinn, oder ist es weit von der Realität entfernt?

Zusammenfassung deines Systems am Morgen:

1. Morgens ist der Akku leer (10 %).
2. Der power_controller.py sagt: "Akku leer! Output auf 0 W, ich mache nichts!"
3. Die Passthrough-Logik sagt: "Ich könnte übernehmen und den Strom am Akku vorbei ins Haus leiten... aber die PV-Module liefern erst 80 Watt. Der Code verbietet mir die Arbeit unter 120 Watt!"
4. Das Resultat: Der Output bleibt bei 0 W. Da die Hardware aber 80 Watt PV-Strom produzieren muss, drückt sie diese mangels Alternative zwangsweise in den Akku, bis deine 12 % Hysterese erreicht sind.

Fazit: Die power_controller.py arbeitet fehlerfrei, ist aber morgens durch den leeren Akku deaktiviert. Die Ursache deines Problems bleibt exakt bei den fest codierten 120 Watt für das SF800Pro-Profil in der Datei device_profiles.py. Wenn du diese Zahl in der Datei auf z.B. 30.0 änderst, ist dein Problem sofort gelöst.

sollten wir daraus nicht lieber ein Issue erstellen damit das ordentlich getrackt wird? Hier in dem Thread sind jetzt viele Probleme die teilweiße schon gelöst sind.

[PalmManiac]

V4.0.4 ist raus mit weiteren umfangreichen Änderungen. Bitte schreib mir, dass es nun endlich läuft. ;)

[JackONeill199]

es wurde etwas besser, gerade hat es aber wieder angefangen, anscheinend fängt das an wenn kurzzeitig eine hohe Hauslast anliegt bzw. vom Netz gezogen wird, hab mir eben ein Kaffee gemacht, die Maschine zieht ca. 1kw zusätzlich, dann hat er wieder angefangen so zu regeln:

[JackONeill199]

Der SF800Pro lädt doch automatisch jeglichen PV Ertrag in den Akku außer es wird eine AC-Ausgangsleistung gesetzt oder der Akku ist 100% voll, sehe ich das richtig?

Wurde das in BSFAI so hinterlegt? Die PV-Ladestart Schwelle die man selbst setzen kann ist ja dann Nutzlos.

[JackONeill199]

Jetzt ist es wieder passiert. Ich habe das Log und die Repo mal mit Codex analysieren lassen. Der Ablauf scheint inzwischen ziemlich gut erklärbar zu sein.

Beim SF800Pro ist Bereit / OUTPUT 0 W offenbar kein neutraler Zustand.

Bereit / OUTPUT 0 W bedeutet also nicht:

PV geht einfach neutral ins Hausnetz.

Sondern eher:

BSFAI setzt keine aktive Ausgangsleistung, und der SF800Pro folgt seiner eigenen Standardlogik. Dabei wird vorhandene PV zuerst in den Akku geladen.

Damit PV aktiv ins Hausnetz geht, muss BSFAI beim SF800Pro eine Ausgangsleistung setzen:

AC mode = OUTPUT und output_limit > 0 W

Wichtig ist dabei die Unterscheidung:

BSFAI setzt INPUT + Ladeleistung
Der Akku wird aktiv geladen. Wenn die PV-Leistung nicht reicht, kann Netzstrom dazukommen.

BSFAI setzt OUTPUT 0 W / Bereit
BSFAI macht nichts Aktives. Der SF800Pro lädt vorhandene PV intern in den Akku.

BSFAI setzt OUTPUT + Entladeleistung
Der SF800Pro speist diese Leistung ins Hausnetz ein. Nur so wird PV/Akku aktiv Richtung Hauslast gedrückt.

Der konkrete Ablauf im Log:

20:27:57  Battery SmartFlow AI Entscheidungsgrund: Bereit
20:27:57  Battery SmartFlow AI KI-Empfehlung: Keine Aktion
20:28:03  SolarFlow 800 Pro Batteriestatus: Ruhezustand
20:28:07  Battery SmartFlow AI Entscheidungsgrund: PV-Überschuss laden
20:28:07  Battery SmartFlow AI KI-Empfehlung: Laden
20:28:09  SolarFlow 800 Pro Batteriestatus: Laden
20:28:13  SolarFlow 800 Pro AC-Eingangsgrenze: 80,0
20:29:17  Battery SmartFlow AI Entscheidungsgrund: Sommer: Hauslast decken
20:29:17  Battery SmartFlow AI KI-Empfehlung: Entladen
20:29:23  SolarFlow 800 Pro AC-Eingangsgrenze: 0,0
20:29:39  SolarFlow 800 Pro Batteriestatus: Entladen

Die Sequenz sieht so aus:

1. Vorher war BSFAI längere Zeit auf Entladen.

2. Dann gab es kurz eine hohe Hauslast. Der SF800Pro hat mit 800 W seine maximale Entladeleistung gebracht.

3. Als der Verbraucher abgeschaltet hat, lagen die 800 W kurz weiter am Hausnetz an. Dadurch hat der Tibber Pulse am Zähler Einspeisung erkannt.

4. BSFAI hat daraufhin die Entladung reduziert bzw. beendet. Das erklärt den Wechsel auf Bereit / Keine Aktion.

5. Danach ist BSFAI aber in den PV-Ladezweig gesprungen: PV-Überschuss laden.

6. Kurz darauf wurde aktiv AC-Eingangsgrenze = 80 W gesetzt.

Der entscheidende Punkt ist:

AC-Eingangsgrenze geändert zu 80,0 ist keine reine Zendure-Automatik, sondern eine aktive BSFAI-Aktion. Zendure lädt dann folgerichtig mit der gesetzten Eingangsgrenze. Wenn in dem Moment nicht genug PV vorhanden ist, kommen die fehlenden Watt aus dem Netz.

Das passt auch zum Codepfad. In der PV-Regel gibt es feste 80 W für Softstart bzw. Keepalive:

if soft_start_ready and not keepalive_charge:
    if import_w <= 60.0:
        charge_w = max(charge_w, 80.0)

und:

if keepalive_charge:
    charge_w = max(charge_w, 80.0)

Das Ergebnis passt exakt zum Log:

PV-Überschuss laden
→ AC-Eingangsgrenze 80 W
→ Akku lädt

Für den SF800Pro ist das problematisch, weil:

• INPUT 80 W bedeutet aktives Akku-Laden.
• Wenn nicht genug PV vorhanden ist, kann Netzstrom dazukommen.
• Ein Lastsprung bzw. das Ende eines Lastsprungs sollte kein Grund sein, in INPUT zu wechseln.
• Beim SF800Pro müsste in so einer Situation eher OUTPUT geregelt bzw. gehalten werden.
• PV-Laden per INPUT sollte beim SF800Pro nur passieren, wenn wirklich sicher kein Netzbezug entsteht.

[PalmManiac]

Und weiter gehts. Da wir uns endlich einer Lösung nähern, waren die aktuellen Anpassungen nicht mehr so Umfangreich. V4.0.5 ist raus.

[tanrai-72]

Bei mir hat der Akku sich letzte Nacht nur von 100 - 80% entladen, obwohl die PV heute locker von 13 auf 100% hätte laden können. Auch heute Abend hat er nicht wirklich mit Entladen begonnen, obwohl der Preis heute Nacht kaum noch teurer wird. Ich habe jetzt den Peak-Faktor auf 1,25 heruntergesetzt, nachdem ich ihn gestern Abend schon auf 1,29 gesenkt habe. Jetzt entlädt er erstmal.
So ganz habe ich die Logik noch nicht verstanden. Sollte er nicht eigentlich mit Entladen beginnen, sobald der Strompreis die effektive Entladeschwelle überschreitet?

[tanrai-72]

Da muss ich wohl noch etwas nach justieren. Ich hatte jetzt Peak Faktor 1,25, Tal Faktor 0,85 und Gewinnmarge 30%. Der Akku wurde letzte Nacht nur bis 60% entladen, bei einer Solarprognose (BSFAI) in knapp 3kWh. Ich habe nur knapp 2kWh Akku.

[PalmManiac]

Wenn er nur bis 60% entladen hat, dann ist der Preis zu dem entsprechenden Zeitpunkt wohl wieder so weit runter gewesen, dass er den Entladevorgang beendet hat und das ist ja auch so gewollt. In den Sensoren kannst du sehen, wo sich immer aktuell die Grenzen bewegen.

[tanrai-72]

Aber an welcem Sensor kann ich das denn sehen? Gestern hat die Ladung ca. oberhalb von 32ct. gestartet. Peak Level war bei ca. 38ct. Und effektive Entladeschwelle bei ca. 26ct

[PalmManiac]

Genau an diesen 3 Sensoren. Beim Überprüfen wird auch geschaut wie groß die Preisspitze ist, also wie lange sie dauert und sucht dann eine Stelle über 26Cent, um die Ladung, passend zu deiner Batterie, zu starten. In deinem Fall waren das etwa >31Cent. War bei mir gestern genauso. Bis hier hin sieht es eigentlich gut aus.

Wenn ich das besondere Problem mit den 800Pro gelöst habe, dann starte ich die Arbeit am nächsten Step der Entwicklung, um die Ladeplanung und die Grundlastberechnung zu automatisieren, also eine Art KI-Funktion. Wenn das läuft, wird dann nicht mehr nur der Preisverlauf angeschaut, sondern eine Art Schablone über den Preis gelegt, um noch besser Ladefenster zu treffen. Das wird toll. :)

[tanrai-72]

Top! Freue mich schon drauf.

[faragot]

Nur mal kurz neben der Arbeit eine schnelle Rückmeldung ohne großes Testen. Immer noch wird der niedrige Ertrag in den Morgenstunden in den Speicher geschoben. (Automatikmodus) Beim heutigen Wetter mit teilweiser Bewölkung schaltet er je nach erzeugter PV-Leistung ständig zwischen Ladung und Entladung hin und her. Der gewünschte Bypass-Modus scheint beim 800Pro irgendwie nicht zu funktionieren. Bei den heutigen Strompreisen wäre es doch sinnvoll, so viel wie möglich direkt zu verbrauchen (Home-Office), und maximal einen eventuellen Überschuss in den Speicher zu schicken. Bei teilweise über 60 ct/kWh heute Abend könnte der Speicher ja kurz vorher auch zur Not aus dem Netz zu ca. der Hälfte des Preises befüllt werden.

[PalmManiac]

Wenn die Solar-Prognose feststellt, dass nicht genug Energie von oben kommt, dann sollte er heute auf AC-Ladung schalten, um den Akku für heute Abend zu füllen.

[faragot]

Ja, das hab ich auch so erwartet und würde bestimmt auch so sein. Leider ist mein Akku dann ja eventuell schon voll. Ich habe gerade noch einmal nur HEMS und nur ZHA probiert und da findet der gleiche Wechsel zwischen Ladung und Entladung statt. Der Bypass-Modus scheint beim 800Pro immer nur bei vollem Akku möglich. Meine, ich hab da irgendwo auch mal was gelesen, dass die das aufgrund von Problemen mit der Tiefenentladung bei älteren Modellen geändert haben. Sollte das so ein, wäre das natürlich die Erklärung warum er morgens immer die paar Watt in den Speicher schiebt und auch jetzt, wo ich gern die komplette PV-Ladung ins Haus bekommen möchte lieber kurz lädt und dann wieder entlädt. Das Laden von Überschuss ist ja in Ordnung, aber sofort wenn PV-Leistung fehlt, wäre doch der Bypass-Modus Pflicht und nicht die Entladung. Hoffe, ich täusche mich da, denn das wäre für mich ein Grund, das Ding wieder loszuwerden, da absolut nicht sinnvoll und schon gar nicht bei der heutigen Preiskurve. Wenn der Speicher immer vorgeht, bringen deine tollen Integrationen von Vorhersage und Strompreisen ja nur bedingt was oder sehe ich das falsch? Vielleicht ist es ja auch irgendeine Einstellung, die ich übersehe. Danke nochmal für deine unendliche Geduld und Bemühungen das Thema zu lösen.

[Dino0811]

Guten Morgen,

nachdem ich meinen SF800 Pro nun auf Firmware V 2.0.0 geupdated habe, sieht es unter BSFAI 4.2.3 so aus als wenn es endlich macht was es soll:

• erst Deckung der Hauslast, bei übersteigen dann Akkuladung

[Dino0811]

Die Sensoren in HA werden neu angelegt weil diese umbenannt werden. Also nicht mit :2, sondern sie heißen anders.
Ich habe einfach die alten gelöscht und führe die neuen weiter. Statistik habe ich im Energie-Dashboard...und die Zendure-Statistik ist mir jetzt eigentlich egal. Zumindest ist es mir den zeitlichen Aufwand nicht wert das zusammenzuführen.

[EDIT] ...das Umbenennen kommt aber vermutlich auch von der Zendure-HA integration

[ff-81]

Update lief bei mir ohne Probleme auf dem 800 Pro. An den Entitäten der ZHA Integration habe ich keine Änderungen feststellen können, läuft nach dem Update weiter wie gewohnt.

Problematik direkt heute morgen nochmals beobachtet, noch bevor ich Dino0811's Hinweis auf das Update gesehen hatte.
Schau also mit Spannung nochmal morgen Vormittag auf das Verhalten....

[tanrai-72]

@Dino0811 Hast du von V1.0.25 auf V2.0.0 upgedatet, oder hast du eine Version übersprungen? Ich meine mich zu erinnern, dass sich beim Update auf V1.0.25 ein paar Entitäten geändert haben.

[Dino0811]

gute Frage, das weiß ich gar nicht mehr so genau welche Version es war.

[tanrai-72]

Egal. Ich denke ich riskiere es demnächst mit dem Update. Wird schon keine negativen Auswirkungen auf die Erdrotation haben. :-)