Neueste Beiträge

#71

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 31 Oktober 2025, 11:04:24

Ich hab das absichtlich rausgenommen, weil mir das bei meinen Tests einen deutlich ungleichmäßigeren Verlauf beim stundenwechsel gegeben hat.
Das "$fref->{ph}" ist ja schon ein sehr gleichmäßiges Signal und garnicht aggresiv. Es stellt die niedrigsmögliche konstante Ladeleistungsbegrenzung dar mit der mit dem letzten Überschuss am Tag der Akku gerade noch voll wird. Das sah mir hier für beide Strategien hier am besten geeignet aus. Die Aggressivität kommt dann ja hinterher mit den Aufschlägen.
Evtl hilft hier auch schon das die aktuelle Stunde gewichtet eingerechnet wird, wodurch diesen "min" nichtmehr gebraucht wird. Falls doch müsste man $spls durch etwas besseres ersetzen, den am Ende der Stunde war das immer viel zu hoch, wodurch die Stunden-Sägezähne mit verursacht wurden.

Ja, $fref->{ph} ist gleichmäßig und wird deswegen ja auch in der Fallentscheidung für smartPower verwendet. Parallix war dies insbesondere bei volatilen Wetterlagen zu hoch, weswegen nun optPower und smartPower gibt mit der unterschiedlichen Anwendung der Begrenzung auf Surplus. Es wird also gebraucht ... allerdings nicht für smartPower.

Das zu behalten ist aber physikalisch richtig, ich hab nun auch die Lösung dazu gefunden, warum das Probleme gemacht hatte. Dazu hab ich noch eine Zeile in ___batFindMinPhWh eingefügt.

Physikalisch richtig schon aber nicht zielführend. Wir wollen nicht in Schönheit sterben sondern eine Batterie laden. 

Hier

Code Auswählen Erweitern

        for my $hod (@hods) {
            my $cap   = $hsurp->{$hod}{surplswh};
            my $nhr   = $hsurp->{$hod}{nhr};
            if ($nhr eq '00') { $cap = min ($mid, $cap) / 60 * (60 - int $minute); }
            $charged += $mid < $cap ? $mid : $cap;
        }

gibt es die Situation, dass in $hsurp->{$hod}{surplswh} bereits schon die Zeitgewichtung der Stunde 00 drin steckt.
Wenn $mid kleiner als $cap ist, passt das mit Zeitgewichtung weil sie auf $mid angewendet wird. Ist aber $cap kleiner wird der schon zeitgewichtete Wert der Stunde 00 nochmal behandelt.
Wenn man es tun will, dann die generelle Ersetzung in $hsurp->{$hod}{surplswh} nicht verwenden (wie Standard) und dann hier:

Code Auswählen Erweitern

        for my $hod (@hods) {
            my $cap   = $hsurp->{$hod}{surplswh};
            my $nhr   = $hsurp->{$hod}{nhr};
            if ($nhr eq '00') { $cap = $cap / 60 * (60 - int $minute); }
            $charged += $mid < $cap ? $mid : $cap;
        }

Das werde ich bei mir mal einbauen und ausprobieren.

Mit der Variante vor meiner Änderung wurde obwohl Überschuss vorhanden war und ein gleichmäßiges Laden mit mittlerer Leistung zum Ladeziel geführt hätte trotzdem nur mit pinreduced geladen.

Das ist unverständlich. War dein SoC < lowSoC? Wenn ja, wieso passiert das bei dir? Auf welchen Wert ist der Parameter eingestellt und wird er auch im Batteriesystem so verwendet?

#72

Solaranlagen / Aw: [23_BYDBox] - Modul für BY...

Letzter Beitrag von Hadl - 31 Oktober 2025, 10:39:32

Nach der Installation des Full Backup Controllers hatte ich in der Fronius Solar-API die Reservekapazität hochgesetzt (testweise auf 10%).

Dennoch wurde meine Batterie auf unter 5% entladen 

Ich hatte vergangenen Winter als fast kein Überschuss produziert werden konnte meine untere Kapazität direkt im Gen24 (nicht über Solarweb, sonder mit technican im Web-Interface) auf 20% nach unten begrenzt.
Das hat er beim Entladen eingehalten. Wenn die Selbstentladung ihn dann nochmal 2% darunter fallen lies hat er sich mit 500W nachgeladen.

Aus verschiedenen Gründen versehe ich das aber mit einem Fragezeichen, vielleicht weiß hier jemand Genaueres.

Nein, ich hab nur gelesen das BYD die Speicher HVB und HVE als Nachfolger handelt, dadurch werden die "alten" vermutlich irgendwann nicht mehr produziert.

#73

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Hadl - 31 Oktober 2025, 10:20:35

Hallo Heiko,
vielen Dank für deine Analyse.

