photron

Als technisches Detail hier das aktuelle Sungrow-Mapping: https://github.com/Tinkerforge/esp32-firmware/blob/master/software/src/modules/meters_modbus_tcp/meter_modbus_tcp.cpp#L48

Das ist der Auszug der Sungrow Daten der anderen Kundenanlage, heute Nachmittag mit etwas Sonne: Total Output Energy [0.1 kWh] (5004): 40723 (40723 0) Inside Temperature [0.1 °C] (5008): 296 Total DC Power [W] (5017): 567 (567 0) A-B / A-N Voltage [0.1 V] (5019): 2346 B-C / B-N Voltage [0.1 V] (5020): 2323 C-A / C-N Voltage [0.1 V] (5021): 2337 Reactive Power [var] (5033): -4 (65532 65535) Power Factor [0.001] (5035): 1000 Grid frequency [0.01 Hz] (5036): 4996 Total PV Generation [0.1 kWh] (13003): 38096 (38096 0) Total PV Energy Export [0.1 kWh] (13006): 24716 (24716 0) Load Power [W] (13008): -1143 (64393 65535) Export Power [W] (13010): 1522 (1522 0) Total PV Energy Battery Charge [0.1 kWh] (13013): 7074 (7074 0) Total Direct Battery Consumption [0.1 kWh] (13018): 6306 (6306 0) Battery Voltage [0.1 V] (13020): 4006 Battery Current [0.1 A] (13021): 0 Battery Power [W] (13022): 0 Battery Level [0.1 %] (13023): 1000 Battery SoH [0.1 %] (13024): 1000 Battery Temperature [0.1 °C] (13025): 160 Total Battery Energy Discharge [0.1 kWh] (13027): 10292 (10292 0) Grid State (13030): 0 Phase A Current [0.1 A] (13031): 6 Phase B Current [0.1 A] (13032): 6 Phase C Current [0.1 A] (13033): 7 Total Active Power [W] (13034): 429 (429 0) Total Import Energy [0.1 kWh] (13037): 37381 (37381 0) Battery Capacity [0.1 kWh | Ah] (13039): 1920 Total Charge Energy [0.1 kWh] (13041): 11234 (11234 0) Total Export Energy [0.1 kWh] (13046): 42965 (42965 0) Und hier im Dunkeln: Total Output Energy [0.1 kWh] (5004): 40725 (40725 0) Inside Temperature [0.1 °C] (5008): 289 Total DC Power [W] (5017): 0 (0 0) A-B / A-N Voltage [0.1 V] (5019): 2338 B-C / B-N Voltage [0.1 V] (5020): 2328 C-A / C-N Voltage [0.1 V] (5021): 2330 Reactive Power [var] (5033): -5 (65531 65535) Power Factor [0.001] (5035): 1000 Grid frequency [0.01 Hz] (5036): 4999 Total PV Generation [0.1 kWh] (13003): 38097 (38097 0) Total PV Energy Export [0.1 kWh] (13006): 24717 (24717 0) Load Power [W] (13008): 335 (335 0) Export Power [W] (13010): -16 (65520 65535) Total PV Energy Battery Charge [0.1 kWh] (13013): 7074 (7074 0) Total Direct Battery Consumption [0.1 kWh] (13018): 6306 (6306 0) Battery Voltage [0.1 V] (13020): 3980 Battery Current [0.1 A] (13021): 9 Battery Power [W] (13022): 319 Battery Level [0.1 %] (13023): 978 Battery SoH [0.1 %] (13024): 1000 Battery Temperature [0.1 °C] (13025): 160 Total Battery Energy Discharge [0.1 kWh] (13027): 10293 (10293 0) Grid State (13030): 0 Phase A Current [0.1 A] (13031): 6 Phase B Current [0.1 A] (13032): 6 Phase C Current [0.1 A] (13033): 6 Total Active Power [W] (13034): 319 (319 0) Total Import Energy [0.1 kWh] (13037): 37381 (37381 0) Battery Capacity [0.1 kWh | Ah] (13039): 1920 Total Charge Energy [0.1 kWh] (13041): 11234 (11234 0) Total Export Energy [0.1 kWh] (13046): 42965 (42965 0) Sorry für das etwas kryptische Format. Der Wert nach dem Doppelpunkt ist der eigentliche Messwert: <Name> [<Einheit>] (<Adresse>): <Wert> (<Rohdaten>) Mir ist noch nicht ganz klar wie Load Power, Export Power, Battery Power und Total Active Power im Zusammenhang stehen. Der untere Fall scheint mir klarer. PV liefert 0W (Total DC Power). Die Batterie wird mit 319W (Battery Power) entladen. Das Haus hat eine Bedarf von 335W (Load Power). Die Differenz von 16W die die Batterie nicht liefert wird aus dem Netz importiert (negative Export Power). Der Wechselrichter liefert dem Haus insgesamt 319W (Total Active Power). Der obere Fall ist mir unklarer. PV liefert 567W (Total DC Power). Die Batterie ist voll und wird nicht entladen (Batterie Level ist 100% und Batterie Power ist 0W). Das Haus hat einen Überschuss (???) von 1143W (negative Load Power, wie kann das sein?). Der Wechselrichter macht aus 567W(DC) dann 429W(AC) (Total Active Power)? Gesammt werden 1522W an das Netz exportiert. Die Summe geht nicht auf, da gehen 50W verloren. Vermutlich liegt dass daran, dass nicht alle Werte zum exakt gleichen Zeitpunkt aufgezeichnet wurden. Zu klären wäre jetzt wie genau die Sungrow-Werte auf unsere Zähler-API zugeordnet werden müssen, damit am Ende etwas sinvolles bei herum kommt.

