go-e Charger WallBox über HTTPMOD

[Prof. Dr. Peter Henning]

So, ich habe das jetzt mal getestet. Wenn man eine REST-Nachricht (also einfach den Webseitenaufruf...)

Code Auswählen Erweitern

http://192.168.0.211/api/set?ids={"pGrid":1280.,"pPv":140.,"pAkku":0.}an die Wallbox sendet, werden die keys

inva   1211501403
pgrid   1280
ppv   140
pakku   0
pvopt_averagePGrid   0
pvopt_averagePPv   0
pvopt_averagePAkku   0

im Status befüllt - aber nur für wenige Sekunden (7-8 habe ich gemessen).
Danach steht darin wieder

Code Auswählen Erweitern


lpsc null
inva 1211501403
pgrid null
ppv null
pakku null
pvopt_averagePGrid 0
pvopt_averagePPv 0
pvopt_averagePAkku 0Mit anderen Worten: die WallBox verlangt, um die internen Algorithmen zum Überschussladen zu verwenden, wirklich alle 5 Sekunden neue Datenwerte.

Langfristig will ich stattdessen meine eigene KI dafür einsetzen. Aber kurzfristig heißt das: Beim Überschussladen müssen alle 5 Sekunden die Datenwerte übermittelt werden. Dafür sehe ich mehrere Möglichkeiten

• In dem existierenden HTTPMOD-Device einen neuen Set-Befehl zu definieren, der zyklisch ausgeführt wird. Ungünstig, weil die Response - die eigentlich nur ein "true" ist - durch alle definierten Filter für die Readings gejagt wird.
• Ein zweites HTTPMOD-Device, das nur die Aufgabe hat, diesen speziellen Request abzusetzen. Und nur ein Reading kennt, nämlich mitteilt, ob die WallBox das geschluckt hat.
• Ein kleines Perl-Code-Snippet in meinen 99_EnergyUtils, das alle 5 Sekunden von einem "at" aufgerufen wird und die Daten übermittelt.
• Ein Shell-Script außerhalb von FHEM, das zyklisch alle 5 Sekunden ausgeführt wird.

Ich habe derzeit noch keine Vorstellung, welches der effizienteste Weg ist. Ich werde das mal mit der Option 3 anfangen.

LG

pah

[Prof. Dr. Peter Henning]

Geht, keine Last feststellbar.

Code Auswählen Erweitern

defmod WallyFiller at +*00:00:05 {GoEC_setPvSPData()}
attr WallyFiller group energyControl
attr WallyFiller room Energie
Und als Perl-Programm:

Code Auswählen Erweitern

sub GoEC_setPvSPData() {
my $uri             = sprintf("http://192.168.0.211/api/set?ids={%%22pGrid%%22:%.0f,%%22pPv%%22:%.0f,%%22pAkku%%22:%.0f}",
  ReadingsVal("E.Verb","power",0.0)*1000,ReadingsVal("nt5000","Pac",0.0)*1000,0.0);

    HttpUtils_NonblockingGet(
        {
            url         => $uri,
            timeout     => 5,
            method      => 'GET',
            doTrigger   => 1,
        }
    );
}
Wobei natürlich die 0 als dritter Parameter noch durch das Reading von Speicher ersetzt werden muss. Wenn ich ihn denn habe...

Großer Vorteil auf diese Weise: Das at kann problemlos deaktiviert werden, wenn kein Auto dran hängt.

LG

pah

[DocCyber]

Macht es dem Auto-Akku was aus, wenn man z.B. den Ladestrom minütlich anpassen würde?

Ich verwende schon seit etwa 2 Jahren eine überschuss-gesteuerte Ladestromkontrolle für meinen Zoe mit einem Mindestintervall von 30 Sekunden.
Anfangs hatte ich mir auch die selben Gedanken gemacht, wie du jetzt.
Ein guter Bekannnter und Mitarbeiter der TH Aachen, der sich genau mit solchen Themen beschäftigt, sieht das unkritisch.
Und wenn ich berücksichtige, dass das Fahrzeug durch die Rekuperation ständig lädt und entlädt, bin ich mittlerweile recht entspannt.

[DocCyber]

Beim Überschussladen müssen alle 5 Sekunden die Datenwerte übermittelt werden.
...
Ein kleines Perl-Code-Snippet, das alle 5 Sekunden von einem "at" aufgerufen wird und die Daten übermittelt.
...

Guter Vorschlag!
Muss ich ausprobieren.

[DocCyber]

Die beste Lösung wäre, eine Variante des HTTPMOD Device für API 1.0 und 1.5 zu produzieren.

