PV Einbrüche die aber nicht da sind

[openWB]

EVU Kit
Fronius WR über IP Adresse eingebunden

Zuerst die Stable Version
Dann die Nightly und nun seit heute Früh wieder die Stable.
LG

Wenn EVU Kit v2 (mit Lovato Zähler) bitte auf die Nightly updaten und bis morgen Abend so lassen und beobachten.

[lew]

Okay - Danke

[Thomas aus W]

Ich habe diese "null-Spikes" auch über alle Versionen hinweg und zwar mit beeindruckender Regelmäßigkeit alle 10 Minuten. Ich denke nicht, dass es an der OWB oder dem Netz liegt, sondern dass die Wechselrichter-Hersteller alle die gleichen Komponenten verbauen, und da halt eine Dabei ist, die diese Fehlmessungen verursacht. Netzwerkfehler wären nicht sooo regelmäßig.

2020-04-02_09-57-50-Spkes_in-der_Leistung.jpg

(97.34 KiB) 497-mal heruntergeladen

bye
TW

[hominidae]

...ich hab die auch (siehe hier: viewtopic.php?f=8&t=787#p8020) mit nem SMA-WR.
Wieso soll das am WR liegen...glaube auch nicht, dass es Netzprobleme sind, da das EVU-Kit einwandfrei läuft und alles im gleichen LAN ist.

[Thomas aus W]

...ich hab die auch (siehe hier: viewtopic.php?f=8&t=787#p8020) mit nem SMA-WR.
Wieso soll das am WR liegen...

Zugegeben, ist eine Vermutung, mehr nicht.

Aber mein WR (von Kostal) beispielsweise fängt beginnend mit so einem Spike noch mal an den Speicher zu laden ob wohl der schon länger 100% voll ist. Da der bei mir auf der DC Seite hängt kann das nicht durch Probleme im (W)LAN verursacht sein.

hier sieht man, dass die Ladung nach dem Spike startet, ohne dass vorher etwas aus dem Speicher entnommen wurde:

Bildschirmfoto_2020-04-06_12-45-48-Spike-startet-ladung.png (26.12 KiB) 4049 mal betrachtet

bye
TW

[hominidae]

...ist auf jeden Fall total seltwürdig...

1. Schuss ins Blaue: openWB ist Ramdisk basiert...als ich noch so antike/bewährte Lösungen nutzte (+40Jahre her), waren immer zuerst die im System/OS vorkonfigurierten File-Handles aufgebraucht weil der global eingestellte Parameter "zu gering" eingestellt war...

2. Frage: wie viele simultane Connections kann der Modus/TCP-Server des WR und des EVU-Kit? Dann könnte man mitloggen, zusammen mit den mqtt-Topics der openWB.

[Thomas aus W]

...ist auf jeden Fall total seltwürdig...

eben.

und bei dem, was mein Kostal-WR sonnst noch so an Merkwürdigkeiten drauf hat ist der bei mir erst mal der Hauptverdächtige...

1. Schuss ins Blaue: openWB ist Ramdisk basiert...als ich noch so antike/bewährte Lösungen nutzte (+40Jahre her), waren immer zuerst die im System/OS vorkonfigurierten File-Handles aufgebraucht weil der global eingestellte Parameter "zu gering" eingestellt war...

Da hllte ich dann aber auf einen Totalausfall der OWB erwartet und nicht nur komische Logeinträge...

2. Frage: wie viele simultane Connections kann der Modus/TCP-Server des WR und des EVU-Kit?

Ich denke, 3 bis 4 pro Sekunde sollten so ein IOT-Gerät noch nicht in's schwitzen bringen, selbst wenn das billigste Harware ist...

Dann könnte man mitloggen, zusammen mit den mqtt-Topics der openWB.

Ja, so ein Vergleich wäre mal wirklich interessant.

bye
TW

[hominidae]

Ich denke, 3 bis 4 pro Sekunde sollten so ein IOT-Gerät noch nicht in's schwitzen bringen, selbst wenn das billigste Harware ist...

...ich meinte nicht die Daten-/Connection-rate sondern wieviele Clients.
Also openWB + Test-Tool müssen für so einen Vergleich ja simultan auf die gleiche IP/Port des Modus-TCP Servers (WR + EVU-Kit) connecten können.
Wahrscheinlich macht Versuch kluch...

Die Register-Specs für den SMA-WR habe ich gefunden...ebenso in Github die für das EVU-Kit....mal sehen, wenn morgen die Sonne wieder scheint, probier ich mal was...node-red kann modbus-tcp und mqtt....mal gucken, wie das mit dem Logging in eine eine einfache (rollierende) Tabelle / CSV funzt.

[Thomas aus W]

Ich denke, 3 bis 4 pro Sekunde sollten so ein IOT-Gerät noch nicht in's schwitzen bringen, selbst wenn das billigste Harware ist...

...ich meinte nicht die Daten-/Connection-rate sondern wieviele Clients.

Das hängt von der Programmierung des Servers ab, und nachdem was ich bisher über die Coder bei Kostal lernen durfte könnte das zumindest bei denen wirklich ein Problem sein...

Also openWB + Test-Tool müssen für so einen Vergleich ja simultan auf die gleiche IP/Port des Modus-TCP Servers (WR + EVU-Kit) connecten können.
Wahrscheinlich macht Versuch kluch...

Die Register-Specs für den SMA-WR habe ich gefunden...ebenso in Github die für das EVU-Kit....mal sehen, wenn morgen die Sonne wieder scheint, probier ich mal was...node-red kann modbus-tcp und mqtt....mal gucken, wie das mit dem Logging in eine eine einfache (rollierende) Tabelle / CSV funzt.

Schon mal Danke für Deine Arbeit!

bye
TW

[hominidae]

so, ein erster Versuch....

Hier gibt es zwei Teile, einmal für die EVU -Seite (Bezug/EInspeisung), im Flow oben und einmal für die PV-Erzeugung, im Flow unten.

Es wird jeweils auf die openWB über MQTT gelauscht und dann der jeweilige Zähler über Modbus abgefragt.
Dabei läuft natürlich die Modbus abfrage "hinterher"....dieser Versatz schwankt auch...habe Laufzeiten von 35-180ms.
Der Versuch, die Modbus-Abfrage näher an den Bereitstellungszeitpunkt der openWB-Werte zu bringen (openWB liefert etwa alle 9800-10200ms einen neuen Wert, also etwa alle 10sec) ist auch nicht genauer hinzubekommen...die Schwankungen/Latenzen sind zu stark.



...die Werte sind an den grünen msg.payload Nodes zu sehen.
Was noch fehlt ist das in eine Tabelle mt Timestamps zu packen....da mache ich morgen weiter.