Das Device unter 247 wirst du nur haben wenn du den WiNet-S hast, vermute ich. Wenn du den nicht verbaut hast kommt vermutlich nichts unter 247. Darf ich fragen, was du em Ende erreichen möchtest? PV-Überschussladen? Dafür muss die Wallbox wissen wieviel Leistung über ist. Mal von SunSpec weg. Hier eine Firmware die einen ersten Schuss für eine generelle Modbus/TCP Unterstützung hat mit Sungrow SH... Vorlage. Das Mapping und die Auswahl der Sungrow-Werte auf unsere Zähler-API ist absolute experimentel und muss definitiv überarbeitet werden. Ich habe da mal ein erste Auswahl getroffen. Es werden aber alle gelesenen Werte auch im Ereignis-Log ausgegeben. Also, anstatt einen SunSpec-Zähler, kannst du einen Modbus/TCP Zähler hinzufügen und als Vorlage Sungrow SH... auswählen. Dann werden die 5000er und 13000er Register von Sungrow gelesen. warp3_firmware_2_3_0_66295a34_883722f39fab0eb_merged.bin

Wir haben gerade noch einen anderen Kunden auch mit Problemen bei Sungrow. Es scheint mir so, dass man die Modbus/TCP Schnittstelle recht schnell überlasen kann. Wenn ich die richtig verstehe fagst du die Daten ach noch mit anderen Programmen ab. Könntest du versuchen die anderen Abfragen zu pausieren, so dass am besten nur wir alleine mit Modbus/TCP reden können? Dann den Suchbereich auf 247-247 einschränken. Das funktioniert gerade beim anderen Kunden, wenn auch mit Aussetzern.

Um zu verhindern, dass wir zu viele Anfragen stellen bei der Gerätesuche, habe ich in dieser Firmware eingebaut, dass der Geräteadressbereich einschränkbar ist. Teste bitte mit dieser Firmware einmal, ob es hilft den Geräteadressbereich von 1-247 auf 247-247 zu stellen und dann die Gerätesuche durchzuführen. warp3_firmware_2_3_0_6627f196_868b4bd89faf633_merged.bin

