Ladeprotokoll - keine Kosten

[Open]

Das wäre ein Thema für den Steuerberater, das hier ist eine "handfeste" Quelle:
https://www.haufe.de/personal/haufe-per ... 37232.html
...
Diese hier ist nicht so "handfest", das musst Du nochmal prüfen lassen, habe dazu aber bisher kein "Veto" gefunden:
https://www.vattenfall.de/infowelt-ener ... ause-laden

Danke für die Info's zum Abrechnungsthema - Das gucke ich mir mal näher an. Bei Bedarf frage ich in einem extra Thread mal nach.

(Fällt bei Dir zwar weg, ist aber halt so, das wird für Deinen Sonderfall vermutlich keiner "ausbauen" wollen)

Ich weiß nicht ob das wirklich ein Sonderfall ist, wenn man in die breite Masse guckt. Ich würde eher vermuten das ist der Normalfall, das E-Autos geladen werden ohne das eine PV Anlage oder Speicher vorhanden ist. Wieviele E-Autos werden denn von Personen/Haushalten gefahren, die kein eigenes Haus haben oder eben keine PV Anlage auf dem Hausdach? Das diese hier im Forum total unterrepräsentiert sind ist nachvollziehbar, was aber nicht heisst, das es sie nicht gibt und das es vllt. sogar die Mehrheit ist. Stichwort: Tellerrand

Das ist genau der Knackpunkt, warum Du den Zählerstand am EVU-Punkt brauchst:
Beim dynamischen Tarif ist der "Preis für Netzbezug" dynamisch, wird hier also ignoriert.

Das mit dem Preis ist korrekt, aber kein Problem. Der Preis ist ja über die Tibber API vorhanden und im System auch korrekt hinterlegt/angezeigt/bekannt.
Das passt also. Wenn die anderen Zähler alle geliefert werden, soll es gehen. Der aktuelle dynamische Preis wird dann auch benötigt und anscheinend auch korrekt genutzt.
Es hängt also nur an den Zählerständen. Wobei ich hier die Verbindung zwischen Zählerstand vom EVU und dynamischen Tarif nicht ganz verstehe.
Denke das geht in Richtung dynamischer Tarif und geeichter Zähler - was Du oben erwähnt hast. Ok, aber...

Daher muss der EVU-Bezug beim dynamischen Stromtarif auch in Deinem Fall über den Zählerstand am EVU-Punkt berechnet werden, um die Anteile korrekt zuzuordnern (In Deinem Fall zwar 100%, 0%, 0%. Aber es muss halt trotzdem berechnet werden)

Hier wird es interessant. Wie macht man das?
Klar, vom EVU Zähler kommt Stand xy, der wird dauernd aktualisiert. Ok - soweit klar. Dieser Zählerstand bzw. die Differenz aus zwei Zählerständen ergibt den aktuellen Verbrauch. Auch klar. Wobei ich diesen Verbrauch ja auch über die Wirkleistung habe. Ist effektiv nichts anderes. Oder?
Aber gut, jetzt haben wir vom EVU Zähler den Verbrauch A über Zeitraum X. In dem Verbrauch A ist aber nicht nur der Verbrauch C der WB enthalten, sondern auch jeglicher anderer Verbrauch B im Zeitraum X (Waschmaschine, zweite WB, Spüler etc. pp.). Wie hilft mir also der Verbrauch A, den genauen Verbrauch C zu berechnen, wenn ich den Verbrauch B nicht kenne?
Deswegen meine Frage, was bringt mir den EVU Zähler, wenn kein weiterer Zähler für die PV/Speicher vorhanden ist.

Mir ist gerade noch etwas dazu eingefallen, da Du ja sowieso mit MQTT Daten hin- und herwirfst:
Versuch doch mal, ob es funktioniert, wenn Du den Zählerstand vom Ladepunkt einfach als Zählerstand in Deinen MQTT-Zähler schreibst.

