STATS Stromkosten Berechnung

[Heatseeker]

Moin,

kann mir einer erklären wie die Stromkosten hier berechnet werden, da ich sowohl per Hand, als auch das offizielle Portal auf deutlich geringere Werte kommen.

Stats ist in Version 32.2.6

schauen wir uns mal den Juni an.

1. Bei 86kwh Bezug von Aussen sollte ich keine 100% Autarkrie haben meiner Meinung nach

2. 254€ sind m.M. nach zu viel:

Ich habe 549kWh Verbrauch, davon 86kWh vom Netz, also 463kWh von Solar. Macht bei einem Strompreis von 0,2225€/kWh → 103€

Dann habe ich noch:

1158kwh erzeugt Minus 463kwh Eigenverbrauch macht 695kWh Einspeisung a 0,082€ → 57€

Unterm Strich (grob gerechnet) also 160€ und keine 254€… Hab ich was vergessen oder was falsch eingegeben???

Wenn ich die komplette Erzeugung mit meinem Strompreis Multipliziere 1158kWh*0,2225€/kWh=257,65€ komme ich fast auf den angezeigten Wert, aber das wäre ja totaler Blödsinn…

Wo liegt der Fehler?

[Astrofreak85]

Ich hatte da auch mal wilde Werte, guck mal ob deine Sensoren ins Stats alle OK sind.
Insbesondere
“Hausverbrauch”
“Netz->Haus”
“Haus->Netz”

ggf. falls in Benutzung die Smartmeter Sensoren…bei mir war der Hausverbrauch mal falsch berechnet, das hat die Werte biss kaputt gemacht…

[Heatseeker]

Hi,

danke für den Tipp, aber die Werte wie Verbrauch und Bezug und Solarertrag decken sich mit den realen Daten…

Obwohl da doch einige Abweichungen sind, nicht massiv aber auffällig. Solar ist in der regel zu hoch… (okay, der hat ja auch immer DC gemessen… evtl) Aber der Verbrauch ist schon geringer als real, Bezug passt einigermaßen…

Ich schau nochmal genau. → sollte passen, das einzige: ich habe einen DC Angebundenen Speicher, heißt “Solar → Haus” ist incl. Das was aus dem Speicher ggf rausgeht oder reingeht. Was anderes gibt es bei mir nicht. Batteriel Lade/Entladelesitung sind richtig angegeben.

Trotzdem wäre es mal gut zu wissen wie gerechnet wird.

[nightrunner]

Gespart wird doch die Differenz zwischen Bezugspreis und entgangener Einspeisungsvergütung.

[Heatseeker]

1. Vermutung: Batterie und Solarerzeugung werden addiert. Dann komme ich auf den angezeigten Solarertrag…

[Heatseeker]

Selbst wenn ich das so rechne, wird die Differenz dann noch größer…

[nightrunner]

Jetzt bin ich wieder zuhause und habe mir das am Laptop mal genauer angeschaut. Handy ist für so etwas eher suboptimal.
Hier zunächst meine Übersicht:

Betrachten wir den Juni 1029 Solar, davon 417 kWh Eigenverbrauch macht 612 kWh Einspeisung
4 kWh bezogen von 417 Verbrauch, macht ca. 1% Netzbezug also ca. 99% Autarkie.
Die Kosten mit 13,63 Euro kommen auch so hin mit 12,67 Grundgebühr und 4*27,38 cent.
Das Ergebnis bei gespart kann ich nicht nachvollziehen.

Was mir dann aufgefallen ist ein Widerspruch in stats:

Dort ist der Solarertrag 1092,6 kWh. Das sind 63 kWh mahr als in der Stromkostenabrechnung.
Vielleicht kann @Tom-HA da was zu sagen.

[Tom-HA]

@nightrunner

Das sind 63 kWh mahr als in der Stromkostenabrechnung.

Hey @nightrunner
Ja dazu kann ich was sagen… Das sind die “alten” Rundungsfehler von Ha Riemann, weswegen ich umgestellt habe auf SOT und eigener Berechnung durch SFML als SOT.
Ich habe mit mir gehadert ob ich die “alten” Werte (die von HA Riemann) mittels Skript lösche um die Genauigkeit zu erhöhen.. habe mich aber dagegen entschieden da die Abweichungen durch die Anzahl an Datenpunkten automatisch immer weiter zunimmt.

