go-e Charger WallBox über HTTPMOD

Begonnen von Prof. Dr. Peter Henning, 28 Januar 2024, 12:12:03

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

#75
Die Anschaltung verschiedener Modi in einem Aufruf - etwa mit "set a_AutoPvCharging" - spart zwar ein paar Byte Netzlast. Allerdings kann man damit nicht andere Dinge auf FHEM-Ebene steuern (jedenfalls nicht ohne Klimmzüge). Das ist deshalb wichtig, weil man natürlich die WallBox nicht alle 5 Sekunden mit den Daten der Solaranlage füttern muss, wenn das solare Überschussladen gar nicht gebraucht wird.

Deshalb geht das bei mir etwas anders: Ein Dummy "WallyPvSurplus" kennt die beiden Set-Befehle "on" und "off". Ein DOIF, das die WallBox sowieso benötigt, bekommt zwei weitere Zweige
## 1. End of day
([23:59:55])
({my $e=ReadingsVal("Wally","energy_total",0);
  fhem("setreading Wally energy_yesterday $e");
},setreading Wally energy_today 0.0)
## 2. Fahrzeug angeschlossen
DOELSEIF
([Wally:car] eq "wait")
({speak("Tab1.EG","ID7 an die Wallbox angeschlossen");})
## 3. Fahrzeug lädt
DOELSEIF
([Wally:car] eq "charging")
({speak("Tab1.EG","Der ID7 beginnt das Laden an der Wallbox");})
DOELSEIF
([Wally:car] eq "finished")
({speak("Tab1.EG","Laden des ID7 an der Wallbox abgeschlossen");})
DOELSEIF
([Wally:car] eq "idle")
({speak("Tab1.EG","Der ID7 wurde von der Wallbox abgekoppelt");})
## 6. PvSurplus
DOELSEIF
([WallyPvSurplus] eq "on")
{GoEC_setPvSP("on")}
DOELSEIF
([WallyPvSurplus] eq "off")
{GoEC_setPvSP("off")}

