Sungrow different modules

[seaspotter]

openWB/openwb-ui-settings#893

Es macht vermutlich Sinn Sungrow in verschiedene Module aufzuteilen, statt wie bisher in einem Modul alles abzubilden. Daher hab ich mit dem PR hier aufgeteilt in Sungrow SH, Sungrow SG Wechselrichter und hinzugefügt Sungrow iHomeManager und die neuen Sungrow Microwechselrichter SxxxS.

letzteren beiden kann ich mangels Hardware nicht testen, ggf müssen da noch Anpassungen gemacht werden, wenn das jemand im Master Zweig testen kann. SxxxxS geben aktuell nur die Schein- und nicht die Wirkleistung aus, weil es hier an Doku mangelt.

Doku für iHM: https://github.com/Jam3s97/sungrow_ihomemanager
Doku für SxxxS: https://www.photovoltaikforum.com/thread/236114-sungrow-sammelthread-mikrowechselrichter-s450s-s800s-s1600s/

Ist ein Hinweis notwendig, dass beim Mergen dieses PR die Konfig von Sungrow Komponenten neu angelegt werden muss?

[seaspotter]

@LKuemmel den Fehler mit dem Datastore bekomme ich nicht weg, der hat mit der Umbenennung von
from modules.devices.sungrow.sungrow.version import Version
zu tun vermutlich in der packages/helpermodules/update_config.py
Kannst du da helfen?

[LKuemmel]

Den Pfad gibt es ja nicht mehr, der lautet nun from modules.devices.sungrow.sungrow_sh.version import Version

[cr0i]

Macht es nicht Sinn, das alte Modul am Leben zu lassen und es Alt, Legacy oder Deprecated zu nennen?
Wenn die Geräte neu konfiguriert werden müssen und damit die Statistiken etc. quasi verloren gehen sowie die alte Konfig in dem Moment vermutlich auch nicht mehr abgeguckt werden kann, finden das die geneigten Anwender bestimmt unlustig.
Dann könnte man sich den Zeitpunkt, wann man das machen möchte (Monats oder Jahreswechsel o.ä.) selber aussuchen.
Die neuen Module können ja einfach parallel angelegt und mit neuen Funktionen ausgestattet werden.

[seaspotter]

Macht es nicht Sinn, das alte Modul am Leben zu lassen und es Alt, Legacy oder Deprecated zu nennen? Wenn die Geräte neu konfiguriert werden müssen und damit die Statistiken etc. quasi verloren gehen sowie die alte Konfig in dem Moment vermutlich auch nicht mehr abgeguckt werden kann, finden das die geneigten Anwender bestimmt unlustig. Dann könnte man sich den Zeitpunkt, wann man das machen möchte (Monats oder Jahreswechsel o.ä.) selber aussuchen. Die neuen Module können ja einfach parallel angelegt und mit neuen Funktionen ausgestattet werden.

Nein macht null Sinn Dinge weiterzupflegen/mitzuschleifen bis Ultimo, weil dann Leute auch unwissend auf dem Stand bleiben und es irgendwann vielleicht nicht mehr funktioniert (Sungrow ist bekannt für Registeränderungen). Also einmalig ein Hinweis etwas tun zu müssen und gut. Und mehr wie einmal eine IP Adresse eingeben ist es bei Sungrow nun auch nicht.

[benderl]

Ich teile die Einstellung von @cr0i
Nach dem Merge wäre jetzt ein vorher funktionierendes System kaputt. Das darf bei einem normalen Update nicht passieren. Wenn schon das alte Modul entfernt wird, sollte es zwingend einen sauberen Upgrade-Mechanismus geben. Genau dafür ist doch die Datei upgrade_config.py da.

Wenn nur die IP migriert werden muss, sollte das doch schnell erledigt sein.

[seaspotter]

@benderl und genau danach hab ich gefragt, um Hilfe dabei schon im ersten Kommentar. Weil mir dies komplett unklar ist. Und @LKuemmel hat nur geschrieben das der Pfad geändert werden muss.
Aber wir sind wieder bei Kommunikation und sauberer Review, altes gleiches Thema. Ich glaub ich lass es zukünftig sein jegliche Mühe und Arbeit in das Projekt zu stecken. Support gleich nicht existent...

[cr0i]

@benderl und genau danach hab ich gefragt, um Hilfe dabei schon im ersten Kommentar. Weil mir dies komplett unklar ist. Und @LKuemmel hat nur geschrieben das der Pfad geändert werden muss. Aber wir sind wieder bei Kommunikation und sauberer Review, altes gleiches Thema. Ich glaub ich lass es zukünftig sein jegliche Mühe und Arbeit in das Projekt zu stecken. Support gleich nicht existent...

