Rückmeldungen 2.1.9 Alpha 2/3

[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]

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 (73.75 KiB) 3171 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.

[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.

[Thomas aus W]

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]

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?

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.

[aiole]

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.

[Till]

Guten Abend,

ich hatte gestern und heute einen Fehler im Zusammenhang mit Tibber: Es wurden keine neuen Preise geladen und auf der Status-Seite war ein Fehler gemeldet. Nach einem Neustart über maintenance/systeminfo.html war in beiden Fällen alles sofort wieder ok.

Hier das vollständige Log: https://paste.openwb.de/yJvBtcOIdYPz1IL

Beste Grüße,
Till

[ChristophR]

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.

Ihr müsst bitte aufpassen, dass Ihr das nicht verschlimmbessert:

- Einige wollen gar keine temporären Einstellungen, Check, hiermit erledigt.

- Andere finden die temporären Einstellungen eine Super Idee, wurde ja auch von der Community lange fordert.
Die Änderungen im Ladeprofil werden nun aber nicht mehr in die temporären Einstellungen übernommen, das war eine Zeitlang in der Alpha Phase noch möglich. So bereitet es vielen Probleme. Diese werden nun durch zusätzliche GUI-Programmierungen im Dashboard gelöst, obwohl es nur wieder ermöglicht werden müsste, dass die Änderungen aus den Ladeprofilen einfach wieder übernommen werden. Hier gab es von Dir nur den Hinweis, dass es wohl einen Use-Case dafür gab, warum es geändert wurde, jedoch haben wir im Forum uns diesen dann nur zusammengeraten, statt dass er von Euch direkt kommuniziert wird. Dann wäre bestimmt mehr Verständnis für Eure Umsetzung da und ggf. gibt es dann hier auch neue Ideen, wie man die Problemfälle behandeln könnte. Der Hinweis, dass es dann auch Auswirkungen auf aktuelle Ladevorgänge hat, ist zwar richtig, war aber vorher auch so, warum soll das plötzlich so schlimm sein?
Wenn ich z.B. einen einmaligen Zeitplan anpassen möchte, kann der ruhig für die Zukunft geändert werden, er ist ja eh einmalig und läuft irgendwann ab. Auch andere Änderungen möchte ich häufig generell übernehmen, wenn ich sie im Ladeprofil ändere. Wenn ich aber nur den Lademodus oder andere Einstellungen im Dashboard wechsle soll das nicht persistent sein.
Für mich würde die aktuelle Umsetzung mit einer Zusatzoption "Einstellungen auch temporär übernehmen" passen, der neue Weg über eine neue GUI wird nach meinem Verständnis eher neue Probleme und Unklarheiten bringen.
Was ist z.B. wenn ich ein komplett neues Ziel brauche, während das Auto angesteckt ist? Soll das auch über die neue GUI möglich sein und danach komplett verschwinden? Das finde ich nicht besonders logisch.
Vielleicht sollten wir uns für solche Probleme auch in einer Videokonferenz treffen, um die Probleme besprechen zu können? Da werden zwar auch nicht alle Zeit haben, aber ich halte das für einen effizienten Weg die "Uservoices" einzusammeln, bevor Ihr Euch an eine neue Umsetzung macht ohne dass wir die mit Euch diskutieren können.

Andere Themen, die dringend in der 2.1.9 gelöst werden sollten, aber nicht direkt zu o.g. Themenbereich gehören:

Die Idee, dass bereits erreichte Ziele beim Zielladen weiter aktiv bleiben, sollte dringend wieder abgeschaltet werden, ich hatte es vor dem Release bereits angebracht, wurde von Euch aber leider anders entschieden. (Aus meiner Sicht falsch und dazu gab es nun schon mehrere Meldungen).
Auch hier habe ich nach einem Use-Case gefragt, wann dies denn von Vorteil sein sollte, den habe ich nicht verstanden, da er mit dem nächsten Ladeziel genauso erfüllt würde.
Der Hinweis, es wäre für den Support einfacher, sehe ich völlig anders, da so bei identischen Einstellungen je nach Ansteckzeitpunkt unterschiedliche Ziele aktiv sein können, das versteht doch wieder keiner.
viewtopic.php?p=134917#p134917
Wenn das nicht mehr so wäre, würde auch mein anderes geschildertes Problem, dass plötzlich losgeladen wird, wenn ich ein Ziel aktiviere, nur weil das Auto schon länger angesteckt war, auch erledigt:
viewtopic.php?p=134498#p134498

Wenn mehrere Ziele den gleichen Zielzeitpunkt haben, wird nicht mehr der Plan mit dem höchsten Ziel-SoC gewählt, sonder zufällig einer. Das ist eher ein Fehler und daher keine Grundsatzdiskussion:

Ein weiteres Problem, was ich gestern Abend festgestellt habe:
Ich habe (wiederum meinen täglichen Zeitplan 07:00 Uhr 85%) aktiviert und mich gewundert, dass die Zeit, wann die Ladung beginnen soll, nicht angepasst wurde.
Ich habe einen weiteren Zeitplan aktiv, der einen Zielzeitpunkt auch heute um 7:00 Uhr (65%) hatte.
Je nachdem, in welcher Reihenfolge die aktiviert wurden, wird der Zeitpunkt angepasst.
Ich habe dann die falsche Reihenfolge aktiv gelassen, um es auszuprobieren und es wird wirklich nur zu dem geringeren SoC geladen.
Früher war es so, dass bei gleichzeitigen Zeitplänen korrekt der mit dem höheren SoC ausgerechnet wurde.
Ich bin zwar gerade auf dem mem-Branch (2025-10-14 09:33:01 +0200 [1b3335af8]), vermute aber, dass sich daran noch nichts geändert hat.
https://paste.openwb.de/kqIjcm7wY91YLtc

[aiole]

Ihr müsst bitte aufpassen, dass Ihr das nicht verschlimmbessert:

- Einige wollen gar keine temporären Einstellungen, Check, hiermit erledigt.

- Andere finden die temporären Einstellungen eine Super Idee, wurde ja auch von der Community lange fordert.
Die Änderungen im Ladeprofil werden nun aber nicht mehr in die temporären Einstellungen übernommen, das war eine Zeitlang in der Alpha Phase noch möglich. So bereitet es vielen Probleme. Diese werden nun durch zusätzliche GUI-Programmierungen im Dashboard gelöst, obwohl es nur wieder ermöglicht werden müsste, dass die Änderungen aus den Ladeprofilen einfach wieder übernommen werden. Hier gab es von Dir nur den Hinweis, dass es wohl einen Use-Case dafür gab, warum es geändert wurde, jedoch haben wir im Forum uns diesen dann nur zusammengeraten, statt dass er von Euch direkt kommuniziert wird. Dann wäre bestimmt mehr Verständnis für Eure Umsetzung da und ggf. gibt es dann hier auch neue Ideen, wie man die Problemfälle behandeln könnte. Der Hinweis, dass es dann auch Auswirkungen auf aktuelle Ladevorgänge hat, ist zwar richtig, war aber vorher auch so, warum soll das plötzlich so schlimm sein?

WEG und Ladeparks sind im Kommen und es werden schon etliche mit openWB betrieben. Gepaart mit der anstehenden Nutzerverwaltung kann man die überscheibenden Auswirkungen auf den use case aktuell laufender Ladungen (auch wenn sie bis dato so waren) leider nicht ignorieren.

Beim neuen Schalter ist erstmal klar, dass man damit
a) konservative Bestandsnutzer:innen
und
b) die Techies
abholt.

Wenn ich z.B. einen einmaligen Zeitplan anpassen möchte, kann der ruhig für die Zukunft geändert werden, er ist ja eh einmalig und läuft irgendwann ab. Auch andere Änderungen möchte ich häufig generell übernehmen, wenn ich sie im Ladeprofil ändere. Wenn ich aber nur den Lademodus oder andere Einstellungen im Dashboard wechsle soll das nicht persistent sein.

ok - also passend zu b):
Ladepläne erstmal außen vor, sollte die Temporärbedienung alle verbleibenden Elemente beinhalten.

Für mich würde die aktuelle Umsetzung mit einer Zusatzoption "Einstellungen auch temporär übernehmen" passen, ...

Sprich als Ersatz für Abstecken?

... der neue Weg über eine neue GUI wird nach meinem Verständnis eher neue Probleme und Unklarheiten bringen.
Was ist z.B. wenn ich ein komplett neues Ziel brauche, während das Auto angesteckt ist? Soll das auch über die neue GUI möglich sein und danach komplett verschwinden? Das finde ich nicht besonders logisch.

Das ist in der Tat ein use case, der unschön wäre, da er erst nach Abstecken temporär auf der main verfügbar und editierbar wäre. Allerdings konfiguriert man in der Praxis seine 3...5 Ladepläne mit seinen Vorlieben und könnte sie nach jetzt geplantem Modell temp. leicht anpassen, da vorn auf der main verfügbar. Aus usability-Gründen ist genau diese main-Einstellung top - insbesondere bei Koala -, da ohne viel Klicken erreichbar Zum Lade-Profil ist es deutlich aufwendiger.

Vielleicht sollten wir uns für solche Probleme auch in einer Videokonferenz treffen, um die Probleme besprechen zu können? Da werden zwar auch nicht alle Zeit haben, aber ich halte das für einen effizienten Weg die "Uservoices" einzusammeln, bevor Ihr Euch an eine neue Umsetzung macht ohne dass wir die mit Euch diskutieren können.

Man ist schon dabei, weil ja einmaliges Zielladen betroffen ist.
Mit temp. Bedienung = nein hat man zunächst die temp. Bedienung optional eingebaut, was ein Mehrwert ist. Jetzt ist noch Optimierung bei temp. Bedienung = ja angesagt.
Bedenke aber die WEG/Ladeparks.

Deine anderen Punkte sollten NACH obigem Thema in der Tat in 2.1.9 behandelt werden. Gut, dass du nochmal die links rausgesucht hast. Danke!

[ChristophR]

WEG und Ladeparks sind im Kommen und es werden schon etliche mit openWB betrieben. Gepaart mit der anstehenden Nutzerverwaltung kann man die überscheibenden Auswirkungen auf den use case aktuell laufender Ladungen (auch wenn sie bis dato so waren) leider nicht ignorieren.

Wenn ich z.B. einen einmaligen Zeitplan anpassen möchte, kann der ruhig für die Zukunft geändert werden, er ist ja eh einmalig und läuft irgendwann ab. Auch andere Änderungen möchte ich häufig generell übernehmen, wenn ich sie im Ladeprofil ändere. Wenn ich aber nur den Lademodus oder andere Einstellungen im Dashboard wechsle soll das nicht persistent sein.

ok - also passend zu b):
Ladepläne erstmal außen vor, sollte die Temporärbedienung alle verbleibenden Elemente beinhalten.

Für mich würde die aktuelle Umsetzung mit einer Zusatzoption "Einstellungen auch temporär übernehmen" passen, ...

Sprich als Ersatz für Abstecken?

Es muss ja gar keine neue Einstellung sein, ja das mit dem Abstecken darf keine Voraussetzung für die Übernahme von Einstellungen sein.
Wie wäre es, wenn Ihr nochmal im Ladeprofil über meinen Vorschlag eines alternativen "Speichern+Übernehmen" Buttons nachdenkt, der die Einstellungen im Ladeprofil speichert und in die temporären Einstellungen übernimmt?
Das kann dann gerne alles sein, damit man da nicht wieder Verwirrung stiftet, wenn jemand dann erwartet, dass es alles übernimmt.
Dann spart man sich die Arbeit der geteilten Einstellungen, weil es mit der 2. GUI für die temporären Einstellungen vermutlich auch keinen Sinn mehr macht, das zu trennen.
Dieser Button müsste in der zukünftigen Benutzerverwaltung in WEGs und Ladeparks entsprechend "verrechtet" werden, dass das normale Nutzer nicht haben/können.
Die sollen evtl. in diesen Szenarien ja auch keine neuen Zielpläne anlegen dürfen, die persistent sind?

... der neue Weg über eine neue GUI wird nach meinem Verständnis eher neue Probleme und Unklarheiten bringen.
Was ist z.B. wenn ich ein komplett neues Ziel brauche, während das Auto angesteckt ist? Soll das auch über die neue GUI möglich sein und danach komplett verschwinden? Das finde ich nicht besonders logisch.

Das ist in der Tat ein use case, der unschön wäre, da er erst nach Abstecken temporär auf der main verfügbar und editierbar wäre. Allerdings konfiguriert man in der Praxis seine 3...5 Ladepläne mit seinen Vorlieben und könnte sie nach jetzt geplantem Modell temp. leicht anpassen, da vorn auf der main verfügbar. Aus usability-Gründen ist genau diese main-Einstellung top - insbesondere bei Koala -, da ohne viel Klicken erreichbar Zum Lade-Profil ist es deutlich aufwendiger.

Ladepläne nicht, Zielpläne schon.
Auch dieses Problem wäre mit o.g. Speichern+Übernehmen gelöst, man muss dann halt in die Ladeprofile, um das zu erledigen.
In der temp. Main-GUI wird es dann ggf. gar nicht die Möglichkeit geben neue Zielpläne anzulegen, oder sie verschwinden nach dem Abstecken halt wirklich.
User machen aber halt nicht immer das, was man sich so ausdenkt...

Vielleicht sollten wir uns für solche Probleme auch in einer Videokonferenz treffen, um die Probleme besprechen zu können? Da werden zwar auch nicht alle Zeit haben, aber ich halte das für einen effizienten Weg die "Uservoices" einzusammeln, bevor Ihr Euch an eine neue Umsetzung macht ohne dass wir die mit Euch diskutieren können.

Man ist schon dabei, weil ja einmaliges Zielladen betroffen ist.
Mit temp. Bedienung = nein hat man zunächst die temp. Bedienung optional eingebaut, was ein Mehrwert ist. Jetzt ist noch Optimierung bei temp. Bedienung = ja angesagt.
Bedenke aber die WEG/Ladeparks.

Das dachte ich mir schon.
Um so wichtiger ist es, die aktuell geplante Umstellung hier im Forum schonmal zu kommunizieren, gerne jeweils in einem eigenen Thread, da es ja noch kein Feedback dazu geben kann.
Das sollte aber von Euch mit der geplanten Umsetzung gestartet werden, damit wir unseren Senf dazu geben können.
Wenn man die anderen Use-Cases kennt, kann man die ja mitdenken.
Wer nur seine persönliche Sicht sieht, hat dann die Möglichkeit die Hintergründe für eine Umsetzung zu verstehen, das bringt evtl. mehr Verständnis.

P.S: Die Diskussion läuft nun hier weiter:
viewtopic.php?t=11388