[nightrunner]

Danke für die schnelle Info.
Aber meinst Du nicht das "die Abweichungen durch die Anzahl an Datenpunkten automatisch immer weiter abnimmt.”

[Astrofreak85]

Ist in der Grafik nicht aber DC? Imho hatte SFML-Stats bisher keinen AC Sensor für Solar, kann auch so die Menge die letztlich auf Netzseite zu Verfügung stand eh nur schätzen(?).
Würde zumindest noch eher erklären, warum da eine Differenz zwischen Zähler und SFML-Stats ist.

[Tom-HA]

@Astrofreak85

Würde zumindest noch eher erklären, warum da eine Differenz zwischen Zähler und SFML-Stats ist.

Hey @Astrofreak85 - Guter Gedanke allerdings kommen die Werte von SmartMeter sind also die Netto-Werte.
SFML hat aber bis vor der Einführung des AC-Sensor bereits mit Hubble den Wirkungsgrad und die Verluste auf diese Art und Weise mit eingepreist. - ich sage ja immer wieder " da passiert viel mehr im Code, als man meint und die KI macht viel mehr als man auf den ersten Blick sieht.. Hubble macht nicht nur " Prognosen"

[Heatseeker]

Okay, dann scheint er bei mir oben etwas falsch zu messen oder zu interpretieren.

Juni:

962,7 kWh

und hier die 1158kWh.

Die 962kWh Erzeugung sind aber auch DC-Erzeugung. AC sind dabei ca 888kWh dabei erzeugt worden.

Was mir auffiel:

1. mein Solar ist zu hoch, der angezeigte Wert würde zu Solar+Akku passen, aber der Akkustrom wurde schon in PV gezählt. Speicher ist DC angebunden. Was ich angegeben habe:

2. mein Verbrauch schein etwas zu niedrig zu sein. Laut meinen aufzeichnungen sollte es grob 670kWh sein anstatt 476kWh.

Bin meine Sensoren nochmal durchgegangen aber bessere Sensoren als die die ich angegeben habe, habe ich nicht…

[Tom-HA]

Hey @Heatseeker

Das Limit und der Maßstab lauten immer: „Welche Werte liefert meine Anlage nativ?“ Und genau hier sind lokale Daten – ohne den Umweg über die Cloud – deutlich im Vorteil.

Bei den cloudbasierten Systemen gibt es mittlerweile eine Art „Diesel-Skandal“ – sprich: ein gezieltes Schönrechnen der Daten. Das geschieht primär aus Kostengründen und Marketinggründen. Ganz vorn dabei ist u.A. Hoymiles..
Die Push-Intervalle sind unregelmäßig, stark von der Serverlast abhängig und vieles mehr.
Viele BKW-Nutzer der ersten Stunde erinnern sich sicher noch an die massiven Probleme bei EcoFlow (PowerStream) mit ständigen Cloud-Abbrüchen und Netzwerkausfällen.

SFML versucht das abzufangen, indem lokale Geräte (wie z. B. ein lokales Smart Meter) priorisiert werden.
Leider entsteht dennoch immer ein gewisser Drift. Deshalb korrigiert SFML beim EOD (End of Day) noch einmal leicht nach, um Cloud-Verluste und „Hersteller-Tricksereien“ auszugleichen.

Das ist wieder ein gutes Beispiel dafür, wie viel Logik im Code steckt, die man auf den ersten Blick gar nicht auf dem Schirm hat.

Das zeigt sich auch perfekt an den unterschiedlichen Rückmeldungen: Während der eine User meldet „Bei mir läuft es tadellos“, kämpft der nächste mit Abweichungen. Genau diese Mechanismen sind die Ursache dafür – vorausgesetzt, die physischen Sensoren messen korrekt.

Bei der Fehlersuche sollte man daher immer erst folgende Punkte abklopfen:

1. Sind meine Sensoren korrekt eingerichtet/ die Daten plausibel?
2. Sind die Rohdaten der Anlage stimmig?
3. Poliert der Hersteller die Daten auf, um sie schöner aussehen zu lassen?
4. Gibt es einen sichtbaren Drift zwischen den (validen) lokalen Messwerten und den Cloud-Daten?

