go-e Charger WallBox über HTTPMOD

[Prof. Dr. Peter Henning]

Die go-e Charger WallBox habe ich mir gekauft, weil sie auf vielfache Weise an FHEM angebunden werden kann. Nach etlichen Versuchen bin ich dazu gekommen, das Gerät über HTTPMOD anzubinden.

Warum?

- Die Anbindung des Gerätes via MQTT ist unterirdisch, weil die WallBox jede Sekunde etliche Daten sendet. Beispielsweise die Netzfrequenz - das braucht kein Mensch, es bremst nur den MQTT-Server aus und generiert Netzlast ohne Ende.

- Die Anbindung über das existierende Modul 46_goecharger.pm ist nicht zeitgemäß. Zwei Gründe dafür: a.) Das Modul funktioniert nur mit dem veralteten API Version 1, damit können aber nicht alle Features gesteuert werden. b.) Die Namen der Readings in diesem Modul sind absurd, beispielsweise verwendet es "current" als Zeitangabe, und die Ströme werden hingegen als "amp" bezeichnet. Statt des Begriffes Leistung (oder power) verwendet es "KW", und so weiter.

Lösung: Anbindung über die HTTP-Schnittstelle, also REST, genau wie das intern in dem Modul goecharger.pm gemacht wird. Aber flexibler und transparenter mit HTTPMOD.

Darin enthalten: Eine Anzahl Readings, die periodisch alle 60 Sekunden aktualisiert werden (oder manuell mit get .. status), ferner eine Anzahl von Readings, die nur stündlich aktualisiert werden (oder manuell mit get .. settings, oder automatisch nach dem Absetzen eines set ... <xxx>-Befehls). Außerdem können die Teilströme, Spannungen etc. noch mit get ... energy_details abgerufen werden.

Am Code nehme ich noch diverse Verbesserungen vor, es handelt sich nachfolgend um die erste Beta-Version. Aber hiermit kann man schon einmal die Funktionalitäten des goecharger-Moduls nachbilden. Also bitte gerne ausprobieren.

LG

pah

Code Auswählen Erweitern

defmod Wally_c HTTPMOD http://192.168.0.xxx/api/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,wh 60
attr Wally_c devStateIcon disabled.*:ev_car_charger@darkgrey not_allowed.*:ev_car_charger@white ready_no_car.*:ev_car_charger@blue charging.*:ev_car_charger@darkorange waiting_for_car.*:ev_car_charger@pink finished.*:ev_car_charger@lime error.*:ev_car_charger@red
attr Wally_c enableControlSet 0
attr Wally_c event-on-change-reading .*
attr Wally_c event-on-update-reading alw,car
attr Wally_c eventMap /charge_allowed on:on/charge_allowed off:off/
attr Wally_c extractAllJSON 0
attr Wally_c get01Name status
attr Wally_c get01URL http://192.168.0.xxx/api/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,wh
attr Wally_c get02Name settings
attr Wally_c get02Poll 1
attr Wally_c get02PollDelay 3600
attr Wally_c get02URL http://192.168.0.xxx/api/status?filter=acs,ama,amp,amt,ate,cbl,cco,clp,dwo,fna,lck,lmo,pha,upo,ust,acu,alw,car,cus,err,modelStatus,tma,tpa,wh
attr Wally_c get03Name energy_details
attr Wally_c get03URL http://192.168.0.xxx/api/status?filter=fhz,nrg
attr Wally_c group energyControl
attr Wally_c reading01JSON alw
attr Wally_c reading01Name charge_allowed
attr Wally_c reading01OMap 0:no, 1:yes
attr Wally_c reading02JSON trx
attr Wally_c reading02Name transaction
attr Wally_c reading03JSON tpa
attr Wally_c reading03Name power
attr Wally_c reading04JSON wh
attr Wally_c reading04Name energy
attr Wally_c reading05JSON tma_0
attr Wally_c reading05Name temperature_box
attr Wally_c reading06JSON tma_1
attr Wally_c reading06Name temperature_cable
attr Wally_c reading07JSON acu
attr Wally_c reading07Name current_allowed
attr Wally_c reading08JSON ama
attr Wally_c reading08Name current_limit
attr Wally_c reading09JSON clp
attr Wally_c reading09Name current_limitPresets
attr Wally_c reading09RecombineExpr join ",", @matchlist
attr Wally_c reading10JSON amp
attr Wally_c reading10Name current_requested
attr Wally_c reading11JSON modelStatus
attr Wally_c reading11Name charge
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:NotChargingBecauseFallbackECO, 18:NotChargingBecauseFallbackAutomaticStop, 19:ChargingBecauseCarCompatibilityKeepAlive, 20:ChargingBecauseChargePauseNotAllowed, 21:NotChargingBecauseSimulateUnplugging, 22:NotChargingBecausePhaseSwitch, 24:NotChargingBecauseMinPauseDuration
attr Wally_c reading12JSON modelStatus
attr Wally_c reading12Name charge_num
attr Wally_c reading13JSON car
attr Wally_c reading13Name car_num
attr Wally_c reading14JSON car
attr Wally_c reading14Name car
attr Wally_c reading14OMap 0:unknown,1:idle,2:charging,3:wait,4:finished,5:error
attr Wally_c reading15JSON err
attr Wally_c reading15Name error_num
attr Wally_c reading16JSON err
attr Wally_c reading16Name error
attr Wally_c reading16OMap 0:none, 1:FiAc, 2:FiDc, 3:Phase, 4:OverVolt, 5:OverAmp, 6:Diode, 7:PpInvalid, 8:GndInvalid, 9:ContactorStuck, 10:ContactorMiss, 11:FiUnknown, 12:Unknown, 13:OverTemp, 14:NoComm, 15:LockStuckOpen, 16:LockStuckLocked
attr Wally_c reading20JSON acs
attr Wally_c reading20Name charge_auth
attr Wally_c reading20OMap 0:open,1:authentication
attr Wally_c reading21JSON xxxx
attr Wally_c reading21Name zzz4
attr Wally_c reading22JSON xxxx
attr Wally_c reading22Name zzzz5
attr Wally_c reading23JSON xxxxx
attr Wally_c reading23Name zzz7
attr Wally_c reading25JSON xxxx
attr Wally_c reading25Name zzz6
attr Wally_c reading27JSON amt
attr Wally_c reading27Name temperature_limit
attr Wally_c reading28JSON fna
attr Wally_c reading28Name name
attr Wally_c reading29JSON lmo
attr Wally_c reading29Name charge_mode
attr Wally_c reading29OMap 3:default,4:eco,5:nexttrip
attr Wally_c reading30Format %2.1f
attr Wally_c reading30JSON dwo
attr Wally_c reading30Name energy_stop
attr Wally_c reading30OExpr $val/1000
attr Wally_c reading31JSON cco
attr Wally_c reading31Name nexttrip_energy_100km
attr Wally_c reading32Format %2.1f
attr Wally_c reading32JSON ate
attr Wally_c reading32Name nexttrip_energy
attr Wally_c reading32OExpr $val/1000
attr Wally_c reading33JSON ust
attr Wally_c reading33Name lock_setting
attr Wally_c reading33OMap 0:while_car_present, 1:while_charging, 2:always
attr Wally_c reading34JSON lck
attr Wally_c reading34Name lock_mode
attr Wally_c reading34OMap 0:normal, 1:auto_unlock, 2:always, 3:force_unlock
attr Wally_c reading35JSON upo
attr Wally_c reading35Name lock_powerout
attr Wally_c reading35OMap 1:unlock, 0:no_unlock
attr Wally_c reading36JSON cus
attr Wally_c reading36Name lock
attr Wally_c reading36OMap 0:unknown, 1:unlocked, 2:unlock_failed, 3:locked, 4:lock_failed, 5:unlock_powerout
attr Wally_c reading37JSON cus
attr Wally_c reading37Name lock_num
attr Wally_c reading40JSON nrg
attr Wally_c reading40Name voltage_L1_L2_L3_N
attr Wally_c reading40RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f",$matchlist[0],$matchlist[1],$matchlist[8],$matchlist[9]
attr Wally_c reading41JSON nrg
attr Wally_c reading41Name current_L1_L2_L3
attr Wally_c reading41RecombineExpr sprintf "%.1f - %.1f - %.1f ",$matchlist[10],$matchlist[11],$matchlist[12]
attr Wally_c reading42JSON nrg
attr Wally_c reading42Name power_L1_L2_L3_N_t
attr Wally_c reading42RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f - %.1f",$matchlist[13],$matchlist[14],$matchlist[15],$matchlist[2],$matchlist[3]
attr Wally_c reading43JSON nrg
attr Wally_c reading43Name phaseF_L1_L2_L3_N
attr Wally_c reading43RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f",$matchlist[4],$matchlist[5],$matchlist[6],$matchlist[7]
attr Wally_c reading44Format %.2f
attr Wally_c reading44JSON fhz
attr Wally_c reading44Name frequency
attr Wally_c room Energie
attr Wally_c set01IMap 1:on, null:off
attr Wally_c set01Name charge_allowed
attr Wally_c set01URL http://192.168.0.211/api/set?trx=$val
attr Wally_c set02IMap 0:open,1:authentication
attr Wally_c set02Name charge_auth
attr Wally_c set02URL http://192.168.0.211/api/set?acs=$val
attr Wally_c set04Hint {ReadingsVal("Wally_c","current_limitPresets","10")}
attr Wally_c set04Max 16
attr Wally_c set04Min 6
attr Wally_c set04Name current_requested
attr Wally_c set04URL http://192.168.0.211/api/set?amp=$val
attr Wally_c set05IExpr $val*1000
attr Wally_c set05Name energy_stop
attr Wally_c set05URL http://192.168.0.211/api/set?dwo=$val
attr Wally_c set06Format %2.1f
attr Wally_c set06IExpr $val*10*ReadingsVal("Wally_c","nexttrip_energy_100km",0)
attr Wally_c set06Name nexttrip_distance
attr Wally_c set06URL http://192.168.0.211/api/set?ate=$val
attr Wally_c set07Name nexttrip_energy_100km
attr Wally_c set07URL http://192.168.0.211/api/set?cco=$val
attr Wally_c set08IMap 0:while_car_present, 1:while_charging, 2:always
attr Wally_c set08Name lock_setting
attr Wally_c set08URL http://192.168.0.211/api/set?ust=$val
attr Wally_c set09IMap true:unlock, false:no_unlock
attr Wally_c set09Name lock_powerout
attr Wally_c set09URL http://192.168.0.211/api/set?upo=$val
attr Wally_c set10IMap 3:default,4:eco,5:nexttrip
attr Wally_c set10Name charge_mode
attr Wally_c set10URL http://192.168.0.211/api/set?lmo=$val
attr Wally_c setFollowGet settings
attr Wally_c showError 1
attr Wally_c useSetExtensions 0
attr Wally_c userReadings state:car.* {my $c=ReadingsVal("$NAME","car_num",5);;\
  my $n=(ReadingsVal("$NAME","charge_allowed","no") ne "yes");;\
  ($n)?"not_allowed":(($c==1)?"ready_no_car":(($c==2)?"charging":(($c==3)?"wait_for_car":(($c==4)?"finished":"unknown"))))},\
