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
danke für den tipp.
aber bei mir klappts nur mit diesem link
http://192.168.0.2/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,wh 60
Gib doch mal die 192.168.0.2 nach außen frei, dann probiere ich, warum das bei Dir anders ist 8)
LG
pah
habe voch V2, einige deiner Parameter hab ich gar nicht, bzw. haben andere bezeichnung.
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"
@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
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!
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
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.
Ich bin mir nicht so sicher, dass dies aus HTTPMOD stammt.
LG
pah
Vermutlich nicht, löst aber anderswo diese Warnung aus. "package main" ?
@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
@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
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.
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
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
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
du kannst jede Stromstärke einstellen, nicht nur die voreingestellten. ich mache das mit "set xxxx Ampere 5"
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
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.
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.
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?
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
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
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
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?
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
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 (https://github.com/goecharger/go-eCharger-API-v1/blob/master/go-eCharger%20API%20v1%20DE.md)
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.
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.
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.
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
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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_averagePAkku
Betreffend 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
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?
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?
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.
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
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.....
ZitatZitatEin 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
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
Hallo.
Wie stelle ich den Abfrageintervall über attr, etc um? Würde gerne nur bei Ladung alle 2min. abrufen, sonst stündlich.
LG
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
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
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.
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...
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.
Ä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
Komisch
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
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
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&=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&=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&=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&=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 angepasstessetreading Wally_c go-E-IP [url=https://192.xxx/]192.xxx[/url].yyy.zzz
nicht 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 (https://forum.fhem.de/index.php?action=dlattach;attach=178195;type=preview;file)
Viele Grüße
Sany
.... ich muss erst mal wieder fahren, bevor ich laden kann.....
...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.readings
nun ist es weg, bin mir nur nicht sicher, ob das nun der "richtige" oder "beste" Weg ist?
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
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
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
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
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
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 ; ;", 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
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
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 (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
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 ;-)
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
@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
Perl-DOIF ist unwartbarer Code. Besser richtigen Perl Code in einer "...utils.pm"
LG
pah
So, jetzt ist das alles auf einer neuen Wiki-Seite ordentlich dokumentiert: https://wiki.fhem.de/wiki/GoE_Charger
LG
pah
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
"AUSKLAPPEN"
pah
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.
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
Zitat von: Sany am 14 Juni 2024, 11:58:19. Leider gibts kein Changelog (oder ich habe es nicht gefunden). Vielleicht kommt da ja noch was nach.
Findet man in App unter Firmware
Habe mir jetzt auch eine V4 gehlt, weil V2 nicht mehr mit flexiblen Strompreis klar kommt.
Möchte mich auch hiermit nochmals bedanken, für das WIKI u. tolle Arbeit.
LG
Hallo Peter.
Habe gestern ja dein Projekt angelegt, weil ich auf V4 umgestigen bin.
Habe dazu eine Frage zu energy, ich lade nichts trotzdem ist der Wert nicht 0.
Habe gestern auch nichts geladen , trotzdem wurde um 23:59:59 der Wert nicht genullt. Habe das Script vom WIKI.
Könntest du mir weiterhelfen?
Zitat von: Prof. Dr. Peter Henning am 20 Oktober 2024, 09:37:42Ich 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
Hallo.
Habe energy_connect heute auf 0 gesetzt, nach nächster abfrage wieder auf gesamtwert gefüllt.
irgendwas passt nicht. werd mal nachsehen.
LG
Hallo zusammen,
ich bin der Empfehlung von Pah gefolgt und nun auch Besitzer einer Go-e Wallbox.
Ich habe diese Box über das Modul Modul 46_GoECharger.pm eingebunden und das funktioniert soweit ganz gut.
Weil ich damit aber einen Wert nicht setzen kann und zudem den Hinweis bekommen habe, dass das Modul nicht mehr gepflegt wird, wollte ich auf HTTPMOD wechseln.
Leider bekomme ich das aber nicht hin. FHEM zeigt entweder
read from http://192.168.178.86:80 timed out
oder
DNS: Cant find host
an.
Der Fehler liegt mit Sicherheit bei mir. Ich weiß aber nicht, was ich falsch gemacht habe und bin für einen Tipp dankbar.
So bin ich vorgegangen:
FHEM Update
FHEM Neustart
Code aus Wiki-Eintrag kopiert und in FHEM eingegeben.
In der App der Box habe ich bei den Api-Einstellungen Api V2, Api V1 und Loler Modbus TCP Api freigegeben.
Die Box habe ich danach neu gestartet.
Hier ein List
Internals:
BUSY 0
DEF http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh 60
FUUID 67543fcc-f33f-8efe-60ba-992634ea58779435
Interval 60
MainURL http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
ModuleVersion 4.2.0 - 11.8.2023
NAME Wallbox
NOTIFYDEV global
NR 3354
NTFY_ORDER 50-Wallbox
STATE <p align="left">
not_allowed
<br/>not authenticated
</p>
TYPE HTTPMOD
eventCount 533
value
CompiledRegexes:
HttpUtils:
NAME
addr http://192.168.178.86:80
auth 0
buf
code 200
compress 1
conn
data
displayurl http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
header
host 192.168.178.86
httpheader HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Connection: close
Access-Control-Allow-Origin: *
httpversion 1.0
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
ignoreredirects 1
loglevel 4
path /api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
protocol http
redirects 0
timeout 2
url http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
sslargs:
QUEUE:
READINGS:
2024-12-10 11:28:42 LAST_ERROR DNS: Cant find host
2024-12-10 11:30:42 car idle
2024-12-10 11:30:42 car_num 1
2024-12-10 11:30:42 charge NotChargingBecauseAccessControlWait
2024-12-10 11:30:42 charge_allowed no
2024-12-10 11:30:42 charge_num 2
2024-12-10 11:30:42 current_allowed
2024-12-10 11:30:42 energy 0.340
2024-12-10 11:30:42 energy_connect 0.000
2024-12-10 11:30:42 error none
2024-12-10 11:30:42 error_num 0
2024-12-10 11:30:42 lock unlocked
2024-12-10 11:30:42 lock_num 1
2024-12-10 11:30:42 power 0
2024-12-10 11:30:42 temperature_box 19
2024-12-10 11:30:42 temperature_cable 14
2024-12-10 11:30:42 transaction
REQUEST:
context reading
data
header
ignoreredirects 0
num unknown
retryCount 0
type update
url http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
defptr:
readingBase:
car reading
car_num reading
charge reading
charge_allowed reading
charge_num reading
current_allowed reading
energy reading
energy_connect reading
error reading
error_num reading
lock reading
lock_num reading
power reading
temperature_box reading
temperature_cable reading
transaction reading
readingNum:
car 14
car_num 13
charge 11
charge_allowed 01
charge_num 12
current_allowed 07
energy 45
energy_connect 04
error 16
error_num 15
lock 36
lock_num 37
power 03
temperature_box 05
temperature_cable 06
transaction 02
readingOutdated:
requestReadings:
get02:
car reading 14
car_num reading 13
charge reading 11
charge_allowed reading 01
charge_num reading 12
current_allowed reading 07
energy reading 45
energy_connect reading 04
error reading 16
error_num reading 15
lock reading 36
lock_num reading 37
power reading 03
temperature_box reading 05
temperature_cable reading 06
transaction reading 02
update:
car reading 14
car_num reading 13
charge reading 11
charge_allowed reading 01
charge_num reading 12
current_allowed reading 07
energy reading 45
energy_connect reading 04
error reading 16
error_num reading 15
lock reading 36
lock_num reading 37
power reading 03
temperature_box reading 05
temperature_cable reading 06
transaction reading 02
lastpoll:
settings 1733824135.89001
Attributes:
cmdIcon on:general_an off:general_aus
devStateIcon disabled.*:ev_car_charger@darkgrey not_allowed.*:ev_car_charger@white ready_no_car.*:ev_car_charger@blue charging_car.*:ev_car_charger@darkorange wait_for_car.*:ev_car_charger@pink finished.*:ev_car_charger@green error.*:ev_car_charger@red
enableControlSet 1
event-on-change-reading .*
event-on-update-reading alw,LAST_ERROR
eventMap /charge_allowed yes:on/charge_allowed no:off/
extractAllJSON 0
get01Name status
get01URL http://%goeIP%/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
get02Name settings
get02Poll 1
get02PollDelay 3600
get02URL http://%goeIP%/api/status?filter=acs,ama,amp,amt,ate,cbl,cco,clp,dwo,fna,fup,lck,lmo,pha,psm,spl3,upo,ust,acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
get03Name energy_details
get03URL http://%goeIP%/api/status?filter=fhz,nrg,pvopt_averagePGrid,pvopt_averagePPv,pvopt_averagePAkku
get04Name led_details
get04URL http://%goeIP%/api/status?filter=lbr,lse,cid,cwc,cch,cfi
get05Name goe_details
get05URL http://%goeIP%/api/status?filter=sse,fwv,typ
group energyControl
oldreadings energy
reading01JSON alw
reading01Name charge_allowed
reading01OMap 0:no, 1:yes
reading02JSON trx
reading02Name transaction
reading03JSON tpa
reading03Name power
reading03OExpr (ReadingsVal("Wallbox","car",0) =~ /charging/)?sprintf("%.3f",$val/1000):0
reading04JSON wh
reading04Name energy_connect
reading04OExpr sprintf("%.3f",$val/1000)
reading05JSON tma_0
reading05Name temperature_box
reading06JSON tma_1
reading06Name temperature_cable
reading07JSON acu
reading07Name current_allowed
reading08JSON ama
reading08Name current_limit
reading09JSON clp
reading09Name current_limitPresets
reading09RecombineExpr join ",", @matchlist
reading10JSON amp
reading10Name current_requested
reading11JSON modelStatus
reading11Name charge
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
reading12JSON modelStatus
reading12Name charge_num
reading13JSON car
reading13Name car_num
reading14JSON car
reading14Name car
reading14OMap 0:unknown,1:idle,2:charging,3:wait,4:finished,5:error
reading15JSON err
reading15Name error_num
reading16JSON err
reading16Name error
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
reading17JSON sse
reading17Name goe_serial
reading18JSON fwv
reading18Name goe_firmware
reading19JSON typ
reading19Name goe_device
reading20JSON acs
reading20Name charge_auth
reading20OMap 0:open,1:authentication
reading21JSON psm
reading21Name phase_switchmode
reading21OMap 0:auto, 1:force_1, 2:force_3
reading22JSON spl3
reading22Name phase_switchlevel
reading23JSON pvopt_averagePGrid
reading23Name power_grid_av
reading23OExpr (ReadingsVal("Wallbox","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
reading24JSON pvopt_averagePPv
reading24Name power_pv_av
reading24OExpr (ReadingsVal("Wallbox","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
reading25JSON pvopt_averagePAkku
reading25Name power_battery_av
reading25OExpr (ReadingsVal("Wallbox","charge_mode",0) eq "eco")?sprintf("%.1f",$val/1000):"-"
reading27JSON amt
reading27Name temperature_limit
reading28JSON fna
reading28Name name
reading29JSON lmo
reading29Name charge_mode
reading29OMap 3:default,4:eco,5:nexttrip
reading30JSON dwo
reading30Name energy_stop
reading30OExpr ($val =~ /\d+/)?sprintf("%.1f",$val/1000):"no"
reading31JSON cco
reading31Name nexttrip_energy_100km
reading32Format %2.1f
reading32JSON ate
reading32Name nexttrip_energy
reading32OExpr $val/1000
reading33JSON ust
reading33Name lock_setting
reading33OMap 0:while_car_present, 1:while_charging, 2:always
reading34JSON lck
reading34Name lock_mode
reading34OMap 0:normal, 1:auto_unlock, 2:always, 3:force_unlock
reading35JSON upo
reading35Name lock_powerout
reading35OMap 1:unlock, 0:no_unlock
reading36JSON cus
reading36Name lock
reading36OMap 0:unknown, 1:unlocked, 2:unlock_failed, 3:locked, 4:lock_failed, 5:unlock_powerout
reading37JSON cus
reading37Name lock_num
reading40JSON nrg
reading40Name voltage_L1_L2_L3_N
reading40RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f",$matchlist[0],$matchlist[1],$matchlist[8],$matchlist[9]
reading41JSON nrg
reading41Name current_L1_L2_L3
reading41RecombineExpr sprintf "%.1f - %.1f - %.1f ",$matchlist[10],$matchlist[11],$matchlist[12]
reading42JSON nrg
reading42Name power_L1_L2_L3_N_t
reading42RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f - %.1f",$matchlist[13],$matchlist[14],$matchlist[15],$matchlist[2],$matchlist[3]
reading43JSON nrg
reading43Name phaseF_L1_L2_L3_N
reading43RecombineExpr sprintf "%.1f - %.1f - %.1f - %.1f",$matchlist[4],$matchlist[5],$matchlist[6],$matchlist[7]
reading44Format %.2f
reading44JSON fhz
reading44Name frequency
reading45Format %.3f
reading45JSON eto
reading45Name energy
reading45OExpr $val/1000
reading46Name phases
reading47JSON fup
reading47Name charge_pvSurplus
reading47OMap 0:no,1:yes
reading48JSON frc
reading48Name forceState
reading48OMap 0:neutral, 1:off, 2:on
reading51JSON lbr
reading51Name led_brightness
reading52JSON lse
reading52Name led_ecomode
reading52OMap 0:no, 1:yes
reading53JSON cid
reading53Name led_colorIdle
reading53OExpr substr $val,1
reading54JSON cwc
reading54Name led_colorWaitcar
reading54OExpr substr $val,1
reading55JSON cch
reading55Name led_colorCharge
reading55OExpr substr $val,1
reading56JSON cfi
reading56Name led_colorFinished
reading56OExpr substr $val,1
replacement70Mode text
replacement70Regex %goeIP%
replacement70Value <IP-Adresse>
room 97.Wallbox
set01IMap trx=0&frc=0:yes, frc=1:no, frc=2:forced
set01Name charge_allowed
set01URL http://%goeIP%/api/set?$val
set02IMap 0:open,1:authentication
set02Name charge_auth
set02URL http://%goeIP%/api/set?acs=$val
set04Hint slider,6,1,16
set04Max 16
set04Min 6
set04Name current_requested
set04URL http://%goeIP%/api/set?amp=$val
set05IExpr ($val =~ /\d+/)?$val*1000:"null"
set05Name energy_stop
set05URL http://%goeIP%/api/set?dwo=$val
set06Format %2.1f
set06IExpr $val*10*ReadingsVal("Wallbox","nexttrip_energy_100km",0)
set06Name nexttrip_distance
set06URL http://%goeIP%/api/set?ate=$val
set07Name nexttrip_energy_100km
set07URL http://%goeIP%/api/set?cco=$val
set08IMap 0:while_car_present, 1:while_charging, 2:always
set08Name lock_setting
set08URL http://%goeIP%/api/set?ust=$val
set09IMap true:unlock, false:no_unlock
set09Name lock_powerout
set09URL http://%goeIP%/api/set?upo=$val
set10IMap 3:default,4:eco,5:nexttrip
set10Name charge_mode
set10URL http://%goeIP%/api/set?lmo=$val
set11IMap 0:auto,1:force_1,2:force_3
set11Name phase_switchmode
set11URL http://%goeIP%/api/set?psm=$val
set12Name phase_switchlevel
set12URL http://%goeIP%/api/set?spl3=$val
set13Name goe_reboot
set13NoArg 1
set13URL http://%goeIP%/api/set?rst="true"
set20Max 255
set20Min 0
set20Name led_brightness
set20URL http://%goeIP%/api/set?lbr=$val
set21IMap true:yes,false:no
set21Name led_ecomode
set21URL http://%goeIP%/api/set?lse=$val
set22FollowGet led_details
set22Name led_colorIdle
set22TextArg 1
set22URL http://%goeIP%/api/set?cid="%23$val"
set23FollowGet led_details
set23Name led_colorWaitcar
set23TextArg 1
set23URL http://%goeIP%/api/set?cwc="%23$val"
set24FollowGet led_details
set24Name led_colorCharge
set24TextArg 1
set24URL http://%goeIP%/api/set?cch="%23$val"
set25FollowGet led_details
set25Name led_colorFinished
set25TextArg 1
set25URL http://%goeIP%/api/set?cfi="%23$val"
set47IMap true:yes, false:no
set47Name charge_pvSurplus
set47URL http://%goeIP%/api/set?fup=$val
set48IMap 0:neutral, 1:off, 2:on
set48Name forceState
set48URL http://%goeIP%/api/set?frc=$val
set70Name a_setAutoPvCharging
set70NoArg 1
set70URL http://%goeIP%/api/set?psm=0&=16&lmo=4&fup=true
set71Name a_setManualMaxCharging
set71NoArg 1
set71URL http://%goeIP%/api/set?psm=2&=16&lmo=3&fup=false
set72Name a_setManualMinCharging
set72NoArg 1
set72URL http://%goeIP%/api/set?psm=1&=6&lmo=3&fup=false
setFollowGet settings
showError 1
sortby 3
stateFormat { my $c=ReadingsVal("Wallbox","car_num",5);
my $ca=ReadingsVal("Wallbox","charge_allowed","no");
my $ch=ReadingsVal("Wallbox","charge_num",0);
my $p=ReadingsVal("Wallbox","power",0);
my $l=ReadingsVal("Wallbox","energy",0);
my $e=(ReadingsVal("Wallbox","connection","") ne "ok");
my $ret;
if($ca eq "no"){
$ret="<p align=\"left\">\nnot_allowed\n<br/>not authenticated\n</p>";
}elsif($c==1){
$ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car (idle)\n<p/>");
}elsif($c==2){
$ret=sprintf("<p align=\"left\">\ncharging_car\n<br/>charging %.1f kW\n<p/>",$p);
}elsif($ch==12){
$ret=sprintf("<p align=\"left\">\ncharging paused\n<br/>charging PvSurplus %.1f kW\n</p>",$p);
}elsif($ch==17){
$ret=sprintf("<p align=\"left\">\ncharging pausedrn<br/>charging PvSurplus paused\n</p>");
}elsif($c==3){
$ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car\n<p/>");
}elsif($c==4){
$ret=sprintf("<p align=\"left\">\nfinished_car\n<br/>finished %.2f\n<p/>",$l);
}else{
$ret="unknown";
}
$ret}
useSetExtensions 0
userReadings nexttrip_distance:nexttrip_energy.* {sprintf("%.1f",ReadingsVal("$NAME","nexttrip_energy",0)/ReadingsVal("$NAME","nexttrip_energy_100km",1)*100)},
energy_today:energy_total.* {sprintf("%.3f",ReadingsVal($NAME,"energy_total",0)-ReadingsVal("$NAME","energy_yesterday",0))},
energy_yesterday:none {}
webCmd on:off
widgetOverride led_brightness:slider,0,1,255 led_colorIdle:colorpicker,RGB led_colorWaitcar:colorpicker,RGB led_colorCharge:colorpicker,RGB led_colorFinished:colorpicker,RGB
Für einen Hinweis/Tipp bin ich echt dankbar.
Gruß,
Jogi
Die Def sieht bei mir genau so aus und funktioniert:
http://192.168.178.98/api/status?filter=acu,alw,car,cus,err,modelStatus,tma,tpa,trx,wh 60
Fehlt ein Setting in der Box?
VG Helmut
Ich nehme auch an, dass da etwas an den Einstellungen fehlt.
LG
pah
Vielen Dank für die schnellen Antworten.
Könnt Ihr mir einen Tipp geben, um welche Einstellung es sich handeln könnt, oder wie Ihr die Box eingestellt habt.
Meine Einstellungen stehen ja schon in meinem Post.
Falls es wichtig ist, meine Box hat die Softwareversion 56.8
Gruß,
Jogi
Geht der Zugriff auf genau diese URL per Browser?
LG
pah
Wenn ich
http://192.168.178.86
in den Browser eingebe, bekomme ich
Nothing matches the given URI
Das finde ich seltsam, denn das andere Modul fragt ja dieselbe IP ab.
Und bei der bekomme ich die Daten ja in FHEM angezeigt.
Ich bin da mit meinen Kenntnissen überfordert.
Nein, bitte komplett mit http://192.168.178.86/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh.
So lange das nicht funktioniert und einen JSON-Code produziert, ist die Wallbox nicht unter dieser Nummer erreichbar, sorry.
LG
pah
Zitat von: Jogi am 10 Dezember 2024, 13:46:41Wenn ich
http://192.168.178.86
in den Browser eingebe, bekomme ich
Nothing matches the given URI
Das finde ich seltsam, denn das andere Modul fragt ja dieselbe IP ab.
Und bei der bekomme ich die Daten ja in FHEM angezeigt.
Ich bin da mit meinen Kenntnissen überfordert.
Schau mal in den API Einstellungen der Box.
Meine ist jetzt 2 Jahre alt und ich habe API 1 und V2 aktiviert
Und im Zweifelsfall auch mal einen ping auf die IP-Adresse setzen.
Nach den unten geschilderten Problemen mit dem WLAN habe ich so ein klein wenig den Verdacht, dass in dem Netz zweimal dieselbe IP-Adresse vergeben wurde und deshalb Kollisionen auftauchen.
LG
pah
Hallo pah,
Danke für die Unterstützung und sorry, wenn ich manches nur laienhaft beschreiben kann. Ich gebe mein Bestes ;-)
Dein Tipp mit der doppelten IP-Adresse war schon mal sehr gut. Ich habe in meinem Unifi Netzwerk tatsächlich die Go-e mit der IP 86 als inaktives Gerät gefunden. Das kam aus der ersten Inbetriebnahme ohne Repeater. Der Repeater ist jetzt aber direkt an der Fritzbox angeschlossen. Somit kann die Box im Unifi Netzwerk nicht auftauchen. Ich habe sie im Unify gelöscht und danach die Fritzbox und den Unifi Controller neu gestartet.
Leider hat das nicht den gewünschten Erfolg gebracht.
Hier das Ergebnis vom Ping:
Ping wird ausgeführt für 192.168.178.86 mit 32 Bytes Daten:
Antwort von 192.168.178.86: Bytes=32 Zeit=15ms TTL=64
Antwort von 192.168.178.86: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.86: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.178.86: Bytes=32 Zeit=6ms TTL=64
Ping-Statistik für 192.168.178.86:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 5ms, Maximum = 15ms, Mittelwert = 7ms
Sowohl in der Fritzbox, als auch im Repeater wird die Wallbox korrekt mit der IP86 angezeigt.
Mich wundern zwei Dinge:
FHEM zeigt für die Wallbox "not authenticated" an. Ist das normal oder muss ich da irgendwas freigeben, identifizieren, autorisieren oder ein Passwort eingeben?
Zudem sieht es für mich so aus, als würden 2 Werte tatsächlich abgerufen werden:
temperature_box
18.5
2024-12-10 17:58:41
temperature_cable
13.5
2024-12-10 17:30:13
Wenn ich direkt in die App gucke, dann stimmen die beiden Werte, zumindest werden dort die gleichen Werte angezeigt.
Ich verstehe es nicht.
"Not authenticated" ist komplett richtig, wenn kein Fahrzeug für die Ladung autorisiert ist.
Also ist doch alles ok, das HTTPMOD-Device verbindet sich ganz wunderbar mit der Wallbox.
LG
pah
Edit: Tipp: Der Wallbox eine feste IP-Adresse geben. 2.Tipp: Einen Repeater setzt man besser so ein, dass er nicht irgendwelche wichtigen Aufgaben von der Zentrale wegnimmt. Also keinen eigenen DHCP-Server aufmacht, sondern die IP-Adressen zentral von der FB vergeben lässt. Und dann dafür sorgt, dass die Wallbox immer dieselbe IP-Adresse bekommt - wenn es schon keine feste sein kann.
Naja, ich bin da nicht so sicher, denn außer den beiden Temperaturwerten passiert da nichts und ich kann auch nichts verstellen.
Aber ich warte jetzt erst mal ab, bis das Auto da ist und dann sehen wir weiter.
Dir vielen Dank für die Unterstützung,
Jogi
PS. Feste IP habe ich übrigens vergeben
Sany hatte schon in Post #78 die erweiterte reading11OMap gepostet.
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
Könntest Du die noch ins Wiki einfügen, pah?
Ich bin erneut drüber gestolpert, da meine WB seit Kurzem den FiDC auslöst.
Lieben Dank (auch fürs Modul)!
Grüße softwear
Zitat von: softwear am 13 Dezember 2024, 17:11:07Könntest Du die noch ins Wiki einfügen, pah
Tipp: Schreibrechte fürs Wiki beantragen und das selbst hineinschreiben.
pah
Zitat von: Jogi am 11 Dezember 2024, 10:52:28Naja, ich bin da nicht so sicher, denn außer den beiden Temperaturwerten passiert da nichts und ich kann auch nichts verstellen.
Sicher? Tipp: Handy mit geöffneter App neben den Computer legen. Wenn man etwas in der App umkonfiguriert, ändert sich der Datenwert in FHEM nach der nächsten Abfrage. Und in FHEM ausgelöste Änderungen sollten kurz danach in der App sichtbar sein.
LG
pah
Antrag ist gestellt :)
Zitat von: Prof. Dr. Peter Henning am 13 Dezember 2024, 17:26:24Zitat von: Jogi am 11 Dezember 2024, 10:52:28Naja, ich bin da nicht so sicher, denn außer den beiden Temperaturwerten passiert da nichts und ich kann auch nichts verstellen.
Sicher? Tipp: Handy mit geöffneter App neben den Computer legen. Wenn man etwas in der App umkonfiguriert, ändert sich der Datenwert in FHEM nach der nächsten Abfrage. Und in FHEM ausgelöste Änderungen sollten kurz danach in der App sichtbar sein.
LG
pah
Leider funktioniert genau das nicht.
In dem Modul 50-myGoE geht das alles, leider aber nicht in Deinem Modul, was ich eigentlich nutzen möchte.
Ich denke, ich werde alles noch mal löschen und die Wallbox zurücksetzen. Dann setze ich alles noch einmal neu auf.
Vielleicht liegt da irgendwas quer.
Jetzt, wo ich die Wlan-Zicken der Box kenne, sollte alles beim ersten Anlauf funktionieren.
Das war bei der ersten Inbetriebnahme nicht so. Da habe ich schon ordentlich experimentiert.
Hoppla. Natürlich sollte das Modul myGOE nicht parallel dazu laufen - kann sein, dass sich das ins Gehege kommt.
LG
pah
Hallo.
Warum wird mir im state <p align="left">
not_allowed
<br/>not allowed
</p>9/code] angezeigt, statt [code]
<p align="left">
open
<br/>waiting for car
</p>
attr stateformat
{ my $c=ReadingsVal("goE_charger","car_num",5);
my $ca=ReadingsVal("goE_charger","charge_allowed","no");
my $ch=ReadingsVal("goE_charger","charge_num",0);
my $ret;
if($ca eq "no"){
$ret="<p align=\"left\">\nnot_allowed\n<br/>not allowed\n</p>";
}elsif($c==1){
$ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car (idle)\n<p/>");
}else{
$ret="unknown";
}
$ret}
readings2024-12-25 11:00:37 car idle
2024-12-25 11:00:37 car_num 1
2024-12-25 11:00:37 charge NotChargingBecauseFallbackECO
2024-12-25 11:00:37 charge_allowed no
2024-12-21 09:46:15 charge_auth open
Weil die erste Abfrage ($ca eq "no") bereits den Wahrheitswert "true" liefert...
LG
pah
Ja, stimmt. Habe mir es umgeschrieben, auch der doppelte state verwirrte mich. Habe Wallbox "Open", angezeigt wird 2x Not allowed.
{ my $c=ReadingsVal("goE_charger","car_num",5);
my $cat=ReadingsVal("goE_charger","charge_auth","open");
my $ca=ReadingsVal("goE_charger","charge_allowed","no");
my $ch=ReadingsVal("goE_charger","charge_num",0);
my $p=ReadingsVal("goE_charger","power",0);
my $l=ReadingsVal("goE_charger","energy",0);
my $e=(ReadingsVal("goE_charger","connection","") ne "ok");
my $ret;
if($ca eq "no" and $cat eq"authentication"){
$ret="<p align=\"left\">\nnot allowed\n<br/>not allowed\n</p>";
}elsif($ca eq"no" and $cat eq "open"){
$ret=sprintf("<p align=\"left\">\nnot allowed\n<br/>open\n<p/>");
}elsif($c==1){
$ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car (idle)\n<p/>");
}elsif($c==2){
$ret=sprintf("<p align=\"left\">\ncharging_car\n<br/>charging %.1f kW\n<p/>",$p);
}elsif($c==3){
$ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car\n<p/>");
}elsif($c==4){
$ret=sprintf("<p align=\"left\">\nfinished_car\n<br/>finished %.2f\n<p/>",$l);
}else{
$ret="unknown";
}
$ret}
Hallo,
wenn man unterschiedliche Autos am go-e-Charger lädt, lässt sich das irgendwie erkennen?
Viele Grüße
CQuadrat
Die Box hat dazu keine Daten.
Du könntest die Box über 2 verschiedene RFID Chips freischalten und die Chips jeweils einem Auto zuordnen.
Das kann man auch über FHEM eintüten, indem man sich softwaremäßig als cardx authentifiziert
LG
pah
Ich bin dabei, dein httpmod zu testen.
Bei jedem get oder set wird folgende FM angezeigt.
LAST_ERROR DNS: Cant find host
Def ist:
http://192.168.178.98/api/status?filter=acu,alw,car,cus,err,eto,modelStatus,tma,tpa,trx,wh
Ich habe den jetzt aktuellen Code vom Wiki per defmod über die alte Def installiert.
Am Fhem Server wird die IP des Chargers fehlerfrei über ping erreicht
Was könnte das sein?
P.S. Die aktuelle Ladeleistung wird korrekt angezeigt.
Im global Device ist das Attribut
dnsServer 192.168.178.1
gesetzt
Zitat von: isy am 17 Januar 2025, 13:28:48Die Box hat dazu keine Daten.
Du könntest die Box über 2 verschiedene RFID Chips freischalten und die Chips jeweils einem Auto zuordnen.
Unterschiedliche Chips zu verwenden ist nicht praktikabel, da jeder Fahrer prinzipiell jedes Auto fährt und auch lädt. Dann bräuchte jeder zwei Chips für jedes Auto. Das hat keinen akzeptablen WAF.
Zitat von: CQuadrat am 17 Januar 2025, 14:08:21Dann bräuchte jeder zwei Chips für jedes Auto. Das hat keinen akzeptablen WAF.
Na, irgendwie musst du ja die Ladung freischalten. Und wenn Deine Holde sich weigert, genau den Button zu drücken, der mit DIESEM Auto verknüpft ist, wird es etwas schwierig.
LG
pah
Zitat von: isy am 17 Januar 2025, 13:48:56Was könnte das sein?
Sieht mir nach einem Fehler bei der DNS-Behandlung aus. Bei mir ist dieses Attribut auch nirgendwo gesetzt - das bekommt der FHEM-Server ja vom Router.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 17 Januar 2025, 17:28:39Zitat von: isy am 17 Januar 2025, 13:48:56Was könnte das sein?
Sieht mir nach einem Fehler bei der DNS-Behandlung aus. Bei mir ist dieses Attribut auch nirgendwo gesetzt - das bekommt der FHEM-Server ja vom Router.
LG
pah
Leider tritt der Fehler auch ohne das Attribut auf.
Mit dem Code aus dem 1. Post läuft der GoE
Ich habe im Code vom Wiki noch diese "IP" bezogene Zeile gefunden:
attr Wally replacement70Mode text
attr Wally replacement70Regex %goeIP%
attr Wally replacement70Value <IP-Adresse>
Ist dort die reale IP einzutragen?
Zitat von: isy am 17 Januar 2025, 18:52:12Ist dort die reale IP einzutragen?
Aber Ja !
Sonst erfolgt der Aufruf eben mit dem wörtlichen String "<IP-Adresse>". Und weil des keine gültige IP-Adresse ist, wird eben der Nameserver angefragt, der damit auch nichts anfangen kann.
LG
pah
Ok, die habe ich erst nicht gesehen, weil an allen anderen Stellen über eine Variable gearbeitet wird.
Vielleicht ist das der Fehler gewesen
Aber das ist doch die Variable %goeIP%?
Sie braucht halt einen Wert.
Lg
pah
Klar, ich habe mich mit dem httpmod noch gar nicht befasst.
Vielleicht kannst du im Wiki dokumentieren, dass die IP an 2 Stellen einzutragen ist
OK, funktioniert, Danke sehr!
Hallo. Gibt es möglichkeit die IP einmal zu hinterlegen, das sich dann in die attr selbst einträgt? Grund ist, das ich meinem goE keine fixe IP geben kann, weil er hinter repeater ist. Ich müsste jetzt alles attr umschreiben.
Lg
Hallo Satprofi,
solltest Du mit dem Replacement70 arbeiten, dann enthält das Attribut replacement70Value die lokale IP.
LG
Danke , Passt.
LG
Hallo.
Bei energy_stop muss man für deaktivieren "no" setzen. Bei 0 startet er gar nicht, weil Limit sofort erreicht . Habe in der App deaktiviert, und im Reading steht no
So, mal wieder etwas Neues. Meine Box hat jetzt Software-Version 56.1 - ich habe keine Ahnung, wann und ob die sich ohne mein Zutun installiert hat.
Seitdem funktioniert das Umschalten auf das solare Überschussladen nur noch so halb: Mit
Zitathttp://%goeIP%/api/set?psm=0&=6&lmo=4&fup=true
wird der Eco-Modus nicht aktiviert. Auch in der App gibt es jetzt regelmäßig eine Fehlermeldung, dass ja gar "Kein Controller angeschlossen" sei.
Irgendetwas haben sie also hineingebastelt, das jedesmal beim Umschalten eine zusätzliche Bestätigung erfordert.
Ich muss noch sehen, wie ich das hier abbilde - es geht jedenfalls, wenn man nach dem obigen noch ein zweites
Zitathttp://%goeIP%/api/set?lmo=4
absetzt.
LG
pah
Hallo pah,
vor einiger Zeit hast Du mir die Empfehlung für die go-e Box gegeben und ich bin der Empfehlung gefolgt.
Seit ein paar Wochen habe ich jetzt auch mein Auto und kann Box und Fhem-Modul ausführlich testen.
Fazit: Super!
Von daher an dieser Stelle einfach mal DANKE für die Empfehlung und das Modul.
Gruß,
Jogi
Vielen Dank für das Modul.
Funktioniert es auch mit der Flex Version?
Die hat ja auch wlan und sogar eine sim.
Mein main Use case ist Tesla und Tibber.
Photovoltaik:
habe nur ein BKW, möche es aber ausbauen, auch mit Marstek Speicher.
Lg
Joachim
Zitat von: joachimS am 11 Juni 2025, 09:16:37Funktioniert es auch mit der Flex Version?
Meine Glaskugel ist leider in der Werkstatt.
Wenn das API dasselbe ist: Ja.
LG
pah