openWB software2 2.1.4 Beta 1, 2 und 3

[mrinas]

Lena, dieser Fehler treibt uns nutzer des Tronity Moduls leider immer noch um. Könnt Ihr da bitte mal einen Blick rein werfen? Die manuelle Berechnung schlägt irgendwann fehl da nicht alle notwendigen Daten übergeben werden - mir ist aber nicht klar warum das so ist.

viewtopic.php?p=105745#p105745

[LenaK]

Probier‘ mal ob‘s mit Zähler besser wird. Mein e3dc bietet auch keinen Zähler, nur die Leistungswerte. In der openWB wird dann ein Zähler simuliert. Vielleicht hat der ja bei einigen Modulen einen Bug? Bei mir habe ich noch keine Peaks feststellen können.

Was meinst du genau?
Meine 3 SolarEdge WR liefern die Werte, bis dato habe ich die Werte summiert und alle 4s an die openWB übergeben.
Ab heute wird ein vermisster Wert ersetzt durch den letzten empfangen Wert, so das lückenlos Werte kommen müssten.

Lena schrieb ja:

Als Datengrundlage für die Diagramme werden die Zählerstände verwendet. Wenn diese nicht aktualisiert werden und dann einen Sprung machen, schlägt sich das als Peak im Diagramm nieder.

Das habe ich so interpretiert, dass es besser werden würde, wenn Du Zählerstände übermittelst statt nur der momentanen Leistungswerte. Was ich daran dann nicht verstehe, ist dass mein e3dc auch keine Zählerstände übermittelt und die openWB dann einen simcount (Simulierter Zähler) dafür erstellt. Den hätte ich außerhalb des Moduls (mqtt oder e3dc oder anderer Hersteller) erwartet, womit der Lenas Lösungsvorschlag keinen Sinn mehr ergibt.

Die simcount-Klasse wird in das Modul importiert, wenn der Hersteller keine Zählerstände liefert. Die Implementierung ist damit zentral, wird aber nur von den Modulen genutzt, die keine Zählerstände liefern.
Die Logging-Klasse arbeitet mit den Modul-Werten. Ob die nun aus dem Gerät selbst kommen oder vom simcount ist unerheblich.

[LenaK]

Hallo,

ich möchte auch eine Auffälligkeit melden.

Die Einspeisung in der Übersichtsseite beträgt immer 0Wh obwohl ich täglich viele kWh einspeise.

Meine Hardware:
Kostal Plenticore 10 G1 mit KSEM G1
Byd HV 6.4
2 Hoymiles HM1500 (nicht in der Open WB mit eingebunden, über den KSEM müsste doch aber der Ertrag mit sichtbar sein)

Softwareversion Open WB:
2024-05-03 10:26:56 +0200 [93a31f7ef]

Bitte mehrere Zyklen posten, wenn eingespeist wird. viewtopic.php?t=1526

[Gero]

Die Logging-Klasse arbeitet mit den Modul-Werten. Ob die nun aus dem Gerät selbst kommen oder vom simcount ist unerheblich.

Womit wir wieder bei der ursprünglichen Problemstellung sind: MQTT hat Sprünge, e3dc nicht. Beide nutzen den selben simcount, also kann es daran nicht liegen.

[LenaK]

Die Logging-Klasse arbeitet mit den Modul-Werten. Ob die nun aus dem Gerät selbst kommen oder vom simcount ist unerheblich.

Womit wir wieder bei der ursprünglichen Problemstellung sind: MQTT hat Sprünge, e3dc nicht. Beide nutzen den selben simcount, also kann es daran nicht liegen.

Nein, bei MQTT wird kein simcount genutzt. Da ist der Benutzer verantwortlich, alle benötigten Werte bereit zu stellen. Das MQTT-Modul macht nichts, die Werte kommen direkt in den Broker.

Zur Analyse wird ein Main-Log im Level Details über mehrere Zyklen und die Tageslog-Datei benötigt, wenn ein Peak auftritt.

[LenaK]

Lena, dieser Fehler treibt uns nutzer des Tronity Moduls leider immer noch um. Könnt Ihr da bitte mal einen Blick rein werfen? Die manuelle Berechnung schlägt irgendwann fehl da nicht alle notwendigen Daten übergeben werden - mir ist aber nicht klar warum das so ist.

viewtopic.php?p=105745#p105745

Ich habe es gefixt. Bitte nochmal testen.

[mrinas]

Lena, dieser Fehler treibt uns nutzer des Tronity Moduls leider immer noch um. Könnt Ihr da bitte mal einen Blick rein werfen? Die manuelle Berechnung schlägt irgendwann fehl da nicht alle notwendigen Daten übergeben werden - mir ist aber nicht klar warum das so ist.

viewtopic.php?p=105745#p105745

Ich habe es gefixt. Bitte nochmal testen.

ha, das ging schnell, danke!

[tcat]

Ich beobachte mit der 2.1.4-Beta.2 schon mehrmals folgenden Fehler. Nun habe ich diesen im Debug-level "Details" eingefangen.
Version: 2024-04-26 12:07:01 +0200 [682ffadf4]

Fehlermeldung aus dem Screenshot: <class 'ValueError'> ('Lade-Status ist nicht aktiv, aber Strom fliesst.',)
Time stamp: 2024-05-03 12:47:40,875

[Nasdero]

Das habe ich so interpretiert, dass es besser werden würde, wenn Du Zählerstände übermittelst statt nur der momentanen Leistungswerte. Was ich daran dann nicht verstehe, ist dass mein e3dc auch keine Zählerstände übermittelt und die openWB dann einen simcount (Simulierter Zähler) dafür erstellt. Den hätte ich außerhalb des Moduls (mqtt oder e3dc oder anderer Hersteller) erwartet, womit der Lenas Lösungsvorschlag keinen Sinn mehr ergibt.

Nein ich übermittel alles was gefordert ist, u.a. PV-Power und auch den Zähler. Wird schon seine Gründe haben das openWB in dem Diagram die Zähler nimmt, hätte ich das früher gewusst, hätte ich sofort an der richtigen Schraube drehen können. Ich bin davon ausgegangen, das PV-Power auch in das Diagramm rein geht.
Beim PV Wert rechnen ich bei SE den ganzen Müll raus, denn wenn der Akku vom Netz geladen wird, dann ist das bei SE ein "PV-Ertrag", bei dem Zähler ist der Müll halt noch drin, darum habe ich mich gewundert, das ich Nacht dort einen PV-Ertrag habe, da ich davon ausgegangen bin, dass in dem Diagramm auch die PV-Power genutzt wird.
Seit meiner Änderung hatte ich keinen Peak mehr, aber das lief auch schon Tage ohne Peak vorher, recht random, mal abwarten.

[Frank-H]

Zur Analyse wird ein Main-Log im Level Details über mehrere Zyklen und die Tageslog-Datei benötigt, wenn ein Peak auftritt.

Ich habe jetzt einen Peak durch den SMA-Wechselrichter im Dateilog erwischt und großzügig beigefügt, ebenso das Tageslog.Der Peak ist genau um 18.15 Uhr aufgetreten. Hoffentlich hilft es bei der Fehlerbehebung.
Über eine kurze Rückmeldung würde ich mich freuen!