Rückmeldungen 2.1.9 Alpha 2

Fragen zur Nutzung, Features, usw..
Antworten
LenaK
Beiträge: 1597
Registriert: Fr Jan 22, 2021 6:40 am
Has thanked: 8 times
Been thanked: 110 times

Rückmeldungen 2.1.9 Alpha 2

Beitrag von LenaK »

Die Ankündigung findet Ihr hier: viewtopic.php?t=11378

Mit Problemen bei Inbetriebnahme / Anschluss oder Hardwareproblemen mit openWB-Hardware bitte direkt über die Support-Funktion unter System -> Support an openWB wenden (Notfalls auch per Mail an support@openwb.de).
Im Forum kann durchaus mal etwas untergehen. Das führt zu Frust und soll nicht sein.

Bitte keine Mehrfach-Meldung per Mail, Support-Ticket und Forum.
Das spart auf unserer Seite Supportzeit und bringt erfahrungsgemäß keine Beschleunigung des Vorgangs.

Bitte bei Problemen immer einen Logauszug posten:
  • Dazu unter System->Fehlersuche das Debuglevel auf Details stellen und mindestens zwei komplette Durchläufe von # ***Start*** bis # ***Start*** aus dem Main-Log kopieren, während das Problem auftritt. Sensible Daten wie Benutzernamen und Kennwörter unkenntlich machen.
    Alternativ das Log hier: https://paste.openwb.de/ hochladen und den Link im Thread posten. Die Logs werden dort automatisch nach 90 Tagen gelöscht. Bitte keine gezippten Logfiles hochladen!
  • Logauszüge bitte als Codeblock posten (Schaltfläche "</>" über dem Editor-Fenster).
  • Bei Problemen mit dem internen Ladepunkt zusätzlich einen Auszug aus dem Log des internen Ladepunkts, bei Problemen mit dem Soc aus dem Soc-Log posten.
  • Bei Problemen mit dem UI/Darstellung bitte ein Theme verwenden, das von openWB gepflegt wird (wird bei der Themeauswahl angezeigt).
  • Bei Peaks in den Diagrammen bitte ein Main-Log im Level Details zum fraglichen Zeitpunkt und das Tageslog aus http://<ip der openWB>/openWB/data/daily_log/<JJJJMMDD>.json von dem Tag, an dem Peak aufgetreten ist.
Screenshots ersetzen keinen Logauszug!
Für Beiträge wie "Funktion XY geht nicht mehr! Woran kann das liegen?" ohne Logs gibt es von uns keine Hilfestellung.
ChristophR
Beiträge: 1323
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 72 times
Been thanked: 109 times

Re: Rückmeldungen 2.1.9 Alpha 2

Beitrag von ChristophR »

Wiederanlauf nach Stromausfall.
Ich schreibe das mal hier rein, obwohl ich gerade noch auf dem Release laufe, da es ja hier bearbeitet werden muss.
Versionsstand: 2025-10-16 15:09:42 +0200 [c05a24d66]

Ich hatte heute morgen eine Zählertausch und danach ein gleichzeitiges hochlaufen aller Komponenten, also Switch, FritzBox (DHCP und DNS), SolarEdge, openWB.
Ich nutze DNS-Namen für die Komponenten in der openWB, daher kann es am Anfang natürlich Probleme mit der Namensauflösung gegeben haben, die müssten sich aber nach 2-3 Minuten erledigt haben.
Gegen Mittag habe ich dann gesehen, dass "SolarEdge Zähler" und "Shelly Schuppen Wechselrichter" noch im Fehlerzustand waren:
2025-10-23 20_07_44-Clipboard.png
2025-10-23 20_07_44-Clipboard.png (73.75 KiB) 246 mal betrachtet
Daraus ergeben sich 2 Probleme:
1. Die DNS-Namensauflösung wurde anscheinend nicht erneut versucht, sondern die openWB hat wohl aufgegeben und es nicht wieder versucht.
2. "SolarEdge Wechselrichter" und "SolarEdge Speicher" lieferten korrekte Werte, was nicht sein kann, da es sich um das gleiche Gerät wie "SolarEdge Zähler" handelt.

