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

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

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

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

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  8)

LG

pah

satprofi

habe voch V2, einige deiner Parameter hab ich gar nicht, bzw. haben andere bezeichnung.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

isy

#4
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"
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Prof. Dr. Peter Henning

#5
@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...

ZitatWas 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!
Ein Weg wird erst zu einem Weg, wenn man ihn geht

CQuadrat

Zitat von: Prof. Dr. Peter Henning am 30 Januar 2024, 17:10:30@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
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

isy

Gerade gesehen:
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.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

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" ?
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Prof. Dr. Peter Henning

#11
@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.

Ein Weg wird erst zu einem Weg, wenn man ihn geht

Prof. Dr. Peter Henning

#14
Danke für die Info zum Überschussladen.

Ich habe die Phasenumschaltung jetzt mal testweise eingebaut:
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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

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" 
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

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

Zitat von: Prof. Dr. Peter Henning am 31 Januar 2024, 16:36:42@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.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

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?
Ein Weg wird erst zu einem Weg, wenn man ihn geht

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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

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:

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

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?
Ein Weg wird erst zu einem Weg, wenn man ihn geht

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:
192.168.xxx.yyy/status?filter=acu,alw,car,cus,err,tma,tpa,trx,wh 60
*API-V1-Doku zur Info
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

DocCyber

Zitat von: Prof. Dr. Peter Henning am 01 Februar 2024, 14:31:24In 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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

DocCyber

Zitat von: Prof. Dr. Peter Henning am 31 Januar 2024, 16:36:42Wie 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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

DocCyber

Zitat von: Prof. Dr. Peter Henning am 28 Januar 2024, 12:12:03Das 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.


Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

Prof. Dr. Peter Henning

#31
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

Zitat von: Prof. Dr. Peter Henning am 19 Februar 2024, 20:05:12Ich 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.

ZitatFü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.

ZitatUnd 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...
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

Prof. Dr. Peter Henning

ZitatGibt 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
attr Wally_c reading45JSON eto
attr Wally_c reading45Name energy_total
eingetragen, 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
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
hat mir die Angaben bei set04Hint am Komma gerennt angeboten. Auch ohne geschweifte Klammern hat es nicht funktioniert. Ich habe dann einen Slider eingebaut:
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
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

#35
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:
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

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
Zitatreading52OMap  => 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
Zitatreading30OExpr => ($val eq "null")?"no":sprintf("%.1f",$val/1000)
setzen, die Notwendigkeit sehe ich aber bei mir nicht.

LG

pah

Sany

Guten Morgen,

ZitatDen 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:
Zitat2024.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:
Zitat2024.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
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

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.
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
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

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.

Zitat** 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
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

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
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

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...)
http://192.168.0.211/api/set?ids={"pGrid":1280.,"pPv":140.,"pAkku":0.}an die Wallbox sendet, werden die keys
Zitatinva   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

lpsc null
inva 1211501403
pgrid null
ppv null
pakku null
pvopt_averagePGrid 0
pvopt_averagePPv 0
pvopt_averagePAkku 0
Mit 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

#46
Geht, keine Last feststellbar.

defmod WallyFiller at +*00:00:05 {GoEC_setPvSPData()}
attr WallyFiller group energyControl
attr WallyFiller room Energie

Und als Perl-Programm:
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

Zitat von: Sany am 26 Februar 2024, 16:22:00Macht 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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

DocCyber

Zitat von: Prof. Dr. Peter Henning am 04 März 2024, 12:14:11Beim Ü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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

DocCyber

Zitat von: Prof. Dr. Peter Henning am 20 Februar 2024, 15:25:12Die 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):
# 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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

Prof. Dr. Peter Henning

#50
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
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
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?
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

Prof. Dr. Peter Henning

#52
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

Zitat von: Prof. Dr. Peter Henning am 05 März 2024, 11:18:49SMAEM 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.

ZitatSmartmeter 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.
Behandle die Menschen so, als wären sie, was sie sein sollten. Dadurch hilfst du ihnen zu werden, was sie sein können. (Goethe)