Du hast es nur etwas umgemodelt. Erst das Replacement direkt ersetzt:

Wunderbar, ja das ist mir auch aufgefallen, das man das vereinfachen könnte. Hab mich aber erstmal auf die Energiedaten fokusiert.

Also bis zu diesem Punkt sind die Versionen identisch, nur dass $total nun $RemainingSurp heißt.

Ja, das hat mir etwas beim Denken geholfen das umzubenennen, ist aber ansonsten identisch

Es wird die gewählte Strategie bzw. Erreichbarkeit des Ziel keine Beachtung mehr geschenkt. Im Original
Code Auswählen Erweitern

Code Auswählen Erweitern

          my $limpower  = $achievable || $strategy eq 'optPower'
                          ? min ($fref->{ph}, $spls)                                                           
                          : $fref->{ph};wird eine Fallentscheidung vorgenommen und bei Erreichbarkeit des Ladeziels oder bei optPower Verwendung der Surplus-Wert als (zunächst) begrenzender Wert herangezogen. Achtung: wichtige Unterscheidung in der Ladeaggressivität was natürlich so bleiben soll.

Ich hab das absichtlich rausgenommen, weil mir das bei meinen Tests einen deutlich ungleichmäßigeren Verlauf beim stundenwechsel gegeben hat.
Das "$fref->{ph}" ist ja schon ein sehr gleichmäßiges Signal und garnicht aggresiv. Es stellt die niedrigsmögliche konstante Ladeleistungsbegrenzung dar mit der mit dem letzten Überschuss am Tag der Akku gerade noch voll wird. Das sah mir hier für beide Strategien hier am besten geeignet aus. Die Aggressivität kommt dann ja hinterher mit den Aufschlägen.
Evtl hilft hier auch schon das die aktuelle Stunde gewichtet eingerechnet wird, wodurch diesen "min" nichtmehr gebraucht wird. Falls doch müsste man $spls durch etwas besseres ersetzen, den am Ende der Stunde war das immer viel zu hoch, wodurch die Stunden-Sägezähne mit verursacht wurden.

Weiterhin wird nun durch die direkte Replacement-Ersetzung in der Iteration der Überschuß der aktuellen Stunde tendienziell gegen 0 gehen mit fortschreitender Zeit. Das hatte ich schonmal drin und hat sich als kontraproduktiv gezeigt, weswegen es entfernt wurde. 

Das zu behalten ist aber physikalisch richtig, ich hab nun auch die Lösung dazu gefunden, warum das Probleme gemacht hatte. Dazu hab ich noch eine Zeile in ___batFindMinPhWh eingefügt. Siehe weiter unten.

Das ist nicht gut. Wenn die Ladung unter lowSoc gefallen ist (was eigentlich nicht vorkommen sollte) wird die Batterie ggf. durch Netzstrom geladen. Das soll nur zaghaft mit pinreduced vorgenommen werden.
Aus welchem Grund bist du der Meinung dies ändern zu wollen?

Mit der Variante vor meiner Änderung wurde obwohl Überschuss vorhanden war und ein gleichmäßiges Laden mit mittlerer Leistung zum Ladeziel geführt hätte trotzdem nur mit pinreduced geladen. Dadurch wurde vom Überschuss nur wenig genutzt, sobald aber dann SocMin erreicht war musste um wieder aufzuholen mit etwas höherer Leistung weitergeladen werden. Das wiederspricht dem Ziel einer schonenden Akku-Ladung und der Nutzung von Energie für den Fall von Stromausfällen.
Falls überhaupt Netzstrom geladen werden kann, würde das ja nur im Fall fehlender Überschüsse passieren, dann wird auch in meinem Fall bei Null Überschuss mit pinreduced geladen.
Ich habe bei mir sogar nochmal außerhalb des Moduls in dem Fall das SOC < (lowSoc <) OptimumTargetSoC die Ladeleistungsbegrenzung fast komplett rausgenommen und sperre optionale Verbraucher. Ich erlaube aber auch keine Netzladung. (Außer die, die der Wechselrichter selbstständig macht zum Akkuschutz)
Das sieht man bei mir immer früh, wenn in der Nacht der Akku unter 40% sinkt.

Nehmen wir an es ist ein Überschuß von 5kWh für die aktuelle Stunde prognostiziert und in der Gesamtkalkulation reicht es aus mit 1kW über diese eine Stunde zu laden, d.h. eine 1kWh in die Bat zu verbringen. Dann ist es völlig in Ordnung wenn zu Beginn der Stunde mit einer Leistung von 1kW geladen wird und am Ende dieser Stunde ebenfalls. Denn dann haben wir genau 1 kWh in der Batterie unter der Voraussetzung, dass über die gesamte Zeit mehr Überschuß als gewünschte/begrenzte Ladeleistung vorliegt.