Da hast du wahrscheinlich Recht.

Für alle jene, die noch eine ältere Go-E-Box haben, möchte ich daher an zwei Beispielen kurz auf die wesentlichen Unterschiede hinweisen (Bei mir heißt das Wallbox-Device schlicht goe):

Code Auswählen Erweitern

# Beispiel 1 für get: Es muss OHNE /api erfolgen
attr goe get01URL http://192.168.xxx.yyy/status?filter=alw,car,err,tma

# Beispiel 2 für set: Es muss OHNE /api, dafür aber mit /mqtt?payload=key=value erfolgen
attr goe set01URL http://192.168.xxx.yyy/mqtt?payload=alw=$val
Davon abgesehen gibt es wesentlich weniger Keys.

[Prof. Dr. Peter Henning]

Erstmal betreffend die Readings beim Überschussladen: Die alle 5 Sekunden upgedateten Werte pgri, ppv und pakku braucht man natürlich nicht auszulesen, die kommen ja aus FHEM. Die Durchschnittswerte werden natürlich nur während des Überschussladens aktualisiert, die habe ich jetzt noch mit

Code Auswählen Erweitern

attr Wally_c reading23Name power_grid_av
attr Wally_c reading23JSON pvopt_averagePGrid 
attr Wally_c reading23OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
attr Wally_c reading24Name power_pv_av
attr Wally_c reading24JSON pvopt_averagePPv 
attr Wally_c reading24OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
attr Wally_c reading25Name power_battery_av
attr Wally_c reading25JSON pvopt_averagePAkku
attr Wally_c reading25OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"in die Readings eingefügt.

Betreffend die Keys, die ich jetzt verwendet habe: Anbei eine Auflistung, welche die API-Dokumentation in die FHEM-Readings übersetzt. Diese Werte hole ich aber nicht beim Status (also alle 60 Sekunden), sondern nur on Demand mit energy_details. Die get03URL lautet also

Code Auswählen Erweitern

http://192.168.0.211/api/status?filter=fhz,nrg,pvopt_averagePGrid,pvopt_averagePPv,pvopt_averagePAkkuBetreffend die Belastung des Speichers durch schnelle Wechsel: Unklar, was das ausmacht. Und nicht unbedingt vergleichbar mit dem Li-Ionenakku im Fahrzeug, weil die besten Speicher mit Lithium-Eisenphosphat arbeiten. Auch die Details des Algorithmus der WallBox sind ja (noch) unklar.

Das muss natürlich bei einem kompletten Energiemanagement ebenfalls berücksichtigt werden.

LG

pah

[DocCyber]

Mit Blick auf die Datenflut rückt (zumindest bei mir) das EnergyMeter ins Blickfeld.
Ich rufe dessen Daten mit dem SMAEM-Modul ab und erhalte rund 70 Readings.
Für die Überschussladung brauche ich eigentlich aber nur die Leistung.

Weiß jemand, ob man nicht HTTPMod nutzen könnte, um nur diesen Wert auszulesen?

[Prof. Dr. Peter Henning]

Hmm. SMAEM bezieht sich auf eine Kiste von SMA? Da muss ich passen, weil ich in meiner Notstrom-Umschalteinrichtung ein Smartmeter von Fronius bekomme. Und meine beiden "modernen Messeinrichtungen" (eine in Polen hergestellt, eine in der Slowakei..) des Netzunternehmens werden ab morgen (hoffe ich) durch 2 Homematic-Sensoren abgefragt.

LG

pah

Edit: Warum um Himmels Willen hat der Ersteller des SMAEM-Moduls nicht eingebaut, dass man die Anzahl der Readings beschränken kann?

[DocCyber]

SMAEM bezieht sich auf eine Kiste von SMA?

Ursprünglich ja.
Das Modul funktioniert aber auch mit meinem Elgris SmartMeter, das ich als 1:1 Ersatz für das ursprüngliche EM von SMA im Einsatz habe.

Smartmeter von Fronius bekomme.

Damit ist das Elgris auch kompatibel - lt. Hersteller jedenfalls.

Ich habe mal in der Doku des Elgris-Geräts gewühlt: Es kann per Modbus ausgelesen werden.
Mal sehen, ob ich das hinbekommen kann.

[Prof. Dr. Peter Henning]

Das Auslesen per Modbus habe ich auch vor. Dauert aber noch, bis ich das Ding habe...

Wenn das alles steht, kann man auch die Modbus-Abfrage und die Benachrichtigung der Wallbox auf einen Raspberry Pi Zero auslagern, auf dem eine Mini-FHEM-Installation läuft. Dann hat man im Prinzip den go-e Controller nachgebildet, aber mit sehr viel größeren Eingriffsmöglichkeiten.