Leider habe ich das main.log direkt vom Start nicht mehr, das wurde aus unerfindlichen Gründen nicht eingesammelt, ich kann von heute morgen also nur die main.latest-warning.log liefern.
Ab 8:17 Uhr habe ich dann eine main.log, die habe ich auch mal dazugepackt:

main.latest-warning.log (mehrere, bis 8:17 Uhr):
https://paste.openwb.de/JzZHk94wLIZr1wd

main.log:
https://paste.openwb.de/fKyZX8FmW0tnwPd

Überlegungen zu Punkt 2:
Kann es evtl. sein, dass sich in der 2.1.8 eine parallele Modbus-Abfrage der Zählerkomponente eingeschlichen hat, was die Probleme, die SolarEdge momentan eh mit den Modbus-Abfragen in ihrer Firmware hat evtl. verschlimmert?
Anders kann ich mir nicht erklären, warum WR und Speicher Werte liefern, aber der Zähler nicht.
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
ChristophR
Beiträge: 1323
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 72 times
Been thanked: 109 times

Re: Rückmeldungen 2.1.9 Alpha 2

Beitrag von ChristophR »

Zielladen bei absehbarer Nichterreichbarkeit des Ziels.
Wenn das Ziel nicht erreicht wird und daher der Ladestrom erhöht wird wird im Hinweistext nicht mit angegeben, was das Ziel ist.
Das wäre eigentlich auch ganz interessant:
Zielladen mit 16A. Der Ladestrom wurde erhöht, um das Ziel zu erreichen.
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
Benutzeravatar
Thomas aus W
Beiträge: 1061
Registriert: Mi Apr 01, 2020 4:00 pm
Has thanked: 99 times
Been thanked: 41 times

Re: Rückmeldungen 2.1.9 Alpha 2

Beitrag von Thomas aus W »

ChristophR hat geschrieben: Fr Okt 24, 2025 4:00 am Zielladen bei absehbarer Nichterreichbarkeit des Ziels.
Wenn das Ziel nicht erreicht wird und daher der Ladestrom erhöht wird wird im Hinweistext nicht mit angegeben, was das Ziel ist.
Aber das Ziel steht doch schon weiter unten....

bye
TW
gpr
Beiträge: 46
Registriert: Sa Feb 05, 2022 5:54 am
Been thanked: 13 times

Re: Rückmeldungen 2.1.9 Alpha 2

Beitrag von gpr »

aiole hat geschrieben: Fr Okt 24, 2025 6:08 pm Im aktuellen Master kam heute die Umschaltoption, welche sowohl die alte Bedienung - nur persistent - als auch die neue mit Temporäreinstellungen ermöglicht.
Ich führe die Diskussion mal hier weiter. Mir ist der Zusammenhang zu meinem Wunsch, Zielladen einfacher zu benutzen nicht ganz klar. Scheint als wäre das der erste Schritt um die Ziellade-Optionen auf die Hauptseite zu bringen? Oder geht es hier einfach darum die verschiedenen Wünsche zum Thema temporär/persistent im Forum abzubilden?
aiole hat geschrieben: Do Okt 23, 2025 7:45 pm Umsetzung läuft mit hoher Prio, da openWB gute usability wichtig ist.
Dem Willen nach erkenne ich das an. Aber ehrlicherweise würde ich dringend professionelle Beratung/Verstärkung, oder zumindest Schulungen empfehlen.

Wie es sein könnte:
Der Nutzer steht im Zentrum, die Oberfläche wird entlang der Bedürfnisse der verschiedenen User-Gruppen designed. Beispiele:
  • Als Privatnutzer möchte ich ein Ladeziel für mein Fahrzeug morgen Mittag einmalig einstellen => Ich stelle auf Zielladen und habe dann einen einfachen direkten Weg um die benötigen Details zu definieren.
  • Als Privatnutzer möchte ich ein regelmäßiges Ladeziel für mein Fahrzeug jeden Dienstag einstellen => wie vorheriger Punkt, nur dass ich die Details vordefiniert habe weil ich sie häufig benutze (ich erwarte auch dafür nicht, dass ich ins Konfigurationsmenü muss)
  • Als Fuhrparknutzer möchte ich alle meine Fahrzeuge auf PV-Laden stellen => Ich arbeite in einem Fuhrparkmodus und stelle den Lademodus um