SunSpec wird leider von verschiedenen Herstellern immer wieder leicht unterscheidlich umgesetzt. Wir arbeiten daran die Kompatibilität zu den Fehlern der Herstellern zu verbessern. Dein erstes Problem ist, wie Matze schon erwähnt hat, dass Sungrow das Ende der Modelliste falsch meldet und wir darüber stolpern. Das haben wir letzte Woche schon bei einem anderen Kunden gesehen. Teste mal bitte die angehängte Firmware, in der dieser Punkt behoben sein sollte. Wir erkennen deinen Wechselrichter als "Wechselrichter einphasig", weil Sungrow den in SunSpec so meldet. Das ist nicht unsere Entscheidung. Das ist leider verwirrend, aber erstmal okay, wie Matze erklärt, weil auch das einphasige Modell dreiphasige Werte melden kann. Hier habe ich noch keine gute Idee wie wir das verbessern könnten. Im Sinne von irgendwie zu raten, dass eigentlich das dreiphasige Modell gemeint ist, Sungrow aber das einphasige meldet. Grundsätzlich liegt kein Problem vor, aber es verwirrt den Kunden. Alles außer dem Anzeigenamen unter dem "Suche starten" Knopf ist relevant. Da wird festgelegt von welcher Modbus/TCP Geräteadresse, von welchem SunSpec Untergerät (Hersteller, Modell, Seriennummer), welches SunSpec-Modell und davon welche Modellinstanz gelesen wird. Da kannst du schlussendlich eintragen was du möchtest, und so lange dein Gerät dann diese Daten auch liefern kann wird es auch funktionieren. Wenn die Suche es aber schon nicht findet, dann ist es höchstwarscheinlich auch nicht vorhanden. Bezüglich der falschen Werte. Die SunSpec Register fangen bei 40000 an. Wir lesen also nicht im 130XX Bereich den du von Hand ausließt. Teste mal bitte mit der angehängen Firmware, ob die Gerätesuche jetzt besser funktioniert. Sobald wir das Problem gelöst haben, schauen wir uns an was bei den Werten nicht passt. Ob wir das falsch lesen, oder ob Sungrow das falsch meldet. Edit: Bitte Firmware im nächsten Post ausprobieren.

Danke für den Hinweis. Ich habe die Dokumentation aktualisiert.

Ich habe deine Änderungen mit in Delphi Bindings 2.1.34 aufgenommen.

Dafür müssen wir das Problem aber nachstellen können. Welches Debian-Derivat nutzt du, auf dem dieses Problem auftritt?

Bindings: C# 2.1.33, Delphi/Lazarus 2.1.34, LabVIEW 2.1.32, Mathematica 2.1.32, Visual Basic .NET 2.1.32 Handle forced socket read timeout for System.AppDomain.Unload timeout fix correctly when using Microsoft .NET runtime on Linux [C#, LabVIEW, Mathematica, VB.NET] Use macOS specific code for all non-Windows platforms [Delphi] Download: C#, Delphi/Lazarus, LabVIEW, Mathematica, Visual Basic .NET

Bindings: C# 2.1.33, Delphi/Lazarus 2.1.34, LabVIEW 2.1.32, Mathematica 2.1.32, Visual Basic .NET 2.1.32 Erzwungener Socket-Lese-Timeout, um das System.AppDomain.Unload-Timeout-Problem zu lösen, wird jetzt auch bei der Verwendung der Microsoft .NET Runtime unter Linux richtig behandelt [C#, LabVIEW, Mathematica, VB.NET] macOS spezifischer Code wird für alle nicht-Windows Platformen verwendet [Delphi] Download: C#, Delphi/Lazarus, LabVIEW, Mathematica, Visual Basic .NET

Klingt gut. Ich baue das ein. Danke!

Das brickv Debian Package hängt ab von: python3 (>= 3.5), python3-pyqt5 (>= 5.5), python3-pyqt5.qtopengl, python3-serial (>= 3.0), python3-tz, python3-tzlocal, python3-pkg-resources Da ist alles dabei was dein Script auch installiert. Da fehlt also erstmal nichts. Der Unterschied ist aber, dass du mit pip die aktuellsten Versionen von PyPI installierst im Gegensatz zu deinem Debian Derivat, dass vermutlich ältere Versionen ausliefern wird. Wir importieren PyQt5.sip nicht direkt. SIP ist ein Implementierungsdetail von PyQt5. Ich vermute das ist ein Bug in der speziellen PyQt5 Version, die dir apt installiert hat, oder in der Art und Weise wie Debian PyQt5 paketiert hat. Vielleicht können wir da einen Workaround für einbauen.

Ich habe die JavaScript Binding im Browser getestet und kann dein Problem leider nicht nachstellen. Die Bindings funktionieren bei mir. Ich habe dieses Beispiel einfach direkt im Browser ausgeführt, ohne es vorher runterzuladen. Ich habe nur die UID meines Outdoor Weather Bricklets eingetragen: https://www.tinkerforge.com/de/doc/Software/Examples/JavaScript/OutdoorWeather_Bricklet_JavaScript_ExampleCallback.html Ich verwenden die aktuellen Softwareversionen: brickd 2.4.5 und Outdoor Weather Bricklet Firmware 2.0.4.

Das Thema ist nicht neu: https://github.com/Tinkerforge/esp32-firmware/issues/210 Das wollen wir uns anschauen, was da realisierbar ist.