nexttrip_distance:nexttrip_energy.* {sprintf("%.1f",ReadingsVal("Wally_c","nexttrip_energy",0)/ReadingsVal("Wally_c","nexttrip_energy_100km",1)*100)}
attr Wally_c webCmd on:off


[satprofi]

danke für den tipp.
aber bei mir klappts nur mit diesem link

http://192.168.0.2/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,wh 60

[Prof. Dr. Peter Henning]

Gib doch mal die 192.168.0.2 nach außen frei, dann probiere ich, warum das bei Dir anders ist 

LG

pah

[satprofi]

habe voch V2, einige deiner Parameter hab ich gar nicht, bzw. haben andere bezeichnung.

[isy]

Hallo Peter,
ich nutze seit Beginn das GoE Modul GoECharger 0.2.5 (das wird allerdings nicht mehr wirklich unterstützt).
Damit habe ich meine PV-Überschussladung realisiert.

Ich habe heute deine Def. mal eingetragen, die läuft ohne Probleme, wie es scheint.
Der Status sieht gut aus und es kommen die Readings.

Im GoECharger Modul gibt es das numerische Reading "car_state" mit den Werten 1-4. Damit wird bei mir das DOIF zur PV-Überschussregelung abgebildet.
Ich sehe, dass ist bei dir über das Reading "car_num" realisiert.

Das ist so OK für mich!

VG Helmut
 

Nachtrag1: Aktuell brauche ich das Feature nicht, aber eine Phasenschaltung über das Modul per "set" wäre nett.
Nachtrag2: Was ist denn die Urdache für das Reading "LAST_ERROR DNS: Cant find host"

[Prof. Dr. Peter Henning]

@satprofi: Ich nehme an, mit V2 meinst Du die Hardware, nicht das API. OK, aber das lässt sich natürlich bei einem HTTPMOD auf einfachste Weise anpassen, weil man nur die readingXXJSON ändern muss. Die Namen der Parameter für API V 1 findet man hier: https://github.com/goecharger/go-eCharger-API-v1/blob/master/go-eCharger%20API%20v1%20DE.md. Ich hänge hier unten ein Dokument an, in welchem ich beschrieben habe, welche Parameter ich für welchen Zweck in dem Codebeispiel verwendet habe (Achtung, Work in Progress)

@isy: Prima. Klar werde ich die Phasenumschaltung auch noch einbauen. Allerdings ist meine Wallbox noch nicht fest angeschlossen (sondern nur über _eine Phase_ testweise mit 230 V verbunden). Sie zieht deshalb noch keine Last (darf sie ja auch gar nicht...), und das E-Auto habe ich auch noch nicht. Ich finde eigentlich, dass ich dafür schon schön ganz weit gekommen bin...

Was ist denn die Urdache für das Reading "LAST_ERROR DNS: Cant find host"

Das meldet offenbar Deine WallBox als Fehler. Welchen Host sie meint, kann ich nicht sagen - vielleicht versucht sie auf die Cloud zuzugreifen und kommt nicht durch die Firewall?

LG

pah

[isy]

Was ist denn die Urdache für das Reading "LAST_ERROR DNS: Cant find host"

Danke für den Tipp!
Die Cloud habe ich nicht aktiviert.
FM stört nicht, alles läuft!