RPi-3 mit HM-CFG-LAN und jede Menge HM Komponenten.

Prof. Dr. Peter Henning

#54
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

ZitatAnfangs 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.....

Zitat
ZitatEin 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.....

ZitatAnbei eine Auflistung, welche die API-Dokumentation in die FHEM-Readings übersetzt.
Danke für die neue Liste.



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

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
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

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:
{$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.

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.
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2

Prof. Dr. Peter Henning

#61
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

Zitat von: Guzzi-Charlie am 12 März 2024, 19:53:03Loxone 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.


gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

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
set05IExpr ($val =~ /\d+/)?$val*1000:"null"
LG

pah

satprofi

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

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

Prof. Dr. Peter Henning

So, E-Auto ist da, und hat schon einmal sagenhafte 9,5 kWh aus der go-e bekommen.

Dabei ist noch etwas Irritierendes aufgetaucht: Das Reading energy = JSON key wh enthält tatsächlich die seit dem letzten Anstecken des Autos hineingeschobene Energie. Und behält diesen Wert auch am nächsten Tag, selbst wenn die Kiste an diesem Tag nicht angeschlossen war.

Das ist insofern ungünstig, als damit das bisherige Reading energy nicht die am Tag hineingeschobene Energiemenge enthält. Ist somit nicht günstig, um eine Tagesbilanz zu erstellen.

Mal sehen, wie ich das löse.

LG

pah

Sany

#67
Hallo,

habe auch seit kurzem mein E-Auto und konnte schon ein wenig experimentieren. Netterweise hat der Händler den zu 100% geladen übergeben, also konnte ich erst gar nicht loslegen mit dem Charger. Aber es kamen dann schon ein paar km zusammen und auch Sonne, also ran ans PV-Überschussladen.

Eine Bitte vorweg: ich finde es sehr unübersichtlich, wenn hier immer wieder API1 und API2 vermischt werden. @Peter: Vielleicht kennzeichnest Du den Thread als goE-Charger ab Hardware V3 mit API (min) V2. Und wer die V1 verwendet könnte bitte einen eigenen Thread dazu aufmachen. Danke.

Bekannt ist ja der Umstand, dass der goE-charger im 5sec Intervall mit grid-Werten versorgt werden muss, um PV-Überschuss-laden zu ermöglichen. In der App ist das ersichtlich in der Form, dass die ECO-konfiguration nur möglich ist, wenn entsprechende Daten gesendet werden.
Da ich meinen Stromzähler mit einem IR-Lesekopf und ESP32 mit tasmota auslese war es nicht kompliziert, das da einzubauen. fhem "redet" per MQTT mit dem Tasmota-ESP32, dort "schalte" ich eine Variable um, abhängig davon sendet der ESP32 dann die grid-Daten per http (websend) direkt an den goE-charger. Im Endeffekt werden die Grid-Daten dann nur gesendet, wenn ein Ladekabel am goE-charger eingesteckt ist (oder ich kann immer noch manuell eingreifen, wenn gewünscht).
Das Überschussladen funktioniert prima, es wird auf einen niedrigen Einspeisewert geregelt (in der App so vorgegeben). Bei ansteigender PV-Leistung klappt das super, bei fallender PV-Leistung (große Wolke vor Sonne) geht die PV-Leistung sehr schnell sehr stark zurück, so dass die Regelung nicht ganz hinterherkommt und "ein wenig" auch am Netz gezogen wird. ich kann das im Moment noch nocht quantifizieren, scheint aber im Wh-Bereich zu liegen und ist mir damit egal.

Weiterhin habe ich das HTTPMOD etwas angepasst: Das zyklische auslesen (alle 60 sec) liest nur noch den eto ( energy_total ), was ich für meine Zwecke in fhem so brauche (habs schon mal geschrieben: alle Energiezähler werden zum minutenwechsel aufgezeichtnet, daraus errechne ich die Leistung und habe sie somit zum rechnen richtig). Die Abfragen zur Steuerung und Überwachung mache ich mittels DOIF, abhängig ob ein Kabel angesteckt ist oder nicht => mit Kabel alle 5 sec, ohne minütlich.
request_go-e_data{
    if(([?Wally_c:car_num:d] == 1 and [+:01]) or ([?Wally_c:car_num:d] > 1 and [+5])){
        fhem("get Wally_c status");
    }
}
so sieht die Zeile in einen Perl-DOIF bei mir aus.
Erweitert habe ich das HTTPMOD um die Readings fup (usePvSurplus), pnp (number of phases) sowie frc (forcestate).
Zusätzlich habe ich set-Befehle definiert, die den charger mit einem Kommando in Überschussladen, minimum-Laden (1Phase mit 6A) oder maximum-Laden (3Phasen mit 16A) schalten. Das ist soweit getestet und funktioniert. Für PV-Überschuss müssen natürlich die Grid-Daten gesendet werden.
Und weil mich das schon die ganze Zeit gestört hat: die IP des goE-chargers muss nun einmalig in ein Reading Attribut geschrieben werden (setreading Wally_c go-E-IP 192.xxx.yyy.zzz) (attr Wally_c replacement70Value 192.xxx.yyy.zzz) und wird dann überall per replacement als %goeIP% verwendet. Zusätzlich:
attr Wally_c replacement70Mode reading geändert in attr Wally_c replacement70Mode text

Zur Steuerung nutze ich ein Perl-DOIF, da ich hier alles an einem Ort habe, incl. GUI. Das kann man natürlich auch anders machen, nur bevor hier wieder Grundsatzdiskussionen über was man doch bitte wie machen soll(te)/kann: Bitte jeder wie er will, ich bin mit meiner Lösung zufrieden, allerdings auch noch nicht fertig. Dazu brauchts noch Recherche, was der goE-charger so alles schickt und wie ich darauf reagieren kann.
Am Ende möchte ich eine "Bedienung" in etwa so: Ein schaltbarer Auto-Modus: ist dieser "on", dann beginnt Überschussladung sobald ein Auto angesteckt wird. Das "kann" nur gehen wenn auch die PV liefert, ergo begrenze ich (mindestens) auf den Normal-Modus vom Wechselrichter (Nachts ist der Modus sleep). Vermutlich fasse ich das Zeitfenster noch enger, da ja in den Randstunden noch nicht genug geliefert wird und es vielleicht keinen Sinn macht, beim ersten Erreichen von 1400W Überschuss das Laden zu starten, wenn die nächste Wolke das wieder deutlich runterfährt. Da könnte wohl auch SolarForecast helfen, mal sehen.
Als weitere Fälle wären da noch minimales Laden und maximales laden (evtl. auch beliebig einstellbar), für den Fall, dass das Laden im Vordergrund steht. Eine Timerlösung in fhem sehe ich als unnötig, da das Auto häufig in der Einfahrt steht und somit der Fall, ich MUSS zu einer bestimmten Zeit eine bestimmte Ladung haben eigentlich nicht relevant ist. Ich will die Sonne nutzen, und wenn es schnell gehen muss habe ich im Umkreis von ca 800m mindestens 14 Ladepunkte mit 50-300KW.

Hier ein RAW vom HTTPMOD. Bitte nicht einfach Copy/Paste! sondern mit dem eigenen vergleichen und ggf nur geünschte Teile übernehmen. Ich habe die Versionen von Peter nur erweitert, also bis auf die IP-Geschichte und die Abfragen eigentlich nix geändert. Ach doch: wh und eto sind in WH!
(Achtung: kann auch noch unvollständig/fehlerhaft sein!!!)
defmod Wally_c HTTPMOD http://192.xxx.yyy.zzz/api/status?filter=eto 60
attr Wally_c alignTime 00:00
attr Wally_c devStateIcon disabled.*:electric_car_charger@darkgrey not_allowed:electric_car_charger@white ready_no_car.*:electric_car_charger@blue charging.*:electric_car_icon@darkorange waiting_for_car.*:electric_car_icon@pink finished.*:electric_car_icon@lime error.*:electric_car_charger@red
attr Wally_c disable 0
attr Wally_c enableControlSet 0
attr Wally_c event-min-interval car:900
attr Wally_c event-on-change-reading temperature_.*:1,.*
attr Wally_c extractAllJSON 0
attr Wally_c get01Name status
attr Wally_c get01URL http://%goeIP%/api/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,wh,psm,trx,pha,amp,pnp,frc
attr Wally_c get02Name settings
attr Wally_c get02URL http://%goeIP%/api/status?filter=acs,ama,amt,ate,cco,clp,dwo,fna,lck,lmo,fup,spl3,upo,ust
attr Wally_c get03Name energy_details
attr Wally_c get03URL http://%goeIP%/api/status?filter=fhz,nrg,pvopt_averagePGrid,pvopt_averagePPv,pvopt_averagePAkku
attr Wally_c get04Name led_details
attr Wally_c get04URL http://%goeIP%/api/status?filter=lbr,lse,cid,cwc,cch,cfi
attr Wally_c get05Name goe_details
attr Wally_c get05URL http://%goeIP%/api/status?filter=sse,fwv,typ
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, 23: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 reading17JSON sse
attr Wally_c reading17Name goe_serial
attr Wally_c reading18JSON fwv
attr Wally_c reading18Name goe_firmware
attr Wally_c reading19JSON typ
attr Wally_c reading19Name goe_device
attr Wally_c reading20JSON acs
attr Wally_c reading20Name charge_auth
attr Wally_c reading20OMap 0:open,1:authentication
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 reading23JSON pvopt_averagePGrid
attr Wally_c reading23Name power_grid_av
attr Wally_c reading23OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
attr Wally_c reading24JSON pvopt_averagePPv
attr Wally_c reading24Name power_pv_av
attr Wally_c reading24OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
attr Wally_c reading25JSON pvopt_averagePAkku
attr Wally_c reading25Name power_battery_av
attr Wally_c reading25OExpr (ReadingsVal("Wally_c","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
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 reading30JSON dwo
attr Wally_c reading30Name energy_stop
attr Wally_c reading30OExpr ($val =~ /\d+/)?sprintf("%.1f",$val/1000):"no"
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
,$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 reading45JSON eto
attr Wally_c reading45Name energy_total
attr Wally_c reading46JSON pnp
attr Wally_c reading46Name phases
attr Wally_c reading47JSON fup
attr Wally_c reading47Name usePvSurplus
attr Wally_c reading48JSON frc
attr Wally_c reading48Name forceState
attr Wally_c reading48OMap 0:neutral, 1:off, 2:on
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:no, 1:yes
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 replacement70Mode text
attr Wally_c replacement70Regex %goeIP%
attr Wally_c replacement70Value 192.xxx.yyy.zzz
attr Wally_c room PV
attr Wally_c set01IMap 1:on, null:off
attr Wally_c set01Name charge_allowed
attr Wally_c set01URL http://%goeIP%/api/set?trx=$val
attr Wally_c set02IMap 0:open,1:authentication
attr Wally_c set02Name charge_auth
attr Wally_c set02URL http://%goeIP%/api/set?acs=$val
attr Wally_c set04Hint slider,6,1,16
attr Wally_c set04Max 16
attr Wally_c set04Min 6
attr Wally_c set04Name current_requested
attr Wally_c set04URL http://%goeIP%/api/set?amp=$val
attr Wally_c set05IExpr ($val =~ /\d+/)?$val*1000:"null"
attr Wally_c set05Name energy_stop
attr Wally_c set05URL http://%goeIP%/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://%goeIP%/api/set?ate=$val
attr Wally_c set07Name nexttrip_energy_100km
attr Wally_c set07URL http://%goeIP%/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://%goeIP%/api/set?ust=$val
attr Wally_c set09IMap true:unlock, false:no_unlock
attr Wally_c set09Name lock_powerout
attr Wally_c set09URL http://%goeIP%/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://%goeIP%/api/set?lmo=$val
attr Wally_c set11Name phase_switchmode
attr Wally_c set11URL http://%goeIP%/api/set?psm=$val
attr Wally_c set12Name phase_switchlevel
attr Wally_c set12URL http://%goeIP%/api/set?spl3=$val
attr Wally_c set13Name goe_reboot
attr Wally_c set13NoArg 1
attr Wally_c set13URL http://%goeIP%/api/set?rst=true
attr Wally_c set20Max 255
attr Wally_c set20Min 0
attr Wally_c set20Name led_brightness
attr Wally_c set20URL http://%goeIP%/api/set?lbr=$val
attr Wally_c set21IMap true:yes,false:no
attr Wally_c set21Name led_ecomode
attr Wally_c set21URL http://%goeIP%/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://%goeIP%/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://%goeIP%/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://%goeIP%/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://%goeIP%/api/set?cfi="%23$val"
attr Wally_c set47IMap true:yes, false:no
attr Wally_c set47Name usePvSurplus
attr Wally_c set47URL http://%goeIP%/api/set?fup=$val
attr Wally_c set48IMap 0:neutral, 1:off, 2:on
attr Wally_c set48Name forceState
attr Wally_c set48URL http://%goeIP%/api/set?frc=$val
attr Wally_c set70Name a_setAutoPvCharging
attr Wally_c set70NoArg 1
attr Wally_c set70URL http://%goeIP%/api/set?psm=0&amp=16&lmo=4&fup=true
attr Wally_c set71Name a_setManualMaxCharging
attr Wally_c set71NoArg 1
attr Wally_c set71URL http://%goeIP%/api/set?psm=2&amp=16&lmo=3&fup=false
attr Wally_c set72Name a_setManualMinCharging
attr Wally_c set72NoArg 1
attr Wally_c set72URL http://%goeIP%/api/set?psm=1&amp=6&lmo=3&fup=false
attr Wally_c set73Name a_setForceOffSetMin
attr Wally_c set73NoArg 1
attr Wally_c set73URL http://%goeIP%/api/set?psm=1&amp=6&lmo=3&fup=false&frc=1&alw=false
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 verbose 0
attr Wally_c webCmd on:off
danach ein angepasstes
setreading Wally_c go-E-IP [url=https://192.xxx/]192.xxx[/url].yyy.zzznicht mehr nötig, ist oben im code schon angepasst auf attr

@ Peter:
ZitatSo, E-Auto ist da, und hat schon einmal sagenhafte 9,5 kWh aus der go-e bekommen.
das fand ich auch ein sehr schönes Gefühl, irgendwie bildlich so als hätte man seine Öl-Quelle im Garten, die so vor sich hinpumpt ;) ;D

Dein goE-Keys PDF mit meinen Anmerkungen schicke ich Dir per PN.
Das geht wohl nicht. Dann hänge ich es hier mit dran.  Keys_goE_2.pdf


Viele Grüße



Sany


.... ich muss erst mal wieder fahren, bevor ich laden kann.....
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Sany

#68
...und gleich noch ne Frage an die, die sich wirklich mit HTTPMOD auskennen (ist bei mir eher trial and error....):

Duch die externe Abfrage mit
get Wally_c status bekomme ich das jeweils im Log quittiert:
Zitat2024.05.11 11:37:00.087 3: get Wally_c status : status requested, watch readings
2024.05.11 11:38:00.095 3: get Wally_c status : status requested, watch readings
2024.05.11 11:39:00.089 3: get Wally_c status : status requested, watch readings
mit verbose 0 geht es nicht weg, jemand ne Idee?


Edit: ich antworte mir mal selbst: habe folgendes in global eingetragen:
attr global ignoreRegexp get.Wally_c.status.:.status.requested,.watch.readingsnun ist es weg, bin mir nur nicht sicher, ob das nun der "richtige" oder "beste" Weg ist?
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Sany

ZitatDabei ist noch etwas Irritierendes aufgetaucht: Das Reading energy = JSON key wh enthält tatsächlich die seit dem letzten Anstecken des Autos hineingeschobene Energie. Und behält diesen Wert auch am nächsten Tag, selbst wenn die Kiste an diesem Tag nicht angeschlossen war.

Das ist insofern ungünstig, als damit das bisherige Reading energy nicht die am Tag hineingeschobene Energiemenge enthält. Ist somit nicht günstig, um eine Tagesbilanz zu erstellen.

Mal sehen, wie ich das löse.
ich hätte einen Vorschlag:
userReadings erweitern
Zitatattr 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($name,"nexttrip_energy",0)/ReadingsVal($NAME,"nexttrip_energy_100km",1)*100)},\
energy_daily:energy.* monotonic {ReadingsVal($NAME,"energy",0)}
und dieses Reading dann um Mitternacht von irgendwoher auf 0 setzen.
wh vom goE-charger summiert zwischen Kabel an- und ab-stecken. Wenn man einen Ladevorgang stoppt und dann wieder startet zählt es weiter, solange das Kabel dranbleibt.

hab das gerade eingebaut und getestet:
2024-05-11 11:54:14.149 HTTPMOD Wally_c energy: 767.4248048
2024-05-11 11:54:14.149 HTTPMOD Wally_c energy_daily: 767.4248048
2024-05-11 11:54:19.142 HTTPMOD Wally_c power: 8858
2024-05-11 11:54:19.142 HTTPMOD Wally_c energy: 779.7789225
2024-05-11 11:54:19.142 HTTPMOD Wally_c energy_daily: 779.7789225
2024-05-11 11:54:24.306 HTTPMOD Wally_c power: 8860.333008
2024-05-11 11:54:24.306 HTTPMOD Wally_c energy: 792.1622817
2024-05-11 11:54:24.306 HTTPMOD Wally_c energy_daily: 792.1622817
energy und energy_daily zählen gleich, auch nach einem Stopp/Start per App.

Zitat2024-05-11 11:58:01.436 HTTPMOD Wally_c power: 0
2024-05-11 11:58:01.436 HTTPMOD Wally_c energy: 0
2024-05-11 11:58:01.436 HTTPMOD Wally_c charge: NotChargingBecauseAccessControlWait
...
2024-05-11 11:58:14.174 HTTPMOD Wally_c charge: ChargingBecausePvSurplus
2024-05-11 11:58:19.215 HTTPMOD Wally_c power: 1160
2024-05-11 11:58:19.215 HTTPMOD Wally_c energy: 0.023756183
2024-05-11 11:58:19.215 HTTPMOD Wally_c car_num: 2
2024-05-11 11:58:19.215 HTTPMOD Wally_c car: charging
2024-05-11 11:58:19.215 HTTPMOD Wally_c charging
2024-05-11 11:58:19.215 HTTPMOD Wally_c energy_daily: 862.082761283
2024-05-11 11:58:24.143 HTTPMOD Wally_c power: 1160.666626
2024-05-11 11:58:24.143 HTTPMOD Wally_c energy: 0.066071994
2024-05-11 11:58:24.143 HTTPMOD Wally_c energy_daily: 862.125077094
2024-05-11 11:58:29.151 HTTPMOD Wally_c power: 1315
2024-05-11 11:58:29.151 HTTPMOD Wally_c energy: 1.478889708
2024-05-11 11:58:29.151 HTTPMOD Wally_c energy_daily: 863.537894808
2024-05-11 11:58:34.161 HTTPMOD Wally_c power: 1343.666626
2024-05-11 11:58:34.161 HTTPMOD Wally_c energy: 3.508869006
und hier schön zu sehen: energy_daily zählt weiter, energy wurde resetted.
Dann nur noch um Mitternacht den energy_daily zurücksetzen.



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

#70
OK, guter Hinweis mit dem "monotonic", danke. Ich teste das mal. Das mit dem %goeIP% habe ich fast übernommen - allerdings mir ein zusätzliches Reading gespart, sondern stattdessen einfach
replacement70Mode text
replacement70Regex %goeIP%
replacement70Value 192.168.0.211
verwendet. Damit hat ist die IP-Adresse als Attribut definiert, das ist logischer als ein Reading.

Bei den anderen Sachen muss ich erstmal sehen, wie sich das auswirkt - die PV-Anlage kommt hoffentlich endlich am nächsten Wochenende.

So siehts derzeit aus in meiner Anzeige:

LG

Edit: Uff, da ist noch irgendwo ein Additionsfehler drin - keinesfalls frisst das Haus derzeit 12 kW ==> Wallbox doppelt gerechnet.
EditEdit: Fehler behoben. Aber die Ladung ist jetzt vorbei. Zuwenig gefahren...
EditEditEdit: So besser, siehe 3. Bild

pah

Sany

ZitatDamit hat ist die IP-Adresse als Attribut definiert, das ist logischer als ein Reading.
das sehe ich auch so und habe es so eingebaut. War von einem anderen Device abgekupfert, dort kann ich das aber auch so ändern.
Danke.

ZitatEditEdit: Fehler behoben. Aber die Ladung ist jetzt vorbei. Zuwenig gefahren...
Das kenn ich (s.o.) Da macht man sich immer Sorgen wegen der Reichweite und dann ist der Akku ständig (zu) voll ;) ;D ::)



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