Erst wenn diese Faktoren ausgeschlossen sind, macht die Suche nach einem eigentlichen Bug im Skript Sinn.

Da ich nicht unzählige Testanlagen hier stehen habe, teste ich primär mit Anker und lokalen Messwerten… als auch mit Hoymiles + Steckerspeicher
Mein persönliche Fazit: Anker-Anlagen messen trotz unregelmäßiger Pushes bereits ziemlich präzise. Bei Zendure, EcoFlow oder No-Name-Günstigsystemen sieht das leider ganz anders aus.

Fun Fact:
Am ehrlichsten und präzisesten arbeiten aktuell die Systeme von Fronius. Die spielen einfach in einer völlig anderen Liga … am anderen Ende steht Hoymiles

DISCLAIMER:
Die getroffenen Aussagen basieren auf User-Datenbanken, eigenen Beobachtungen, eigenen Testreihen und sind nicht repräsentativ - eine Diskussion hierzu ist nicht zielführend. Meine Beobachtungen sind reine Code und Q/A Aussagen, was ich selber sehen kann. - daher kennzeichne ich es ausdrücklich als meine persönliche Meinung

[Heatseeker]

Moin @Tom-HA

meine Anlage ist eine Huawei. Daten werden per Modbus TCP lokal aus den Komponenten ausgelesen (Intervall ist ca 60s), jedoch nur das was auch verfügbar ist.

Bei Huawei kann man zum einen eine EMMA haben, das ist HEMS welches etwas performanter ist (wie hier) und ein Dongle, das hatte ich früher. Beim Dongle könnte man nur etwa alle 60s den ModbusTCP auslesen da der Recht langsam ist, die EMMA schafft es eigentlich öfters, aber die Integration lässt kein Einstellen der Abruffrequenz zu, deshalb auf 1min limitiert.

Aber wie gesagt, ich kann nur das angeben was ich habe. Bei DC angebundenen Speichern ist das vermutlich weniger als wenn man einen AC Speicher hätte…

Also bei meinen Sensoren fällt mir nichts auf und hier sind auch prinzipiell die daten drin die auch HA für seine Energiestatistik nutzt.

Hausverbrauch:

• Dies ist auch der Sensor welcher genutzt wird um meinen Aktuellen Hausverbrauch in Huawei-Portal anzuzeigen. Wird lokal per MODBUS_TCP aus dem Huawei-Smartmeter (Emma) ausgelesen.

Solar → Haus:

• Wirkleistung des Wechselrichters, Lokal ausgelesen, hier wird aber alles was in den Akku reingeht abgezogen was ja richtig sein sollte, aber beim ausspeisen aus dem Akku wird hier dann eine Leistung angezeigt, da diese auch erstmal durch den WR durch muss. Reiner Direktverbrauch ohne Akku Einfluss gibt es so nicht.

Wechselrichter-Ausgang AC (W):

• Wirkleistung des Wechselrichters (gleicher Sensor wie oben)

Batterie Leistung (W)_

• Lade/Entladeleistung der Batterie (Vorzeichen stimmen), Lokal ausgelesen

Solar → Batterie:

• Gleicher Sensor wie bei Batterie Leistung nur der reingehende Anteil

Batterie → Haus:

• Gleicher Sensor wie bei Batterie Leistung nur der rausgehende Anteil

Netz → Haus (und auch Smartmeter Bezug):

• reingehender Anteil des Huawei Smartmeters, lokal ausgelesen

Haus → Netz (und auch Smartmeter Einspeisung):

• rausgehender Anteil des Huawei Smartmeters, lokal ausgelesen

Also: Nur Solar → Haus ist ein Punkt der nicht passen könnte, aber hier frage ich mich welche integration hierfür einen extra Wert bieten sollte und warum…

[Astrofreak85]

Grob gesagt:

Hausverbrauch:

Solar+Akku+Netzbezug

Solar->Haus:
Solar-Akku-Rückspeisung

Bzw. Baut dir die Integration alle Summensensoren so zusammen wie du sie für SFML-Stats brauchst:

README_de.md

[Wolfi1]

@Tom-HA
Netzbezug Juli stimmt nicht Fehler (Ausreißer)?

[Joachim-xo]

@Heatseeker

welche integration hierfür einen extra Wert bieten sollte und warum…