[CQuadrat]

@isy: Prima. Klar werde ich die Phasenumschaltung auch noch einbauen. Allerdings ist meine Wallbox noch nicht fest angeschlossen (sondern nur über _eine Phase_ testweise mit 230 V verbunden). Sie zieht deshalb noch keine Last (darf sie ja auch gar nicht...), und das E-Auto habe ich auch noch nicht. Ich finde eigentlich, dass ich dafür schon schön ganz weit gekommen bin...

Ich habe auch den go-e Charger - allerdings bisher mit MQTT angebunden. Da stört mich allerdings auch die hohe Message-Dichte.
Deshalb will ich auch mal die Anbindung per HTTPMOD probieren. Da ich auch schon ein zugehöriges Fahrzeug habe    könnte ich gerne das eine oder andere testen.

Viele Grüße

Christoph

[isy]

Gerade gesehen:

Code Auswählen Erweitern

2024.01.31 11:02:27 3: ga_GoE: perl expression eval with expresion package main; my $timeDiff = $oRef->{'$timeDiff'};$val/1000 created warning: Argument "" isn't numeric in division (/) at (eval 502525) line 1.
"ga_GoE" ist das httpmod Device meiner GoE Box.

[Prof. Dr. Peter Henning]

Ich bin mir nicht so sicher, dass dies aus HTTPMOD stammt.

LG

pah

[isy]

Vermutlich nicht, löst aber anderswo diese Warnung aus. "package main" ?

[Prof. Dr. Peter Henning]

@Isy: Sehr witzig, weil man nach dem doch sehr prägnanten Tippfehler "expresion" ein grep machen kann...
Dieser Tippfehler taucht in genau 2 Modulen auf: readingsGroup und readingsProxy.

Und noch ein Anliegen "Damit habe ich meine PV-Überschussladung realisiert."
Würde mich interessieren, wie genau. Das habe ich nämlich bei mir auch vor.

LG

pah

[Prof. Dr. Peter Henning]

@CQuadrat: Da ich die WallBox erstmal provisorisch an einer Phase hängen habe und keine Last ziehen kann, kann ich die Phasenumschaltung nicht wirklich ausprobieren.

Wie funktioniert denn die Leistungssteuerung durch den go-e Kontrollkasten? Ich nehme an, dass dieser (per Modbus TCP??) Daten an die WallBox meldet, z.B. die gegenwärtige Leistung der PV-ANlage. Dafür gibt es ja Variablen im API, die allerdings via REST-Schnittstelle nur lesbar sind.

Und welche Parameter werden dann verändert? Wir haben ja 5 Leistungstufen des Ladestroms, macht zusammen mit der Phasenumschaltung zwischen einer und drei Phasen dann 10 Leistungsstufen.

LG

pah

[isy]

Und noch ein Anliegen "Damit habe ich meine PV-Überschussladung realisiert."
Würde mich interessieren, wie genau. Das habe ich nämlich bei mir auch vor.

Das ist per DOIF realisiert.
Ich nutzte einen SMA Hybrid-WR inkl. Batteriespeicher mit dem entspr. Modul.
Siehe Textdatei.
Die Werte sind natürlich individuell zu wählen.
Das funktioniert bei mir ganzjährig. Bei Ankunft am Haus Ladestecker rein, fertig. Hoher WAF.
Der Einsatz unseres E-Fahrzeugs erfolgt weitgehend nur auf Kurzstrecken in der Stadt.

Dazu ein separates DOIF mit Auslesen meiner BMW-Fahrzeugdaten (per mqtt) zur Ladung auch ohne PV-Überschuss, wenn weniger als 6km elektr. Reichweite.

Dazu kommen noch manuelle Funktionen, wie
- Ladung "Ohne PV Status, mit Vorwahl für 4km, 12km und 20km". Nutze ich nur noch selten, seit ich die Reichweite meines Fahrzeugs auslesen kann.
- Ladung "Ohne PV Überschuss bis voll, nach Freigabe durch RFID-Chip.

[Prof. Dr. Peter Henning]

Danke für die Info zum Überschussladen.

Ich habe die Phasenumschaltung jetzt mal testweise eingebaut:

Code Auswählen Erweitern

attr Wally_c reading21JSON psm
attr Wally_c reading21Name phase_switchmode
attr Wally_c reading21OMap 0:auto, 1:force_1, 2:force_3
attr Wally_c reading22JSON spl3
attr Wally_c reading22Name phase_switchlevel

attr Wally_c set11Name phase_switchmode
attr Wally_c set11URL http://192.168.0.xxx/api/set?psm=$val
attr Wally_c set12Name phase_switchlevel
attr Wally_c set12URL http://192.168.0.xxx/api/set?spl3=$val

attr Wally_c get02URL http://192.168.0.xxx/api/status?filter=acs,ama,amp,amt,ate,cbl,cco,clp,dwo,fna,lck,lmo,pha,psm,spl3,upo,ust,acu,alw,car,cus,err,modelStatus,tma,tpa,wh

Was mir noch nicht klar ist (weil ich es noch nicht ausprobieren kann) ist, wann die "automatische" Phasenumschaltung greift. Geht das nur, wenn die WallBox von ihrem "Controller" eine PV-Überschussleisting von > 4,2 kW gemeldet bekommt? Diesen phase_switchlevel kann man ja in der gegenwärtigen Version auch einstellen, ich weiß aber noch nicht ob das Sinn macht. Oder wird das von der WallBox "automatisch" gemacht, wenn irgendein anderer Parameter sich ändert? Und wenn ja, welcher?

Ich habe mir außerdem einen Deckel für den Charger gedruckt. Erstens finde ich die mitgelieferte Diebstahlsicherung unmöglich, und zweitens stört mich das fette "go-e" Logo auf der ansonsten ganz gut designten Box. Es wird sich noch weisen, ob dieser Deckel sich schlecht auf die Innentemperatur auswirkt - aber das Ding hat, schön weiß lackiert, einen hohen WAF. Und kann nahtlos an einen Kabelkanal 30x15mm² angeschlossen werden. Wer Interesse hat, kann die STL-Datei gerne von mir bekommen.

LG

pah

[isy]

Moin,
hier bin ich leider raus aktuell, da ich nur 1-phasig laden kann!

Wo gib es eine automatische Phasenumschaltung? Geht das nur in Zusammenhang mit dem go-E Controller?
Meine Box Hardware V3, SW 055.8

VG Helmut

[Prof. Dr. Peter Henning]

Ich versuche ja gerade herauszufinden, was diese "Automatik" auslöst. In der Wallbox ist das jedenfalls implementiert, sieht man auch in der App unter Ladung->Strom.

Der Witz ist, dass man damit die Ladeleistung feiner steuern kann

1P 6A => 1,4 kW
1P 10A => 2,3 kW
1P 12A => 2,8 kW
1P 14A => 3,2 kW
1P 16A => 3,7 kW
3P 6A => 4,1 kW
3P 10A => 6,9 kW
3P 12A => 8,3 kW
3P 14A => 9,7 kW
3P 16A => 11 kW

Zusätzlich hat man auch noch die Möglichkeit, die einzelnen Stufen ganzzahlig zu verändern. Das macht natürlich nur Sinn, wenn einem nicht irgendeine "Automatik" dazwischenfunkt.