Das mit dem "monotonic"-modifier funktioniert noch nicht korrekt. Aus irgendeinem Grund werden die letzten Werte nicht übernommen.

Insofern hat "energy" gestern den korrekten Wert 10,935 kWh gehabt, "energy_today" als userreading aber nur 9,62 kWh.

LG

pah


Prof. Dr. Peter Henning

#73
Soho. PV-Anlage ist da, Überschussladen funktioniert prima.

Alle 5 Sekunden hole ich die Daten aus dem Wechselrichter und schiebe sie in die Wallbox. Wichtige Erkenntnis am Rande: Bei der Meldung an die Wallbox ist das Vorzeichen der aus dem Speicher bezogenen Energie wichtig.

LG

pah

fichtennadel

#74
Vorab erstmal Danke an pah, Sany und die anderen Beitragenden hier.

Aufbauend auf euren Beiträgen habe ich meine go-e Wallbox eingebunden, seit Freitag steht das Auto in der Garage und direkt nach dem Einstecken in die Wallbox ging auch schon das Überschussladen mit fhem wie geplant los  ;D

Folgende Ergänzungen habe ich vorgenommen, vielleicht sind sie ja für den ein oder anderen hilfreich:

Die Grid-Werte sende ich auch über das HTTPMOD Device, zB mit set Wally_c pGrid_pPV_pAkku {"pGrid":-126.0,"pPv":3864.0,"pAkku":0.0}. Dann habe ich alles an einer Stelle definiert.
attr Wally_c set49Name pGrid_pPV_pAkku
attr Wally_c set49TextArg 1
attr Wally_c set49URL http://%goeIP%/api/set?ids=$val