Nette Idee, ziemlich schräg, aber kann man mal testen.

@aiole
Geklärt ist leider gar nichts. Es bringt niemanden etwas eine Antwort zu geben und diese dauernd stumpf zu wiederholen ohne auf die Frage einzugehen. Und Nein, es bringt auch nichts immer die selbe Frage zu wiederholen wenn man eh keine sinnvolle Antwort erhält.
"F: Warum ist der Zählerstand wichtig? A: Weil er wichtig ist." Das ist weder eine sinnvolle Kommunikation noch hilft das irgendjemanden weiter. Es deutet lediglich darauf hin, das man selbst keine Antwort auf die Fragen hat, es aber nicht zugeben will. Ich habe aber die Hoffnung, das sich auch die Leute mal melden, die die Antwort geben könnten, da sie den technischen Hintergrund haben und wissen was im Code hinterlegt ist.

Beim anlegen vom MQTT Zähler werden alle möglichen MQTT Topics angezeigt. Welche davon zwingend benötigt werden wird nicht erwähnt.

Aber trotzdem habe ich mir deine letzte Antwort mal etwas näher angesehen, insbesondere was Du mit dem virtuellen. Zähler geschrieben hast.
Ich habe also den MQTT Zähler gelöscht und einen virtuellen. Zähler angelegt. Dadurch sind mir drei Bugs aufgefallen.

1) Im charge.log steht jetzt ein Hinweis, der genau in die Richtung geht, die ich schon beim letzten Post vermutet habe:

Fehler beim Berechnen der Ladekosten für Ladepunkt 1
Traceback (most recent call last):
File "/var/www/html/openWB/packages/control/chargelog/chargelog.py", line 331, in calculate_charge_cost
log.debug(f'power source {energy_source_entry["energy_source"]}')
KeyError: 'energy_source'

Ich gehe davon aus, das diese Meldung bedeutet, das die Energiequelle nicht gesetzt ist.
Mit dieser Meldung findet man auch weitere Einträge hier im Forum. Ich bin an der Stelle also nicht der einzige der über das Problem stolpert.

2) Beim Umstellen habe ich zuerst nur den MQTT Zähler gelöscht. Danach war aber keine Ladung möglich. Es schien alles zu funktionieren. Aber der Ladevorgang ist nicht gestartet. Ohne Fehlermeldung - ohne Hinweis. Erst im main.log habe ich den Hinweis gefunden, das ohne Zähler keine Regelung und kein Laden möglich ist. Das stand sogar (fast) wörtlich so im log. Hier sollte dann auch eine entsprechende Meldung generiert und im Display / Web-Seite angezeigt werden.
Das ist ein Einrichtungsfehler, keine Frage, aber der Grund warum keine Ladung gestartet wird, sollte trotzdem angezeigt werden.

3) Beim anlegen des virtuellen. Zählers habe ich dann einen Fehler in der Einrichtung des Zählers gemacht. Ich wollte ich den Hausverbrauch auf 400W fest einstellen ( simulieren). Habe also am viert. Zähler 400 eingegeben ohne darauf zu achten das hier als Einheit kw hinterlegt ist. Damit war also die max Belastung des EVU (anscheinend) erreicht und es wurde kein Ladevorgang gestartet, was absolut korrekt ist. Es kam von der OpenWB aber keinerlei Fehlermeldung oder Hinweis. Ich habe ewig gesucht warum kein Ladevorgang startet und habe alle möglichen Logs durchsucht. Hier sollte dann am Display oder auf der Seite ein Hinweis kommen, das die max. Last am EVU erreicht ist und deshalb kein Ladevorgang gestartet werden kann. Es kann auch im echten Betrieb durchaus mal vorkommen, das der max. Strom erreicht wird, dann sollte das entsprechend angezeigt werden.


