SMA Home Manager Software Change auf 2.07.5.R

[ALDI-Tuete]

Bei mir passt seit dem SMA Update einiges nicht mehr :-/

- Ich habe auch die Aussetzer sowohl in der PV-Leistung als auch im Hausverbrauch
- Von meinem SMA SBS 3.7 (Akku WR) bekomme ich überhaupt keine Daten mehr

Meine Python-Kenntnisse reichen leider nicht aus um das zugrundeliegende Skript anzupassen.
Ist da jemand schon dran?

[sagibo]

Hallo,

ich habe den gleichen Batterie-WR und kein Problem damit (Firmware 3.12.33.R). Netzwerktechnisch WLAN-frei, alles verkabelt.
Ich habe nur die hier diskutierten Aussetzer in der Kommunikation zwischen dem HomeManager (2.07.5.R) und openWB (1.9.244 stable). Die treten ziemlich regelmäßig alle fünf Minuten auf, manchmal auch nicht, in wenigen Fällen öfter. Die Kommunikation zum PV-WR (SMA Tripower 8.0, FW 3.10.15.R) läuft bei mir auch problemlos.

Ich vermute, dass Dein Batterie-WR-Problem nichts mit dem Kommunikationsproblem zwischen openWB und dem PV-WR zu tun hat, da würde ich nochmal separat fahnden. Hat sich z.B. wg. dhcp die WR-IP-Adresse geändert?, Verkabelung ok?, Modbus TCP (noch) aktiv? …oder irgendwas anderes, wo man sich hinterher wundert, dass man nicht gleich dran gedacht hat…

[ALDI-Tuete]

Jein, das muss ich präzisieren Ich habe zwei Anlagen (alt und neu).
Die Wechselrichterleistung der Altanlage lese ich über einen eigenen SMA EnergyMeter aus. Bei der Neuanlage wird der SMA WR direkt ausgelesen.

Nun zum Akku: Da habe ich mich vertan, ich lese direkt den BYD Akku aus, das lief auch jahrelang ohne Probleme und liefert nun keine Daten mehr. Restart vom Akku ist bereits erfolgt, leider ohne Erfolg - warum auch immer.

Aber dank deiner Nachfrage habe ich hier an der Stelle jetzt den SMA SBS 3.7 konfiguriert und jetzt erhalte ich wieder Daten. Danke!

Die generelle Frage ist für mich aber wie ich diese Aussetzer loswerde.

[sagibo]

Ja, das wäre sehr schön. Die Nightly 250 löst das Problem nicht (und hat dafür neue andere, z.B.beim Aufruf der Modulkonfig für den Batterie-WR, so dass es gut ist, wenn man ein backup hat… oder besser zwei).

[yankee]

Nun zum Akku: Da abe ich mich vertan, ich lese direkt den BYD Akku aus, das lief auch jahrelang ohne Probleme und liefert nun keine Daten mehr. Restart vom Akku ist bereits erfolgt, leider ohne Erfolg - warum auch immer.

Siehe auch: viewtopic.php?p=52722#p52722 (ein paar Seiten später gibt es von mir sogar eine nicht-hilfreiche Antwort: viewtopic.php?p=52864#p52864)

[MadMax219]

Hab einen PR #1845 erstellt um alle Daten-Pakete kleiner als 608 zu ignorieren.

Da dies mein erster PR überhaupt ist benötige ich auf github einen Maintainer.
-> help needed

[ALDI-Tuete]

@MadMax219 Erstmal vielen Dank für deine Mühe! Ich habe die Änderungen in meinem Testsystem manuell nachgezogen und das hat für meinen SMA Homemanager2 augenscheinlich auch funktioniert.
Ich nutze für meine alte PV-Anlage einen SMA EnergyMeter (die WR sind zu alt und zu dumm) und dementsprechend habe ich im PV-Modul "SMA Energy Meter" mit Seriennummer konfiguriert. Hier erhalte ich aber nach dem Fix falsche Werte, die PV-Erzeugung steigt kontinuierlich auf Werte die technisch gar nicht möglich sind.

Ich habe dann die Änderung in smaemd_pv/sma-em-measurement.py wieder rückgängig gemacht und habe nun wieder korrekte Werte (inkl. Aussetzer ).

Ein Logging hierzu konnte ich nicht finden, ich kenne mich in dem Bereich aber auch nicht so gut aus.

Weißt du ob die Datenpakete vom SMA EnergyMeter evtl. kleiner als 608 Byte sind und somit vom Fix komplett ignoriert werden?

Im Anhang ist noch ein Screenshot vom Prodsystem.

Danke!

[Becker]

Weißt du ob die Datenpakete vom SMA EnergyMeter evtl. kleiner als 608 Byte sind und somit vom Fix komplett ignoriert werden?

viewtopic.php?p=51478#p51478

[ALDI-Tuete]

Die 58 Byte Datenpakete kenne ich, die sind ja für die Aussetzer verantwortlich.
Ein valides Datenpaket vom HomeManager2 (HM2) ist 608 Byte groß.

Meine Frage ist ob ein valides Datenpaket vom EnergyMeter (EM) kleiner als ein valides Datenpaket vom HM2 ist. Ich glaube da mal irgendwo was gelesen zu haben. Der EM kann ja viel weniger als der HM2 und dementsprechend werden dort viele HM2-Messwerte gar nicht existieren.

Wenn dem so ist, verhindert der Fix das valide EM-Datenpakete ausgewertet werden.

[MadMax219]

Vorweg: Vielen Dank daß sich das jemand anschaut!

Ich gestehe, daß ich das Ganze bei mir nur mit (m)einem SMA SHM getestet habe.
Die relevante Datei ist also modules/bezug_smashm/sma-em-measurement.py

Ich habe vorab einige Minuten mitgeloggt und dabei nur Pakete mit Länge 608 und 58 gefunden.
Und ich hab das seit gestern parallel am Laufen auf 2 verschiedenen Test-Systemen, einmal mit Bugfix und einmal ohne Bugfix.
Die Graphen sind absolut identisch, außer eben den fehlenden Aussetzern bei einem der beiden.

Die andere Datei modules/smaemd_pv/sma-em-measurement.py hab ich dann gleich mit angepasst, in der offensichtlich irrigen Annahme daß der Ablauf dort identisch ist. Mea culpa.
Wenn der SAM-EM natürlich kürzere Pakete liefert werden dann alle ignoriert.

Und ja, der Fix verwirft einfach alle Pakete kleiner als 608.
Drum erwähnte ich im PR, daß es um einen "Dirty Hack" geht.
Vielleicht sollten wir die Logik umdrehen und explizit die 58er verwerfen?

@ALDI-Tuete
Kannst/Magst Du mal den Traffic des SMA-EM mitschneiden (wireshark) und anschauen oder mir zukommen lassen?
Order magst Du den Code einfach mal in die Richtung Len <> 58 anpassen und dann beim SMA-EM testen?
Ich besitze keinen SMA-EM.

PS: Es gibt ja auch noch eine 3 Stelle, wo Pakete mit 608er Länge erwartet werden, da hab ich aber die Finger von gelassen.
Es gibt jedoch einen PR #1846 dazu (der ist aber nicht von mir).