Zusätzlich aktuelle Leistung zum Icon in der State-Anzeige:
attr Wallbox_goe reading58JSON nrg
attr Wallbox_goe reading58Name power_curr
attr Wallbox_goe reading58RecombineExpr sprintf("%.1f",$matchlist[3])

attr Wally_c devStateIcon {\
  my $state = ReadingsVal($name, "state", "disabled");;\
  my $devStateIcon_ready = 'electric_car_charger';;\
  my $devStateIcon_car = 'electric_car_icon';;\
  my $devStateIcon = 'electric_car_charger';;  \
  \
  if ($state eq "disabled") {\
    $devStateIcon = "$devStateIcon_ready\@darkgrey";;\
  } elsif ($state eq "not_allowed") {\
    $devStateIcon = "$devStateIcon_ready\@white";;\
  } elsif ($state eq "ready_no_car") {\
    $devStateIcon = "$devStateIcon_ready\@blue";;\
  } elsif ($state eq "charging") {\
    $devStateIcon = "$devStateIcon_car\@darkorange";;\
  } elsif ($state eq "waiting_for_car") {\
    $devStateIcon = "$devStateIcon_car\@pink";;\
  } elsif ($state eq "finished") {\
    $devStateIcon = "$devStateIcon_car\@lime";;\
  } elsif ($state eq "error") {\
    $devStateIcon = "$devStateIcon_ready\@red";;\
  }  \
  \
  "<div>" . sprintf("%.1fkW &nbsp;;&nbsp;;", ReadingsVal($name,"power_curr",0)/1000) \
          . FW_makeImage($devStateIcon) . \
  "</div>"\
}