Punkt 2 und 3 sind etwas Off-Topic aber ich wollte sie hier mit erwähnen. Bei Bedarf kann das in einem extra Thread besprochen werden.

Punkt 1 führt uns aber sicherlich der Lösung von dem eigentlichen Problem, das nicht nur ich habe, ein gutes Stück in die richtige Richtung.
Wenn sich denn mal jemand findet, der / die auch substantiell was zum Thema sagen kann oder will.

Grüße

[aiole]

Beim anlegen vom MQTT Zähler werden alle möglichen MQTT Topics angezeigt. Welche davon zwingend benötigt werden wird nicht erwähnt.

Als reiner Anwender gehe ich davon aus, dass ALLE zwingend sind. Code-Enthustiasten können für tiefere Einblicke gern auf Github nachsehen.

[Open]

Ich habe noch etwas weiter experimentiert.
Das Problem hängt nicht (primär) am dynamischen Stromtarif und nicht am viert. Zähler sondern rein am MQTT.

Ich habe zwar in der OpenWb den MQTT Zähler gelöscht und einen virtuellen. Zähler eingerichtet, trotzdem aber noch im Hintergrund die MQTT Topics gesetzt. Das wird auch von der OpenWB trotzdem noch angenommen und verarbeitet (Warum?).

Dann habe ich das MQTT abgeschaltet, so das auch keine Topics mehr geschickt werden.

Dann sagt das Ladelog:

2024-03-24 12:00:02,782 - power source {'grid': 1.0, 'pv': 0.0, 'bat': 0.0, 'cp': 0.0}
2024-03-24 12:00:02,783 - charged_energy 1768.0700000000652
2024-03-24 12:00:02,784 - Ladepreis für die letzte Stunde: 0.0€ Speicher (0.0%), 0.31895982800001177€ Netz (1.0%), 0.0€ Pv (0.0%)
2024-03-24 12:00:02,785 - current costs 0.319, total costs 0.319

Das Ladeprotokoll gibt jetzt auch die Kosten mit aus, so wie es hier im Log steht.
Der Zählerstand es EVU wird für die Berechnung also nicht (!) benötigt. Aber, wenn per MQTT ein Wert kommt, in dem Fall die EVU Wirkleistung, verliert sich die Berechnungslogik an irgendeiner Stelle im Nirwana. Oder es fehlt noch ein Parameter / Wert der gesetzt oder mitgeliefert werden muss. Gesendet wurde das Topic set/counter/3/get/power mit dem Inhalt der aktuellen Wirkleistung am EVU

Jetzt könnte es natürlich sein, das es an der Kombination den. Stromtarif und MQTT liegt. Ohne die Berechnungslogik zu kennen macht das aber wenig Sinn.
Es wäre schön wenn sich das mal jemand ansehen kann, der/die den Code auch kennt und das einordnen kann.

Die Frage wäre noch, kann man die Wirkleistung am EVU auch setzen ohne die Berechnungslogik auszuhebeln?

Grüße

[Open]

Als reiner Anwender gehe ich davon aus, dass ALLE zwingend sind. Code-Enthustiasten können für tiefere Einblicke gern auf Github nachsehen.

Als reiner Anwender gehe ich davon aus, das dies die möglichen Werte sind, solange nichts anderes da steht und das hier lediglich das entsprechend Topic mitgegeben wird, damit man weiß was auf der anderen Seite gesetzt werden muss. Die Topics sind dynamisch und richten sich nach der ID des jeweiligen Gerätes.
Vermutlich liefern nur ein Bruchteil der Zähler alle aufgeführten Werte. Bei einigen Werten wird an anderer Stelle auch aufgeführt, das diese Optional sind.

Grüße

[aiole]

Achso - in einer Grenzbetrachtung reicht dann 1 Wert ?
Trotzdem gut, dass Du Dich mit der Materie beschäftigst. Nur das bringt Lösungen - nicht die reine Erwartungshaltung, die Du anfänglich zeigtest.