Rückmeldungen 2.1.9 Alpha 2/3

[AlexSE]

Dafür hat man ja das Eingabefeld.

Nein. Der Andwendungsfall des Feldes ist es bei mehr installierter kWP Leistung und DC angebundener Batterie als der WR AC zeitig leisten kann zu erkennen das eine Erhöhung des Ladestroms nicht dazu führt das die Spericherladung reduziert wird wenn Prio EV konfiguriert ist.
Der WR kriegt die Leistung schlicht nicht nach AC gewandelt.

Ob man das Feld mit weiterer Funktionalität belegen kann ist ein anderes Thema.

Nicht böse gemeint, aber in der Zeit in der man eine belehrende Antwort formuliert, hätte man das ihm Code wahrscheinlich schon fast eingebaut.
Ich meine mit dieser "tollen" SolarEdge Anlage und der OpenWB sind bisher alle Datenauswertungen seit Einbau 2023 für die Tonne.

Da immer diese Spikes drin sind/waren.
Dieser simple Abgleich könnte helfen, solche Fehler zukünftig zu vermeiden.
Aber anscheinend nicht gewollt.

Es kommt mir so vor, als würden Rückmeldungen hier lieber erst mal angezweifelt, als ernst genommen zu werden und der Fehler zuerst beim Endanwender gesucht.

Gleiches bei meinem gemeldeten Thema mit dem Modbus Fehler der externen Produktion hier im Thread.
Ich musste erst einmal eine zweite openWB Instanz auf einer VM aufsetzen, die gleichzeitig auf einen Modbus Proxy zugreift, bevor ich mit dem Thema ernst genommen wurde...
Und selbst da wurde es in der ersten Antwort nochmal angezweifelt.
Einfach kein schöner Umgang.

[LutzB]

Dir ist schon klar, dass Dein letzter Peak gar nichts mit einer Maximalleistung, sondern einem Sprung im Zählerstand zu tun hat?

[AlexSE]

Dir ist schon klar, dass Dein letzter Peak gar nichts mit einer Maximalleistung, sondern einem Sprung im Zählerstand zu tun hat?

q.e.d. was ich gerade geschrieben habe.
Gleich wieder belehren, anstatt es konstruktiv aufzugreifen. Unglaublich.

Bessere Antwort für das nächste Mal:
"Interessanter Vorschlag, es berücksichtigt aber leider nicht die Zählerstände. Dafür müssten man noch abc..."

Aber wie vorhin schon geschrieben.
Umgang ist hier ab und zu verbesserungsfähig...
Schließlich will der Großteil der Kunden/Endanwender, die sich hier mit ihrer Freizeit einbringen, einen positiven und konstruktiven Beitrag leisten und nicht nur belehrt werden.

Danke

[openWB]

Schließlich will der Großteil der Kunden/Endanwender, die sich hier mit ihrer Freizeit einbringen, einen positiven und konstruktiven Beitrag leisten und nicht nur belehrt werden.

Vollkommen nachvollziehbar und Danke an jeden für seinen Einsatz beim stetigen Testen und Feedback geben.

Auf der anderen Seite habe ich gerade bei SE einige größere Partner und stetig einige Anlagen im Blick.
Wenn diese mit 4 WR / 2 Speichern nach gefühlt Jahren mit einer neuen Version endlich mal stabil und unauffällig sind und im Gegenzug eine VM Installation mit Modbus Proxy dazwischen Probleme macht kannst du sicherlich auch verstehen das da erstmal Zweifel bestehen, oder?

Mein letzter Einwand war übrigens überhaupt garnicht provokativ gemeint sondern sollte schlicht aufzeigen welche Aufgabe die Abfrage der WR Leistung hat.

[ChristophR]

Das manuelle Modul berechnet die Reichweite, wenn Werte kommen, funktioniert das nicht. Hast Du auch den SoC per MQTT, wenn Du die Reichweite per MQTT hast? Es gibt ein eigenes MQTT-Modul für die Fahrzeuge.