Die Steuerung habe ich mit diesem DOIF gelöst:
- den Status (car, alw, ... ) von der go-e hole ich mir über das HTTPMOD def alle 60s (abweichend von Sanys Lösung)
- Auswahl von PV - Tag/Nachttarif - Ladestart - Steuerung ohne fhem / per App
- Gridwerte mit "set Wally_c pGrid_pPV_pAkku ..." alle 5s , aber nur wenn im PV Modus && Kabel angesteckt && PV > 0

defmod DI.Wallbox.PV DOIF (([$SELF:modus] eq "PV") and ([$SELF:state] ne "PV")) (\
  (set Wally_c a_setAutoPvCharging)\
  \
) DOELSEIF (([$SELF:modus] eq "NetzTarif") and ([$SELF:state] ne "NetzTarif")) (\
  (set Wally_c a_setManualCharging)\
  \
  ## direkt stoppen oder starten\
 ,{if ("[DI.SmartMeterTarif]" eq "Freizeittarif") {\
    fhem("setreading $SELF Log start NetzTarif direkt");;\
    fhem("set Wally_c forceState on")\
   } else {\
    fhem("setreading $SELF Log stop NetzTarif direkt");;\
    fhem("set Wally_c forceState off")\
   }\
  }\
  \
) DOELSEIF (([$SELF:modus] eq "PV") and ([+5]) and ([?Wally_c:car_num:d] > 1) and ([?wechselrichter:PowerFlow_Site_P_PV:d] > 0))  (\
  {( fhem("set Wally_c pGrid_pPV_pAkku ".sprintf("{\"pGrid\":%.1f,\"pPv\":%.1f,\"pAkku\":0.0}"\
                                                    ,[wechselrichter:PowerFlow_Site_P_Grid]\
                                                    ,[wechselrichter:PowerFlow_Site_P_PV]\
                                                    ) \
         ) \
  )}\
  \
) DOELSEIF (([$SELF:modus] eq "NetzTarif") and ([DI.SmartMeterTarif] eq "Freizeittarif")) (\
  (set Wally_c forceState on)\
  \
) DOELSEIF (([$SELF:modus] eq "NetzTarif") and ([DI.SmartMeterTarif] ne "Freizeittarif")) (\
  (set Wally_c forceState off)\
  \
) DOELSEIF (([$SELF:modus] eq "Laden")) (\
  (set Wally_c a_setManualCharging)\
 ,(set Wally_c forceState on)\
\
) DOELSEIF (([$SELF:modus] eq "Idle")) (\
  (set Wally_c a_setDefaultCharging)\
\
)

attr DI.Wallbox.PV alias Wallbox Steuerung
attr DI.Wallbox.PV checkall event
attr DI.Wallbox.PV cmdState initPV|initNetzTarif|PV|NetzTarif|NetzKeinTarif|Laden|Idle
attr DI.Wallbox.PV devStateIcon initPV:electric_car_charger@orange initNetzTarif:electric_car_charger@red PV:electric_car_charger@yellow NetzTarif:electric_car_charger@green NetzKeinTarif:electric_car_charger@greeen Laden:electric_car_charger@green Idle:electric_car_charger@gray
attr DI.Wallbox.PV do always
attr DI.Wallbox.PV event-on-change-reading .*
attr DI.Wallbox.PV readingList modus
attr DI.Wallbox.PV setList modus:uzsuSelectRadio,PV,NetzTarif,Laden,Idle
attr DI.Wallbox.PV webCmd modus
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

#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