Moin @Tom-HA, danke für die fixe Antwort! Ich hatte irgendwie gehofft/angenommen, dass der durchschnittliche Strombedarf intern schon vorliegen, ähnlich wie die Prognosedaten für heute, morgen und übermorgen. Aber das ist offensichtlich nicht der Fall. Dann muss ich mir da selber was überlegen 
.
Hallo Joachim,
das ist lösbar, ich habe das so gemacht als template Sensor:
{# === Strompreis Aktuell Octopus === #}
{% set jetzt = now() %}
{% set stunde = jetzt.hour %}
{% if stunde >= 0 and stunde < 4 %}
{{ 16.28 | round(2) }}
{% elif stunde >= 4 and stunde < 5 %}
{{ 20.38 | round(2) }}
{% elif stunde >= 5 and stunde < 18 %}
{{ 30.37 | round(2) }}
{% elif stunde >= 18 and stunde < 21 %}
{{ 33.20 | round(2) }}
{% else %}
{{ 30.37 | round(2) }}
{% endif %}
Grüße in den hohen Norden
Stefan
Der liegt ja auch vor… in den AI.. anders geht es auch nicht, da Jahreszeiten, Wetter, Sonnenstand, Wochentage, Wochenende, ect… alles eine Rolle spielen. Einen einfachen “Mittelwert” zu bauen, macht absolut keinen Sinn. Daher ist es ein AI Thema.. ein Lernthema und kein reines Durschnittsthema
Planst du denn so ein Laden einzuführen?
Also den Akku tagesbilligst aus dem Netzt voll zu laden (Falls der PV nicht reichen wird), damit man in den peakpreis Zeiten aus dem Akku leben kann?
Wenn Du den ersten Beitrag in diesem thread liest, hast Du die Antwort 
Genau das macht SMC. Du kannst dir auf der Website die Funktion auch noch einmal genau ansehen…
Hallo Tom,
es tut mir echt leid. Bald werft ihr mich hier raus
Ich habe es alles durchgelesen.
ich beobachte aber beim meinem Smart Charging ein steuerungstechnisches Problem. (Außer ich habe es doch nicht verstanden)
Mein min_soc steht auf 10 %. Trotzdem hat das System die Batterie mitten in der Nacht auf ca. 40 % nachgeladen. Grundsätzlich verstehe ich, dass STATS/GPM hier einen dynamischen Ziel-SoC aufgrund der PV-Prognose und des Hausverbrauchs ansetzt.
Das Problem ist jedoch das wirtschaftliche Timing:
Gestern hat das System um 4 Uhr morgens bei einem Börsenpreis von ca 40-50 Cent geladen. Ein paar Stunden später, um 8 Uhr morgens, lag der Preis jedoch bei nur noch 25 Cent.
Wenn das System ohnehin auf einen dynamischen Ziel-SoC von 40 % laden möchte, warum wartet der Algorithmus dann nicht das deutlich günstigere Preisfenster am Morgen ab, sondern lädt in der teuersten Nachtstunde? Wird hier der morgendliche Preistrend bei der force_charge-Berechnung noch nicht korrekt berücksichtigt, oder liegt das an einer starren Begrenzung des Nachtfensters? Oder habe ich etwas falsch konfiguriert?
Viele Grüße,
Benninger87
Rausgeworfen wird hier niemand
OK, dann lass uns mal deine Konfig analysieren.
Ein Punkt, der eine Änderung bringen kann ist dein eingestellter Preis. Bei 50 ct gilt quasi fast alles als günstig, wodurch für SMC in dem Nachtfenster wahrscheinlich (fast) immer eine Ladung möglich ist.
Bitte sage hier genau, welchen du meinst, es gibt 2 Punkte, wo der abgelesen werden kann.
Einmal in STATS → SMC und einmal unter Einstellungen → Geräte → GPM → Smart Charging target SoC, denn beide können durchaus zu unterschiedlichen Werten / Ergebnissen kommen.
(Bei mir gerade in STATS 66%, in GPM 19%)
(Das doppelt vorhanden sein kommt daher, das zuerst das SMC in GPM verfügbar war und dann in STATS gewandert ist und jetzt aus Kompatiblitätsgründen in GPM immer noch vorhanden ist)
Daraus folgt meine 2. Frage, wie hast du bei dir SMC umgesetzt? Hast du im Config Flow von STATS deinen Schalter eingetragen? Oder nuntzt du eine Automation mit den Automationssignal “Smart Charging Active” aus STATS?
Was du stattdessen auch probieren kannst:
Probiere mal mit einer Automation mit den Signalen von GPM das SMC und schaue, ob das besser an deine Vorstellungen herankommt.
Automation Beispiel für GPM
alias: Akku_Laden_GPM
description: ''
triggers:
- type: charging
device_id: b9744cd98146c9decb617a190f64c9f6
entity_id: 281f189d70d7f4cda65a54885f75296d
domain: binary_sensor
trigger: device
id: Ein
- type: not_charging
device_id: b9744cd98146c9decb617a190f64c9f6
entity_id: 281f189d70d7f4cda65a54885f75296d
domain: binary_sensor
trigger: device
id: Aus
conditions: []
actions:
- choose:
- conditions:
- condition: trigger
id:
- Ein
sequence:
- action: switch.turn_on
metadata: {}
target:
entity_id: switch.solarbank_3_e2700_pro_notladeoption
data: {}
enabled: true
- conditions:
- condition: trigger
id:
- Aus
sequence:
- action: switch.turn_off
metadata: {}
target:
entity_id: switch.solarbank_3_e2700_pro_notladeoption
data: {}
enabled: true
enabled: true
mode: single
Naja, das liegt an dem Nachfenster.
Momentan liegt 8 Uhr noch nach dem Sonnenaufgang, weshalb dort der Nachtmodus nicht greift.
Und starr Begrenzt ist das Nachtfenster eigentlich nicht, denn es ändert sich Anhand von der Zeit des Sonnauf- und Untergangs je nach Jahreszeit.
Gruß
Johnny
Mega danke
kann man das Nachtladen denn deaktivieren? Jetzt in meinem Beschriebenen fall war es ja schlecht Nachts zu laden.
So habe ich es bei STATS:
Und so bei GPM:
Ich habe in Stats meinen Ladeschalter meines Akkus eingegeben. Und “hatte” in STATS “Smart Charging aktivieren” aktiviert.
Du meinst ich soll mal probieren. in STATS das ganze zu deaktivieren und dafür dann eine Automation zu schreiben, die den Akku läd wenn binary_sensor.sonstiges_solar_forecast_stats_smart_charging_active Ein ist , bzw aus bei aus. Ist da denn dann aber der zu erwartende PV ertrag dabei?
Mein Hauptziel ist ja, vor allem im Winter meinen Akku billig möglichst voll zu bekommen um die teuren Spitzen zu überstehen. Und an einem tag wo mal 60 cent im verhältnis billig sind soll er da laden. wenn an nem anderen tag 30 cent billig sind dann da….. und halt auch nur soviel, dass ich auch pv falls was kommt noch rein bekomme.
Kann man das deaktivieren?.
@Johnny_1993 oder bist du der Meinung, dass das wie ich es mir vorstelle damit gar nicht geht, dann mache ich es im winter wieder jeden morgen so in etwa selber, indem ich in evcc eine Hausladen Preisschwelle einstelle
Nein, soweit ich weis nicht. Wenn dann nur über die Einstellung der Günstig-Preisschwelle.
Wobei ich auch sagen muss, das in dem Winterhalbjahr die Nachtzeit an sich oft die günstigste Zeitspanne des Tages darstellt aus meiner Erfahrung heraus.
Versuch ist es wert. Ich hatte am Anfang auch über manuelles Laden, dann eine eigene Automation geschrieben, dann bei GPM gelandet und darüber hat das richtig gut funktioniert.
Ich würde nur den Schalter aus der Konfig entfernen, SMC in Stats aber an sich aktiviert lassen. So hast du dann die möglichkeit zu vergleichen, was hätte STATS-SMC gemacht zu was hat GPM-SMC gemacht.
Ich würde dir folgenden Sensor vorschlagen:
binary_sensor.solar_forecast_gpm_smart_charging
Mit dem hatte ich es bei mir am laufen, musst blos dann deine Günstig-Preisschwelle in GPM anpassen an deine Wünsche.
Wobei, wie gesagt, bis jetzt, selbst bei Dunkelflaute, hab ich nie wirklich was teueres als 40 ct bei einen dynamischen Tarif gesehen in der Nacht.
Und ja, auch dort wird die Solarprognose des nächsten Tages berücksichtigt, aber der ist m.E. etwas defensiver, was den Ziel-SOC angeht.
Naja, Ziel sollte ja sein, in Abhängigkeit der Prognose am günstigsten Zeitpunkt des Tages nur das benötigte nachzuladen, egal wann der Zeitpunkt ist. Mir kommt es etwas so rüber, als wenn du dich zu sehr darauf versteifst, das nachts nicht geladen werden sollte, ohne dich jetzt angreifen zu wollen.
Und das gilt es ja, zu erreichen, den Günstigsten Preis zu nutzen, egal, wann der ist.
Gruß
Johnny
Hat dazu keiner eine Antwort? Leider konnte ich dazu bisher nirgendwo was finden 
Danke für deine Antwort. Ich werde es mal ausprobieren.
Ja das Klingt etwas als hätte ich mich drauf versteift, aber es ist einfach nur zufall, dass es da Nacht war.
Er hat halt zu knapp 50 cent den akku von 10 auf 40% geladen obwohl der preis nur wenige stunden später deutlichst billiger war. Da hätte ich einfach gedacht, er läd dort nicht, sondern wartet auf das billige
Da es immer wieder zu Verwirrungen kommt, es auch eine Lösung für Österreich im Bezug auf die Energieerzeugergemeinschaften bedarf.. plane ich hier breits eine Änderung.
Stats wird seine “Preiseingabe” verlieren und GPM wird die einzige Preisquelle werden / bleiben. Das ist auch notwendig um Tag/Nachttarife mittels selbstentwickelter Sensoren oder andere Tarifstrukturen besser und einfacher umzusetzen.
Das ist eine richtig gute Nachricht von Dir. Danke!
Es ist nur leider sehr sehr komplex, da es (so wie es ist) historisch gewachsen ist. Ich muss einen Weg finden, das solide umzubauen. Mein Plan an dem ich aktuell arbeite
STATS verliert seinen Config-Flow im Bezug auf Preise, GPM ist Pflicht für Kostenrechnung(en) und die Zentrale.
GPM soll die Möglichkeit bieten:
- Dynamische Preise
- Fix-Preis
- Stunden /Tageszeitpreise (zum Beispiel Tag / Nacht / Tarif
- Zeitfensterbasierte Preise
- Hochlanden von CSV Daten (Energiegemeinschaften) die dann die Preise korrigiert.
und die Möglichkeit historische Daten via CSV hochzuladen / importieren.. hier ist die Schwierigkeit es korrekt aufzuteilen.. es ist also vieeeeeeeel komplexer als es klingt! - erste Tests laufen schon. Auf Grund der Komplexität wird es vermutlich ein Lizenz-Feature / Spenden-Feature werden ( automatisch bei Spende wie die anderen Features) .. Also WP, EAI, HP, WB, GPM als gemeinsames Bundle.. das hängt auch damit zusammen das EAI und Co ja auch auf die Strompreise zugreifen, ich sehe aktuell noch keinen Punkt das korrekt zu trennen ohne vieeeeeel Aufwand.
Ich hoffe das das nicht zu Problemen / Diskussionen führt… 
@nightrunner Was mir in dem Kontext einfällt: Das kommende Update wird auch sehr sehr viel Ressourcen schonender sein. Ich habe den kompletten Start-up Prozess und EOD komplett neugemacht incl der LOGS damit sollten auch PI´s Greens, Yellow es einfacher haben.. auch die LOGS im Terminal sind klarer und ausgedünnt. Das hatte ich @suedschwede auch schon mal versprochen, nun ist der Zeitpunkt gekommen es umzusetzen da SFML stabil läuft (KI-Seitig) und die intensiven Logs in der Fülle nicht mehr gebraucht werden. DEVs haben aber weiterhin die Möglichkeit durch eine Codeänderung alle LOGs zu zeigen
Hallo @Tom-HA
Wäre im Zuge der Änderungen eine Integrierung zur Steuerung nach §14a EnWG denkbar, so dass entweder eine Dimmung der betroffenen Geräte bis jeweils 4,2kW oder bei Verwendung des Gleichzeitigkeitsfaktors die entsprechende max. Gesamtleistung berücksichtigt wird?
Vielen Dank für dein Engagement und die Umsetzung der zeitfensterbasierten Preise. Das betrifft mich ebenfalls und ich freue mich auf das Update. 
Gruß
Christian
Das Problem ist, dass die Anlagen netzorientiert steuerbar sein müssen. Also Netzsteuerungssignale vorhanden sein müssen. - Mir ist nicht bekannt, dass es bereits umgesetzt ist. - Hast Du ein Netzsteuerungssignal zur Zwangsdrosselung deiner Anlage, oder Umgehen der Drosselung für WP?
Wir haben von unserem Netzbetreiber einen Brief erhalten, dass die Umsetzung noch für dieses Jahr vorgesehen ist. Demnach sollten wir sowohl einen Smart Meter Gateway als auch die notwendige FNN-Steuerbox erhalten. Ob die Steuerbox mittels EEBus oder Relaiskontakt gesteuert wird kläre ich gerade ab und warte auf die Antwort des Netzbetreibers.
Wir haben bei uns eine PV Anlage von Sigenergy mit 20kWp, 17 kW Wechselrichter, DC Wallbox mit 12,5 kW und 27kWh DC-Speicher sowie eine Lambda Wärmepumpe EU10L und Daikin Perfera Splitklimaanlage verbaut. Sigenergy und Lambda können das Steuerungssignal eigenständig verarbeiten und die Dimmung umsetzen. Die Klimageräte können das aktuell noch nicht und würden einen “hard off” vornehmen. Über den Gleichzeitigkeitsfaktor könnte ich dies softwareseitig verhindern.
Daher die Frage, ob SFML die Steuerungsmöglichkeit bei vorhandenem Netzsteuerungssignal künftig umsetzen könnte. So würde die anstehende Anpassung von Smart Charging um eine weitere Funktion ergänzt und andere Lösungen wie EVCC wären nicht zusätzlich notwendig.
Nur eine Idee
Gruß
Christian
Das ist eine sehr gute Idee, sie steht auch schon auf dem Zettel. Wir haben das auch schon öfter im Monatlichen Community Call (jeder kann dazukommen) besprochen.
Solange das aber alles noch nicht in DE umgesetzt ist und es keine einheitliche Info gibt, ist es leider nicht möglich hier für mich etwas zu bauen… ABER wenn es da ist, die Novelle umgesetzt ist.. wird es in SFML kommen.
Vielleicht interessant für Dich: