Ich hätte gerne 80%=80%

[therobbot]

Nachtrag: ich habe noch ein bisschen rumprobiert: Anscheinend wird in der App dann tatsächlich der gerundete Wert angezeigt. Verwirrend, aber damit kann ich leben. Allerdings habe ich trotzdem noch keine Möglichkeit gefunden, den SOC für das Nachtladen über MQTT zu setzen, nur für PV-Laden und Sofortladen. Und gerade das Nachtladen wäre das relevante. Die anderen würde ich einfach auf 75 setzen, aber beim Nachtladen würde ich dann gerne 79 einstellen, um 80% zu garantieren.

[therobbot]

Gibt es denn eine Möglichkeit, die Slider für die Lademengenbegrenzung so zu ändern, dass nicht nur 5%-Schritte möglich sind? Durch den 80%!=80%-Bug und die 5%-Schritte vom E-Up ist das sonst schon alles irgendwie unschön... ich würde gerne auf 79% stellen.

Aus Bediengründen speziell am SmartPhone gibt es nur die 5% Schritte.
Du kannst per MQTT aber durchaus in 1% Schritten den Wunschwert senden.

Das scheint aber nicht für den Ziel-SOC beim Nachtladen zu gelten, richtig? Wie bekomme ich den denn auf 79%? Beim Sofortladen stoppt die Ladung bei mir interessanterweise korrekt bei 80%, wenn ich 80% einstelle, beim Nachtladen aber nicht.

[hhoefling]

Das Sofortladenmodule hat mehre stellen an denen mit SOC verglichen wird,
Bei zwei stellen wird dort schon korrekt abgeschaltet (mit >=, also nix mit Balancing)
Bei den anderen steht ebenfalls ">" wie beim Nachladen
Ich durchaue noch nicht unter welchen Bedingungen welche Variante wirkt.

[therobbot]

Also zusammengefasst:

Je nach Lademodus ist 80%=80% oder 80%<80%. Das zweite Verhalten ist angeblich kein Bug, sondern ein Feature, was dann aber hieße, dass das momentane Verhalten im Sofortlademodus ein Bug ist. 79% kann man nur über MQTT einstellen, was aber wiederum nicht für alle relevanten SOC-Grenzen funktioniert (Nachtladen!). Ich hoffe wirklich, dass hier eine bessere Lösung seitens des Herstellers kommt oder dass zumindest dieses Verhalten in der 2.0-Version besser gelöst sein wird.

[aiole]

Gewachsener code hat manchmal solche Inkonsistenzen. Überbewerten würde ich diese hier bei den Minimalabweichungen aber nicht, zumal der SoC auch nicht in Stein gemeißelt ist. Wird es nachts z.B. kälter, kann er auch mal ohne Zutun 3% sinken.
Ich bin auch Fan von gleichen Strukturen, wo es sich anbietet. Im v2.x-Re-write wird das hoffentlich eindeutig gelöst.

[therobbot]

Das mit dem gewachsenen Code ist mir schon klar. Ich habe selber mal hauptberuflich Software entwickelt. Was mich etwas stört ist, dass es teils so kommuniziert wird, als ob das alles keine Probleme wären. Mit "momentan ist für Support von so was keine Zeit, weil wir mit Hochdruck an 2.0 arbeiten, wo das gelöst sein wird" kann ich eher leben.

Im Grunde würde ich einfach am liebsten die Software selber kompilieren und anpassen, was ich anders will, aber das beißt sich vermutlich mit der Gewährleistung, oder? Ich denke schon darüber nach, auf EVCC umzusteigen und die Openwb nur als Ladepunkt zu betreiben. Dann könnte ich mir die Software nach belieben anpassen. Aber eigentlich hatten wir extra mehr Geld ausgegeben, um ein System aus einem Guss zu haben. Vielleicht war das ein Fehler.

Klar sind es keine großen Sachen, aber in Kombination mit den 5% Sprüngen bei VW sind es halt 4-5% Abweichung.

[aiole]

..., dass es teils so kommuniziert wird, als ob das alles keine Probleme wären.

Ersetze "keine" durch "kleine"

Im Grunde würde ich einfach am liebsten die Software selber kompilieren und anpassen, was ich anders will, aber das beißt sich vermutlich mit der Gewährleistung, oder?