LG

pah

[satprofi]

du kannst jede Stromstärke einstellen, nicht nur die voreingestellten. ich mache das mit "set xxxx Ampere 5" 

[Prof. Dr. Peter Henning]

In dem HTTPMOD-Device kann man "current_requested" auch setzen. Allerdings ist mir nicht klar, ob das dann auch eingehalten wird - das ist ein "Wunsch" an die Wallbox. Kann ich, wie gesagt, derzeit noch nicht selbst probieren.

Wenn das klarer ist, werde ich daraus ein "Power requested" machen.

LG

pah

[CQuadrat]

@CQuadrat: Da ich die WallBox erstmal provisorisch an einer Phase hängen habe und keine Last ziehen kann, kann ich die Phasenumschaltung nicht wirklich ausprobieren.

Wie funktioniert denn die Leistungssteuerung durch den go-e Kontrollkasten? Ich nehme an, dass dieser (per Modbus TCP??) Daten an die WallBox meldet, z.B. die gegenwärtige Leistung der PV-ANlage. Dafür gibt es ja Variablen im API, die allerdings via REST-Schnittstelle nur lesbar sind.

Und welche Parameter werden dann verändert? Wir haben ja 5 Leistungstufen des Ladestroms, macht zusammen mit der Phasenumschaltung zwischen einer und drei Phasen dann 10 Leistungsstufen.

LG

pah

Was meinst Du mit "go-e Kontrollkasten"? Den go-e Controller? Den habe ich nicht, da ich aktuell noch keine Solaranlage habe.

Phasenumstellung kann ich daher nur manuell durchführen (z.B. per App oder MQTT). Bisher habe ich daher immer ausschließlich 3-phasig geladen.

Analoges gilt für die Ladeleistung: da beginne ich aktuell immer mit einer Maximalleistung. Je nach Ladefortschritt geht die Leistung in Stufen automatisch zurück. Auch bei eingeschalteter Vorklimatisierung ist die Ladeleistung je nach Außentemperatur unterschiedlich hoch.

[Prof. Dr. Peter Henning]

Genau, ich meine das Ding, was die "Controller" nennen. Den will ich eigentlich nicht haben, sondern das mit FHEM erledigen. Ob ich dabei die entsprechenden Variablen in der Box beschreiben kann (in denen z.B. die gegenwärtige PV-Leistung abgelegt ist), kann ich noch nicht sagen. Eventuell geht es auch ohne, indem man eben die Umschaltung manuell macht. Das ist mir deshalb lieber, weil ich da eine nette kleine KI dransetzen möchte.

LG

pah

P.S:Ab heute ist die Box auch ordnungsgemäß an 3 Phasen angeschlossen. Von einer echten Fachkraft.

[isy]

Hi Peter,
Im goE Modul gibt es ein Reading "unlocked_by_card".
Das wechselte bisher zw. 0 und 1, wenn man den RFID Chip davor hielt. Geht nicht mehr.

Kannst du das mit deinem Modul abbilden?

[Prof. Dr. Peter Henning]

Aber natürlich. Der JSON-Schlüssel heißt in der aktuellen API-Version trx, übersetzt durch HTTPMOD-Device in "transaction".

transaction 
"" => Wartet auf Authentifizierung
0 => Authentifiziert über FHEM (durch SETZEN von trx)
1, 2, etc: Authentifiziert über "Karte"

LG

pah

[isy]

Danke sehr für die Info.
Ich finde bei mir die Attrbute dazu, u.a. trx oder transaction, aber keine Readings dazu.
Worin kann denn mein Fehler liegen?

VG Helmut

[Prof. Dr. Peter Henning]

In dem Code, den ich "da unten" gepostet habe, fehlte in der URL bei der Moduldefinition, sowie bei der getURL für Settings der entsprechende Filter-Eintrag ",trx". Ohne den wird der JSON-Key gar nicht angefordert. Es muss also lauten:

Code Auswählen Erweitern

http://192.168.0.xxx/api/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,trx,wh 60
bzw.

Code Auswählen Erweitern

http://192.168.0.xxx/api/status?filter=acs,ama,amp,amt,ate,cbl,cco,clp,dwo,fna,lck,lmo,pha,psm,spl3,upo,ust,acu,alw,car,cus,err,modelStatus,tma,tpa,trx,wh
Ist halt derzeit noch experimentell, es kann noch weitere Änderungen geben.

LG

pah

[isy]

Ist halt derzeit noch experimentell, es kann noch weitere Änderungen geben.
Zum Test bin ich mit eingestiegen.

Habe die Änderungen eingebaut, das Reading kommt an, steht aber nichts drin aktuell.
Ich werden nachher (Auto lädt) mal den Chip vorhalten und schauen, ob was passiert.

Kannst du mir noch erklären, warum es 3 getURL gibt?
Müssen die alle gleich besetzt sein?

[Prof. Dr. Peter Henning]

Nein.

Die URL aus der Definition ist die zyklische Statusabfrage.

Diesen Status soll man aber auch manuell abfragen können - mit get status ==> get01

Die Settings werden zyklisch nur alle Stunde abgefragt, können aber mit get settings auch direkt geholt werden. Zur Sicherheit werden dabei auch alle status-Readings aktualisiert, darum ist der Filter bei get02 ziemlich lang.

get03 ist für Details der elektrischen Daten, z.B. die Spannung und die Frequenz

Ich werde in den nächsten Tagen noch etwas dazu bauen, um die erfolgten Authentifizierungen etc. abzufragen.

Wer an dem Device selber etwas ändern möchte, nur zu! Ich habe ja unten das PDF mit den Beschreibungen der JSON Keys gepostet, damit kann man schön spielen.

LG

pah

[DocCyber]

Hallo zusammen.

Auch bei meiner schon etwas älteren^* Box klappt es nur ohne api/ und ohne modelStatus, also so:

Code Auswählen Erweitern

192.168.xxx.yyy/status?filter=acu,alw,car,cus,err,tma,tpa,trx,wh 60
^*API-V1-Doku zur Info

[DocCyber]

In dem HTTPMOD-Device kann man "current_requested" auch setzen. Allerdings ist mir nicht klar, ob das dann auch eingehalten wird - das ist ein "Wunsch" an die Wallbox.

Das ist tatsächlich nur ein Wunsch; Ladeströme werden teils um 0.5A unterschritten.
Überhaupt ist die Strommessung nicht die Paradediszipin der go-e-Box.
Meine Zoe benötigt eine Ladestrom von mindestens 6A. Stelle ich das an der Box ein, passiert nichts, denn de facto liegen dann nur 5.5A an. Also muss ich an der Box einen Mindestladestrom von 7A vorgeben.

[DocCyber]

Wie funktioniert denn die Leistungssteuerung durch den go-e Kontrollkasten?

Den Kasten habe ich nicht.
Ich frage periodisch (Intervall einstellbar; Minimum 30 Sekunden) mein EnergyMeter ab und setze die Ladestromstärke entsprechend. Funktioniert bestens.

[DocCyber]

Das Modul funktioniert nur mit dem veralteten API Version 1, damit können aber nicht alle Features gesteuert werden.