Wie es nicht sein sollte:
Es liegt eine technische Umsetzung vor, diese führt für bestimmte Nutzer zu einem nicht erwarteten Verhalten. Andere Nutzer benötigen genau dieses Verhalten, da anderer Usecase. Es wird eine Einstelloption geschaffen, die ich, weil ich hier im Forum mitlese, verstehe nachdem ich den Hilfetext 3x gelesen habe. Andere möglicherweise eher nicht, schon erkennbar an technischen Begriffen wie Persistenz und der Notwendigkeit von Beispielen.

Ähnlich ist es mit der zu Beginn der 2.x viel kritisierten Konfiguration, die stark abstrahiert und dann alle Datenobjekte für den Nutzer exponiert. Ist es richtig, dass ich ein Fahrzeugprofil, und dann ein Fahrzeug konfigurieren kann? Dann noch Lade-Profile? Ein Ladepunktprofil und dann Ladepunkte? Technisch weiß ich das nicht. Möglicherweise braucht es die Abstraktion für bestimmte Use Cases. Was ich aber weiß, ist, dass ich mir bis heute die Beziehungen der Datenobjekte zueinander nicht merken kann und ich das Menü meiner Frau nicht zeigen darf. Die Konfiguration könnte sehr viel einfacher sein, wenn sie auf die einzelnen Nutzergruppen zugeschnitten wäre, nicht auf die technische Umsetzung.
Ich habe zu Beginn meiner Berufslaufbahn Software entwickelt und wenn ich auf die Ergebnisse selbstkritisch zurückblicke, genauso von der Technik her gearbeitet. Es ist vermutlich natürlich für einen Entwickler das zu tun. Nur leider ist das Ergebnis nicht immer natürlich für einen Nutzer, weswegen es Experten für UX gibt.

Ich hoffe, meine Sicht ist fair. Und ich möchte gleichzeitig meinen Respekt für die Entwickler ausdrücken, die sich laufend komplexe Materie erarbeiten und diese beherrschen, sich mit extrem vielen Nutzungsarten, Features, Schnittstellen hervorragend auskennen und ständig viele hilfreiche Verbesserungen bringen und dabei in vielen Fällen auch den User sehr gut mitnehmen.
Zuletzt geändert von gpr am Fr Okt 24, 2025 8:11 pm, insgesamt 1-mal geändert.
aiole
Beiträge: 8560
Registriert: Mo Okt 08, 2018 4:51 pm
Has thanked: 156 times
Been thanked: 163 times

Re: Rückmeldungen 2.1.9 Alpha 2

Beitrag von aiole »

gpr hat geschrieben: Fr Okt 24, 2025 7:42 pm
aiole hat geschrieben: Fr Okt 24, 2025 6:08 pm Im aktuellen Master kam heute die Umschaltoption, welche sowohl die alte Bedienung - nur persistent - als auch die neue mit Temporäreinstellungen ermöglicht.
Ich führe die Diskussion mal hier weiter. Mir ist der Zusammenhang zu meinem Wunsch, Zielladen einfacher zu benutzen nicht ganz klar. Scheint als wäre das der erste Schritt um die Ziellade-Optionen auf die Hauptseite zu bringen? Oder geht es hier einfach darum die verschiedenen Wünsche zum Thema temporär/persistent im Forum abzubilden?
Sowohl als auch.
Dein Wunsch kann wie früher mit der alten Lösung umgesetzt werden oder bei Temporärnutzung wird das Lade-Profil der persistenten Voreinstellung im Ladepunkt temporär editierbar - ohne extra Abstecken.

Für deine Grundsatzdiskussion bitte einen neuen thread aufmachen.
Antworten