Freischaltung beim Support beantragen -> Gewährleistungsentfall für die SW -> fertig

Ich denke schon darüber nach, auf EVCC umzusteigen und die Openwb nur als Ladepunkt zu betreiben. Dann könnte ich mir die Software nach belieben anpassen. Aber eigentlich hatten wir extra mehr Geld ausgegeben, um ein System aus einem Guss zu haben. Vielleicht war das ein Fehler.

Das kommt immer auf den Anwender an.
Stelle Dir z.B. einen Solarteur vor, der ein EMS beim Kunden installieren soll. Dieser braucht ein einfach einzustellendes System und professionelle Unterstützung, wenn etwas gar nicht läuft.
Gleiches gilt für die Mehrzahl der Anwender hier bei openWB. Die wenigsten können selbst coden.
Es hindert niemand die Profis daran, auf ein anderes System umzusteigen. Bist dann halt nicht mehr bei v2.x dabei, was schon einen ordentliche step darstellen wird. Dort wird es anfangs sicher auch Bugs geben, aber die Weichen sind gestellt, um 3 Jahre oWB-Erfahrungswerte in eine neue SW zu gießen.

Klar sind es keine großen Sachen, aber in Kombination mit den 5% Sprüngen bei VW sind es halt 4-5% Abweichung.

Nun lass mal die Kirche im Dorf. Du konzentrierst Dich hier auf EIN Problem(chen) und übersiehst, was die SW als Ganzes zu leisten im Stande ist. Ich würde sie zumindest erst einmal ausgiebig praktisch nutzen und danach entscheiden.
Mit v2.x gibt es sicher auch wieder Bedarf an code-Zuarbeiten für weitere Verbesserungen, falls Du mithelfen möchtest.

[mrinas]

Das mit dem gewachsenen Code ist mir schon klar. Ich habe selber mal hauptberuflich Software entwickelt. Was mich etwas stört ist, dass es teils so kommuniziert wird, als ob das alles keine Probleme wären. Mit "momentan ist für Support von so was keine Zeit, weil wir mit Hochdruck an 2.0 arbeiten, wo das gelöst sein wird" kann ich eher leben.

Im Grunde würde ich einfach am liebsten die Software selber kompilieren und anpassen, was ich anders will, aber das beißt sich vermutlich mit der Gewährleistung, oder? Ich denke schon darüber nach, auf EVCC umzusteigen und die Openwb nur als Ladepunkt zu betreiben. Dann könnte ich mir die Software nach belieben anpassen. Aber eigentlich hatten wir extra mehr Geld ausgegeben, um ein System aus einem Guss zu haben. Vielleicht war das ein Fehler.

Klar sind es keine großen Sachen, aber in Kombination mit den 5% Sprüngen bei VW sind es halt 4-5% Abweichung.

das sollte in der Tat kein PRoblem sein, ist ja 'nicht mal' kompilierter Code sonder vorallem scripte & co, liegen alle auf GitHub. Mit der Freischaltung des SSH Zugangs auf die Box über den Support hat man dann alle Möglichkeiten.

[therobbot]

Was heißt Gewährleistung für die Software? Kaputtgehen kann ja eigentlich nur die Hardware. Ist die dann weiterhin abgedeckt? Oder geht es um Haftung bei Schäden am EV und der Hardware, die durch Software verursacht wurden? Wer muss das dann nachweisen? Da wäre halt eine klare Trennung schön, daher der Gedanke mit EVCC.

Nein, es ist ja nicht nur diese eine Sache, sondern viele kleine Dinge, die ich gerne anders hätte. Dass ich da eher ein Spezialfall bin, ist mir schon klar.

[mrinas]

Was heißt Gewährleistung für die Software?

Nach meinem Verständnis geht es hier vorallem um die (kostenfreie) Nutzung des Support. Wenn man selbst SSH Zugang hat, rumfrickelt, und den Support bemüht wird, kann der Aufwand in Rechnung gestellt werden. Was ich vollkommen fair und nachvollziebar finde.

Ein klarer Hardwaredefekt wird hier sicher nicht verwehrt, wurde in einem anderen Thread schon mal klargestellt.