LG

pah

[Sany]

Anfangs hatte ich mir auch die selben Gedanken gemacht, wie du jetzt.
Ein guter Bekannnter und Mitarbeiter der TH Aachen, der sich genau mit solchen Themen beschäftigt, sieht das unkritisch.
Und wenn ich berücksichtige, dass das Fahrzeug durch die Rekuperation ständig lädt und entlädt, bin ich mittlerweile recht entspannt.

das kann ich nachvollziehen. Die Ladeelektronik sollte es eigentlich auch können.....

Ein kleines Perl-Code-Snippet, das alle 5 Sekunden von einem "at" aufgerufen wird und die Daten übermittelt.
...

Guter Vorschlag!
Muss ich ausprobieren.

Wenn Du da am probieren bist: Kannst Du ausprobieren ob es auch geht, wenn nur 1 mal pro Minute die Grid-Power an den go-E geschickt wird? Also ob der dann anfängt zu regeln? 2te Version wäre alle 5 sec den gleichen Wert. Das wird aber vermutlich die Charger-Logik nicht mitmachen, denn die will ja die Einspeisung "auf Null" regeln, und bei 60sec den gleichen Wert schicken würde das ja bedeuten, es ist immer noch Überschuss da also weiterregeln (Ladestrom erhöhen).

Ich werde vermutlich die Logik selbst machen mit meinen minütlichen Werten. Andererseits könnte ich auch meinen ESP32, der mittels Tasmota den Hauszähler liest, überreden, den Powerwert alle 5sec zu übermitteln. Kann ich ja auch abhängig von der Tageszeit machen, dann wäre Nachts nicht unnötig "Last" im System, mal sehen.....

Anbei eine Auflistung, welche die API-Dokumentation in die FHEM-Readings übersetzt.

Danke für die neue Liste.



Gruß



Sany

[Prof. Dr. Peter Henning]

Das Update alle 5 Sekunden ist nur nötig, wenn Überschussladen realisiert werden soll. Nachts ist das eher weniger der Fall, es sei denn, man will den Speicher leeren.

LG

pah

[satprofi]

Hallo.
Wie stelle ich den Abfrageintervall über attr, etc um? Würde gerne nur bei Ladung alle 2min. abrufen, sonst stündlich.

LG

[Prof. Dr. Peter Henning]

Das ist die "60" in der Definition des Devices (=1 Minute). Da werden nicht viele Daten geholt, ich würde das auf 1x pro Minute belassen. Sonst würde FHEM ja eventuell erst eine Stunde später merken, dass das Auto weg ist...

Wenn man das dynamisch ändern möchte, muss man das Internal ändern:

Code Auswählen Erweitern

{$defs{'Wally_c'}->{Interval}=3600} setzt die Abfrageperiode auf eine Stunde hoch.
Allerdings kann ich nicht ohne eigene Recherche sagen, ab wann das neue Intervall dann gilt: Ab sofort, oder erst ab dem nächsten Ablauf der Periode.

Alternativ kann man das Intervall auf Null setzen (kein automatischer Abruf) und mit Hilfe eines DOIF eine komplett dynamische Abfrage mit "get Wally_c status" erzeugen. DOIF kommt prima damit zu Recht, dass Zeitintervalle in irgendwelchen Readings festgelegt werden.

LG

pah

[Prof. Dr. Peter Henning]

So, ich habe noch drei weitere Readings und je einen get- und set-Befehl eingebaut. Damit man ggf. auch mal die Firmware-Version abfragen kann. Der Reboot funktioniert auch - ob man das benötigt, kann ich nicht sagen.

Code Auswählen Erweitern

attr Wally_c set13Name goe_reboot
attr Wally_c set13URL http://192.168.0.211/api/set?rst="true"
attr Wally_c set13NoArg 1
attr Wally_c reading17Name goe_serial
attr Wally_c reading17JSON sse
attr Wally_c reading18Name goe_firmware
attr Wally_c reading18JSON fwv
attr Wally_c reading19Name goe_device
attr Wally_c reading19JSON typ
attr Wally_c get05Name goe_details
attr Wally_c get05URL http://192.168.0.211/api/status?filter=sse,fwv,typ
Es hat übrigens jemand gefragt, warum das Device bei mir Wally_c heißt. Na ja, Wally_a ist dasselbe Gerät über MQTT, Wally_b mit dem alten obsoleten Modul und Wally_c eben über HTTPMOD. Wird sich irgendwann ändern, wenn ich die beiden anderen komplett herauswerfe.

LG

pah