Du beschwerst Dich über Kommunikation und klinkst jedes Mal aus, wenn Dir etwas nicht passt?
Wie soll denn so eine sinnvolle Diskussion entstehen? Das geht bestimmt entspannter...

[benderl]

Ich bin für das Frontend zuständig und nur wegen der Benachrichtigung von GitHub hierauf aufmerksam geworden.

Dein erster Kommentar ist jetzt 11 Stunden alt. Sorry, aber so kurzfristig können wir kein komplettes Review machen. Lena hat lediglich geschrieben, wie Du den letzten Fehler beheben kannst. Bis zum Review wird es noch etwas dauern, da wir mit den Vorbereitungen für 2.2.0 aktuell gut ausgelastet sind. Bitte hab etwas verständnis dafür und Geduld. Danke

[seaspotter]

@benderl um mal konstruktive Kritik zu äußern: Eine gute Kommunikation von dir/euch wäre gewesen:

Das Problem mit dem löschen des bestehenden Moduls und Ändern in komplett neue Module können wir abfangen über die upgrade_config.py, da müssen wir dann dafür noch was einbauen, sollte möglich sein und wäre der richtige Weg. Wenn du nicht weißt wie das geht, dann unterstützen wir da sehr gerne wenn wir Zeit haben. Wird etwas dauern, aber bekommen wir hin.

Genau diese Kommunikation findet aber nicht statt und da geht es mir gar nicht um Zeit, das ist mir bewusst das ihr gerade anderes auf der Agenda habt. Aber offenbar habt ihr beide schon detaillierter reingesehen, dann ist eine unterstützende Antwort kein Beinbruch. So wie es aktuell kommuniziert ist, kommt es nämlich eher an bei mir: "Ist scheiße so, kann nicht so bleiben und musst du irgendwie umbauen oder es bleibt beim Alten"

Genau das meine ich mit Kommunikation und daher reagiere ich auch so "pissed", weils schon immer so war (in meinen Augen).
Nochmal konstruktive Kritik: Nehmt euch mal ein Beispiel wie Kommunikation, Codereview, Diskussion bei EVCC gelebt wird im Github Repo, das ist positiv!

[ndrsnhs]

@seaspotter das Modul ist zur Review bei mir gelandet da ich für die Module zuständig bin. Ich bin erst gestern sozusagen von den Toten auferstanden nachdem ich Anfang der Woche ausgefallen bin.
Gestern ging es dann drunter und drüber und ich hatte noch nicht die Zeit mich im Detail mit dem Pull Request zu beschäftigen.
Natürlich sind wir dankbar wenn sich die Community beteiligt.
Die Antwort von @LKuemmel sehe ich als schnellen Hinweis auf deine Frage. Das mag kurz aussehen würde ich jetzt aber nicht negativ anlasten wollen.
Ich schaue mir das heute im Detail an und gebe dir Rückmeldung, gib mir aber bitte noch etwas Zeit.

[ndrsnhs]

@seaspotter ich stimme zu, die Aufteilung des Sungrow Moduls ist sinnig. Bei manchen Modellen gibt es ja zig Firmwareversionen die man berücksichtigen muss. Die Aufteilung wird definitiv die Lesbarkeit und Wartbarkeit erhöhen.
iHomeManager und SxxxS sind dabei unkritisch, da es komplett neue Module sind, bedeutet die wurden ja vorher noch nie eingerichtet.
Für SG und SH müsste man die aktuelle Konfiguration überführen. Wie angedeutet ist da die update_config.py die richtige Anlaufstelle.
Grundlegende Strategie wäre zu prüfen ob ein Sungrow eingerichtet ist und falls ja die Konfiguration auszulesen und in die neuen Module zu pressen.
In der update_config.py hast du im unteren Bereich etliche upgrade_datastore Methoden. Die werden bei Update ausgeführt und ziehen alle Änderungen bis zur aktuellen Version nach.
Du musst dafür einmal die Datastore Version in Zeile 20 erhöhen und eine neue Methode schreiben die die Anpassungen durchführt.

Schau z.B. mal in Zeile 2636. Dort wird geprüft ob ein Victron eingerichtet ist und falls ja wird dort die neue Einstellung vebus_id hinzugefügt. Das wäre ggfs. ein erster Ansatz um mal ein Gefühl dafür zu bekommen.

[seaspotter]

Vielen Dank @ndrsnhs, jetzt ist einiges deutlich klarer geworden.
Hab mal eine Upgrade Routine versucht zu bauen, kannst du bei Gelegenheit ja mal drüberschauen, ob das so passt Dankeschön