Ich traue mich nicht zu fragen: „Aus welchem Grund löscht Du dann nicht einfach diese Integration? Deine kann‘s doch eh besser.“

Was erwartest Du jetzt noch von @Tom-HA , er hat‘s doch detailliert erklärt?

[Heatseeker]

Hausverbrauch habe ich nativ, da bastel ich mir nichts.

Solar → Haus: Das müsste dann

Wechselrichterleistung (AC) - Akku Entladen sein

Aber ich frage mich warum man den Solardirektverbrauch überhaupt braucht…

Es sollte doch reichen:

• Hausverbrauch
• Wechselrichterleistung (oder DC-PV Leistung wenn SFML selbst die Verluste berechnen mag)
• Akkuleistung (rein und raus)
• Netzleistung (rein und raus)

da erschließt es mir nicht warum man den direkten Verbrauch von Solar braucht.

Aber ich kann da gerne mal einen Template-Helfer für machen wenn SFML das so braucht (beide Werte hätte er ja sogar schon). Aber ich befürchte, dass dann die Historie nicht da ist und dann passt das eh nie

[Tom-HA]

@Heatseeker

Also: Nur Solar → Haus ist ein Punkt der nicht passen könnte, aber hier frage ich mich welche integration hierfür einen extra Wert bieten sollte und warum…

Solar → Haus ist der Direktverbrauch! Also das was direkt verbraucht wird. Das kann nicht das gleiche sein wie AC-WR Einspeiseleistung ins Haus. Dann würdest Du die Umwandlungsverluste und Wirkungsgrad ignorieren.

Solar → Haus ist : DC Gesamterzeugung - DC Akkuladung

WR (AC) → Haus ist der von DC in AC gewandelte Wert der ins Haus eingespeist wird. Die Leistung kann aus folgenden Quellen kommen - sich zusammensetzen:

Solar
Akku
Akku + Solar

Daher kann sie nicht identisch sein mit Solar → direkt ins Haus.

@Heatseeker

Es sollte doch reichen:

• Hausverbrauch
• Wechselrichterleistung (oder DC-PV Leistung wenn SFML selbst die Verluste berechnen mag)
• Akkuleistung (rein und raus)
• Netzleistung (rein und raus)

Nein eben nicht, so vermischt du AC und DC und unterschlägst die Effizienz der Anlage, da du Umwandungen " Wechselrichter wechselt DC in AC" der am WR angeschlossenen DC Quellen (Solarzellen, Akku,..)

Das ist im Übrigen auch meine Hauptkritik an der Marketing Autarkie-Berechnung! Sie stellt nur AC-Output gegen Netzbezug / Verbrauch. Das ist massiv falsch, da je nach Qualität der Komponenten z.T. doch erhebliche Verluste durch Eigenstromverbrauch, Clouddienste, Umwandlung DC/AC entstehen. → Daher weißt STATS das getrennt aus.
Mein Lieblingsbeispiel sind die wirklich schlechten Stecker-Akku-Systeme wie von Hoymiles. Die Verluste sind enorm und der Wirkungsgrad unterirdisch.

Wer nicht weiß wie die Teile Funktionieren:

Solarzelle → WR (gedrosselter AC 800W) → Via Schukostecker an den Akku → vom Akku dann via 2 WR und nochmal Schukostecker ins Hausnetz.

Da passiert folgendes:

Egal wie hoch DC-Leistung der Solarzellen es kommen immer nur 800Watt AC raus die werden dann umgewandelt auf DC um sie zu speichern um sie dann noch einmal umzuwandeln in AC um sie einzuspeisen. - Meine Eltern haben ein solches System.

Autarkie laut Hoymiles App: 95%
echte Autarkie nach Abzug und berücksichtig der Drosselungen und 3x Umwandlung = 62%

Wirkungsgrad über alles von ca. 59 - 62% je nach Wetter

Zum Vergleich eine Anker Solix und andere Systeme die Hybrid arbeiten erreichen einen Wirkungsgrad zwischen 88 und 96% !!!

[Heatseeker]

@Tom-HA

Solar → Haus ist : DC Gesamterzeugung - DC Akkuladung

stimmt, die Akkuladung ist DC…. ich hatte diese Verluste als einen Gesamtverlust der Anlage gesehen, der zwischen DC-Eingang und AC-Ausgang entsteht.