In dem Perl-Programm GoEC_setPVSP habe ich die nötigen FHEM-Befehle gruppiert:
sub GoEC_setPvSP($) {
  my ($cmd) = @_;
  if( $cmd eq "on" ){
     speak("Tab1.EG","Solares Überschussladen an der WallBox eingeschaltet";
     fhem("set Wally charge_mode eco");
     fhem("set Wally charge_pvSurplus yes");
     fhem("set Wally interval 10");
     fhem("set PowerFlow interval 10");
     fhem("set WallyFiller active");
  }else{
    fhem("set WallyFiller inactive");
    fhem("set PowerFlow interval 60");
    fhem("set Wally interval 60");
    fhem("set Wally charge_pvSurplus no");
    fhem("set Wally charge_mode default");
    speak("Tab1.EG","Solares Überschussladen an der WallBox ausgeschaltet";
  }
Ah ja, nur dass sich niemand wundert: Das Ding hieß bei mir Wally_c, weil ich nebenbei noch die Steuerung über MQTT und das veraltete Modul in Betrieb hatte. Die sind jetzt endgültig auf den Müllhaufen gewandert...

LG

pah

Sany

Hallo zusammen,
es gibt ein paar Neuigkeiten:
go-E hat die Api-Dokumentation erweitert.
https://github.com/goecharger/go-eCharger-API-v2/blame/main/apikeys-de.md hier kann man das schön sehen, was sich geändert hat. Für uns hier relevant (also bei Steuerung über Api v2) eigentlich nur, das ids nun dokumentiert ist sowie ein paar "modelStatus" dazugekommen sind.
Hier die Ergänzung für Wally_c (ja, heisst bei mir immer noch so ;-))
attr Wally_c reading11OMap 0:NotChargingBecauseNoChargeCtrlData, 1:NotChargingBecauseOvertemperature, 2:NotChargingBecauseAccessControlWait,3:ChargingBecauseForceStateOn, 4:NotChargingBecauseForceStateOff, 5:NotChargingBecauseScheduler, 6:NotChargingBecauseEnergyLimit, 7:ChargingBecauseAwattarPriceLow, 8:ChargingBecauseAutomaticStopTestLadung, 9:ChargingBecauseAutomaticStopNotEnoughTime, 10:ChargingBecauseAutomaticStop, 11:ChargingBecauseAutomaticStopNoClock, 12:ChargingBecausePvSurplus, 13:ChargingBecauseFallbackGoEDefault, 14:ChargingBecauseFallbackGoEScheduler, 15:ChargingBecauseFallbackDefault, 16:NotChargingBecauseFallbackGoEAwattar, 17:NotChargingBecauseFallbackAwattar, 18:NotChargingBecauseFallbackAutomaticStop, 19:ChargingBecauseCarCompatibilityKeepAlive, 20:ChargingBecauseChargePauseNotAllowed, 22:NotChargingBecauseSimulateUnplugging, 23:NotChargingBecausePhaseSwitch, 24:NotChargingBecauseMinPauseDuration, 26:NotChargingBecauseError, 27:NotChargingBecauseLoadManagementDoesntWant, 28:NotChargingBecauseOcppDoesntWant, 29:NotChargingBecauseReconnectDelay, 30:NotChargingBecauseAdapterBlocking, 31:NotChargingBecauseUnderfrequencyControl, 32:NotChargingBecauseUnbalancedLoad, 33:ChargingBecauseDischargingPvBattery, 34:NotChargingBecauseGridMonitoring, 35:NotChargingBecauseOcppFallback
Ich nutze übrigens auf einem Android-phone die Beta-App von go-E, das könnte relevant sein wenn man Einstellungen dort beschreibt oder auch bei der Firmware: Da kam nun recht frisch die Beta-Software 56.8.
Gestern habe ich damit geladen und mein fhem erweitert, hat genauso funktioniert wie die "Software 56.1", die ich vorher nutzte. Leider gibts kein Changelog (oder ich habe es nicht gefunden). Vielleicht kommt da ja noch was nach. Ich habe nach wie vor die Hoffnung, dass der MQTT-Output mal eingebremst wird und werde in einer ruhigen Minute das mal wieder testen. Es klappt zwar alles mittels HTTPMOD, allerdings würde ich MQTT bevorzugen, da eben die Box dann meldet, wenn sich was ändert. Mal abwarten.

Ansonsten stört mich ein wenig, dass die Box das Überschussladen immer 3-Phasig beginnt und dann zwar nicht auf 11kw hochdreht, aber doch schon auf 8 oder 9, wenn der Überschuss nur um die 4 oder 5 kw beträgt. Das wird dann so innerhalb 30-60 sec ausgeregelt. Ich habe jetzt bei mir das so eingerichtet:
liefert die Solaranlage mehr als 11500 W (der 5min durchschnitt vom Wechselrichter) wird der go-E auf Auto-Phase und 16A Strom und Überschussladen gesetzt, darunter wird mit 1 Phase und 6A gestartet, nach 2 min wird Auto-Phase und 16A wieder gesetzt. Ist dann genug Überschuss für 3-Phasig vorhanden schaltet die Box auf 3 Phasen um. danach regelt sie wieder hoch, das schwingt dann auch ein wenig über, aber nicht so krass wie wenn sie gleich bei 3 phasen startet. Das werde ich bei den nächsten Ladungen (lade-Tests) mal mitplotten und genauer auswerten.
(Auto-Akku ist halt wieder mal voll...)

Dann noch eine Anmerkung zu alw (in Wally_c charge_allowed) und trx (in Wally_c transaction):
beim setzen von transaction wird dieses zu "charge_allowed" in Wally_c, hat aber mit alw/charge_allowed gar nix zu tun. alw ist eher ein interner Wert, ob es der Box "erlaubt" ist, das Auto zu laden. trx/transaction gibt den Ladevorgang per App oder RFID (oder auch per http) frei, wenn die Box (wie bei mir) so eingerichtet ist. Vielleicht kann man das anders bezeichnen, damit es nicht zu Verwechslungen kommt (vielleicht charge_release für die Freigabe per trx).

Nettes Gimmick, aber eigentlich der smarte Teil am smart-home:
Ich habe mir einen OBD2-Adaper mit BLE (BluetoothLowEnergy) ins Auto gesteckt und 2 ESP32 mit OpenMQTT-Gateway mit BLE Erkennung geflashed. Eingerichtet mit den Templates und presence in fhem weiß ich nun 1. ist das Auto zu Hause oder nicht und 2. steht es in der Garage (da ist einer der ESP32) oder in der Einfahrt (der andere ESP32)(presence wertet hier den letzten IO aus, mit dem Kontakt war, das ist eben der "stärkere"). Nur wenn es in der Einfahrt steht kann ich es auch laden, weil dort der go-E-charger an der Wand ist. Also genügt es, das kabel anzustecken, den Rest macht fhem und der go-E. Steht das Auto in der Garage oder ist gar nicht da und irgendwer steckt da sein Auto dran passiert nix, da der go-E freigegeben werden muss.


@Peter: In Deinem DOIF wertest Du "finished" aus: Laden abgeschlossen. Das kommt aber auch bei Phasenwechsel oder wenn PV nicht ausreicht und dann das Laden unterbrochen werden soll (Einstellung in der App)
Ich habe bei mir beobachtet, dass wenn die vom Auto vorgegebene Lademenge erreicht ist und quasi das Auto das laden beendet geht die Ladeleistung runter auf 20-100 W, das ist das, was das Auto noch so zieht. Nach einigen Minuten (meine ich) hat das auch der go_E mitbekommen und beendet das Laden. Das kann man wohl "abkürzen" durch Test auf "car finished" und "charge_allowed yes".


Gruß


Sany

hier mal ein Output vom Wally_c von gestern. Zur besseren Lesbarkeit habe ich Leerzeilen eingefügt.
2024-06-13 16:40:37 car idle

2024-06-13 16:41:00 charge NotChargingBecauseAccessControlWait
2024-06-13 16:41:00 car wait

2024-06-13 16:41:17 charge_allowed yes
2024-06-13 16:41:17 charge ChargingBecausePvSurplus

2024-06-13 16:41:22 car charging

2024-06-13 16:43:02 charge_allowed no
2024-06-13 16:43:02 charge NotChargingBecausePhaseSwitch

2024-06-13 16:43:07 car finished

2024-06-13 16:43:17 charge_allowed yes
2024-06-13 16:43:17 charge ChargingBecausePvSurplus

2024-06-13 16:43:22 car charging

2024-06-13 16:49:47 charge_allowed no
2024-06-13 16:49:47 charge NotChargingBecauseFallbackECO
2024-06-13 16:49:47 car finished

2024-06-13 16:50:17 charge_allowed yes
2024-06-13 16:50:17 charge ChargingBecausePvSurplus
2024-06-13 16:50:17 car charging

2024-06-13 16:55:47 charge_allowed no
2024-06-13 16:55:47 charge NotChargingBecauseFallbackECO
2024-06-13 16:55:47 car finished

2024-06-13 16:56:18 charge_allowed yes
2024-06-13 16:56:18 charge ChargingBecausePvSurplus
2024-06-13 16:56:18 car charging

2024-06-13 17:11:22 car charging

2024-06-13 17:18:17 charge_allowed no
2024-06-13 17:18:17 charge NotChargingBecauseFallbackECO
2024-06-13 17:18:17 car finished

2024-06-13 17:18:47 charge_allowed yes
2024-06-13 17:18:47 charge ChargingBecausePvSurplus
2024-06-13 17:18:47 car charging

2024-06-13 17:21:47 charge_allowed no
2024-06-13 17:21:47 charge NotChargingBecausePhaseSwitch
2024-06-13 17:21:47 car finished

2024-06-13 17:22:02 charge_allowed yes
2024-06-13 17:22:02 charge ChargingBecausePvSurplus

2024-06-13 17:22:07 car charging

2024-06-13 17:34:28 charge_allowed no
2024-06-13 17:34:28 charge NotChargingBecausePhaseSwitch

2024-06-13 17:34:33 car finished

2024-06-13 17:34:43 charge_allowed yes
2024-06-13 17:34:43 charge ChargingBecausePvSurplus

2024-06-13 17:34:53 car charging

2024-06-13 17:40:43 charge_allowed no
2024-06-13 17:40:43 charge NotChargingBecauseFallbackECO

2024-06-13 17:40:48 car finished

2024-06-13 17:41:13 charge_allowed yes
2024-06-13 17:41:13 charge ChargingBecausePvSurplus

2024-06-13 17:41:18 car charging

2024-06-13 17:44:33 charge_allowed no
2024-06-13 17:44:33 charge NotChargingBecausePhaseSwitch
2024-06-13 17:44:33 car finished

2024-06-13 17:44:48 charge_allowed yes
2024-06-13 17:44:48 charge ChargingBecausePvSurplus

2024-06-13 17:44:53 car charging

2024-06-13 17:54:31 charge_allowed no
2024-06-13 17:54:31 charge NotChargingBecausePhaseSwitch
2024-06-13 17:54:31 car finished

2024-06-13 17:54:46 charge_allowed yes
2024-06-13 17:54:46 charge ChargingBecausePvSurplus

2024-06-13 17:54:51 car charging

2024-06-13 17:56:16 charge_allowed no
2024-06-13 17:56:16 charge NotChargingBecauseFallbackECO
2024-06-13 17:56:16 car finished

2024-06-13 17:56:46 charge_allowed yes
2024-06-13 17:56:46 charge ChargingBecausePvSurplus
2024-06-13 17:56:46 car charging

2024-06-13 18:05:46 charge_allowed no
2024-06-13 18:05:46 charge NotChargingBecauseFallbackECO
2024-06-13 18:05:46 car finished

2024-06-13 18:06:16 charge_allowed yes
2024-06-13 18:06:16 charge ChargingBecausePvSurplus
2024-06-13 18:06:16 car charging

2024-06-13 18:09:16 charge_allowed no
2024-06-13 18:09:16 charge NotChargingBecausePhaseSwitch
2024-06-13 18:09:16 car finished

2024-06-13 18:09:31 charge_allowed yes
2024-06-13 18:09:31 charge ChargingBecausePvSurplus

2024-06-13 18:09:36 car charging

2024-06-13 18:18:01 charge_allowed no
2024-06-13 18:18:01 charge NotChargingBecauseFallbackECO
2024-06-13 18:18:01 car finished

2024-06-13 18:22:01 charge_allowed yes
2024-06-13 18:22:01 charge ChargingBecausePvSurplus
2024-06-13 18:22:01 car charging

2024-06-13 18:24:31 charge_allowed no
2024-06-13 18:24:31 charge NotChargingBecausePhaseSwitch
2024-06-13 18:24:31 car finished

2024-06-13 18:24:46 charge_allowed yes
2024-06-13 18:24:46 charge ChargingBecausePvSurplus

2024-06-13 18:24:51 car charging

2024-06-13 18:27:16 charge_allowed no
2024-06-13 18:27:16 charge NotChargingBecauseFallbackECO
2024-06-13 18:27:16 car finished

2024-06-13 18:27:46 charge_allowed yes
2024-06-13 18:27:46 charge ChargingBecausePvSurplus
2024-06-13 18:27:46 car charging

2024-06-13 18:35:01 car finished

2024-06-13 18:35:06 car idle

2024-06-13 18:36:00 charge_allowed no
2024-06-13 18:36:00 charge NotChargingBecauseAccessControlWait

2024-06-13 18:51:00 car idle

2024-06-13 19:07:00 car idle
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

fichtennadel

Danke für die Hinweise.

In den Bewertungen im Android Play Store zur aktuellen Version der App habe ich gelesen, dass die Probleme macht, ich bin daher noch auf der 3.2.14 geblieben.
Ist die neue Version wirklich so schlecht bzw. was hat sich denn groß geändert?


Zitat von: Sany am 14 Juni 2024, 11:58:19Ansonsten stört mich ein wenig, dass die Box das Überschussladen immer 3-Phasig beginnt und dann zwar nicht auf 11kw hochdreht ... Das werde ich bei den nächsten Ladungen (lade-Tests) mal mitplotten und genauer auswerten.

Das ist mir auch schon negativ aufgefallen. Wenn Deine Lösung dafür funktioniert, wär' ich am DOIF dazu sehr interessiert ;-)
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

Prof. Dr. Peter Henning

Bin derzeit in den USA und habe nur sehr eingeschränkten Zugang zur Wallbox...

Das mit den 8kW kann ich nicht bestätigen. Wenn ich bei mir den FTUI-Button für solares Überschussladen betätige, läuft das mit 1,4 kW los.

Für Code und weitere Details müsst Ihr noch bis Mitte Juli warten.

LG

pah

Sany

@fichtennadel
ZitatIn den Bewertungen im Android Play Store zur aktuellen Version der App habe ich gelesen, dass die Probleme macht, ich bin daher noch auf der 3.2.14 geblieben.
Ist die neue Version wirklich so schlecht bzw. was hat sich denn groß geändert?
Die App ist optisch ganz neu gemacht. Läuft bei mir ohne Probleme (V4.0.7)
Die schlechten Bewertungen kommen wohl daher, dass die neue App nur mit Hardware ab V3 läuft, für die davor brauchts die alte App noch. Und hier beklagen sich die User, dass sie nun 2 Apps nutzen müssen, wenn sie einen "alten" und einen "neuen" go-E haben. Das Gejammer hat aber mit der App an sich nix zu tun.

aus eine Email von go-E an die Kunden vom Mai 2024:
ZitatWas müssen Nutzer der go-e Charger HOME Serie (Hardwareversion V2) beachten?
Wenn du einen go-e Charger der HOME Serie (nur Hardwareversion V2) besitzt, musst du dir die klassische go-e App herunterladen, da die neu designte App die Hardwareversion V2 nicht unterstützt. Falls du eine go-e Wallbox mit dieser Hardwareversion mit dem go-e Controller kombinieren möchtest, musst du sowohl die klassische als auch die neu designte App verwenden. Dasselbe gilt, wenn du einen Charger der HOME Serie und einen go-e Charger der Gemini Serie verwendest. Aber keine Sorge, die beiden Apps arbeiten gut zusammen. Wenn du zum Beispiel spezielle Funktionen wie das Lastmanagement aktivieren möchtest, musst du das einfach in beiden Apps tun.

Zitat von: fichtennadel am 14 Juni 2024, 13:19:32Wenn Deine Lösung dafür funktioniert, wär' ich am DOIF dazu sehr interessiert ;-)
Vom Prinzip mache den Start abhängig von der Solarleistung (wie schon beschrieben). Da bin ich aber noch am Testen, das ist noch nicht fertig.
Wenn ich 11,5 KW vom Dach bekomme wird mit 3phasig, automatische Umschaltung und 16A gestartet, wenn nicht dann erst mal 1phasig und mit 6A. Nach 2 Minuten gebe ich dann automatische Phasenumschaltung und 16A frei. Das geht einzeln über die Set-Befehle vom Wally_c oder Du schaust Dir die set-Befehle a_XXX , definiert im Wally_c bei set70...set74 an, so kannst Du Dir beliebige Befehle basteln, die auf einen Rutsch verschiedene Änderungen an die Wallbox schicken.
Wie auch schon mal erwähnt nutze ich Perl-DOIF. Das ist dann etwas umfangreicher, macht bei mir aber alles incl. Oberfläche. Nur ist das noch nicht "vorzeigbar" da noch einige Dinge fehlen und auch die Steuerung noch nicht immer so funktioniert, wie gewünscht. Dazu brauche ich noch mehr Daten für verschiedene "Zustände" beim Laden, um die DOIF-Logik dann so hinzubekommen, das es alle Möglichkeiten abdeckt. Mit alle Möglichkeiten meine ich die Unterschiede, die passieren, wenn man z.B. doch mal die App nutzt, um das Laden freizugeben, oder am Auto das Laden beendet oder..oder....
Als Ziel soll das DOIF dann mal dafür sein, automatisch zu laden (nur Kabel anstecken), und zwar nur mein Auto, sowie wahlweise minimal oder maximal, unabhängig von der Uhrzeit, viellecht mal noch mit Timer fürs Ladeende, um vor einer frühen Urlaubsreise mal 100% zu laden, wenn man dann gleich losfährt.


Gruß


Sany
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Prof. Dr. Peter Henning

Perl-DOIF ist unwartbarer Code. Besser richtigen Perl Code in einer "...utils.pm"

LG

pah

Prof. Dr. Peter Henning

So, jetzt ist das alles auf einer neuen Wiki-Seite ordentlich dokumentiert: https://wiki.fhem.de/wiki/GoE_Charger

LG

pah

appi

Hallo Alle
super Arbeit die ihr da geleistet habt. Wollte alles mal implementiern, habe aber die aktuelle Dafinition des HTTPMOD Moduls für für die go-e gefunden......
Auf der Wiki-Seite von Peter auch nicht. Liegt aber sicher an mir........

Gruss Remo

Prof. Dr. Peter Henning


Prof. Dr. Peter Henning

#84
So, ich hab jetzt am Device noch etwas optimiert. Denn das Laden kann man zwar mit trx=0 starten, aber mit einem anderen Wert von alw nicht stoppen. Der Setter mit dem Namen charge_allowed geht jetzt also nicht mehr auf den trx-Key, sondern auf den frc-Key.

Ist schon im Wiki.

LG

pah

Edit: Habe heute (5.9.) noch etwas an set01IMap und set01IExpr geändert, so dass je nach Wert einer oder beide der Keys trx und frc verwendet werden.

Prof. Dr. Peter Henning

Ich habe noch eine Änderung (auch im Wiki) durchgeführt.

Umbenennung der Readings

energy -> energy_connect
energy_total -> energy

Begründung: Wenn man tägliche, monatliche und jährliche Verbräuche aufzeichnen will, geht das sehr einfach mit dem "statistics"-Modul. Allerdings erwartet dieses ein monoton ansteigendes Reading "energy", eben nicht "energy_total"

LG

pah