Wir nutzen beim WiCAN OBD2-Dongle das manuelle SoC-Modul, da einige Fahrzeuge während der Ladung keine Werte liefern, oder der Dongle wegen der Alarmanlage abgeschaltet bleiben muss. Das MQTT-Modul würde den SoC dann nicht weiterrechnen, daher brauchen wir das.

Die Reichweite ist ganz nett, da ich sie dann im Status sehen kann, so richtig wichtig ist sie mir nicht.
Mir ist das nur aufgefallen, weil es vorher ohne Probleme funktioniert hat.
Kann das nicht auch wie bei anderen SoC-Modulen funktionieren, wenn Range-Werte geliefert werden?
Nicht alle Fahrzeuge unterstützen das, daher müsste es optional oder automatisch berücksichtigt werden.

Ich habe konsistent zum json-SoC-Modul die beiden anderen generischen Module http und mqtt um den Button "während der Ladung berechnen" erweitert und bitte Dich, deine Topcis auf das Mqtt-SoC-Modul zu ändern.

Wird dann während der Ladung nur berechnet oder fließen geänderte Werte, wenn sie gesendet werden mit ein?
Wäre für die morgendliche Voorklimatisierung wichtig, damit er dann bei Bedarf nachregeln kann.

[LenaK]

Wir nutzen beim WiCAN OBD2-Dongle das manuelle SoC-Modul, da einige Fahrzeuge während der Ladung keine Werte liefern, oder der Dongle wegen der Alarmanlage abgeschaltet bleiben muss. Das MQTT-Modul würde den SoC dann nicht weiterrechnen, daher brauchen wir das.

Die Reichweite ist ganz nett, da ich sie dann im Status sehen kann, so richtig wichtig ist sie mir nicht.
Mir ist das nur aufgefallen, weil es vorher ohne Probleme funktioniert hat.
Kann das nicht auch wie bei anderen SoC-Modulen funktionieren, wenn Range-Werte geliefert werden?
Nicht alle Fahrzeuge unterstützen das, daher müsste es optional oder automatisch berücksichtigt werden.

Ich habe konsistent zum json-SoC-Modul die beiden anderen generischen Module http und mqtt um den Button "während der Ladung berechnen" erweitert und bitte Dich, deine Topcis auf das Mqtt-SoC-Modul zu ändern.

Wird dann während der Ladung nur berechnet oder fließen geänderte Werte, wenn sie gesendet werden mit ein?
Wäre für die morgendliche Voorklimatisierung wichtig, damit er dann bei Bedarf nachregeln kann.

Nein, entweder es können Daten während der Ladung abgefragt werden oder sie werden berechnet. Abgefragt wird nur, wenn nicht geladen wird.

[openWB]

Dafür hat man ja das Eingabefeld.

Nein. Der Andwendungsfall des Feldes ist es bei mehr installierter kWP Leistung und DC angebundener Batterie als der WR AC zeitig leisten kann zu erkennen das eine Erhöhung des Ladestroms nicht dazu führt das die Spericherladung reduziert wird wenn Prio EV konfiguriert ist.
Der WR kriegt die Leistung schlicht nicht nach AC gewandelt.

Ob man das Feld mit weiterer Funktionalität belegen kann ist ein anderes Thema.

Ich muss mich an der stelle selbst korrigieren.
Die Ausgangsleistung wird dazu verwendet peaks abzufangen, siehe.
https://github.com/openWB/core/blob/584 ... ter.py#L59
und
https://github.com/openWB/core/blob/584 ... og.py#L533

Bei dir wird der Zählerstand vom WR genutzt, nicht unsere Berechnung.
Heißt der Wert kommt so direkt vom Wechselrichter.
Eine mögliche Erklärung von dem Peak könnte aber sein das deine Auslesung einige Stunden / Tage / Woche nicht funktionierte.
In der Folge hast du einen Peak vom letzten bekannten Zählerstand bis zum heutigen.
Im Rahmen der gesamtheitlichen Erfassung ist das richtig, sonst würde über das Jahr gesehen diese Menge fehlen.
Statt in x Wochen ist die halt in 5 Minuten gepackt.
Genau wie das auch bei neu angelegten Geräten ist bei denen der Zählerstand übernommen wird.