"Veraltet" ist hier nicht der richtige Ausdruck. Die API V1 funktioniert mit den älteren Wallboxen.
Deine aktuelle Lösung basiert auf der API-V2, die für die neueren Boxen notwendig ist, aber mit den älteren -ohne entsprechende Anpassungen- nicht funktioniert.
Die Zahl der Parameter ist zudem qualitiv und quantitiv unterschiedlich.

[Prof. Dr. Peter Henning]

Ich denke, diejenigen mit den älteren Wallboxen können problemlos mit dem älteren Modul leben. Für neuere Modelle aber schlage ich doch vor, nicht auf das alte API zu setzen. Und da ist die Lösung mit HTTPMOD in meinen Augen ganz nett.

Die Arbeit geht aber zugegeben etwas langsam voran, weil bei mir die wesentlichen Teile - E-Auto, Speicher und 2. PV-Anlage noch "im Zulauf" sind.

Wie man die Ladeleistung selbst optimieren kann, ist mir auch klar. Ich würde nur gerne wissen, wie der proprietäre Kasten mit der WallBox interagiert.

LG

pah

[DocCyber]

Ich denke, diejenigen mit den älteren Wallboxen können problemlos mit dem älteren Modul leben.

Ja, auch wenn dort die Begriffe Strom, Spannung, Leistung, Energie bzw. deren Einheiten ziemlich durcheinander gewürfelt werden.

Für neuere Modelle aber schlage ich doch vor, nicht auf das alte API zu setzen.

Wenn man alle Features nutzen möchte, geht das auch gar nicht anders, denn es gibt im neuen API Parameter, die es im alten nicht gibt - und umgekehrt.

Und da ist die Lösung mit HTTPMOD in meinen Augen ganz nett.

Yow. Es wäre aber natürlich elegant, wenn es mit dieser Lösung möglich wäre herauszufinden, um welche Wallbox es sich handelt und man dann das jeweils passende API -für einen universellen Einsatz- einsetzen würde.

Gibt eigentlich ein Aufruf mit einem nicht existierenden Parameter einen auswertbaren Fehler zurück?
Das könnte dann ein möglicher Ansatz sein...

[Prof. Dr. Peter Henning]

Gibt eigentlich ein Aufruf mit einem nicht existierenden Parameter einen auswertbaren Fehler zurück?

Ja. Aber hier eine "automatische Auswahl" zu realisieren, halte ich für ziemlich sinnlos. Die beste Lösung wäre, eine Variante des HTTPMOD Device für API 1.0 und 1.5 zu produzieren. Mittelfristig wird der Code dann im Wiki bereitgestellt und jeder kann damit glücklich werden.

LG

pah

[Sany]

Hi,

vielen Dank für den Einstieg, den go-E-Charger per httpmod an fhem anzubinden.
Bei mir hängt das Teil schon eine Weile an der Wand, nun ist auch das nötige Auto "in Arbeit". Bis es dann auf dem Hof steht sollte die Überschussladung möglich sein.
Feedback: Wallbox ist die go-E Homefix 11kW, Hardwareversion 3, also mit Phasenumschaltung, Software 56.1 beta. Es ist im Moment nur die Cludverbindung sowie lokaler HTTP API v2 erlaubt.
Das Wally_c Device habe ich nach den Posts 1, 14 und 24 angelegt, hat soweit gleich funktioniert.
Ein paar "Fehlerchen" sind aufgetaucht:
- Reading 30 (dwo) habe ich die Expression und die Formatierung gelöscht, da der Wert auch "null" sein kann und somit ein Fehler bei der Division auftritt. Kann man vermutlich in der Expression abfangen, für mich tut es das erst mal so, da ich mit dem Wert noch nicht wirklich etwas anzufangen weiß.
- beim attr reading11OMap fehlt 23:NotChargingBecausePhaseSwitch 
Zusätzlich habe ich noch

Code Auswählen Erweitern

attr Wally_c reading45JSON eto
attr Wally_c reading45Name energy_totaleingetragen, das ist quasi der "Stromzähler" in der Wallbox.
Den nutze ich, um die minütliche Leistung zu rechnen. Das mache ich bei allen Stromzählern so, die Werte werden in den ersten Sekunden einer Minute errechnet und somit bekomme ich aussagekräftige Diagramme (zumindes solange die Auflösung der Zähler hoch genug ist)

