openWB Forum

Seit FW40.0 hat die API des go-e Chargers offenbar einen neuen Befehl zum Setzten des Ladestroms speziell bei Überschussregelung
(https://www.goingelectric.de/forum/view ... start=3090)

"Es gibt nun auch in der normalen HTTP bzw. MQTT api einen neuen Befehl:

amx

z.B. amx=16
Dieser setzt den Ladestrom auf einen anderen Wert, ohne dass dieser permanent im EEPROM gespeichert wird. Nach einem Neustart der Ladebox ist der Ampere Wert wieder auf dem zuletzt mit amp= gesetzten Wert. Das ist besonders für Energiemanagement praktisch, wo man nicht permanent den Ladestrom verstellen möchte, und auch die Anzahl der Schreibzyklen auf den Flash Speicher limitieren möchte.

Vielleicht will einer der Entwickler im go-e Modul ein p durch ein x ersetzen um den EEPROM zu schonen.

Ein Hauch mehr gehört schon dazu - zumindest bis alle Go-e ein Update erhalten haben. Sonst gehen die alten nicht mehr.

War mit einem zwinkernden Auge gemeint

Laut API Doku gibt der Parameter 'fwv' die Firmware-Version zurück, also sollte zB eine Verzweigung der Art
Wenn Firmware >=40
benutze amx
else
benutze amp

möglich sein?

Klar, das Ganze dann noch in effizient, failsafe und zuverlässig; es hängt natürlich immer etwas mehr dran als man schnell daher sagt.
In erster Linie ging es mir um die Mitteilung dass es einen neuen und ggf. für die Implementierung in openWB sinnvollen go-e API Befehl gibt.

liZErd hat geschrieben: ↑Di Okt 20, 2020 5:40 pm Laut API Doku gibt der Parameter 'fwv' die Firmware-Version zurück, also sollte zB eine Verzweigung der Art
Wenn Firmware >=40
benutze amx
else
benutze amp

Hallo liZErd

Ja, das sehe ich auch so. Ich habe die Änderungen des Parameters AMP bei mir mal über mein KNX System/die ETS5 beobachtet. Bei mir wäre die maximale Schreibzyklenzahl hochgerechnet nach weniger als einem Jahr erreicht. Das mag in der Praxis ja etwas länger halten, aber ich halte das für bedenklich.
Sollte der Fall eintreten, dass die Zelle totgeschrieben wurde, weiß ich bisher nicht, was dann passiert.
Ich habe auch bisher nicht gefunden, wie die openWB Software den AMP überhaupt sendet. Im modules Ordner gibt es zwar drei Unterordner, goelp1 bis ~3, für drei Ladepunkte mit go.e, aber darin enthalten ist jeweils nur ein Shell Script, was ausschließlich den go.e Status ausliest und einige Werte in die Ramdisk schreibt.

Wo das Schreiben erledigt wird, weiß ich (noch) nicht.

Aber viel interessanter ist, ob es den AMX tatsächlich gibt. Ich habe die 040 drauf und da sieht man in der Statusausgabe keinen AMX. Weder über die http Abfrage, noch über MQTT (ist der selbe json String). Mag sein, dass der Wert nur geschrieben werden kann. Das wäre aber unschön, denn dann könnte man den aktuellen Wert nicht auslesen und anzeigen. Wäre aber zu Verschmerzen. Die openWB zeigt eh nur den AMP Wert an, den sie selber setzt, und nicht den AMP, der vom e.go im Status kommt. Drum passen die Werte Ladeleistung und Ladestrom auch häufig nicht zusammen, weil die geänderte Leistung beim Verstellen des AMP erst im nächsten Update-Zyklus angezeigt wird und da wurde häufig schon wieder ein neuer AMP Wert gesendet. Das passt eigentlich nur, wenn der Wert längere Zeit konstant bleibt.

DWS ist auch so ein Parameter über den man nachdenken sollte. Liefert wesentlich genauer die geladene Energiemenge als es in der openWB gezeigt wird (immer nur volle kWh).

Schön dass doch noch jemand auf diesen Zug aufspringt!

Denke auch hier wäre Umsetzungs-/Optimierungspotential. Gerade wenn weiß dass der amp Befehl den Speicher "kaputtschreibt" und es aber Abhilfe gibt wäre es fahrlässig, hier gar nicht zu reagieren (Stichwort Nachhaltigkeit).
Verstehe aber natürlich auch, dass es für das oWB Team nicht No. 1 Prio ist, ein Drittgerät "schonender" zu betreiben, allerdings gibt es doch einige die oWB in Kombination mit der go-e nutzen (es gibt auch eine "offizielle" Kooperation zwischen den Unternehmen soweit ich weiß), also wäre die Reichweite dieser Anpassung doch relativ groß.

Warum sollte es den AMX Befehl nicht auch tatsächlich geben, zumindest in der API Dokumentation ist er beschrieben soweit ich weiß. Der Energiemengenparameter DWS ist auch Interessant, das wusste ich bisher nicht. Damit ließe sich der Darstellungsbug in den Diagrammen auch beseitigen. Vielleicht solltest du dazu ein neues Thema/feature request aufmachen.

Ich nutze den dws Wert in iobroker und lasse mir per Telegram am Ende der Ladung auf 3 Stellen den kWh Wert schicken. So kann ich am PC von Telegram das gleich in eine Tabelle integrieren.

liZErd hat geschrieben: ↑Di Feb 23, 2021 5:10 pm Schön dass doch noch jemand auf diesen Zug aufspringt!

Denke auch hier wäre Umsetzungs-/Optimierungspotential. Gerade wenn weiß dass der amp Befehl den Speicher "kaputtschreibt" und es aber Abhilfe gibt wäre es fahrlässig, hier gar nicht zu reagieren (Stichwort Nachhaltigkeit).
Verstehe aber natürlich auch, dass es für das oWB Team nicht No. 1 Prio ist, ein Drittgerät "schonender" zu betreiben, allerdings gibt es doch einige die oWB in Kombination mit der go-e nutzen (es gibt auch eine "offizielle" Kooperation zwischen den Unternehmen soweit ich weiß), also wäre die Reichweite dieser Anpassung doch relativ groß.

Warum sollte es den AMX Befehl nicht auch tatsächlich geben, zumindest in der API Dokumentation ist er beschrieben soweit ich weiß. Der Energiemengenparameter DWS ist auch Interessant, das wusste ich bisher nicht. Damit ließe sich der Darstellungsbug in den Diagrammen auch beseitigen. Vielleicht solltest du dazu ein neues Thema/feature request aufmachen.

Es gibt Fälle wo es unklar ist. Daher muss man alles abwägen und auch den Bestand weiterhin unterstützen.

Die openWB bzw. Das Logging baut nunmal auf Zählerständen auf die absolut sind und nicht Deltas. Bis auf die goe klappt das auch überall einwandfrei.
Sehe die +-1 kWh bei der goe aber ohnehin unkritisch aufgrund ihrer Ungenauigkeit.

Hallo zusammen,

bin neu und warte sehnsüchtig auf meine openWB, die ich mit der go-e betreiben möchte. Die go-e habe ich schon erhalten. Daher unterstütze ich den Ansatz die Anbindung der go-e zu optimieren und die Fehler in der Darstellung zu lösen. Ich bin davon ausgegangen, dass die openWB die go-e problemlos unterstützt und nicht den Speicher überlaufen lässt oder es fehlerhafte Darstellungen in den Auswertungen gibt. Das war meine Kaufentscheidung für die beiden Produkte.

Go-e (und weitere) sind andere Hersteller als oWB. Auf Nummer sicher geht man nur, wenn man oWB-HW kauft.

Des Weiteren hängt es von der Zusammenarbeit mit den Fremdherstellern ab.
SmartWB hat sich z.B. von Anfang an auf die Fahnen geschrieben, ein solider Partner für oWB zu sein. Wir unterstützen uns gegenseitig, weshalb dort ein hohes Maß an Feature-Nutzung ermöglicht wird. Das bekommt man dann zwar nicht ganz zum Ultra-Tiefstpreis, hat aber langfristig Produktsicherheit Dank interagierender Softwarepflege.

aktuelles Bsp: viewtopic.php?p=25872#p25872
Go-e hat keine CP-Unterbrechung in Hardware.

Hi,

gibt es Neuigkeiten bzgl. der Schreibzyklen-Thematik beim Go-E?

Es wäre schade wenn man den zweiten LP durch die Steuerung durch die OpenWB vorschnell "altern" lässt und somit Schaden anrichtet.

Gruß