[LenaK]

Ein main.log vom Abstecken (wenn es beim nächsten Anstecken schief geht) würde helfen, dann könnte ich sehen, ob beim Zurücksetzen des Timestamps was schief gegangen ist.

Das müsste das passende main.log vom Ende des Ladevorganges davor gewesen sein:
https://paste.openwb.de/UYVB4fGzibmUh6M

P.S: Hier noch vom Abstecken (gegen 7:17 Uhr):
https://paste.openwb.de/uVwcE4bYo4VRnNp

In dem Log ist es leider auch schon in dem Zustand, dass der Timestamp noch gesetzt ist, aber der Tag schon gelöscht. Ich habe das Zurücksetzen nochmal angepasst.

[AlexSE]

Dafür hat man ja das Eingabefeld.

Nein. Der Andwendungsfall des Feldes ist es bei mehr installierter kWP Leistung und DC angebundener Batterie als der WR AC zeitig leisten kann zu erkennen das eine Erhöhung des Ladestroms nicht dazu führt das die Spericherladung reduziert wird wenn Prio EV konfiguriert ist.
Der WR kriegt die Leistung schlicht nicht nach AC gewandelt.

Ob man das Feld mit weiterer Funktionalität belegen kann ist ein anderes Thema.

Ich muss mich an der stelle selbst korrigieren.
Die Ausgangsleistung wird dazu verwendet peaks abzufangen, siehe.
https://github.com/openWB/core/blob/584 ... ter.py#L59
und
https://github.com/openWB/core/blob/584 ... og.py#L533

Danke für die Erklärung und Verlinkung.
Die Methode ist einfach und macht halt sehr viel Sinn.
Schön

Bei dir wird der Zählerstand vom WR genutzt, nicht unsere Berechnung.
Heißt der Wert kommt so direkt vom Wechselrichter.
Eine mögliche Erklärung von dem Peak könnte aber sein das deine Auslesung einige Stunden / Tage / Woche nicht funktionierte.
In der Folge hast du einen Peak vom letzten bekannten Zählerstand bis zum heutigen.
Im Rahmen der gesamtheitlichen Erfassung ist das richtig, sonst würde über das Jahr gesehen diese Menge fehlen.
Statt in x Wochen ist die halt in 5 Minuten gepackt.
Genau wie das auch bei neu angelegten Geräten ist bei denen der Zählerstand übernommen wird.

Das ist korrekt.
Da sich die Daten auf der openWB mit Version 2.1.8 Patch 3, nach dem SolarEdge Wechselrichtertausch komplett zerschossen hatten und die Datenfelder auf den max Werten nicht weiter befüllbar waren, habe ich mit einer Neuinstallation auf Version 2.1.9 Alpha 3 alles neu aufsetzen müssen.
Daher hat das System, wie von dir beschrieben, den Gesamtzählerstand übernommen.
Ich verstehe, dass es bei manchen Leuten etwas bringen kann, in meinem Fall leider nicht wirklich.

1. Die Daten der externen Produktion sind von 2024 bis jetzt. Also dadurch auch dem falschen Jahr zugeordnet.
2. Es ergab einen falschen Tages und Monatswert
3. Da ich die Produktionswerte des Hauptwechselrichters nicht wieder herstellen kann, es der Mehrwert der externen Produktion überschaubar

Wenn aber Version 2.1.9 nun keine Peaks mehr zulässt, dann hab ich zumindest für 2026 einen sauberen Start und ab da dauerhaft brauchbare Werte
Ist ja auch ein positiver Fortschritt.
Danke


Hat man bei anderen PV Herstellern auch solche Probleme bei der Auslesung der Daten, oder ist das hauptsächlich eine SE Sonderlocke?

[openWB]

Hat man bei anderen PV Herstellern auch solche Probleme bei der Auslesung der Daten, oder ist das hauptsächlich eine SE Sonderlocke?

SE hat sich hier leider als negatives Beispiel rausgestellt. Daumen sind aber gedrückt das es nun final stabil läuft.