Perfekt, ich hatte genau die gleiche Vorstellung. Das hab ich erreicht indem ich noch mit einer Zeile die Zeitgewichtung der aktuellen Stunde in ___batFindMinPhWh eingebaut habe. Dadurch wurde am Ende der Stunde nichtmehr erwartet das man in deinem Beispiel 12 Minuten vor Stundenende von den 5kWh noch 1kWh Überschuss übrig hat und man denke man kann das mit 1kW Leistung reinladen. Das klappt auf 12 Minuten nicht, sondern da kriegt man nur 200Wh rein.
Damit sieht die Leistung heute morgen auch über die Stundengrenzen hinweg super gleichmäßig aus!

Ich hab heute wieder genügend Überschuss und erwarte dadurch eine sehr schonende gleichmäßige Ladung trotz des aggressiveren SmartPowers.
Bisher sehe ich garkeine Stunden-Abweichungen! 
Die aggressiveren Varianten könnte ich evtl. am Sonntag mit viel Wolken und Regen wieder sehen.


Viele Grüße

Hadl

#74

Bastelecke / Aw: ESP RGBWW Controller - Fir...

Letzter Beitrag von pjakobs - 31 Oktober 2025, 09:57:42

Ich überarbeite mal die Code-Teile, die nach einem neuen Namen momentan einen Reboot erfordern. Gebt mir ein bisschen Zeit.

#75

MQTT / Aw: Shelly H&T Gen3 als TempGe...

Letzter Beitrag von amehl - 31 Oktober 2025, 09:50:20

Sorry, hat sich erledigt ich habe es gefunden

#76

MQTT / Aw: ShellyWall Display

Letzter Beitrag von joachimS - 31 Oktober 2025, 09:37:49

Kann man (per MQTT oder anderweitig) auch einstellen was im Display angezeigt wird? Also ist ein benutzerdefinierter Text (von FHEM generiert und gesendet) zur Darstellung von Gerätezuständen möglich?

Denke nicht.
Aber schau mal hier: https://shelly-forum.com/thread/29897-rpc-mqtt-topics/

#77

Unterstützende Dienste / Aw: ble2mqtt - Bluetooth Anwes...

Letzter Beitrag von DasQ - 31 Oktober 2025, 09:32:14

Ohne Logs configs usw. Ist das immer wie hellsehen. Den jsonvariablen hast du Namen gegeben? Wenn nicht landen die alle zeitgleich in einer und werden dann sofort überschrieben. (Laienhafter Versuch das zu erklären)

#78

Off-Topic / Aw: Verzeichnis von Diskstatio...

Letzter Beitrag von betateilchen - 31 Oktober 2025, 09:24:33

Das ,,mounten wenn gebraucht" kann doch inzwischen systemd nahezu perfekt übernehmen? Da muss man sich mit fstab nicht mehr rumärgern.

#79

FHEM Development / Aw: pre-commit hook: file has ...

Letzter Beitrag von betateilchen - 31 Oktober 2025, 09:22:13

@Boris: kann ich fast alles nachvollziehen, nur Dein beschriebenes Anspruchsdenken nicht.
Und um auf 2007 zurückzukommen: damals gab es noch keine 500 Module mit zusätzlichen Anforderungen an benötigten perl-Modulen.

Wie groß würde FHEM werden, wenn jedes Modul seine Abhängigkeiten mitbrächte, und das auch noch zwangsweise für jeden Nutzer, egal ob er ein Modul überhaupt nutzt oder nicht?

#80

TabletUI / FTUI3 pipes format

Letzter Beitrag von PNinBB - 31 Oktober 2025, 09:21:38

Bei der Anzeige des Batteriezustandes eines entsprechenden Gerätes wollte ich eigentlich nur das Datum des battery Readings darstellen. Aus Platzgründen sollte die Jahreszahl aber zweistellig sein, also schrieb ich

Code Auswählen Erweitern

   <ftui-label class="size-1" [text]="AZ_HZ_T1:battery:time | toDate() | format('DD.MM.YY') | prepend(' (') | append(')')"></ftui-label>
Das bleibt aber wirkungslos, die Jahreszahl ist vierstellig !
Der berühmte Hund liegt in '../ftui/modules/ftui/ftui.helper.js', Zeile 243 begraben.

Code Auswählen Erweitern

  const YY = date.getFullYear().toString().substring(-2);Da Javascript die Funktion 'substring ...' mit einem negativen Wert nicht so verarbeitet wie erwartet, müsste
diese Zeile wie folgt abgewandelt werden:

Code Auswählen Erweitern

  const YY = date.getFullYear().toString().slice(-2);Ich habe es in meiner 'ftui.helper.js' gemacht; alles funktioniert wie gewünscht; es müsste aber das nächste Update überstehen !
Mit besten Dank im Voraus
Peter