Was geht ist die Auswahl der Stromstärke (current_requested) ((ach ja, da war auch noch ein Fehler drin: das

Code Auswählen Erweitern

attr Wally_c set04Hint {ReadingsVal("Wally_c","current_limitPresets","10")}
attr Wally_c set04Max 16
attr Wally_c set04Min 6
attr Wally_c set04Name current_requestedhat mir die Angaben bei set04Hint am Komma gerennt angeboten. Auch ohne geschweifte Klammern hat es nicht funktioniert. Ich habe dann einen Slider eingebaut:

Code Auswählen Erweitern

attr Wally_c set04Hint slider,6,1,16
attr Wally_c set04Max 16
attr Wally_c set04Min 6
attr Wally_c set04Name current_requested
Das zusammen sollte reichen, die Wallbox für Überschussladung zu steuern. Was mir fehlt (weil noch keine Auto...) wäre mal ein Event-Monitor Auszug von diesem Device, um mal zu sehen, wie sich die diversen Readings ändern. Also z.B. nichts angesteckt, Auto angesteckt und freigegeben zum laden, Phasenumschaltung, verschiedene Ladeströme.
Wie schnell kann man die Box "umschalten", also z.B. verschiedene Ströme oder auch die Phase. Laut Anleitung wird die Ladung zum Fahrzeug bei der Phasenumschaltung unterbrochen, aber wie lange dauert das? Macht es dem Auto-Akku was aus, wenn man z.B. den Ladestrom minütlich anpassen würde?
Sorry falls da ein paar doofe Fragen dabei sind, aber wie gesagt: mir fehlt noch das Auto, deshalb kenne ich die Abläufe beim Laden nicht.


Viele Grüße




Sany

[Prof. Dr. Peter Henning]

OK, Danke für die Hinweise, werde ich korrigieren bzw. ins Wiki aufnehmen.

Ich habe ja auch das Problem, dass ich bisher "autofrei" agiere. Wir werden sehen, was man noch anpassen muss.

Ich habe jetzt noch einen weiteren Befehl "get led_details" und zugehörige set-Befehle eingebaut:

Code Auswählen Erweitern

attr Wally_c get04Name led_details
attr Wally_c get04URL http://192.168.0.211/api/status?filter=lbr,lse,cid,cwc,cch,cfi
attr Wally_c reading51JSON lbr
attr Wally_c reading51Name led_brightness
attr Wally_c reading52JSON lse
attr Wally_c reading52Name led_ecomode
attr Wally_c reading52OMap 0:off, 1:on
attr Wally_c reading53JSON cid
attr Wally_c reading53Name led_colorIdle
attr Wally_c reading53OExpr substr $val,1
attr Wally_c reading54JSON cwc
attr Wally_c reading54Name led_colorWaitcar
attr Wally_c reading54OExpr substr $val,1
attr Wally_c reading55JSON cch
attr Wally_c reading55Name led_colorCharge
attr Wally_c reading55OExpr substr $val,1
attr Wally_c reading56JSON cfi
attr Wally_c reading56Name led_colorFinished
attr Wally_c reading56OExpr substr $val,1
attr Wally_c set20Max 255
attr Wally_c set20Min 0
attr Wally_c set20Name led_brightness
attr Wally_c set20URL http://192.168.0.211/api/set?lbr=$val
attr Wally_c set21IMap true:on,false:off
attr Wally_c set21Name led_ecomode
attr Wally_c set21URL http://192.168.0.211/api/set?lse=$val
attr Wally_c set22FollowGet led_details
attr Wally_c set22Name led_colorIdle
attr Wally_c set22TextArg 1
attr Wally_c set22URL http://192.168.0.211/api/set?cid="%23$val"
attr Wally_c set23FollowGet led_details
attr Wally_c set23Name led_colorWaitcar
attr Wally_c set23TextArg 1
attr Wally_c set23URL http://192.168.0.211/api/set?cwc="%23$val"
attr Wally_c set24FollowGet led_details
attr Wally_c set24Name led_colorCharge
attr Wally_c set24TextArg 1
attr Wally_c set24URL http://192.168.0.211/api/set?cch="%23$val"
attr Wally_c set25FollowGet led_details
attr Wally_c set25Name led_colorFinished
attr Wally_c set25TextArg 1
attr Wally_c set25URL http://192.168.0.211/api/set?cfi="%23$val"

LG

pah

Edit: Und damit die Angaben alle in kWh sind, habe ich auch noch

Code Auswählen Erweitern

set45Format %.3f
set45OExpr $val/1000
spendiert

[Prof. Dr. Peter Henning]

Ich habe noch zwei Änderungen. Wenn man nämlich die einfachen Kommandos "set <Charger> on/off" übernehmen möchte, die für das alte Modul definiert waren, kollidiert dies mit den Settings für den Energiesparmodus der LEDS. Den kann man dann nicht mit on/off auslesen oder setzen, stattdessen benötigt man yes/no. Also

reading52OMap  => 0:no, 1:yes
set21IMap      => true:yes,false:no

Den Einwand reading energy_stop kann ich nach Prüfung nicht nachvollziehen. Auch wenn man diesen Wert in der App löscht, kann er nicht "null" werden, sondern wird eben nummerisch 0.0.

Um sicher zu sein kann man

reading30OExpr => ($val eq "null")?"no":sprintf("%.1f",$val/1000)

setzen, die Notwendigkeit sehe ich aber bei mir nicht.

LG

pah

[Sany]

Guten Morgen,

Den Einwand reading energy_stop kann ich nach Prüfung nicht nachvollziehen. Auch wenn man diesen Wert in der App löscht, kann er nicht "null" werden, sondern wird eben nummerisch 0.0.

Mit der ersten Version gabs folgendes im Log:

2024.02.25 11:00:03.252 3: Wally_c: perl expression eval with expresion package main; my $timeDiff = $oRef->{'$timeDiff'};$val/1000 created warning: Argument "" isn't numeric in division (/) at (eval 11187352) line 1.

mit der neuen reading30OExpr => ($val eq "null")?"no":sprintf("%.1f",$val/1000) kommt das im Log:

2024.02.28 21:54:01.750 3: Wally_c: perl expression eval with expresion package main; my $timeDiff = $oRef->{'$timeDiff'};($val eq "null")?"no":sprintf("%.1f",$val/1000) created warning: Argument "" isn't numeric in division (/) at (eval 9083344) line 1.

wenn ich per URL die Daten im Browser (Firefox) abfrage bekomme ich dwo: null

Ohne die Formatierung im HTTPMOD gibts keine Fehlermeldung.
Wenn ich es recht verstehe kann man bei dwo einen Wert setzen (und auch lesen) der einer gewünschten Lademenge in Wh entspricht. null bedeutet deaktiviert. Jetzt habe ich mal was eingetragen, dann gibts auch keine Fehlermeldung mehr.

Wenn ich das Ladelimit in der App lösche wird in der App 0 kWh angezeigt, die Abfrage per Browser ergibt wieder dwo: null und mit Formatierung gibts im Log die Fehlermeldung.
Dies nur zur Info. Für mich ist das nicht wirklich relevant. Sollte ich mit setzen von dwo/energy_stop mal etwas anfangen kann ich auch mit einer Angabe in Wh leben. Aber ich schau mir das an, sobald ich mal ein Auto an die Box bekomme.

Gruß


Sany

[Prof. Dr. Peter Henning]

Sieh mal einer an. Natürlich ist der JSON-Datenwert "null", wenn man dwo in der App löscht. Bei mir wird das aber durch HTTPMOD in 0.0 übersetzt, also bekomme ich keine Fehlermeldung.

Bevor ich mir überlege, woran das liegen kann, fangen wir es doch einfach ab.

Code Auswählen Erweitern

reading30OExpr => ($val =~ /\d+/)?sprintf("%.1f",$val/1000):"no"
set05IExpr     => ($val =~ /\d+/)?$val*1000:"null"
LG

pah

[Sany]

getestet, funktioniert! Vielen Dank.
Im go-E Charger wird dwo auch zu null, wenn man in der App die kWh auf 0 setzt. Wenn ich per Wally_c energy_stop auf 0 setzte steht auch 0 drin.
Verstehe nicht ganz, warum die überhaupt "null" als deaktiviert da drin haben. 0 wäre ja genauso gut und leichter zum Auswerten.
acu / current_allowed ist vielleicht auch noch so ein Kandidat. Steht im Moment per Browser ausgelesen auf null, im Wally_c ist das Reading leer. Da der Wert ja nur gelesen werden kann müßte der sich beim Laden irgendwie ändern? Vielleicht in Abhängigkeit von current_requested während der Ladung. Mal sehen.....

Grüße


Sany

[Prof. Dr. Peter Henning]

Man braucht die WallBox nur auf "on" zu setzen, dann geht current_allowed zunächst mal auf den Wert von current_requested.
Die Frage ist nur, was sinnvoller in der Anzeige ist: "none", wenn kein current allowed ist, oder der Leerstring.

Eine "0" würde ich dort ungerne anzeigen lassen, weil das ja ein nummerischer Wert ist, der auch beim Lademanagement auftreten kann.

LG

pah

[Sany]

Hier mal ein wenig Event-Monitor von Wally_c mit Auto wie es bisher in diesem Thread aufgebaut wurde. Ich habe nur die Formatierung für energy_total nicht übernommen, da ich Wh statt kWh möchte.

** Kabel am Charger und dann am Auto angesteckt, Charger per RFID-Token freigegeben, Auto lädt sofort. Vorgewählt war Phase "Auto" und  6 A. Der Powerwert ist langsam angestiegen. Es ist eingestellt, dass das Kabel beim Laden verriegelt wird.
2024-03-02 15:06:00.593 HTTPMOD Wally_c charge_allowed: yes
2024-03-02 15:06:00.593 HTTPMOD Wally_c transaction: 1
2024-03-02 15:06:00.593 HTTPMOD Wally_c power: 7.666666508
2024-03-02 15:06:00.593 HTTPMOD Wally_c energy: 0.064030489
2024-03-02 15:06:00.593 HTTPMOD Wally_c current_allowed: 6
2024-03-02 15:06:00.593 HTTPMOD Wally_c charge: ChargingBecauseFallbackDefault
2024-03-02 15:06:00.593 HTTPMOD Wally_c charge_num: 15
2024-03-02 15:06:00.593 HTTPMOD Wally_c car_num: 2
2024-03-02 15:06:00.593 HTTPMOD Wally_c car: charging
2024-03-02 15:06:00.593 HTTPMOD Wally_c lock: locked
2024-03-02 15:06:00.593 HTTPMOD Wally_c lock_num: 3
2024-03-02 15:06:00.593 HTTPMOD Wally_c charging

** eine Minute später: die Power ist auf ~4.2 kW angestiegen.
2024-03-02 15:07:00.418 HTTPMOD Wally_c power: 4290.333496
2024-03-02 15:07:00.418 HTTPMOD Wally_c energy: 62.7054239
2024-03-02 15:07:00.418 HTTPMOD Wally_c energy_total: 2190

2024-03-02 15:08:00.505 HTTPMOD Wally_c power: 4292
2024-03-02 15:08:00.505 HTTPMOD Wally_c energy: 133.5881661
2024-03-02 15:08:00.505 HTTPMOD Wally_c temperature_box: 15.625
2024-03-02 15:08:00.505 HTTPMOD Wally_c energy_total: 2261

2024-03-02 15:09:00.632 HTTPMOD Wally_c power: 4295
2024-03-02 15:09:00.632 HTTPMOD Wally_c energy: 205.8556107
2024-03-02 15:09:00.632 HTTPMOD Wally_c energy_total: 2333

** In der App auf einphasig und Strom auf 13A umgestellt: Laden wird gefühlt 30 sec unterbrochen
2024-03-02 15:10:00.705 HTTPMOD Wally_c charge_allowed: no
2024-03-02 15:10:00.705 HTTPMOD Wally_c power: 4290.666504
2024-03-02 15:10:00.705 HTTPMOD Wally_c energy: 264.690517
2024-03-02 15:10:00.705 HTTPMOD Wally_c current_allowed:
2024-03-02 15:10:00.705 HTTPMOD Wally_c charge: NotChargingBecausePhaseSwitch
2024-03-02 15:10:00.705 HTTPMOD Wally_c charge_num: 23
2024-03-02 15:10:00.705 HTTPMOD Wally_c car_num: 4
2024-03-02 15:10:00.705 HTTPMOD Wally_c car: finished
2024-03-02 15:10:00.705 HTTPMOD Wally_c phase_switchmode: force_1
2024-03-02 15:10:00.705 HTTPMOD Wally_c energy_total: 2392
2024-03-02 15:10:00.705 HTTPMOD Wally_c not_allowed

** umschalten auf 1 Phase erledigt, die "Zielleistung" liegt noch nicht ganz an.
2024-03-02 15:11:00.650 HTTPMOD Wally_c charge_allowed: yes
2024-03-02 15:11:00.650 HTTPMOD Wally_c power: 2217.666748
2024-03-02 15:11:00.650 HTTPMOD Wally_c energy: 288.1251803
2024-03-02 15:11:00.650 HTTPMOD Wally_c current_allowed: 13
2024-03-02 15:11:00.650 HTTPMOD Wally_c charge: ChargingBecauseFallbackDefault
2024-03-02 15:11:00.650 HTTPMOD Wally_c charge_num: 15
2024-03-02 15:11:00.650 HTTPMOD Wally_c car_num: 2
2024-03-02 15:11:00.650 HTTPMOD Wally_c car: charging
2024-03-02 15:11:00.650 HTTPMOD Wally_c energy_total: 2415
2024-03-02 15:11:00.650 HTTPMOD Wally_c charging

** Strom auf 10A reduziert und auf 3phasig umgeschaltet
2024-03-02 15:12:00.585 HTTPMOD Wally_c power: 1630
2024-03-02 15:12:00.585 HTTPMOD Wally_c energy: 312.2353637
2024-03-02 15:12:00.585 HTTPMOD Wally_c current_allowed: 10
2024-03-02 15:12:00.585 HTTPMOD Wally_c phase_switchmode: force_3
2024-03-02 15:12:00.585 HTTPMOD Wally_c energy_total: 2439

** Laden wird auch hier unterbrochen
2024-03-02 15:13:00.483 HTTPMOD Wally_c power: 7117.333496
2024-03-02 15:13:00.483 HTTPMOD Wally_c energy: 419.3656874
2024-03-02 15:13:00.483 HTTPMOD Wally_c temperature_cable: 21.625
2024-03-02 15:13:00.483 HTTPMOD Wally_c car_num: 4
2024-03-02 15:13:00.483 HTTPMOD Wally_c car: finished
2024-03-02 15:13:00.483 HTTPMOD Wally_c energy_total: 2545
2024-03-02 15:13:00.483 HTTPMOD Wally_c finished

** Laden am Auto ausgeschaltet: Laden beendet und Kabel an der Box freigegeben, Kabel abgezogen
2024-03-02 15:15:00.638 HTTPMOD Wally_c charge_allowed: no
2024-03-02 15:15:00.638 HTTPMOD Wally_c transaction:
2024-03-02 15:15:00.638 HTTPMOD Wally_c current_allowed:
2024-03-02 15:15:00.638 HTTPMOD Wally_c charge: NotChargingBecauseAccessControlWait
2024-03-02 15:15:00.638 HTTPMOD Wally_c charge_num: 2
2024-03-02 15:15:00.638 HTTPMOD Wally_c car_num: 1
2024-03-02 15:15:00.638 HTTPMOD Wally_c car: idle
2024-03-02 15:15:00.638 HTTPMOD Wally_c lock: unlocked
2024-03-02 15:15:00.638 HTTPMOD Wally_c lock_num: 1
2024-03-02 15:15:00.638 HTTPMOD Wally_c not_allowed

** das normale Abfragen der Box, ohne Änderungen (car: idle wird ca alle 15min "durchgelassen")
2024-03-02 15:19:00.412 HTTPMOD Wally_c temperature_box: 16.75
2024-03-02 15:25:00.376 HTTPMOD Wally_c temperature_box: 17.75
2024-03-02 15:31:03.932 HTTPMOD Wally_c car: idle
2024-03-02 15:31:04.149 HTTPMOD Wally_c current_requested: 10
2024-03-02 15:47:00.618 HTTPMOD Wally_c car: idle
2024-03-02 16:03:00.362 HTTPMOD Wally_c car: idle

Gruß


Sany

[Prof. Dr. Peter Henning]

So, Danke an Sany für das Ausgraben der Diskussion https://github.com/goecharger/go-eCharger-API-v2/discussions/110

Der Knackpunkt ist einfach eine Meldung von Gesamtleistung des Hauses und des Akkus an die WallBox alle 5 Sekunden, die WallBox steuert dann von selbst das Überschussladen

Womit sich die Frage stellt, ob man das wirklich innerhalb von FHEM realisieren sollte. Mit einem externen MQTT-Server sollte das einfacher gehen, ohne die FHEM-Hauptschleife zu belasten.

LG

pah

[Sany]

Ja, die Geschichte ist interessant. Allerdings hätte ich da auch Bauchschmerzen, die Datenflut im fhem hauptsächlich "nicht" zu verarbeiten. Denn man braucht ja vergleichsweise wenig davon. Auch ich war schon 2021 mit dem Support in Kontakt wegen der vielen sekündlich gesendeten Daten, wenn ich jetzt in der Github-Diskussion immer noch davon lese, dass sich User deshalb "beschweren" habe ich trotz Ankündigung, da "soll was zum Einstellen und Filtern" kommen nicht so recht die Hoffnung, das sich da bald was tut. Man kann das ja beobachten.
Aus den gestern gewonnenen Daten kann man aber schön erkennen, was der go-E charger so macht, wenn man Phasenumschaltung oder Stromänderung per App schickt. Mit dem HTTPMOD-Device von pah kann man die selben Dinge an den Charger schicken. Damit läßt sich die Überschussladung ebenso realisieren, einige Ansätze dazu findet man auch hier im Forum. Ich werde das auch so erst mal realisieren, da ich aber noch ein paar Monate auf das Auto warten muss hat das auch Zeit. Wie schon weiter oben erwähnt habe ich nur minütliche Powerdaten(*), diese aber von allen Messstellen quasi gleichzeitig am Minutenwechsel, so dass kurz nach dem Minutenwechsel Werte exisitieren, mit denen man rechnen kann. Ist für meinen "Kraftwerksbetrieb" völlig ausreichend, und wenn ich bei der Überschussladung mal für ne Minute in teilweisen Bezug komme... so what. Ausserdem kann man ja auf eine gewisse Resteinspeisung runtergehen als Puffer, die muss ja nicht 0 werden, wie vom go-E charger wohl angestrebt.
Bin gespannt, was sich bei go-E demnächst so tut. Irgendwie habe ich aber den Eindruck, dass dort "größer" gedacht wird, also Betrieb mehrerer Charger, fernbedienbar, OCPP.... da fällt der einfache USer mit einem Charger vielleicht hinten runter mit seinen Bedürfnissen.....


Gruß


Sany


(*) errechnet über den Zählerunterschied der letzen Minute

[Prof. Dr. Peter Henning]

Ich hab derzeit weder BEV, noch 2. PV-Anlage, noch Speicher, noch Leistungsmessung zum Verbrauch. Die HomeMatic-Interfaces für die "modernen Messeinrichtungen" hatten nämlich 3 Wochen Lieferzeit, und das war erst vor 2 Wochen ...

LG

pah

[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

[Guzzi-Charlie]

Hallo und vielen Dank schonmal für die bisher erbrachte Arbeit zur Einbindung des go-eChargers über HTTPMOD in FHEM.

Ich bin nach den Schwierigkeiten mit der Einbindung des neuen (Gemini) go-eChargers per MQTT nun auch zu der Einsicht gekommen das die Einbindung per HTTPMOD wohl die bessere Variante ist. Also habe ich das Heute gleich mal umgesetzt und, was soll ich sagen, es hat sofort funktioniert.

Als nächstes werde ich nun versuchen auch den go-eController per HTTPMOD einzubinden. Ja, ich habe dieses teure Teil (ca. 250€) tatsächlich, weil es für den Erhalt der KfW442-Förderung notwendig war (der go-eCharger Gemini ist nur in Verbindung mit dem go-eController für die Förderung gelistet), aber in Anbetracht der Tatsache das es dafür insgesamt 9.600€ Förderung gibt läßt sich das verschmerzen.

Meine Hausautomation ist in Bezug auf PV, Speicher, E-Auto's (2), V2H, Wärmepumpen (2), Tibber-Strombezug schon ziemlich komplex und wird mit der zweiten Wallbox auch nicht einfacher. Im Moment laufen alle Daten in FHEM zusammen. Weil ich mich aber schon immer mit der unübersichtlichen Programmierung und der Syntax in FHEM schwer getan habe und es mir oft unmöglich war das "interne Geschehen der Logiken in FHEM" im Falle von Fehlersuchen life vernünftig zu verfolgen habe ich den größten Teil der Logik vor 2-3 Jahren in einen Loxone Miniserver Go ausgelagert. Dort kann man alle Logiken graphisch "programmieren" (so wie ich es von den großen Automationssystemen in meinem Berufsleben bei ABB gewohnt war) und hat auch jederzeit eine Life-Ansicht über alle Daten- und Logikzustände.

Dort habe ich eine vollautomatische Steuerung für alle steuerbaren Verbraucher sowie Erzeuger programmiert. Die E-Autos sind z.B. immer angesteckt (wenn sie in der Garage stehen) und nehmen automatisch am Energiemanagment teil, d.h. sie werden automatisch mit PV-Überschußstrom geladen (nachdem die Hausspeicher voll sind) UND auch über eine selbst gebaute V2H-Box entladen wenn die Hausbatterie leer ist und kein PV-Strom zur Verfügung steht. Auch der Strombezug (Tibber) wird bei Bedarf gesteuert und z.B. bei niedrigen Strompreisen zum Laden der Hausbatterie oder der E_Autos genutzt. Das ist aber noch nicht vollständig implementiert.

Was ich jetzt mit dem go-eController und den zwei Go-eChargern versuchen will ist das FHEM im Falle des Überschußladens nur noch die Freigabe an den go-eController erteilt und dieser dann die Steuerung der Wallboxen selbst übernimmt. Ich verspreche mir davon eine genauere Regelung. In diesem Fall wüde die Datenflut der go-e Geräte vielleicht zu etwas gut sein ohne FHEM zu belasten.

Wenn ich soweit bin werde ich darüber berichten.

[Prof. Dr. Peter Henning]

Es wäre sinnvoll, in das angehängte Dokument einfach eine neue Spalte einzufügen, die sich auf die Version 1 bzw. 1.5 des API bezieht. Dann hat man alles an einer Stelle und kann mit 2 verschiedenen Versionen des HTTPMOD-Devices nahezu identische FHEM-Einbindungen realisieren.

Ein weiterer Grund für mich, das alte Modul nicht wirklich zu benutzen, war die eher absurde Benennung der Readings.

LG

pah

Loxone Miniserver Go

Igitt...

[satprofi]

Hallo.
Bin gerade dabei das ganze in FTUI3 zu implementieren, dabei fiel mir auf das der Ladestop in deinem Beispiel falsch ist.

attr Wally_c set05IExpr $val*1000
attr Wally_c set05Name energy_stop
attr Wally_c set05URL http://192.168.0.211/api/set?dwo=$val

wenn ich das auf *1000 lasse stehen bei mir statt 5kWh 500kWh, ebenso bei den readings.
ich muss *10 einstellen

Kann man super in der app mitverfolgen.

[Prof. Dr. Peter Henning]

Äh - nö. Ich habe es gerade noch einmal ausprobiert. Wenn ich 77 eingebe, kommen wunderbare 77 kWh in der App an.

Übrigens habe ich auch das Löschen eines Limits abgefangen

Code Auswählen Erweitern

set05IExpr ($val =~ /\d+/)?$val*1000:"null"
LG

pah

[satprofi]

Komisch

[Prof. Dr. Peter Henning]

Nö, wieder einmal versionsspezifisch. In der API Version 2 sind es Wh, nicht 0,1 kWh.
https://github.com/goecharger/go-eCharger-API-v2/blob/main/apikeys-de.md

Wie schon gesagt: Es müssen (mindestens) zwei verschiedene Versionen dieses HTTPMOD-Devices beschrieben werden.

LG

pah