openWB Forum

Hauptsache einheitlich, wie genau ist mir eigentlich egal, solange die ersten 15 Zeichen eindeutig unterscheidbar sind. Ändern muss ich meine ganzen Logiken jetzt eh nochmal, aber dann hoffentlich zum letzten mal.

noch eine Ergänzung: ich fände die kurzen neuen Definitionen besser, da die alten längeren mit _charging im Zusammenhang mit KNX eh immer Probleme aufgrund der Länge gemacht haben (in einem String KNX Kommunikationsobjekt werden nur die ersten 14 oder 15 Zeichen übertragen...)

Vielen Dank für die ganzen Anpassungen an der simpleAPI! Das wird nun schon ganz gut.

Allerdings gibt es einen Punkt der mir gerade noch die Nutzung sehr schwer macht:

beim Schreiben des Chargemode ist folgende Definition der Lademodi gegeben:
set_chargemode instant, pv, eco, stop, target

Beim ...

ich rede im Prinzip von beiden... siehe meine EDIT Einträge. Da hab ich die topics noch ergänzt die ich meine (ja, das sind die Status topics, zum setzen gibt es ja noch diesselben mit /set/ dazwischen...) Aber ich kann auch damit leben die vorhandenen "internen" zu nutzen, das funktioniert auch ...

Hab mich jetzt mal intensiver noch mit der neuen 2.1.9 beschäftigt und da scheint ja jetzt auch die lange gewünschte Hysterese für den min_soc_bat_mode umgesetzt zu sein. Es ist jetzt zwar nicht als direkte Hysterese Offset zum bisherigen SoC umgesetzt (den hätte ich pauschal mit z.B. 5% fest belegt ...

Die ID ist auf der Status Seite im webinterface einsehbar.
Ich halte das so für zumutbar, ihr?


Ah, ja das ist auch eine gute Idee! Fände ich auch ok, wenn man das im Wiki für die simpleAPI entsprechend gut dokumentiert und beschreibt wie man an die ID Nummer einfach ran kommt! Sind nur 3 ...

Ich befürchte du bist auf ein alter version. Im Thread wurde erörtert das das aufgesplitterte Charge_template zu komplex ist.
Daher wurde das entfernt und per Cherry Pick nur einzelne Werte übernommen.
Dabei hat in der Tat min_current und einige andere bisher gefehlt.
Den PR dafür habe ich soeben ...

und wenn ich mir das Gesamtbild ansehe würde ich gleich noch einen Schritt weiter gehen um den Supportaufwand und auch Pflegeaufwand in der Entwicklung weiter zu reduzieren:

Ich würde nur noch die neue simpleAPI Standardmäßig ausgeben, die interne Struktur würde ich nur in einem in den ...

Hier kann ich dir nicht folgen.
Wenn es jeweils mehr als eins gibt willst die IDs unbedingt haben. Davor ist es optional.


Betrachte es anders rum: Wenn jemand mehr wie ein Ladepunkt hat, bekommt er leider immer einen Ladespunkt mehr angezeigt und hat diese unnötige Zwischenstruktur mit get/set ...

Oder ist das wirklich so gedacht und auch sichergestellt daß auch immer der aktuelle Status (egal ob über Webinterface oder externe Steuerung) immer auch das SET topic

openWB/simpleAPI/set/chargepoint/4/minimal_permanent_current

den aktuellen Status beinhaltet? Wäre zumindest ein Logikbruch im ...