FHEM Forum

Anmerkung: Den go-ECharger kann man auch über MQTT oder HTTPMOD einbinden, siehe Thread https://forum.fhem.de/index.php?action=post;topic=105457.30;last_msg=1043399 (https://forum.fhem.de/index.php?action=post;topic=105457.30;last_msg=1043399) !

Modul 46_GoECharger.pm    (siehe https://github.com/LuRhe/fhem-46_GoECharger (https://github.com/LuRhe/fhem-46_GoECharger))

zur Steuerung wichtiger Funktionen und zum Auslesen der go-eCharger Home+ 11kW / Home+ 22kW / Homefix 11kW / Homefix 22kW in FHEM
(E-Auto Ladestationen bzw. Wallboxen der Firma go-e® GmbH).

Es lassen sich alle API-Werte auslesen (default nur die m.E. wichtigsten) und wesentliche Funktionen in der Box zum Setzen des Ladestromes, zum Aktivieren, zur Kabelverriegelung, zur Mengenladung, zu preisgesteuerter Naturstromladung (Anbieter aWattar ), PV-Überschussladung u.v.m. steuern.
Die Funktionen sind ähnlich der App, dienen aber der Anbindung an Fhem, um im Zsh. mit anderen Geräten und Sensoren noch mehr Möglichkeiten zur Automatisierung (und zum Loggen) zu haben.
Mit Fhem ist dann quasi alles möglich... vor allem eine Anpassung der Ladeleistung an einen PV-Überschuss, die Berücksichtung der Hauslast, Berücksichtigung von Speicher- oder Auto-Ladestand, zeitgesteuerte Aktivierung, Lastmanagement...
Es wird empfohlen, die jeweils aktuelle go-eCharger Firmware einzusetzen.
Auf der Webseite von go-e.co findet man die Bedienungsanleitung zur Wallbox und die Http-API-Beschreibung (die in der Hilfe des Moduls weitgehend beschrieben ist). Der go-E kann nur drei- ODER einphasig an das Stromnetz angeschalten werden (Aussage go-e), vor Änderung der Phasenzahl sollte ein Ladevorgang beendet und die Box stromlos gemacht werden.
Seit Modulversion 0.1.8 wird für amp_current ein neues payload command verwendet - es wurde von go-E zum Schonen des Flash-Speichers eingeführt (s.a. Hilfe zum Modul).


Installation und Update:
Die Box sollte bereits im gleichen LAN eingebunden sein und Verbindung zu Fhem haben.

Entweder manueller Download aus github https://github.com/LuRhe/fhem-46_GoECharger (https://github.com/LuRhe/fhem-46_GoECharger) mit Kopieren in FHEM-Ordner oder besser
über Kommandozeilenbefehl mit Hinzufügen zum Update-Repository:
update add https://raw.githubusercontent.com/LuRhe/fhem-46_GoECharger/main/controls_46_GoECharger.txt

dann FHEM update:
update

und Neustart:
shutdown restart

Device anlegen:
define myGoE GoECharger 192.168.1.34

... und sichern mit save nicht vergessen.

Viele Grüße,
Lutz
Anhänge:
- Screenshot eines goECharger-Devices



EDIT 14.05.2021: Version 0.2.2
- "set <device> restart" für gezielten Neustart eingefügt
EDIT 03.02.2021: Version 0.2.1 und Überführung nach github
- Korrekturwert für gemessene Leistung als Attribut möglich (Meßwert ist aufgrund der IC's des goE meist niedriger als real),
- Hilfe und Code für Attribut used_api_keys korrigiert (nun default, minimal, all);
- devStateIcon geändert auf ev_car_charger.svg (Download s. github);
- diverse Attribute vorbelegt,

Ich kann mir das die Tage gerne mal anschauen.
Welches Modul hast Du als Basis genommen?


Grüße

Hi Cooltux,
hab ja gehofft, dass Du das ggf. auch adoptierst ;)
Basis war Dein TeslaPowerwallAC-Modul - wegen der JSON-Auswertung und NonBlocking Http...
und weil es überschaubar und gut strukturiert ist (aber mit einer Unmenge Readings, die ja per JSON zwangsläufig so rüberkommen).
Viele Grüße,
Lutz

Ich schaue die Tage erstmal. Wenn brauchen wir wenigsten 5 User die das ein paar Tage testen.
Aber ein Schritt nach dem anderen.

Hallo Lutz,

Ich habe mir Dein Modul angeschaut und eine Frage.
Möchtest Du mehr über FHEM Modulentwicklung wissen oder reicht es Dir wenn dieses eine Modul für Dich so funktioniert wie es funktioniert.


Grüße
Marko

Das Modul ist hoffentlich nicht nur für mich nützlich, sondern auch für andere. Wenn es über die Distro/Update mitkommt, ist die Installation für viele einfacher.
Ansonsten würde ich natürlich gern tiefer einsteigen, weil ich noch paar offene bessere Lösungen anstelle HttpMod suche (Fronius PV, Tesla). Hab auch noch ein altes Modul für Wärmepumpe, was mit Blocking arbeitet. Leider ist es so, dass ich zu selten was mache und oft wieder von vorn reindenken muß, Fhem intern zu verstehen und Perl zu lernen. Soll ich in der Developer-Ecke mal ein Thread zu der Modul-Progr. aufmachen?
Ansonsten würde ich schauen, wo Du was schicker machst: sicher die Set-Funktion und Def/Attr.
Danke, Lutz

Also eigentlich habe ich nicht die Zeit da was zu machen. Deswegen habe ich Dich gefragt ob Du Interesse hast tiefter in FHEM Modulentwicklung ein zu steigen. Dann zeige ich Dir gerne wie Du wo was machen kannst.
Aber das ganze Modul zu pflegen schaffe ich aktuell nicht. Wenn Du also Lust hast mehr zu lernen und zu machen dann wäre mein erster Ansatz ein VideoCall da ich einige Fragen habe.


Grüße

Danke für die Hilfe.
Habe damit einiges optimiert. Das einzig ungewöhnliche im Code ist m.E. noch das Löschen aller Readings, wenn man die Anzahl der auszulesenden API-Keys/Readings über Attr anpasst. Dies soll aber ewige Reading-Leichen verhindern. Die ActionQueue ist im Code noch drin (schadet nicht), da das Herausnehmen aufwendiger ist. Wäre höchstens schöner für Lesbarkeit des Moduls.

Was genau passt denn noch nicht beim löschen?

Die Fhem interne Funktion deleteReading erwartet ja den genauen einzelnen Readingname (um dann reading und oldreading dazu zu löschen). Es gelingt mir nach wie vor nicht, eine Schleife durch alle Readings des Hashes zu machen, um jeden Readingnamen als String dabei zu erhalten und zu prüfen (Dein letzter Tip aus PM ging auch nicht).
Also hab ich mal noch den externen fhem-Aufruf zum löschen der Readings in der Attr-Funktion drin ( {fhem ("deletereading $name .*")}; ).

Das ist seltsam. Bei mir geht mein Code. Eventuell liegt es daran wo Du ihn ausführen lässt.

danke für das neue modul, verwende noch das alte hier.
aber "verbindung abgelehnt", was muss man noch definieren?

lg

[edit] klappt jetzt. wlan verbindung des go-E ist sehr misaerabel......

Sorry, die Version oben 0.1.5 ist grad noch fehlerbehaftet, die Hilfe-Anzeige geht nicht auf allen Systemen. Hab ja zwischenzeitlich auch nicht gehört, dass es jemand überhaupt nutzt.

Ja, der go-E braucht starkes WLAN, hat nur schwachen Sender/Empfänger. Ich hab ein Repeater gebraucht und musste wieder lokal in den Hotspot und Neustart machen...

Edit: Wenn man das Modul neu reinkopiert und nur reload... macht, reicht das nicht. Es braucht ein löschen des Gerätes oder ein Restart. Ggf. noch ein deletereading für das device mit .* (wenn man es nicht neu anlegt).
Die Hilfe wird auf meinem Pi nicht kpl. angezeigt, anders als auf meinem Testsystem unter Win...

Hier mal ein raw - Beispiel zum define mit Modifikation der Icon-Anzeige...
EDIT: nochmal korrigiert an Version 0.1.5:


defmod myGoE GoECharger 192.168.0.xxx
attr myGoE devStateIcon disabled.*:ev-station@darkgrey not_allowed.*:ev-station@white ready_no_car.*:ev-station@blue charging.*:ev-station@darkorange waiting_for_car.*:ev-station@pink finished.*:ev-station@lime error.*:ev-station@red .*:ev-station@yellow
attr myGoE interval 60
attr myGoE room Energie
attr myGoE used_api_keys default


Hier ein Raw eines DOIF für Überschuß-Laden eines Tesla Model3 (unter Mitnutzung und Auswertung Tesla Powerwall) inkl. des nötigen Weckens des M3 über Modul Teslacar aus github. Die VIN_des_Teslacar muss entsprechend angepasst werden. Für die Powerwall2 hab ich separate HttpMod (hier im Bsp. PW2_Meters und PW2_SOC) definiert, die mir Info's zum Hausverbrauch und zur Powerwall liefern. Schön ist was anderes - es funktioniert aber zunächst erstmal so, wie ich es gerade brauche...

Als Code konnte ich das nicht einfügen (Fehler Textfeld wurde nicht ausgefüllt), daher als Anhang die Textdatei des Raw (als Template für Anpassung an eigene Bedürfnisse...).

Hier ein DOIF für die autom. Einstellung der Helligkeit der LED mittels definiertem Twilight-Modul...

defmod di_GoE_led_brightness DOIF ([+00:10])\
  (set GoE led_brightness [?Twilight:twilight:d1:$1*2+30])\
DOELSE
attr di_GoE_led_brightness cmdState set|wait
attr di_GoE_led_brightness do always
attr di_GoE_led_brightness room Energie,control


kannst du mir weiterhelfen?


unexpected end of string while parsing JSON string, at character offset 948 (before "(end of string)") at ./FHEM/46_GoECharger.pm line 697.

wie setzt man zusätzliche api für abfrage?

Gern, wenn möglich.
1. Hast Du Version 0.1.5 (steht bei den Internals) und was für eine SW-Version hat der go-E? Da kommt im Json was, was bei mir anders ist und was wohl die Perl-Funktion eval{decode_json($json)};stört.
2. Benutzt Du die Api-Keys wie default (nach Installation) o. was stehen bei Dir bei den Internals für aktive API-Keys?
3. Kannst Du bitte mal verbose auf 4 setzen, dann sollte im Logfile/Event "GoECharger ($name) - Recieve JSON data: $data"; mit den tatsächlichen Json-Daten auftauchen. Diese bitte mal senden.

Andere Variante: reduziere die von Dir tatsächlich benötigten Api-Keys im Attribut - bei einem steht viell. nix oder was schlechtes drin.
Mal sehen...
Hast Du neu installiert bzw. neu definiert?

Zitatwie setzt man zusätzliche api für abfrage?

Das Attribut unten anpassen (used_api_keys): statt Wort default geht z.B. auch editierte Kopie der Liste unter Internals.
Die Syntax muss aber passen und nur ein Leerz dazwischen...

Alternativ: Das Attribut kann statt default auch auf minimal oder allkeys gesetzt werden - oder eben Liste...

PS: Du kannst auch in einem Browser wie Firefox einfach mal http://192.168.x.yyy/status eingeben, um zu sehen, was der go-ECharger über die API an Keys und Werten dazu liefert...

Zitat von: LR66 am 09 Mai 2020, 18:47:50
PS: Du kannst auch in einem Browser wie Firefox einfach mal http://192.168.x.yyy/status eingeben, um zu sehen, was der go-ECharger über die API an Keys und Werten dazu liefert...

kenn ich, habe auch die doku. fw 033

Gesendet mit Tapatalk

Ok, Du kannst ja mit dem o.g. das Problem eingrenzen.
Könnte es sein, dass es zu Verbindungsproblemen WLAN kommt und die Antwort der zykl. Abfrage unvollst. kam (go-E ggf. mal näher am Router in die Steckdose packen oder Repeater probieren)?

Wenn es ein Modulfehler ist, würde ich mich freuen, mehr zu hören - natürlich auch, wenn es wie erwartet geht.

PS: fwv 033 habe ich auch im go-E

den einzigen fehler den ich noch entdecken konnte, wenn ich die ootion "all" bei den api nehme das dann keine readings kommen. aber ich werde das mit der manuellen methode heute testen . komisch ist nur das ich das eigene Wlan von goE locker 20m weiter über 192.168.4.1 immer erreiche, nur über die ip vom router teilweise.

Gesendet mit Tapatalk

so, habe nun die ip neu vergeben, und es dürfte besser laufen. evt. Router problem gewesen.
Waren die readings nicht in deutsch? Habe jetzt alles englisch. Sonst läuft es richtig gut, danke dafür.

WIe frage ich die Spg., und Leistung auf den Phasen ab? nrg[0] klappt nicht z.b.

Na das freut mich ja.
Das nrg-Array hab ich bis auf eins nicht ausgewertet, wäre extra Aufwand weil ja gesondert key und value zu ermitteln wären (ein Array versteckt in der Json Antwort). Dito mit Fehlermeldungen... - gibt ja noch die App. Primär wollte ich Steuerbarkeit. Die Spannungen stimmen ja leider auch nicht (bei mir ca. 10V niedriger). Ich nehm die vom go-E gemessene Ladeleistung und hab sie mir neben das icon gepackt, um zu sehen wie es lädt. Sonst schau ich noch die Phasen, daher Binärdarstellung. Zum Einstellen Ladestrom bzw. Ladeleistung geh ich vom rechnerischen Wert aus. Hältst Du nrg für sinnvoll? Der go-E berechnet ja selber mit den vielen Einzelwerten z.b. die akt  Ladeleistung. Ich würde eher einen Korrekturfaktor für die Leistung einbauen  zb. Faktor 1,05, weil die Spannungen nicht passen.

PS: Das Atribut used_api_keys kann anstelle einer Api-Key-Liste auch eines von 3 Schlüsselwörtern sein: "default", "minimal", "allkeys" (ohne Anführungszeichen) - also nicht "all"  Ich brauchte im  Code klaren Unterschied zu 3-Buchstaben-API-Strings...

Wird bei Dir im Web die Hilfe angezeigt??

PS: die Readings hatte ich so gut es geht in englisch gemacht, ist m.E  universeller und ermöglicht fast immer kürzere Wörter. Nur im Modulcode sind Kopie'n aus der dt.-sprachigen Api...

help wird mir angezeigt, ja. ;)

Bei mir funktioniert es seit letzter Änderung im Mai problemlos, nutzt es noch jemand? Gibt es Änderungsbedarf? Geht bei Euch die Hilfe zum Modul (auf meinem Haus-Pi erstaunlicherweise nicht)?

Hallo Lutz,

ich nutze / möchte es auch nutzen.
Aktuell habe ich jedoch Probleme dei Ertragsdaten der PV Anlage zu Fhem zu bekommen. Lese diese über ein EM1000 ein, aber die Funkverbindung ist instabiel. Es kommen ca 30 Min lang Daten, dann kommt nix mehr. Muss den EM dann immer neu starten.

Jedenfalls, wenn mal neue Werte kommen, regelt das Modul den Go-e erstmal soweit ganz gut.
Durch die Datenprobleme kann ich es aber noch nicht so nutzen wie ich möchte. Die Hilfe geht bei mir.

Gruß Stefan

Schön zu hören, dass es mit dem go-e prinzipiell funktioniert.

Ärgerlich, wenn Du EM1000 hast und der nicht gut empfangbar ist (Repeater gibt es da nicht?). Du hast doch bestimmt elektron. 2-Richtungszähler? Ich meinte da reicht quasi schon eine Fotodiode zum TTL-seriell-empfangen und serielle Pakete  viell. mit ESP8266 per Wlan an Fhem senden und wie Volkszähler einbinden? So in der Art hatte ich das vor, bis ich gemerkt hatte, dass PV-Sensor und PV-Speicher ja auch nötige Info's zum PV-Überschuss haben und ich den Zählerzugriff nicht unbedingt brauche. Hängt aber eben von der Anlage ab.
Danke für die Rückmeldung und viel Erfolg,
Lutz

Hallo Lutz,

gehört zwar nicht hier in dieses Thema, aber möchte dir trotzdem hier gerne kurz antworten, evtl interessiert es ja noch andere.

Das mit dem EM1000 war erstmal die einfachste Art die PV Anlage auszulesen (hatte ich noch da). Der Ertragszähler ist noch mit Ferraris Scheibe (Anlage von 2009).
Der EM sitzt provisorisch ca 3m Luftlinie vom Fhem Raspi und sendet auch regelmäßig alle 5min. Es gibt da zwar eine Holzwand dazwischen, aber die Tür ist auf. Jedes mal nach einem Neustart vom EM kommen die Werte auch in Fhem an, jedoch nach ca 20-30 min gibt es in Fhem keine Aktualisierungen der Werte mehr, bzw kommen nicht an. Gesendet wir aber trotzdem (rote LED am EM).
Bei den Tests war das schon recht gut, obwohl ich sagen muss, das mir die 5 min Intervalle eh nicht so richtig gefallen. Wenn es viel abwechselnd bewölkt ist, wird halt auch sehr oft Strom zugekauft bis wieder neu nachgeregelt wird. Von daher ist das eh nicht die beste Wahl.

Der zweirichtungs Zähler ist nicht so der modernste. Er hat eine rote LED für die KwH, aber die ist für beide Richtungen. Es leuchtet dann zusätzlich noch eine grüne für Lieferung oder Bezug. Somit kann ich den Eigenverbrauch auch nicht wirklich mit in Fhem einbinden, zumindest nicht ohne größeren Aufwand.

Eigentlich logge ich den PV-Ertrag über den SunWatch, aber des bekomme ich mit Fhem nicht hin den auszulesen. Hatte es mit diesem ECMD Modul versucht, aber bin nicht so der programmier Held.

Mal sehen, ob ich mir das mit dem ESP8266 mal anschaue, oder ob das meine Fähigkeiten übersteigt.

Separate Hardware, wie ein SmartMeter, wären schon nicht schlecht. Jedoch habe ich im Verteilerschrank absolut keinen Platz mehr. Es müsste also auf irgendwas externes raus laufen.

Gruß Stefan

Ok, mit so alten Zählern bringt auch Bastelaufwand nix, aber dafür hast Du gut EEG. Ja, ist Off-Topic aber passt im Zsh. Ein Zählertausch auf moderne, leichter auslesbare Bauform wird Dir der Netzbetreiber wohl erst zum Zwangstermin oder gegen Geld machen. Als ich noch keine PV hatte, hätte das wohl ~120-180€ gekostet und trotzdem noch basteln oder Zukauf nötig gemacht. Schau Dir mal AWattar.de mit Tarif Hourly oder Cap an, ob das was für Deinen Netzbezug wäre . Die machen dann, was die Grundgebühr erhöht - den Meßstellenbetrieb über Discovergy. Monatl. kündbar, aber an Discovergy wärst Du 2J gebunden (muss Dir aber anderer Versorger rausrechnen). Dann würdest Du einen smarten Zähler von Discovergy bekommen - da hab ich grad 'fhem discovergy' gegoogelt: https://forum.fhem.de/index.php?topic=61271.0
... und Du würdest nach stündl. Börsenpreis Grünstrom abrechnen. Das wäre eine Variante an einen guten Zähler und guten Tarif zu kommen, im TFF-Forum haben welche von 22ct im Schnitt geschrieben (glaub ich nicht ganz). Bei der höheren Grundgebühr hat sich das bei mir mit Miniverbrauch (hohe Eigenversorg.) nicht gerechnet und hab dann doch Yearly-Tarif ohne Zählerwechsel genommen (besser als hiesiger Versorger).
PS: Ich denke die würden folglich nur den 2-Richt.zähler auf Discovergy machen, der Ferraris-Ertragszähler würde bleiben.

Hallo Lutz, super Modul - "nutze" ich seit heute - da mein go-e auch erst heute ankam & eingebaut ist.
Ich habe die Messwerte noch nicht verglichen, werde ich morgen mal tun.
Bei mir läuft FHEM auf einem Ubuntu 16.04.3 - und die Hilfe geht nicht, wenn ich darauf klicke erscheint zwar unter der Fusszeile fett und groß "Go-eCharger", aber weiter nix.
Muss mir auch noch passende Daten für das DB logging machen, sowie ein Plot, oder ggf. ein Plot pro Fahrzeug (es werden bis zu 3 KFZ) geladen mit unterschiedlichen RFIDs.

Werde meine Erfahrungen natürlich hier posten  ;)

Danke soweit für das Modul  :)
Torsten

Das freut mich. Mit dem Hilfethema ist es ärgerlich, aber da das Modul läuft, hab ich auch nix weiter daran gemacht. Die RFID-Namen und -Nummern kannst Du ja m.E. in Deinen Wunschreadings einblenden, mindestens das Anlernen geht nur am Gerät/über App. Der goE misst bei mir ca. 10V je Phase weniger, als real. Wenn es bei Dir auch ist und Du auf genaueren Wert brauchst, könntest Du ja die Leistung über Fhem und ein UserReading oder Readingsprox auch mit einem Korrekturwert multiplizieren.

Hallo,

benutze auch dein Modul, funktioniert mit Tesla Model 3.
Ich würde noch die Readings in deutsch oder englisch ermöflichen über Attribut.
Eventuell Start /stop Button.

Sonst alles super.

Andy

Danke für die Rückmeldung und Nutzung! Auch wenn mein Englisch nicht das Beste ist, hat es teilweise auch echte Vorteile Englisch zu nutzen, weil die Begriffe oft kürzer sind und in der Darstellung ni so so viel Breite brauchen. Beide Sprachen wäre leider eine echt aufwendige Schreib-/Programmierarbeit für einen nicht so ausgesprochenen Programmierer wie mich ::) Was das Start/Stop betrifft: Du kannst Dir doch m.E. das webcmd nach Belieben konfigurieren? Edit: und über DevStateIcon auch definieren, was beim Tippen auf den jew. Iconzustand passiert...

Hallo Lutz,

hat sich gerade überschnitten. Start Stop habe ich inzwischen so gemacht.
Andreas

Hallo zusammen

Ich habe heute mein go-e in Betrieb genommen. Als nächstes will ich den Charger in FHEM einbinden mit diesem Modul hier. Mit welchen webcmd lässt sich die oben beschriebene Start/Stop Funktion realisieren.
Ich möchte den Ladevorgang aus FHEM heraus stoppen können.  Ist dafür alw=0 zu verwenden
Oder wie hast Du das gemacht, Andreas?

Gruss, birdy

Hallo birdy,
schön zu hören.
Auf die Schnelle anbei ein Screenshot meiner Attributes - dies zeigt ein Standard on und off zur Bedienung ohne explizites webcmd (durch eventmap). Man kann :on oder :off auch an diejenigen Stati des devStateIcon hängen, wo man ggf. gezielt mit Klick auf das Icon die explizite Änderung möchte (on off geht aber wie bei einer Lampe so auch schon bei Klick auf Ladesäule)

PS: fp_Haus ist bei mir meine Position für die Darstellung im Floorplan.
Die ausgelesen kWh könnte man auch noch mit einem Faktor multiplizieren, da m.E. jeder go-E die  Spannungen meist konstant niedriger anzeigt (und zur Berechnung verwendet) als sie tatsächlich im Auto angezeigt werden. Bei mir ca. knapp 5% mehr Leistung in der Realität als der go-E anzeigt/berechnet.

On off geht ja aber auch über App, also besser ist dann noch Automatisierung mit DOIF für zeitgesteuertes, kWh-vorgegebenes oder PV-Ertrag abhängiges Laden (oder für Laden ohne in Limit Haussicherung zu laufen, falls viele Verbraucher an sind)... das hängt dann davon ab, was Du noch so in Fhem an verwertbaren Geräten/Sensoren/Readings
hast.
Vg Lutz

Hallo Lutz

Ich möchte Wochentag abhängig mein Auto laden. An den meisten Tage nur auf 80% an andern darf es dann gerne etwas mehr sein.  FHEM hat die Kontrolle und soll dann die Ladung des go-e abbrechen sobald der gewünschte Ladestand erreicht ist. Dafür muss ich wissen welchen Commandi ich dafür verwenden kann.

Gruss, birdy

Hallo birdy,
das sollte über eine DOIF - Steuerung gehen, wenn Du Zugriff auf den SoC des Fz  hast. Aber kannst Du nicht auch im Auto generell ein Limit 80% einstellen und dann einfach einstecken, wenn Du kommst? Ansonsten siehst Du die set-Befehle unter der Commandline (eschreibung in Hilfe oder in der Datei .pm):
- zum Freischalten: set GoE allow_charging 0 macht aus, 1 an (in der App vorher unter Einstellungen Zugangskontrolle per RFID/App aktivieren), alternativ wenn Du eventmap wie ich oben gemacht hast geht auch set goE on oder set goE off
- Stromstärke auswählen: set GoE amp_current 16
- Laden von zb 32 kWh: set GoE stop_at_num_kWh 32
(statt goE Dein Devicename)
Wie liest Du den SoC aus, hast Du da ein Reading? Was für ein Fz. hast Du? Kannst Du die Ladegrenze auch über ein set für das Fz. setzen?
Bei DOIF kannst Du ja mal Kapitel Zeitstruerung in der Commandref lesen.
Viele Grüße,
Lutz

Hallo Lutz

Habe ein Kona EV. Könnte natürlich die Ladegrenze auch im Fz. setzen. Aber meines Wisssens geht das nur fix und nicht abhägign vonm Wochentag.  Ich habe keine Lust die Grenze täglich zu verstellen. Für etwas habe ich ja FHEM und ein go-e :-)
Setze also im Fz. 100%  und berche dann, ja nach Wochentag, bei z.B. 80% ab. 
Den SoC lese ich über ein altes Handy, welches in Fz., liegt via EVnotify aus.
Die Logik zur Steuerung werde in in einer Sub in 99_myUtils.pm programmieren. Da sind noch ein paar andere Parameter die ich berücksichtigen will.
So will ich den LS (leider nur 16A) möglichst nahe an der Kennlinie betreiben. Warm darf er werden aber nicht auslösen.

Das ist schön, ein Kona! Wenn das Handy den Kona SoC lesen kann, kriegst Du das viell. auch noch direkt nach Fhem - hat da noch keiner was gemacht? Da ginge viell. auch noch mehr... Für Deine Ladestrategie könntest Du auch die zu ladende kWh-Differenz berechnen und über den go-E vorgeben, dann beendet er so. Zusätzlich könntest Du die Lade-Dauer abschätzen und Beginn der Ladung so setzen, dass z.B. bei Langfahrten zum Abfahrtszeitpunkt ausnahmsweise eben 95-100% drin sind.
PS:
Wenn Dein LS  16A das Limit ist, dann setze am Besten auch in der Software des go-e ein Limit: "set goE max_amp_Wallbox 16" (oder eben 15). Bei mir ist wg. dünnem Kabel zum go-e eine CEE16-rot und ich hab den zugeh. Adapter dazwischen, da wird dieser Wert schon über die go-e Hard-/Software gesetzt. Geschieht ja auch bei dünnem Typ-2 Kabel. Solltest Du zur Sicherheit mal prüfen und ggf vorgeben.
Viel Erfolg und Freude beim Fahren und der Ladesteuerung!

Danke. Welches Fz. hast Du?
Den SoC habe ich in FHEM, muss also keine kWh-Differenzen berechnen :)

go-e hat ja einen 32A Stecker. Stecker und Leitung dazu sind frisch verlegt und für 32A ausgelegt. Aber nur 16A bewilligt, darum ist die Leitung nur mit 16A abgesichert. Der "Schwachpunkt" ist also der LS. Wer schon mal die Kennlinie von LS studiert hat weiss, dass die nur bei Kurzschluss schnell Schalten. Bei Überlast sind die träge. Da gibt es Reserven, und die will ich rausholen. Ein paar % Überlast hält ein LS schon eine gewisse Zeit aus.

Gestern habe ich knappe 4 Std. mit 20 A Einstellung auf go-e = effektiv 19.1A geladen. Der 16A LS wurde spürbar warm, aber ausgelöst hat er nicht.
Je nach errechneter Ladedauer wird überlastet, so viel wie gem. Kennlinie und Erfahrungswert eben geht. 
Gruss , birdy

Ich hab Model3 - von daher kann ich eh nur 11kW bei AC. Ich weiß ja nicht was der Kona max kann (22kW?), aber würde schon bei 16A bleiben und das nicht ausreizen und auch im go-E als Limit setzen. Sollte doch dann auch in spät. 7-8h voll sein?
Viele Grüße, Lutz

Keine Angst ich weiss was ich mache.
Mein Kona MY19 kann nur einphasig laden, dafür auf dieser einen Phase 32A.
Du siehst mit 16A (1x16x230 = 3.6kw) kommt man eben nicht so weit, das gilt es jedes A auszunützen.
Erst MY20 hat 3Phasenlader mit 11kW, der kann dann wirklich nur 16A, dafür auf allen 3 Phasen.

Hallo Lutz
Vielen Dank für die Bereitstellung dieses Modules. Funktioniert bei mir seit ein paar Tagen ausgezeichnet.
Evtl. eine blöde Frage, aber wie kann ich am elegantesten auf eine Änderung des car_state reagieren? Ich habe aktuell einen Notify auf den car_state definiert. Funktioniert soweit auch. Aber der wird alle 60 S (Default Interval) ausgeführt. Was nicht sein müsste sondern eben nur wenn der car_state auf 1 wechselt.

Hintergrund meiner Frage: Wenn das Fz den gewünschten SoC erreicht hat, setze ich allow_charging = 0 was die Ladung unterbricht. Sobald das Kabel aus dem Fz entfernt wird soll allow_charging =1 gesetzt werden. So dass beim nächsten anstecken das Fz automatisch wieder zu laden beginnt.

Gruss
birdy

Versuch mal Dich in DOIF einzulesen und dort als auszuwertend das Reading (nicht Event) zu nehmen.
Alternativ oder in Deinem Fall viell. einfacher kannst Du für go-E-Modul das Attribut event-on-change-reading setzen ( mal im Forum/Wiki/commandref suchen: ich hab es sogar auf alles mittels .* gesetzt), sodass nur Wertänderungen zu einem Event führen (also ni alle 60s sondern nur wenn sich der car_state ändert).
Dann geht auch Dein notify nicht alle 60s.
Viele Grüße, Lutz

Genau ein DOIF auf das Reading "car_state" ist das was ich gesucht habe. Funktionier bestens  :)
Vielen Dank für diesen Tip
Gruss, birdy

Hallo zusammen,
Regelt hier jemand die Leistung des go e abhängig von seiner PV Anlage? Ich frage mich gerade wie ich das machen könnte. Klar ein doif aber ich möchte ja mit der ladeleistung hoch und runter gehen. Und bei einem doif  PV Leistung > 3000 Watt könnten ja dann auch das doif PV Leistung > 2000 Watt zuschlagen. Ich hoffe ich konnte mein Problem so halbwegs formulieren.

Weiter oben hatte ich ein Beispiel meines DOIF für PV-Laden als Text "GoE_max_PV_DOIF_raw.txt" angefügt. Das Beispiel kann deutlich vereinfacht werden - bei mir wird ja zusätzlich das Auto geweckt und der Speicherstand des Hausakku geprüft. Sowas, wie auch Meldung über Telegram, könnte z.B. auch raus. Bei mir läuft der go-E aber dreiphasig, womit die minimale Ladeleistung 3×6A×230V ist, darunter hilft dann mein Speicher und es soll beendet werden, wenn dieser eine bestimmte Grenze unterschreitet. Man könnte vor den go-E auch Schütze in die Phasen setzen und bei Unterschreiten der PV-Leistung 3x6Ax230W die Ladung anhalten, den go-E abschalten, nur mit einem Schütz einphasig neu starten und weiter mit niedrigerer PV laden. Ob das Sinn macht, ist eine Frage, da ja die gesamte Ladeelektronik des Auto's ganz schön lange anbleibt und einen Ladeverlust bedeutet. Für Regeln ab 6A ist ein DOIF wie oben ok, man muss halt entscheiden, wie oft man den Sensor überprüft (oder dessen Polling verändert), um auf Wolken o.ä.zu reagieren. Ich hoffe, ich hab Deine Frage damit etwas beantworten können.

Zitat von: Chris_XXX am 11 September 2020, 07:45:26
Hallo zusammen,
Regelt hier jemand die Leistung des go e abhängig von seiner PV Anlage? Ich frage mich gerade wie ich das machen könnte. Klar ein doif aber ich möchte ja mit der ladeleistung hoch und runter gehen. Und bei einem doif  PV Leistung > 3000 Watt könnten ja dann auch das doif PV Leistung > 2000 Watt zuschlagen. Ich hoffe ich konnte mein Problem so halbwegs formulieren.

ja, ich z.b. mit DOIF


([10:00-17:00] and [GoECharger:amp_max_cable] > 6 and [GoECharger:allow_charging] eq "0" and [solarlog_totalpac] >= 2500) ((set GoECharger allow_charging 1),( set GoECharger amp_current 6))
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "11" and [PowerMeter] >250) (set GoECharger amp_current 12)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "10" and [PowerMeter] >250) (set GoECharger amp_current 11)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "9" and [PowerMeter] >250) (set GoECharger amp_current 10)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "8" and [PowerMeter] >250) (set GoECharger amp_current 9)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "7" and [PowerMeter] >250) (set GoECharger amp_current 8)
DOELSEIF ([10:00-17:00] and [GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "6" and [PowerMeter] >250) (set GoECharger amp_current 7)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "12" and [PowerMeter] <1) (set GoECharger amp_current 11)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "11" and [PowerMeter] <1) (set GoECharger amp_current 10)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "10" and [PowerMeter] <1) (set GoECharger amp_current 9)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "9" and [PowerMeter] <1) (set GoECharger amp_current 8)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "8" and [PowerMeter] <1) (set GoECharger amp_current 7)
DOELSEIF ([GoECharger:car_state] eq "2" and [go_e_Steuerung:state] eq "7" and [PowerMeter] <1) (set GoECharger amp_current 6)
DOELSEIF ((([16:00-18:00] and [GoECharger:car_state] eq "2") and [solarlog_totalpac] >= 1 and [PowerMeter] <1) or ([GoECharger:amp_max_cable] < 6)) (set GoECharger allow_charging 0)

Habe das Modul heute installiert und es läuft nach ersten Tests einwandfrei  :)
Auch die Modulhilfe wird richtig angezeigt, FHEM läuft bei mir auf einem ubuntu-Server 18.04.2

Beim go-E habe ich mich gestern zu einem Firmware-Update via App auf die v040.0 hinreissen lassen, aber auch damit kommt das Modul wohl zurecht.
Vielen Dank an @LR66   :)

Hat von Euch auch schon jemand die FW v040 drauf ?
Seit dem Update funktioniert der Neustart via App (Cloud) nicht mehr richtig: goE hängt sich nach Restart auf (unten 1 grüne und 10 weiße LED's, rechts oben die x blauen Strom-LEDs, WLAN aus) und muss durch Netztrennen restartet werden. Habe Support angeschrieben, muss aber noch auf Antwort warten.

Danke für die positive Rückmeldung. Das go-E Update hab ich durch Deinen Post erst jetzt wahrgenommen - da warte ich wohl  dann lieber ...
Vg Lutz

Ich habe jetzt mittels Supportunterstützung von go-e wieder ein Downgrade auf die Firmware 033 gemacht. Jetzt ist das Aufhängen nach "Neustart" gottseidank wieder weg.
Warnung: Ich vermute die 040, die über die App zum Update angeboten wird, ist noch etwas buggy und mit Vorsicht zu genießen.

@LR66: Kannst Du die Firmware Version vielleicht auch noch als Reading auslesen ?
(fwv im JSON)

Ich hatte es am Wochenende gewagt mit 040 - ging bisher problemlos inkl. Neustarts.Ich hatte mal probiert, ob ich dem go-E eine Phase wegschalten kann - das mag er nicht.
Nach Rü. mit go-E:

Zitatein zweiphasiger Betrieb ist beim go-eCharger nicht möglich - darauf folgt immer ein Fehler.
Es ist lediglich ein einphasiger oder dreiphasiger Betrieb möglich. Allerdings empfehlen wir hierbei unbedingt den Charger beim Umschalten komplett vom Netz zu nehmen damit es zu keiner Beschädigung am Auto oder am Charger kommt. Bei manchen Autos kann dabei sogar tatsächlich der Lader defekt werden.

Nur als Tip, falls jmd. nur einphasig z.B. nach PV laden will. Dann also Laden Auto deaktivieren, alle Phasen abschalten, nur mit einer Phase (denke L1) wieder einschalten.

Wegen fwv (Firmware) als Reading: Du kannst doch frei entscheiden welche Readings benutzt werden (s. HILFE und used_api_keys Attribut.
Vg Lutz

Hallo zusammen!

Habe seit gestern einen go ECharger Home+ (22kW). Das Modul läuft super, auch mit der neuen FW (0.40). Musste nach dem Update auch den Strom wegnehmen...

Den aktuellen Bezug/Stromfeed (habe eine 9,6kWp-PV-Anlage) lese ich über das OBIS-Modul und einer zweiten FHEM-Instanz auf einen RPi im Technikraum aus und schicke alle 60s den Dummy via FHEM2FHEM auf meinen Haupt-FHEM-RPi.

Das DOIF von LR66 hat mir sehr geholfen, vielen Dank dafür! Habe es auf meine Bedürfnisse angepasst:

## 1 ## incr
## Tagsueber Ladestrom nach PV steuern # Ladestrom stufenweise erhoehen
(([06:30-23:00])                                  ## tagsueber, evtl. hell
and ([powermeter:power] < -690)                   ## Einspeisung > 690 Watt
and ([?goe:amp_current] < [?goe:amp_max_wallbox]) ## Unter maximalem Strom?
and ([?goe:car_state] == 2))                      ## Auto laedt
(set goe amp_current [goe:amp_current:d:$1+1])   ## Strom 1 Amp erhoehen
##
## 2 ## decr
## Ladestrom stufenweise erniedrigen, keine / wenig Einspeisung tagsueber
DOELSEIF (([06:30-23:00])                         ## tagsueber, evtl. hell
and ([powermeter:power] > -690)                   ## Einspeisung < 690 Watt
and ([?goe:amp_current] > 6 )                     ## ueber minimal 6 Amp
and ([?goe:car_state] == 2))                      ## Auto laedt
(set goe amp_current [goe:amp_current:d:$1-1])   ## Strom 1 Amp erniedrigen
##
## 3 ## fullpower
## Ladestrom Nachts maximal, Netz weniger belastet. Bis 06:30, da hier Auto im Winter vorgeheizt wird.
DOELSEIF (([23:00-06:30])                         ## Nachts, kein PV, wenig Netzlast
and ([powermeter:power] > -10000)                 ## Einspeisung < 10kW = immer
and ([?goe:car_state] == 2))                      ## Auto laedt
(set goe amp_current [goe:amp_max_wallbox])      ## auf maximalen Strom stellen
##
## 4 ## finished
## Laden fertig
DOELSEIF ([goe:car_state == 4])                   ## Laden fertig
()
##
## 5 ## start
## Auto angeschlossen, Laden starten mit niedrigem Strom (6A)
DOELSEIF ([goe:car_state] == 3)                   ## Warten auf Auto
(set goe amp_current 6)                          ## auf minimalen Strom setzen, obige Regeln erhoehen je nach PV-Strom
##
## 6 ## nocar
## Kein Auto angeschlossen
DOELSEIF ([goe:car_state] == 1)                   ## Bereit, kein Auto
()
##
## 7 ## charge
DOELSEIF (([goe:car_state] == 2)                  ## Auto laedt
and ([powermeter:power] > -10000))                ## Einspeisung < 10kW = immer
()
##
## 8 ## wait
DOELSE
()


Danke für euren Input, ist sehr hilfreich!

Flo

Hallo zusammen,
vielen Dank für das super Modul!!
Ich habe es installiert und meinen neuen go-e 11kw Charger gestern Abend erfolgreich eingebunden. Die Steuerung zusammen mit der PV-Produktion klappt super.
Jetzt fehlt nur noch mein e-Niro zum Anschließen  ;)
Viele Grüße, Peter

P.S.: Wer eine sonnen Batterie ECO8 hat und z.B. das Entladen unterdrücken möchte, findet hier meinen Lösungsansatz: https://forum.fhem.de/index.php/topic,32037.msg1100149.html#msg1100149

Danke für Eure Rückmeldung und das übersichtliche gute DOIF von bofax / Flo !
Viel Spaß dann beim Laden und elektrisch fahren!
Viele Grüße,
Lutz

Hallo,
das set Kommando zum Regeln des Ladestromes (über 'amp_current') habe ich mit Version 0.1.6 (siehe Threadstart) nun so geändert, dass der neue Wert nicht im EEPROM gespeichert wird (erfordert neue Firmware 040 mit dem von go-e neu implementierten payload command 'amx').

Da man gerade bei PV-geführtem Laden den Wert per Fhem oft ändert, ist die bisherige API-Funktion auf die Dauer schlecht für den Flash-Speicher.

Das bisherige Setzen des Stromes wie in der App mit Speicherung im EEPROM gibt es nun noch als 'amp_current_eeprom' - damit kann man den Wert dort speichern (für Verhalten nach Neustart). In Fhem wird das Setzen im EEPROM im Reading 'Saved_amp_current' vermerkt. Achtung, die Nutzung der App oder anderer Prog ändert das gegebenenfalls.
... s. auch Hilfe
Weiterhin wurde das Setzen des Stromes limitiert auf den kleinsten Wert von (Wallbox max, Kabel, Temperatureinschränkung, Adapterverwendung).
Viel Spaß beim Testen,
Lutz

Danke für das tolle Modul!  :) Super, dass die amx Unterstützung jetzt geht.

Ein Problem seit 0.1.6 bei mir: der Slider bei amp_current zeigt mir nur noch die Werte 0-6 an, ein manuelles set GoE amp_current 16 z.b. ergibt ein "Arg 16 not allowed for amp_current".

Firmware ist die 040, App-Bedienung funktioniert...

 Oh, dein Problem schau ich mir an. Es soll beim Setzen von amp_current geprüft werden, das man amp_max_wallbox, amp_limit_by_temp,  amp_max_cable nicht überschreitet und bei Adapter (amp_max16A_adapter=1) nicht über 16A geht - das hat bei mir die App z.B. zumindest per Slider teilweise nicht verhindert. Dass bei Dir die 16 nicht geht, ist aber sicher ein Fehler in meinem Code. Schau bitte mal, was amp_max_wallbox für einen Wert hat (bzw. setze es auf Wert Deiner vorgelagerten Sicherung) und was die anderen o.g. Readings zeigen. Ich prüfe heute abend mal den Code.

amp_max_wallbox ist bei mir auf 16 (habe die Homefix 11kw), amp_max_cable ist 20 und das Reading amp_limit_by_temp habe ich gar nicht. Nur temperature, das steht auf 2. Der Befehl http://192.168.x.x/mqtt?payload=amx=16 im Browser funktioniert übrigens, das wird auch im Modul korrekt übernommen.

Habe nach Rückmeldung Kasi13 nun Version 0.1.7 eingestellt.
Für das Setzen von amp_current oder amp_current_eeprom (per Befehl oder Slider) wird nun der obere Wert nur noch gegen den

• lokalen Maximalwert der Wallbox gem. Reading amp_max_wallbox (payload 'ama'),
• vom go-E ermittelten Maximalwert des Typ2-Kabels gem. Reading amp_max_cable (payload 'cbl'),
• aktives 16A CEE-Adapterset gem. Reading amp_max16A_adapter (payload 'adi')

geprüft und ggf. limitiert.

(Gegen Wert amp_limit_by_temp aus payload 'amt' wird nicht mehr geprüft, das war ja ggf. das Problem bei Kasi13 und die Wallbox sollte intern ja selber ein Limit setzen, wenn die Temperatur zu hoch ist).

Jetzt funktioniert es perfekt! Danke nochmals für die Super-Arbeit  ;)

Hallo zusammen,

gibt es einen Trick damit der Wert amp_max16A_adapter richtig erkannt wird? Ich habe den Schuko Adapter dran und er ermittelt den Wert 1. In der GoE App sagt er 16A max Adapter.

Viele Grüße
Christian

Es gibt für die Adapter - egal ob z.B. für CEE16 rot oder Steckdose - m.W. nur den Kontakt, der dann 0 oder 1 liefert und damit lt. API das Limit auf 16A setzt. Passt ja auch als Limit zur jeweiligen Phasenzahl und geeignetem Stecker. Dass dies bei Baumarkt-Schuko kritisch werden könnte, ist eine andere Sache. Ich weiß nicht, ob wie bei anderen ein Temperatursensor im Schuko verbaut ist. Hast Du denn mal den go-E an der Steckdose mit 16A betrieben? Was zeigt da die App von go-E als max. möglichen Ladestrom und bezüglich des Adapters?

Wenn Du angepasst an Deine Ladesituation (Vorsicherung, Schuko) ein Limit setzen willst, kannst Du in der App unter "Einstellungen - Druckknopf - Absolut Max" genauso wie im Fhem-Modul den Wert von amp_max_wallbox setzen. Z.b. eben auf ein Limit von 10A.

Danke für die Tips. Ich glaube mein Problem liegt wo anders. Ich habe kein Typ2 Kabel angeschlossen da ich das Ganze momentan im Haus teste. Damit steht das reading amp_max_cable auf 0. Also kann ich auch keinen Ladestrom einstellen
Da kann ich wohl eine Trockenübungen machen. Danke trotzdem

Also ich kann an CEE16 rot die Wallbox auch ohne eingestecktes Typ2 aktivieren und Ladestrom voreinstellen (Edit: nur per App). Das Modul habe ich nicht mit Schuko getestet. Schau mal, ob Du mit der App aktivieren und Ladestrom einstellen kannst. Ggf. kann ich auch die Prüfung auf Adapter im Modul rausnehmen...

Bei mir weigert er sich mit Schuko adapter. Ich bekomme beim Scrollbalken nur 6-0 angeboten und wenn ich was setzen möchte sagt er dann "Arg 2 not allowed "
Was ist eigentlich der Unterschied zwischen "allow charing" und "on / off"?

Vergleiche bzgl. der Funktionen oder Readings kannst Du mit der App machen. Dort was verstellen - in Fhem schauen und umgekehrt. Mit Schuko hab ich das Modul nie getestet, ist das für Dich später nötig?

Das Vergleichen habe ich gemacht. Bei beiden sagt er mir Aktivierung notwendig.
Schuko wäre zumindest als Backup recht hilfreich. CEE dose habe ich nicht überall

Das Modul prüft den Eingabewert für den Strom auch auf den max. zulässigen Wert des Typ2-Kabels, d.h. amp_max_cable (payload 'cbl'). Wenn Typ2 nicht eingesteckt ist, ist der Wert 0 und mein Modul weigert sich, einen Stromwert einzustellen. Mit der App kann man den Strom dennoch einstellen, was ggf. als Voreinstellung Sinn macht. Ich schaue mal, dass ich das ändere.

Cool. Danke dir.

Version 0.1.8 eingestellt:
Für das Setzen von amp_current oder amp_current_eeprom (per Befehl oder Slider) wird nun der obere Wert nur noch gegen den

• lokalen Maximalwert der Wallbox gem. Reading amp_max_wallbox (payload 'ama'),
• vom go-E ermittelten Maximalwert des Typ2-Kabels gem. Reading amp_max_cable (payload 'cbl') , aber nur, wenn er ungleich 0 ist (d.h. wenn Typ2-Kabel angesteckt ist).
  Somit kann man jetzt auch ohne angestecktes Typ2-Kabel die Voreinstellung Ladestrom über das Modul machen.
• aktives 16A CEE-Adapterset gem. Reading amp_max16A_adapter (payload 'adi')

geprüft und ggf. limitiert.

Funktioniert 1a. Vielen Dank!
Den Unterschied zwischen "allow_charing" und "on / off".... ich finde ihn nicht. Leds blinken die Gleichen und die app sagt auch das Gleiche. Gibs zu, das ist nur um die Leute zu verwirren ;)

Danke nochmals

Wenn der go-E aktiv ist, kann man rangehen, ein Typ2-Kabel mit Auto anstecken und das Laden beginnt gem. der Einstellungen.
Es könnte sein, dass dies vielleicht nicht so gut ist, wenn die Box frei zugänglich montiert ist und Du keine Stromflatrate hast...
Der go-E ist auf verschiedene Art aktivierbar: siehe App -> Einstellungen -> Zugangskontrolle oder eben ähnliche Einstellungen über Fhem.
Eine Bedienungsanleitung sollte es m.E. auch geben.

Zitat von: Chris_XXX am 18 November 2020, 16:48:29
Funktioniert 1a. Vielen Dank!
Den Unterschied zwischen "allow_charing" und "on / off".... ich finde ihn nicht. Leds blinken die Gleichen und die app sagt auch das Gleiche. Gibs zu, das ist nur um die Leute zu verwirren ;)

Danke nochmals

allow_charging entspricht in der App dem Schalter "Aktivierung", also ob man mit dem go-eCharger laden kann oder nicht. Lässt sich auch setzen (Modul Version 0.1.6).
Den Schuko-Adapter hatte ich zuletzt mit Modulversion 0.1.5 im Einsatz, da ich so direkt das Ergebnis im Haus sehen konnte.
Das hat ohne Probleme funktioniert.
Leider warte ich noch auf das E-Auto. Unter Realbedingungen kann ich daher nicht testen  ;)

Hallo,

Hab heute 2 Stück go-E 11kW fix bekommen und im Keller mal provisorisch einphasig angeschlossen zum Konfigurieren. Das Problem, dass mit der neuen FW ein Reboot nicht mehr klappt habe ich auch. Hab schon ein Ticket offen, hab das hier zu spät gelesen. Die zweite lasse ich dann erst einmal auf der alten FW.
Ich will das Lastmanagement nutzen, da ich nur 1 Zuleitung 5x2,5 mm2 zur Garage habe, dort sollen aber gleich zwei Ladepunkte hin, wenn man die Boxen derzeit wegen KfW Förderung ja quasi für Umme bekommt.
Was mich da noch verwirrt: Beziehen sich die dort einzustellenden Werte für die Lastgruppe auf eine Phase oder auf alle drei ?

Auto (e Soul) ist bestellt, kommt aber erst im Frühjahr, wahrscheinlich eher wie der Elektriker zum Box anschliessen, der um die Ecke wohnt.

Das Modul habe ich testweise mal angebunden, sieht so weit alles gut aus (bis auf die nicht funktionierende Hilfe). Vielen Dank schon mal an den Autor. Das Vorhandensein einer fhem-Anbindung war für mich ein KO-Kriterium bei der Produktauswahl der Wallbox.

Grüße, gagdet.

Da bin ich gespannt: Ich werde auch eine 2. Kfw-geförderte 11kW-Box "parallelschalten" (auch nur 5x2,5mm2) und hoffe auf gutes Lastmanagement, damit die Sicherung nicht kommt. Ich denke mit dem Strom im Lastmanagement ist der je Phase gemeint. Fallback würde ich wg. max 16A bei mir dann auf 8A stellen - wenn die Cloud mal nicht erreichbar ist. Leider hat man mir gesagt, dass das Lastmgmt. über API wohl nicht kommt. Aber PlanB ist für mich die Ladesteuerung von 2 BEV dann über Fhem (DOIF/notify). Mein 2. go-E kommt aber erst Februar und 2. BEV frühestens Mai.
Das die Modul-Hilfe bei Dir auch nicht geht, ist schon interessant. Bei manchen geht es, alternativ am Besten ggf mit Texteditor im File ganz unten lesen.
Vg Lutz

Hallo,

das mit der Hilfe lässt sich einfach lösen. Im Abschnitt für die deutsche Hilfe steht ja nix drin. Wenn Du den raus wirfst, kommt dann halt die englische Hilfe.
Also


=begin html_DE

<a name="GoECharger"></a>
<h3>Go-eCharger</h3>

=end html_DE


raus und Modul-Reload.

Grüße, gadget

Danke für den Tip! Habe in neuer Version 0.1.9 (s. Threadstart) nun eine deutsche Hilfe ergänzt und auch an der englischen ein paar nicht beschriebene Key's ergänzt.
Viele Grüße, Lutz

Hallo LR66,

super Arbeit. Modul funktioniert super auf Anhieb.
Meiner Meinung nach könnte es auch über update ausgeliefert und aktuell gehalten werden können :-)

Viele Grüße

Ich habe nun auch set - Befehle für das Lastmanagement ähnlich der App in das Modul übernommen - siehe Version 0.2.0 im Start-Threat.

Diese Funktion der Boxen wird ja nötig, wenn man 2 oder mehr Boxen an einem limitierten Stromnetz betreiben möchte (bei mir 2 Stück  11kW-Boxen an einem 11kW-Kabel mit entspr. Sicherung).
Das geht sicher auch direkt in Fhem zu lösen, aber ich möchte in Fhem nur noch die Prioritäten der Boxen automatisieren (wer lädt / klimatisiert zuerst, oder beide gleich priorisiert...) und will nur überwachen, ob die go-e Überlastvermeidung klappt ...
Viele Grüße,
Lutz

Edit: Eine Integration über update in Fhem würde voraussetzen, dass das Modul gewissen aufwärtskompatiblen Regeln entspricht (die ich so nicht alle kenne), es sauber programmiert ist, in github liegt und es einen Maintainer/Developer für die Pflege gibt. Da habe ich kein Account/Berechtigungen usw. - ich hatte ja mal gehofft, dass es einer der Developer adoptiert  ??? ...

Hallo Lutz,

danke für deine Arbeit und dieses Modul.

Ich habe mir einen go-eCharger HOMEFIX 11kW zugelegt.
Die Gründe waren dein Modul und die aktuelle KFW-Förderung.

Den Charger habe ich nun provisorisch in der Unterverteilung meiner Garage installiert.

Er zeigt mir in den Readings folgendes
Http_lastRequestError   192.xxx.xxx.xxx: Keine Route zum Zielrechner (113)

Was bedeutet dies?

Wie bekomme ich noch die tatsächliche Ladeleistung neben dem icon angezeigt?

Gruß

Ralf

Hallo Ralf,
die Http-Fehlermeldung ist eine reguläre Fehlermeldung, da hat das Modul - ggf beim Start - wohl mal keine IP-Verbindung zum goE gehabt (Du siehst am Zeitstempel, ob das nur einmalig oder regelmäßig ist).
Für die Anzeige von Icon und Meßwert hab ich mir ein Atrribut stateFormat mit Inhalt
state␤KW_charging_measured kW
angelegt (beachte Zeilenumbruchzeichen hinter dem Wort state!).
Viele Grüße,
Lutz

Hallo Lutz,

danke für die schnelle Antwort.

Du hast Recht, der Fehler war einmalig und ich habe ihn gelöscht.

Das stateFormat
state
KW_charging_measured kW

funktioniert nicht.

Da bekomme ich neben dem ladenden Icon(orange) ein gelbes dazu!
Bei meinen PCA301 funktioniert dies aber tadellos!

Ich kümmere mich erstmal um das Überschussladen mit werten aus meiner Powerwall2.
Dazu schaue ich mir mal dein Beispiel an.

Gruß
Ralf

Für Überschussladen hast Du noch paar Wochen Zeit (wenn Deine Anlage nicht gerade riesig ist :-) ).
Schau Dir mal Deine jeweiligen states und das devStateIcon an. Das devStateIcon .* für alles unbekannte habe ich bei mir rausgenommen (kommt ja dann auch bei initialized,...).
Mein devStateIcon:
disabled.*:ev-station@darkgrey not_allowed.*:ev-station@white ready_no_car.*:ev-station@blue charging.*:ev-station@darkorange waiting_for_car.*:ev-station@pink finished.*:ev-station@lime error.*:ev-station@red
... aber kannst Du auch anpassen.
Beim stateformat wird quasi state und der Messwert angezeigt. Beim Anlegen kopiere ggf eine Kopie meines o.g .Textes mit Zeilenumbruch. Wenn Du auf edit des Attr stateFormat klickst, muss sich das Fenster mit 2 entsprechenden Zeilen zeigen.

Vielen Dank für deine Hilfestellung.

Bei mir sieht es nun in den Attributen aus wie von dir beschrieben.

Das Ergebnis sieht leider nicht aus wie bei dir.

Gruß

Ralf

Hi, zur Darstellung:
Lösch mal bitte das devStateIcon:   .*:ev-station@yellow
Über das .* allein führen alle nicht anders definierten state zu gelbem  Symbol, damit auch kW_charge_measured...
Also nur benannte wie 'ready_no_car' oder 'error' explizit mit Farbe für Symbol definieren.
Viele Grüße, Lutz

Zitat von: LR66 am 10 Januar 2021, 09:17:12
Hi, zur Darstellung:
Lösch mal bitte das devStateIcon:   .*:ev-station@yellow

Hallo Lutz,

vielen Dank für die Hilfe.

Das löschen hat geholfen!

Nun habe auch Ich eine Verbrauchsanzeige neben dem Symbol!

Gruß
Ralf

Moin zusammen,

ich habe seit zwei Tagen auch endlich meinen go-eCharger. Bin gerade dabei alles in FHEM einzurichten. Grundsätzlich läuft alles, aber wenn ich used_api_keys von default auf all stelle kommen nur noch zwei Readings. Ich hatte es so verstanden dass dann alles was möglich ist abgefragt wird.

Habe den "Fehler" gerade selber gefunden. Im Code steht allkeys und in der Hilfe all. Wenn man  also allkeys eingibt dann funktioniert es.

Oh, sorry... danke für den Hinweis auf den Fehler.
Viele Grüße,
Lutz

Das funktioniert fast perfekt  :)

Eine Frage noch. Ich habe die svg Datei nach www/images/fhemSVG kopiert.
Mir werden die Symbole aber nicht angezeigt, nur der Text.

Jemand eine Idee?  ;D

Das ist der richtige Platz. Der Icon-Cache muss neu geladen werden - da gab es was, wie man das macht, weiß ich grad nicht. Wenn Dir ein Neustart nicht weh tut (gleich mit Update verbinden), sollte das auch klappen.

Hallo allerseits,

ich versuche (basierend auf dem weiter oben im Thread geposteten DOIF) den Go-E in Abhängigkeit des verfügbaren Überschusses zu steuern:


## 1 ## incr
            (([SMA_Energymeter:Saldo_Wirkleistung] > (1*230)/2-1000) ## speist mehr als 690 ins Netz?
and ([GoE:car_state] == 2)                           ## beim Laden?
and ([?GoE:amp_current] < [?GoE:amp_max_wallbox]))   ## akt. Ladestrom < max?
  {Log 1,"GoE 1 state:[GoE:car_state] incr allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
  (set GoE amp_current [GoE:amp_current:d:$1+1])
##
## 2 ## decr
DOELSEIF   (([SMA_Energymeter:Saldo_Wirkleistung] < -(1*230)/2-500) # bezug
and ([?GoE:car_state] == 2)
and ([?GoE:amp_current] > 7))
  {Log 1,"GoE 2 state:[GoE:car_state] decr allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
  (set GoE amp_current [GoE:amp_current:d:$1-1])
##
## 3 ## stop
DOELSEIF   (([SMA_Energymeter:Saldo_Wirkleistung] < -(1*230)/2-500)
and ([?GoE:car_state] == 2)
and ([?GoE:amp_current] == 7))
  {Log 1,"GoE 3 state:[GoE:car_state] stop allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
  (set GoE allow_charging 0)
  {Log 1,"GoE_max_PV: PV Chg STOP @ [?VIN_des_Teslacar:battery_level]% / [?VIN_des_Teslacar:charge_limit_soc]%"}
##
## 4 ## finished
DOELSEIF (([SMA_Energymeter:Saldo_Wirkleistung] > -10000)
and ([?GoE:car_state] == 4))
##and ([?VIN_des_Teslacar:charge_limit_soc] <= [?VIN_des_Teslacar:battery_level]))
  {Log 1,"GoE 4 state:[GoE:car_state] fin  allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
##  {Log 1,"GoE_max_PV: PV Chg OK @ [?VIN_des_Teslacar:battery_level]% / [?VIN_des_Teslacar:charge_limit_soc]%"}
##
## 5 ## start
DOELSEIF (([SMA_Energymeter:Saldo_Wirkleistung:avg3] > 6*1*230-500)
and ([?GoE:car_state] > 1))
##and ([?VIN_des_Teslacar:charge_limit_soc] >= [?VIN_des_Teslacar:battery_level])
##and ([?VIN_des_Teslacar] =~ "online"))
  {Log 1,"GoE 5 state:[GoE:car_state] strt allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
  (set GoE amp_current 7)
  (set GoE allow_charging 1)
##  {Log 1,"GoE_max_PV: PV Chg START @ [?VIN_des_Teslacar:battery_level]% / [?VIN_des_Teslacar:charge_limit_soc]%"}
##
## 6 ## noCar
DOELSEIF (([SMA_Energymeter:Saldo_Wirkleistung] > -10000)
and ([?GoE:car_state] == 1))
  {Log 1,"GoE 6 state:[GoE:car_state] !car allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
##
## 7 ## wakeupCar
DOELSEIF      (([SMA_Energymeter:Saldo_Wirkleistung] > 6*1*230-500)
and ([?GoE:car_state] > 1))
##and ([?VIN_des_Teslacar:charge_limit_soc] > [?VIN_des_Teslacar:battery_level])
##and ([?VIN_des_Teslacar] !~ "online")
##and ([?PW2_SOC:pct] > 50))
##  (set VIN_des_Teslacar wakeUpCar)
  {Log 1,"GoE 7 state:[GoE:car_state] wake allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
##
## 8 ## charge
DOELSEIF (([SMA_Energymeter:Saldo_Wirkleistung] > -10000)
and ([?GoE:car_state] == 2))
  {Log 1,"GoE 8 state:[GoE:car_state] chg  allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}
##
## 9 ## wait
DOELSE
  {Log 1,"GoE 9 state:[GoE:car_state] wait allow:[GoE:allow_charging] amp_current:[GoE:amp_current]"}


Aus für mich nicht ersichtlichen Gründen will DOIF aber nicht so wie ich es gerne hätte. Im Block Nr 2 (also Ladestrom senken) wird beharrlich die letzte Bedingung "and ([?GoE:amp_current] > 7)" ignoriert. Auch wenn der Stromwert schon auf 6 steht, wird trotzdem der zweite Block ausgeführt und versucht den Stromwert weiter (auf 5) zu senken.

Irgendwas muss ich da übersehen haben. Wieso ignoriert DOIF diese Bedingung?

Du hast einen Kommentar #bezug mit nur einem # Zeichen, das geht m.W. schon mal schief?!

Danke! Da versteift man sich auf den Code, und es liegt am Kommentar   ???

Was ist eigentlich der Unterschied zwischen car_state==1 und car_state==3?

Klar, bei 1 ist Kabel nicht angesteckt. Aber was hindert das Auto bei 3 zu laden?

Wenn meine ZOE zwischdurch aufgehört hat zu laden (weil zB dunkle Wolken der PV den Saft abgedreht haben), dann verbleibt sie bei car_status==3 und fängt nicht wieder an zu laden.

Kurioserweise wacht sie wieder auf und fängt wieder an zu laden wenn man eine Tür öffnet. Die fängt also wieder an zu lader, wenn man losfahren will. Das haben sich die Herren Inschenöre richtig clever ausgedacht  :o

Zitat von: LR66 am 06 Februar 2021, 11:14:24
Das ist der richtige Platz. Der Icon-Cache muss neu geladen werden - da gab es was, wie man das macht, weiß ich grad nicht. Wenn Dir ein Neustart nicht weh tut (gleich mit Update verbinden), sollte das auch klappen.

Danke!
Erstaunlicherweise musste ich relativ viel suchen um die Lösung zu finden.
Für den Fall das noch mal jemand sucht, es gibt in dem Zusammenhang zwei Befehle:
- set <FHEMWEB> clearSvgCache
- set <FHEMWEB> rereadicons

Zitat von: gadget am 08 Dezember 2020, 17:32:08
Hallo,

Hab heute 2 Stück go-E 11kW fix bekommen und im Keller mal provisorisch einphasig angeschlossen zum Konfigurieren. Das Problem, dass mit der neuen FW ein Reboot nicht mehr klappt habe ich auch. Hab schon ein Ticket offen, hab das hier zu spät gelesen. Die zweite lasse ich dann erst einmal auf der alten FW.
Ich will das Lastmanagement nutzen, da ich nur 1 Zuleitung 5x2,5 mm2 zur Garage habe, dort sollen aber gleich zwei Ladepunkte hin, wenn man die Boxen derzeit wegen KfW Förderung ja quasi für Umme bekommt.
Was mich da noch verwirrt: Beziehen sich die dort einzustellenden Werte für die Lastgruppe auf eine Phase oder auf alle drei ?

Auto (e Soul) ist bestellt, kommt aber erst im Frühjahr, wahrscheinlich eher wie der Elektriker zum Box anschliessen, der um die Ecke wohnt.

Das Modul habe ich testweise mal angebunden, sieht so weit alles gut aus (bis auf die nicht funktionierende Hilfe). Vielen Dank schon mal an den Autor. Das Vorhandensein einer fhem-Anbindung war für mich ein KO-Kriterium bei der Produktauswahl der Wallbox.

Grüße, gagdet.

@gadget: Hallo gadget,
hast Du das Lastmanagement für 2 Boxen bereits in FHEM realisiert ?

Ich habe das gleiche Thema (nur 3ph x 16A für 2 Boxen verfügbar) und das Cloud-Lastmanegemnt von goE scheint ja leider immer noch nicht zu funktionieren.

Falls ja: Wäre super, wenn Du deinen Code posten könntest  :)

Vielen Dank

Warte immer noch auf Elektriker, denke Ende März kann ich was sagen. Bislang nur ein E-Auto, das je nachdem wo es zum stehen kommt an der einen oder an der anderen Box geladen wird, den Bedarf gleichzeitig an beiden zu laden werde ich voraussichtlich erst nächstes Jahr haben.

Ich habe das Modul geringfügig geändert und nun über github verfügbar gemacht (s. Start des Thread).
Zum Lastmanagement bin ich auch gespannt, ich dachte das vom go-E über Cloud geht?
Ich betreibe in Zukunft auch 2 an einer max. 16A Zuleitung: Wenn das go-e Lastmgmt. nicht geht würde ich zunächst 2 notify (oder ein DOIF) anlegen:
Wenn event Box1 allow_charging=1 dann setze Box2 allow_charging=0 und das ganze umgekehrt nochmal. Auch wichtig: das Intervall ggf. runter setzen. Dann könnte man im weiteren versuchen,  über DOIF stattdessen ein Lastmanagement hinzubekommen...

Habe heute auf Nachfrage von goE die Info bekommen, dass das Cloud-Lastmanagement (eigentlich) wieder funktionieren sollte.
Nachdem ich jetzt auch die zweite Box 3-phasig angeschlossen habe, werde ich's in den nächsten Tagen wieder ausprobieren.

Hallo zusammen,

ich überlege mir derzeit eine Wallbox zu kaufen und schaue, welche für meine Bedürfnisse am besten passt.
Meine Grundkonfiguration:
- fhem nutze ich seit mehr als 6 Jahren sehr intensiv
- PV mit Ost / West und 23 kWp
- Wechselrichter und Energy Meter sind in fhem eingebunden, habe also aktuelle Werte
- Skoda Citigo e mit maximaler Ladung von 7,2 kW/h (über 2 Phasen).

Da ich dank der Größe der PV-Anlage selbst im Winter immer wieder eine Überschussladung hin bekommen sollte, suche ich nun eine Wallbox, die ich entsprechend steuern kann.

Deshalb mal ein paar Fragen zum Modul :
Im Winter wäre es wichtig, die Ladeleistung so gering wie möglich zu halten. Das geringste, was das Auto zulässt, wären 220/230V mit 6 A und zwar einphasig. Ich habe gelesen, dass man den Strom beliebig zwischen 6 und 32A (16A bei dem kleinen Go-ECharger) vorgeben kann und das dann für alle Phasen gilt. Aber kann ich auch die Anzahl der Phasen vorgeben? Kann ich im laufenden Ladevorgang über fhem den Strom anpassen (z.B. weil mehr oder weniger Sonne und somit mehr Überschuss da ist?) Bekommt man in diesem Modul eigentlich den Ladezustand des Autos mitgeteilt? (ich meine hier gelesen zu haben, dass nein, bin mir aber etwas unsicher)

Viele Grüße und schonmal DANKE
Thomas

Hallo Thomas,

leider kann der go-eCharger nicht die Anzahl der Phasen steuern.
Habe das mit denen schon diskutiert und sie haben es "für eine mögliche nächste Generation aufgenommen".

Da ich eine 10 kWp Anlage habe, sind die Überschüsse bei mir natürlich geringer.
Daher habe ich es aktuell so gelöst, dass ich ein 1-phasiges Typ2 Kabel nutze.

In Planung mit einem Kollegen ist eine zusätzliche Steuerung über LAN / WLAN, vermutlich mit einem Arduino o.ä., der zum einen den Zustand des go-eChargers prüft (Ladung ja/nein, aktuelle Ladeleistung ...), zusätzliche Sensoren auswertet und dann bei Anforderung von außen (fhem) eine Umschaltung von 1- und 3-phasigem Betrieb vornimmt.
Denn der go-eCharger kann nur mit L1 oder 3-phasig arbeiten. Allerdings muss ZWINGEND sichergestellt werden, dass die Ladung erst gestoppt wird und wenn dann wirklich keine Leistung mehr anliegt, die Umschaltung erfolgt. Danach dann die Ladung wieder starten.
Der Arduino würde dann ein Lastrelais steuern.

Aber das ist noch in Planung.

Wie Eckat schrieb: Der go-E kann nur ein- oder 3-phasig betrieben werden und dies kann man nur über externe Schaltung erreichen (manueller Schalter oder Schütz an Fhem über z.b. Homematic o.ä.). Man sollte nur ohne laufenden Ladevorgang umschalten und möglichst nicht nur Phasen weg/zu, sondern aus und mit neuer Phasenzahl einschalten. Und dann kannst Du dem go-E natürlich beliebig ändernd den gewünschten Ladestrom zw. 6...32A vorgeben - je nach z.B. Auswertung PV oder Leistungsflüsse an Zählern in Fhem.

Den Ladezustand eines Fahrzeugsakkus kann keine Wallbox nur über das Typ2-Ladekabel erfahren. Für manche BEV gibt es API's, sodass ggf. über Software auf Fahrzeuginfo's zugegriffen werden kann.

Eine alternative: OpenWB kann ggf bestimmte PV, Fahrzeuge und Phasenumschaltung - aber mit hohem Preis.

@LR66

Wo du das gerade mit dem Ladezustand des Autos schreibst.
Das habe ich auch bei go-e nachgefragt, aber sie sagen, das geht aktuell und in Zukunft nicht.
Daher stimmt das mit deiner Aussage überein.

Was mich wundert ist, woher bekommen bei den Schnellladesäulen die Infos? Die zeigen doch auch, zumindest manche, den SoC des Autos an.
Meiner Meinung nach müsste das doch auch über die beiden Daten-Pins im Typ-2 Stecker laufen.  :)

Das Problem ist der ESP, der schon zu "voll" ist.
Weswegen sie für neue Funktionen eigentlich den ESP ändern müssten.

Nein.
Bei CCS (DC-Ladung) ist ein anderes Protokoll als bei Typ2 (AC-Ladung) definiert. Ist halt normiert, wie was wann kommuniziert wird und darf -> Wikipedia, Google

Auch bei AC kann man bei fast allen Autos den SOC auslesen.

https://de.m.wikipedia.org/wiki/IEC_62196_Typ_2 (https://de.m.wikipedia.org/wiki/IEC_62196_Typ_2)

Da wird lt. Wiki erst dran gearbeitet und das muss dann im BEV (!) und Wallbox (!) implementiert sein:

ZitatDie nach IEC 61851-1 spezifizierte, im Adressumfang sehr bescheidene, analoge Signalisierung wird zurzeit im Hinblick auf die geplante Smart Grid Integration der Elektro- und Hybrid-Fahrzeug-Ladeinfrastruktur ergänzt um einen auf IPv6 basierenden bidirektionalen Kommunikationskanal. Die Kommunikation und zugehörige Test- und Konformitätsanforderungen werden im Standard ISO 15118 beschrieben. Die Datenübertragung kann leitungsgebunden mit Hilfe von Powerline Communications (PLC) oder (ab ISO 15118 Edition 2) nicht-leitungsgebunden erfolgen

Edit: Ich kenne keine für den Hausgebrauch gedachte Wallbox, die das heutzutage allein über das Typ2-Kabel kann.
Führt hier aber auch zu weit weg vom Thema Fhem Modul für den go-ECharger nach aktueller API über WLAN...

War bei deinem Auto ein Ladeziegel dabei ? Der muss ja so ausgelegt sein, dass man den Schuko-Stecker jederzeit abziehen kann, da der ja nicht verriegelt ist.
Dann würde ich mir einfach zusätzlich eine legrand Steckdose ( 60 Eur) mit einem ausreichend dimensionierten Schaltaktor (20 Eur) davor installieren und den dann von fhem aus einschalten wenn Du PV Überschuss hast. Da stöpselst Du dann dein Auto an, wenn Du es mit dem Laden nicht eilig hast, und der Wetterbericht auf ordentlichen Solarertrag hoffen lässt.
Und wenn es schnell gehen soll oder du über Nacht aufladen musst nimmst Du stattdessen die Wallbox. Die würde ich auf jeden Fall installieren schon wegen der KfW Förderung und künftig hast Du ja vielleicht mal ein Auto das auch dreiphasig lädt.

Thomas schreibt aber, er hat eine große PV-Anlage und möchte auch 3-phasig laden können  ;)

Zitat von: gadget am 16 März 2021, 12:19:04
War bei deinem Auto ein Ladeziegel dabei ? Der muss ja so ausgelegt sein, dass man den Schuko-Stecker jederzeit abziehen kann, da der ja nicht verriegelt ist.
Dann würde ich mir einfach zusätzlich eine legrand Steckdose ( 60 Eur) mit einem ausreichend dimensionierten Schaltaktor (20 Eur) davor installieren und den dann von fhem aus einschalten wenn Du PV Überschuss hast. Da stöpselst Du dann dein Auto an, wenn Du es mit dem Laden nicht eilig hast, und der Wetterbericht auf ordentlichen Solarertrag hoffen lässt.
Und wenn es schnell gehen soll oder du über Nacht aufladen musst nimmst Du stattdessen die Wallbox. Die würde ich auf jeden Fall installieren schon wegen der KfW Förderung und künftig hast Du ja vielleicht mal ein Auto das auch dreiphasig lädt.

Genau das ist meine jetzige "Wallbox". So wie du es beschrieben hast, habe ich das Ganze umgesetzt. Somit lade ich mit 2.2 kWh. Da mein Kleiner leider nur mit 2 Phasen laden kann, wären das bei 6A Einstellung ca 2,7 kWh an der Go e. So groß ist der Unterschied dann auch nicht mehr zum Ladeziegel (schönes Wort!!), denke dann würde ich eher mal durchrechnen, ob sich nicht ein 1 phasiges Typ 2 Kabel für den Winter lohnt.
Deshalb jedenfalls fast das doppelte, für eine andere Wallbox, in die Hand zu nehmen, erscheint mir ein wenig wie mit Kanonen auf Spatzen zu schießen. Das werde ich mir aber mal ausrechnen.

Zitat von: Eckat am 16 März 2021, 12:29:24
Thomas schreibt aber, er hat eine große PV-Anlage und möchte auch 3-phasig laden können  ;)

Ja, ich hab eine etwas größere PV Anlage, aber ich glaube nicht, dass ich in nächster Zeit noch ein weiteres Auto kaufen werde. Somit würden mir 2 Phasen schon reichen. Hauptsache etwas schneller, als die jetzigen 2,2 kWh!! Da dauert eine komplette Ladung schonmal 17 Stunden.

Schonmal vielen Dank für euren Input!! Ich denke diese Wallbox kommt auf jeden Fall in die nähere Auswahl!!!

Viele Grüße
Thomas

Als Idee einer GoE-Phasenumschaltung über FHEM (wäre m.E. finanziell überschaubar):
- Wandverteiler ca. 20€
- Installationsschütz 400V~ 4p >=20A ca. 20€ (4p weil üblich und billig, aber nur L1..3 schalten, meist sind die günstigen normally open)
- Installationsschütz/Relais 230V~ 1p >=20A ca. 20€ (möglichst normally closed oder Wechsler falls Versuch Ansteuerung mit nur 1 Aktor)

Wenn Du schon Homematic hast , dann dazu
- 1x Homematic Hutschienaktor 1p für ca 65€ (da muss aber Schaltlücke für goE reichen) oder
- 2x Homematic Hutschienaktor 1p (ein Aktor für Schütz 3phasig ein/aus, der andere für einphasig ein/aus um goE auch komplett stromlos zu schalten)
Eine Phase würde ich nicht direkt damit schalten, da gerade so für 16A ausgelegt...

Wenn keine Homematic vorhanden: 1-2 beliebige FHEM-kompatible Aktoren die die 400/230V-Schütze anschalten/umschalten.

Also mit 120-200€ Material sollte das m.E. machbar sein...

Zitat von: thobo am 16 März 2021, 16:14:59
(...) ob sich nicht ein 1 phasiges Typ 2 Kabel für den Winter lohnt.

Was beim Go-E recht einfach zu machen ist: Der förderfähige 11kW go-E fix hat ein flexibles Kabel zur Festinstallation dran. Am Ende sind bereits Adernendhülsen. Da kann also durch ganz einfach auch wieder ein CEE rot 16 A angeschlossen werden (6 EUR). Als Gegenstück dann zwei CEE Dosen ( 2x 8 EUR) montieren, die erste voll verdrahtet mit PE,N,L1,L2,L3 und die zweite nur mit PE,N,L1. Dann im Winter einfach auf die einphasige umstecken. Ist zwar nicht "smart", aber trivial umzusetzen und du brauchst kein 1-poliges Kabel extra.

Kurze Frage an die Runde:
Habe beobachtet das der Charger min 1x täglich automatisch rebootet.
Wurde bei mir vor 22 Tagen eingebaut.

Reading ,,reboot_counter" hat akt. 33.
Setze ,,allow_charging" Abends immer auf 0 und Morgens auf 1 sobald genug PV Einspeisung vorhanden.
Durch den aut. Reboot z.B. früh Morgens wird ,,allow_charging" bereits um 7.50 gesetzt.

habt ihr dieses Verhalten auch ?

Gerade mal nachgeschaut, einer aus 02/20 hat 61 Reboots, der seit 02/21 hat 18. Vielleicht ist das auch abhängig von der Stabilität des WLAN?? Und wie Status Aktivierung nach Reboot ist, hab ich nicht geprüft. Da ich eingestellt habe "Aktivierung durch RFID/App" müsste es nach Reboot eigentlich aus sein.

Also meiner macht keine Reboots, weder automatisch noch manuell angefordert.

Ich habe z.B. das Problem, dass er alle paar Wochen keine Gesamtladeleistung mehr angibt, nur noch für die einzelnen Phasen.
Sage ich ihm dann über die App er solle rebooten, klappt das nicht "ganz". Er bleibt an einer mir unbekannten Stelle stehen. Ich muss ihn dann vom Strom trennen und neu verbinden. Dann ist wieder alles gut.

Am besten mit dem Support von go-e in Verbindung setzen. Die sind meiner Erfahrung nach gut und schnell!

Danke für den Tipp LR66, habe in der App nun auch "Aktivierung durch RFID/App,, eingestellt.
Somit ist nach dem Reboot ,,allow_charging" = 0.

Heute steht ,,reboot_counter" auf 37. Hat also seit Gestern 4x rebootet.
Stört mich weiter nicht aber...

Zitat von: Eckat am 15 April 2021, 11:07:51
Sage ich ihm dann über die App er solle rebooten, klappt das nicht "ganz". Er bleibt an einer mir unbekannten Stelle stehen. Ich muss ihn dann vom Strom trennen und neu verbinden. Dann ist wieder alles gut.

Das ist ein bekannter Bug der Firmware Version V0.40. Ich habe mit Hilfe des Supports einen Downgrade auf die V0.33 gemacht, bei der funktioniert der Soft-Reboot.  Stand Anfang März gibt es noch keine neuere Version, die diesen Fehler nicht hat.

Versionsgeschichte:


Version 025.0:
*Lastmanagement

*neue WLAN-Treiber

Version 025.1:
*Behebe Fehler mit LED-Animation

Version 030.b1:
*Awattar Zone auswählbar

*eigener MQTT Server verwendbar(beta)

*Stabilitätsverbesserung

Version 033:
*Fehlerbehebung bei der MQTT Verbindung zur go-eCloud

Version 040.0:
*Implement Modbus TCP on Port 502



Hallo,
hab heute meinen neuen go-e ins fhem integriert.
Noch nie ein device so schnell zum laufen gebracht. Ip eingetragen und fertig :-) Super Arbeit.

Jetzt kommt die Kür:
Photovoltaik-Überschuss-Laden:
Hab dafür bisher noch nix gefunden. Die Ergebnisse der Suchmaschine haben mich noch nicht zu einem schönen Algorithmus gebracht.

Aber hier direkt noch eine Frage zum go-e:
Würde gerne je nach Key entweder einfach so "volle Kanne" laden bzw. nur PV-Überschuss Laden.
Das liesse sich wunderbar über 2 verschiedene RF-Id machen, aber ich sehe bei den Readings nicht, welcher Id verwendet wurde?
Gibts ne Möglichkeit rauszufinden welcher RF-Id verwendet wurde?
Danke, Harald

Glückwunsch  :D

Also ich habe das Überschussladen mit einem Notify gemacht, wobei darin alles mit Perl ist.
Obwohl ich ahnte, dass es nicht so trivial wird, wie man sich das im ersten Moment denkt, und sogar mit einem PAP gearbeitet habe, musste ich noch diverse Male nacharbeiten.

Bei mir kommt aber auch noch der Hausspeicher dazu.
Herausforderungen, die mir spontan einfallen:

• Der Hausspeicher soll im Überschuss Modus nicht geleert werden.
• Die Überschussleistung muss über einem gewissen Level liegen, da der go-eCharger erst ab 6 A laden kann.
• Bei geringer Überschussleistung macht 1-phasiges Laden am meisten Sinn (6 A * 230 V = 1.380 W). Bei 3-phasig ist die Mindes-Überschussleistung schon 4.140 W die für die 6 A benötigt wird.
• Wenn man die Überschussleistung berechnet hat, dann den Ladevorgang startet, wurde im ersten Versuch gleich danach die Ladung wieder beendet ... Denn durch die Ladung war natürlich der Überschuss "weg"  ;D

Zu 3. habe ich noch keine Lösung. Aktuell liefert meine 10 kWp Anlage aber auch selten mehr als 5 kW, da nutze ich noch einfach ein 1-phasiges Typ2 Kabel.
Angedacht ist ein Leistungsrelais mit Steuerung über einen Arduino o.ä.. Da möchte ich dann von fhem aus L2 und L3 schalten. WICHTIG ist aber, dass man nur schalten darf, wenn keine Last (Ladung) anliegt. Hier muss ich auch noch eine Lösung erdenken, möglichst mit dem Arduino. Denn das möchte ich nicht mit Programmierung in fhem machen (Ladung prüfen, wenn aktiv, Ladung beenden, Phasen umschalten, Ladung starten), denn da kann ein kleiner Fehler zu teuren Ausfällen führen. Mir schwebt daher eher vor, dass der Arduino das selbstständig macht, dann kann ich da nix "versauen".

4. war halt nur ein Denkfehler, hat mich beim ersten Laden aber sehr gewundert  ::) Problem ist, dass man natürlich die Leistung aus dem go-eCharger wieder hinzuaddieren kann, aber zum einen ist die nach dem Ändern des Ladestroms oder dem Aktivieren der Ladung nicht direkt bei dem Maximum, sondern baut sich langsam auf. Zum anderen hat der go-eCharger da eine Macke. Hin und wieder ist die Gesamtleistung immer 0, nur noch für die einzelnen Phasen wird was angezeigt.

Ich werde das noch mal etwas testen und würde es dann gerne weiter optimieren.

Aber wie man das für sehr unterschiedliche Gegebenheiten "veröffentlichen" sollte, kann ich mir noch nicht vorstellen.

Danke xerion  :D

Ich habe lange gesucht und konnte nichts finden.
Werde das am Wochenende mal testen.

Ja ... EVCC sieht gut aus, wollte ich auch mal probieren. Nur Installation ist mir auf RasPi noch nicht klar. Extra Docker neben Fhem auf RPi3? Schafft er das von wegen Last? Oder direkt unter Raspbian installieren? Das war beim letzten nachschauen leider karg beschrieben. Gibt es fertige Binaries für Pi oder braucht es die Installation eines GO-Interpreters?

Zitat von: LR66 am 19 April 2021, 08:48:19
Ja ... EVCC sieht gut aus, wollte ich auch mal probieren. Nur Installation ist mir auf RasPi noch nicht klar. Extra Docker neben Fhem auf RPi3? Schafft er das von wegen Last? Oder direkt unter Raspbian installieren? Das war beim letzten nachschauen leider karg beschrieben. Gibt es fertige Binaries für Pi oder braucht es die Installation eines GO-Interpreters?

Ich selber nutze FHEM auf einem Raspi 4 und habe diverse andere Sachen auf einem Raspi 3+ im Docker Container laufen wie z.B. EVCC. Aber es klappt auch wenn Docker und FHEM auf einem Raspi laufen. Ich habe mich nur dazu entschieden mit zwei Raspi´s zu arbeiten, damit nicht alles von einem System abhängig ist.
Von EVCC gibt es diverse Binarys (max, Linux Docker, Windows) siehe https://github.com/andig/evcc/releases

Hallo,
hab einen Raspi2 und der ist mit allem anderen (Einspeisezähler, Lüftungsanlage, Schaltsteckdosen, Photovoltaikanlage, Rolladen, ....) schon mit allen logs heftig ausgelastet.
Steuerung vom go-e sollte eigentlich nicht so schlimm sein?
Alle Minute mal nachsehen, was der 5min Mittelwert des Einspeisezählers sagt und dann hoch / runterschalten?
Ich werden mal die Codeschnipsel vom Anfang dieses Fadens versuchen weiter zu entwickeln.
Hab mich bloß gewundert, dass es da nicht schon ne "Standardlösung" gibt...
Freundlichen Gruß, Harald

Hallo,
nochmal zurück zu meiner Frage:
Unterschiedliche RF-ID erkennen?
Wäre für mich ein entscheidendes Feature für unterschiedliches Verhalten
- Volle Ladeleistung freigeben
- Nur Überschußladung
Gibts da ne Möglichkeit? In der App werden ja unterschiedliche Zählerstände hochgezählt?
Danke, Harald

Sollte gehen: Siehe Feld
uby = unlocked_by_card     (Nummer der RFID Karte, die Ladevorgang freigeschalten hat)
Dieses abfragen und anhand dessen den Lademodus bestimmen.
Ist bestimmt ein interessantes Feature, da die Go-E so ziemlich viele verschiedene RFID Karten erkennen ...

Genau, bis zu 10 beliebige Chips, Karten (eine Metro-Karte Dubai o.ä. geht ebenso wie eine Tesla-Chipkarte) sind anlernbar und mit Name hinterlegbar (s. App und Darstellung im Modul s. Hilfe) und weiteres kann dann wie von vitolinker geschrieben über unlocked_by_card und notify, DOIF und im Logfile gemacht werden.

Hallo,
danke versuche ich dann, wenn ich das DOIF zum laufen kriege...
Im Moment wird immer nur eins weiter geschaltet, also toggelt nur um einen Wert herum. Es schaltet jeweils nur ein mal hoch und dann nur wieder runter, aber niemals noch mal hoch oder runter.
defmod Ladesteuerung DOIF (([ez:power] < -250) and ([?myGoE:amp_current] < [?myGoE:amp_max_wallbox]) and ([?myGoE:car_state] == 2)) (set myGoE amp_current [myGoE:amp_current:d:$1+1]) DOELSEIF (([ez:power] > -250) and ([?myGoE:amp_current] > 6 ) and ([?myGoE:car_state] == 2)) (set myGoE amp_current [myGoE:amp_current:d:$1-1]) DOELSE ()
Bin da recht ratlos...
Weiter oben sollte das so funktionert haben???
Danke, Harald

Ist das DOIF korrekt angelegt? Müsste es nicht mit define angelegt werden?

Auch mit define tuts nicht...
Irgendwie klemmt der Trigger.

defmod Ladesteuerung DOIF (([ez:power:d] < -250) and ([?myGoE:amp_current] < [?myGoE:amp_max_wallbox]) and ([?myGoE:car_state] == 2)) (set myGoE amp_current [myGoE:amp_current:d:$1+1]) DOELSEIF (([ez:power:d] > -250) and ([?myGoE:amp_current] > 6 ) and ([?myGoE:car_state] == 2)) (set myGoE amp_current [myGoE:amp_current:d:$1-1]) DOELSE ()

setstate Ladesteuerung cmd_2
setstate Ladesteuerung 2021-04-21 17:35:21 Device ez
setstate Ladesteuerung 2021-04-21 17:10:54 cmd 2
setstate Ladesteuerung 2021-04-21 17:10:54 cmd_event ez
setstate Ladesteuerung 2021-04-21 17:10:54 cmd_nr 2
setstate Ladesteuerung 2021-04-21 17:35:21 e_ez_power 516
setstate Ladesteuerung 2021-04-21 17:10:54 state cmd_2


e_ez_power ist 516 um 17:35 und damit > -250 und dann sollte der strom erniedrigt werden, es passiert aber nix?

Tja, dann mal schauen was er für readings und cmd's macht, was ez:power liefert und am Besten das DOIF mehrzeilig gestalten um eine Übersicht zu bekommen, ggf. erstmal vereinfachen (Prüfung ob er schon am Laden ist, ist ja ggf erstmal bei Handstart nicht nötig, amp_max_wallbox wird je nach Anlage vielleicht eh nie erreicht...)
Edit: ein DOIF wird mit define definiert und ist kein Device oder Modul, schau Dir da die commandref bitte nochmal an...

Mir fallen hierzu folgende Fehler / Konfigurationen ein die nützlich sein könnten:
- Attribut do always bei DOIF gesetzt?
- werden auch Events erzeugt von dem Zähler (checken im Eventmonitor)

VG

augenscheinlich fehlte hier ein
attr Ladesteuerung do always
Danke, sieht jetzt gut aus, zählt gerade runter ;-)

Zitat von: vitolinker am 21 April 2021, 09:50:40
Sollte gehen: Siehe Feld

Code Auswählen Erweitern

uby = unlocked_by_card     (Nummer der RFID Karte, die Ladevorgang freigeschalten hat)
Dieses abfragen und anhand dessen den Lademodus bestimmen.
Ist bestimmt ein interessantes Feature, da die Go-E so ziemlich viele verschiedene RFID Karten erkennen ...

Tschuldigung, noch mal ne Anfängerfrage:
Wo finde ich das Feld?
Bei meinen Readings ist nix?
Danke, Harald

Über das Attribut used_api_keys (s. Hilfe) kannst Du gewünschte Readings aktivieren. Derzeit steht bei Dir wohl nur default. Am einfachsten: Setze es auf all kopiere dann die unter Internals USED_API_KEYS gezeigte Liste aller Readings in das Attribut und lösche das raus, was Dich nicht interessiert und setze es dann. Dann deletereading <dein-device> .* damit wieder eine kürzere Liste Deiner gewünschten Readings kommt.
Sollte so ähnlich wie im Screenshot aussehen (mit dem was Du gem. Hilfe magst).

Hallo,

Ich schreibe einige Readings des Moduls nach DBLog weg und habe mir ein SVG gebastelt, das mir u.a. das Reading KW_charging_measured darstellt (rote Linie). Bei einem Ladevorgang fluktuiert das sehr stark zwischen 4,6 und knapp unter 11 kW . Wenn ich mir die App anschaue pendelt die aktuelle Ladeleistung aber immer um die 11 kW. Kann das jemand bestätigen ?

Grüße, gadget.

Könntest du an die entsprechenden Stellen etwas ranzoomen?

Aber ich werde es bei mir in meinem Normalfall nicht nachstellen können, da ich PV-Überschussladen mache und die Leistung daher immer schwankt.
Werde das mal bewusst testen, also manuelles Laden auf 11 kW und dann beobachten.

Würde bei dir denn die geladene Menge zu der Zeit passen? Also 2 Stunden mit 10,5 kW müssten ja in etwa 21 kWh sein.

Welches Auto hast du und wie bekommst du den SoC in fhem?

Zitat von: Eckat am 27 April 2021, 07:21:44
Könntest du an die entsprechenden Stellen etwas ranzoomen?
(...)
Würde bei dir denn die geladene Menge zu der Zeit passen?

Mir geht es um die  roten Bereiche (Momentane Ladeleistung). In der Grafik weiter oben sind zwei Ladevorgänge zu sehen, einmal auf 100% SOC und dann nochmal auf 80% SOC. Ich würde da ein Ansteigen auf 11KW erwarten und während des Ladens ein fluktuieren so zwischen 10 und 11 KW, aber die Werte gehen bis auf 5 KW runter. Ich lese den go-e alle 60 Sekunden aus. Ich hänge einen Zoom auf den ersten Ladevorgang an. Da wurde von 60% auf 100% SOC geladen. und das waren am Ende  29,4 KWh  (reading kWh_charged_last, blauer Bereich) in rund 3,5 Stunden. Das wäre ein Schnitt von 8,4 kWh. (Der SOC ist der grüne Bereich). Der braune Bereich ist die maximale Leistung vom go-e aus dem Lastmanagement, das sind immer 11 kW. Ich habe zwei Charger mit nur einer Zuleitung, aber aktuell eh nur den einen Stromer,  da muss das Lastmanagement also nix abregeln.

Zitat von: Eckat am 27 April 2021, 07:21:44
Werde das mal bewusst testen, also manuelles Laden auf 11 kW und dann beobachten.

Danke ! Wäre interessant. Ich könnte mir vorstellen, dass im Modul oder der API evtl. noch ein Bug ist und irgend ein anderer Messwert "einstreut" (z.B. der von einer einzelnen Phase)

Zitat von: Eckat am 27 April 2021, 07:21:44
Welches Auto hast du und wie bekommst du den SoC in fhem?

Ich habe einen kia E-Soul mit 64 kWh Batterie und optionaler 3Phasen AC Ladung mit 11kW (das Vorjahresmodell konnte nur 1phasig). Laden von 60% SOC auf 100% SOC wären also ca. 26 kWh. Mit Ladeverlusten sind die geladenen 29,4 kWh also realistisch. Der SOC stammt von kia UVO. Während eines Ladevorgangs lese ich den alle 20 Minuten aus.

Grüße, gadget

OK, mit dem Zoom ist es gut zu erkennen. Vorher war es eher ein dicker Strick  :)
Das mit den 8,4 kW (nicht kWh  ;)) passt dann ja eher dazu, dass der wirklich rauf und runter regelt und es kein Auslesefehler ist.

Ich habe einen Kia e-Niro, auch mit 11 kW und UVO Connect. Aber wie hast du es hinbekommen, dass die Daten von UVO in fhem vorhanden sind?

Zitat von: Eckat am 27 April 2021, 10:41:22
Aber wie hast du es hinbekommen, dass die Daten von UVO in fhem vorhanden sind?

siehe https://forum.fhem.de/index.php/topic,118822.msg1145434.html#msg1145434 (https://forum.fhem.de/index.php/topic,118822.msg1145434.html#msg1145434) - ist ziemlich von hinten durch die Brust. Aber funktioniert. Wenn Du mehr wissen willst können wir das ja in diesem Thread weiter führen, hat ja nichts mit dem go-e Modul zu tun.

Hallo zusammen,

Ich habe dem Modul heute ein Update verpasst. Danach ist mein device verschwunden. Ein Versuch es neu zu erstellen bringt mir den Fehler:

Cannot load module GoECharger

Der Blick ins Logfile sagt mir:

Excessively long <> operator at ./FHEM/46_GoECharger.pm line 18.

Kenne mich mit der Modulprogrammierung gar nicht aus. Ist der Fehler bekannt?

Mmmh, ich kann in einem leeren Testsystem mit vollem Update den Fehler nicht nachvollziehen: neues Device anlegbar.
Das mit Zeile 18 irritiert mich. Schaust Du mal bitte im Log, ob der Download auch erfolgreich war und ob im Ordner FHEM die Datei 46_GoECharger.pm mit 63099 Bytes und Datum 03.03.21 ca. 02:00 lesbar drin liegt ???
Ich mache mal morgen ein Update in meinem Live-System...
PS: Bin auch nicht der Programmierer von Haus aus - tut mir leid, wenn es bei Dir hakelt. Schauen wir mal, dass wir das geklärt kriegen.
EDIT 30.04.: Bei mir geht alles, auch im Live-System.

Habe heute meine Box eingerichtet. Anlegen geht, Status auslesen auch. Aber wenn ich "set myGoE on" als Befehl absetzte, wird die Box angeschaltet, aber FHEM zeigt nur noch leere Seite auf der "Device-Fläche", der Raum-Tree bleibt. Muss dann den Raum und dann das Device öffnen, um das Ergebnis des "set" zu sehen. Weiterhin kann ich per set keinen Einfluss nehmen, also z. B. den Ladestrom nicht einstellen. "set myGoE amp_current" der normalen fhem-Funktionalität läßt keine Eingabe des Wertes zu. Manuell abgesetzt, auch "setreading", führt kurz zur Anzeige des neuen E´Reading-Values, ein "get state" zeigt das alte Value und die Box reagiert auch nicht.
Versucht mit "amp_current" und "stop_at_num_kWh".
Woran kann das liegen?

ps: parallel gerade Steuerung per MQTT getestet. Da funktioniert alles wie erwartet und die Box läßt sich perfekt steuern.

ZitatStatus auslesen auch. Aber wenn ich "set myGoE on" als Befehl absetzte, wird die Box angeschaltet, aber FHEM zeigt nur noch leere Seite auf der "Device-Fläche", der Raum-Tree bleibt. Muss dann den Raum und dann das Device öffnen, um das Ergebnis des "set" zu sehen. Weiterhin kann ich per set keinen Einfluss nehmen, also z. B. den Ladestrom nicht einstellen. "set myGoE amp_current" der normalen fhem-Funktionalität läßt keine Eingabe des Wertes zu.

So wie Du es beschreibst, ist das normales Verhalten bei händischer Eingabe Kommandozeile. Wozu das? Warum nimmst Du nicht die über webcmd definierten angezeigten on oder off, den slider für Strom etc auf der Device-Seite oder in der Übersicht??

Die Reaktion auf Texteingabe in der Kommandozeile ist normal. Die Text-Kommando's sind für DOIF oder notify gedacht. Ein Device bedient man über die definierten und angezeigten webcmd in der Device-Übersicht oder über die Möglichkeiten in der Deviceansicht. Kommandozeile eher weniger...
Und on off geht bei mir ebenso wie amp_current auch über Kommandozeile (mit dem normalen Effekt, dass man wieder in s Device reingehen muss - das ist m.E. normal in FHEM): die ausgeschriebenen Text-Komando's sind wie gesagt für Automatisierung z.b. über DOIF. Was soll ein "setreading" manuell in der Kommandozeile ausgeführt??? Die Readings werden vom go-Echarger = dem Device = über die API und das Modul gesetzt und nicht manuell (oder eben indirekt über set Kommando's oder webcmd). Die wenigsten Fhem-Devices für physische Geräte erlauben das direkte Setzen von Readings, das ist eher für Dummy-Devices u.a.

So, hm, es wird mir also am Device mit den normalen Web-Elementen (wahrscheinlich nutze ich hier den falschen Begriff, dafür entschuldige ich mich schonmal vor dem nächsten Anschiss) ein slider für "amp_current" angeboten. Dieser kann verschoben werden, um den Wert anzupassen. Suuuuper. Und wie soll dieser eingestellte Wert zur Box kommen????? Ich bin da naiv und denke, es geht wie bei meinen Lampen: man nehme den "set" Button. Nur dann passiert nix, die Box bleibt auf ihrem bisherigen Wert.
Dazu noch eine Info: jeder arbeitet anders. Ich nutze z. B. gerne die Kommandozeile für z. B. "set"-Kommandos, um einzelne Befehle zu prüfen. Tut mir leid, dass ich dafür keine Web-Cmds generiere oder irgendwelche Programme, bin wohl zu unprofessionell.

Ja, dafür gibt es die fhemweb-Oberfläche. Anbei ein Bild in der Device-Ansicht mit bedienbaren Elementen, in der Device-Übersicht mit bedienbaren Elementen und wie das dafür nötige Attribut aussieht: Wenn Du das Attribut webcmd auf on:off:amp_current setzt, bekommst Du am device ein Button on, ein Button off und den slider für amp_current wie im kleinen Bild.
Auch dran denken, dass Veränderungen am Lader (z.B. gemessene Ladeleistung) erst nach Ablauf der Zeit Interval (in Sekunden) aktualisiert werden. Auch das Interval kannst Du anpassen.

So, weiter gesucht:
nach der Device spez. Hilfe soll set <name> amp_current <value> gehen, bei mir hat es keine Auswirkung.
Zur Ergänzung für den Kollegen, der meint set in der Kommandozeile ist mehr oder weniger nicht erlaubt: habe es aus einem Notify eines anderen Elemnts heraus genutzt, hoffe das ist ok.
stop_at_num_kWh funktioniert, also sollte es nicht an der Methode liegen...

ZitatZur Ergänzung für den Kollegen, der meint set in der Kommandozeile ist mehr oder weniger nicht erlaubt: habe es aus einem Notify eines anderen Elemnts heraus genutzt, hoffe das ist ok.

Dafür ist das set Textkommando gedacht und natürlich kannst Du es in der Kommandozeile nutzen: Es führt lediglich zu dem Effekt, über den Du Dich oben beschwert hast, dass Du die geöffnete Device-Seite nach Ausführung nicht mehr siehst.
Und es gibt ein Unterschied zwischen 'set' und 'setreading' ...
Bei mir geht z.B. ein set myGoe amp_current 7 problemlos sowohl auf Kommandozeile auch in DOIF's.

genau das geht bei mir nicht, amp_current kann ich nicht setzen. Es bleibt auf dem aktuellen Wert stehen. Über MQTT kann ich einen anderen Wert setzen, der erscheint dann nach get status. Über das device keine Möglichkeit.
Nach Verbose = 5 steht folgender Eintrag im Log:
Send with URI: http://192.168.178.69/mqtt?payload=amx=10 (host: 192.168.178.69, path: mqtt?payload=amx=10 )
Sollte im payload nicht amp stehen?

In den Logs steht auch die Fehlermeldung:
./www/images/fhemSVG/ev_car_charger.svg is not useable
SVG liegt da, wo es liegen soll, Berechtigung wie auch alle anderen SVGs

der amx-Parameter hat bei mir keine Auswirkung auf den Ladestrom, der orientiert sich nur an amp.

Dann hast Du ggf. eine Firmware vor 040.0? Payload amx gibt es erst ab 040 und schreibt nicht wie amp in den Flash des goE und ist daher bei häufiger Änderung (z.B. bei Solarladen) besser als amp. Dann schau mal unter den set Kommando's nach dem Befehl amp_current_eeprom , dieser nutzt das frühere amp und speichert den Wert im Flash. Der sollte bei Dir dann gehen...
webCmd auf amp_current_eeprom ändern.
Wenn svg nicht geht, obwohl es an der richtigen Stelle liegt, ggf. Icon Cache in Fhem neu laden (da gibt es reread -Befehl, weiß ich grad nicht -> googlen im Wiki) oder Neustart.

Zitat von: burgi400 am 01 Mai 2021, 18:45:56
So, weiter gesucht:
nach der Device spez. Hilfe soll set <name> amp_current <value> gehen, bei mir hat es keine Auswirkung.
....

Welche Firmware-Version ist bei Dir auf der Box ?
Bei der 033 funktioniert das set <name> amp_current <value> nicht (mehr), da das FHEM-Modul daraus den amx-Befehl generiert und per API an die Box schickt.
Und der amx-Befehl wird erst ab FW 040 von der Box unterstützt (lt. Auskunft im Github der GoE-API https://github.com/goecharger/go-eCharger-API-v1/issues/49 (https://github.com/goecharger/go-eCharger-API-v1/issues/49))

Bei FW033 funktioniert wahrscheinlich nur  set <name> amp_current_eeprom <value>, allerdings stresst häufiges Schreiben die EEPROM-Zellen in der Box.
Daher die an sich sehr sinnvolle Änderung von LR66 auf den amx API-Befehl, funktioniert aber erst mit der neuesten FW040, die bei mir und eingen anderen aber das Problem hat, dass sich die Box nach einem Reset-Befehl aus der App raus aufhängt.
Deshalb bin ich immer noch bei 033 geblieben.

Firmware ist 040, auch kein Update verfügbar. Ich versuche es morgen wieter, vieleicht der Feiertags Blues....

Sind in den Einstellungen der Box (über die App) auch HTTP Zugriffe erlaubt? Kann das das Problem sein, dass die Amps sich nicht verstellen lassen?

[Gelöst]: Scheinbar war das Firmware-Update nicht so ganz richtig durchgelaufen, obwohl ich mehrere Neustarts durchgeführt hatte. Die Neustarts waren nötig, da die Box auch Probleme mit der Verbindung zu meinem MQTT-Server hatte. Zuerst wollte sie sich nicht verbinden, dann ging es plötzlich. HTTP-Requests zur Statusabfrage hatten aber immer funktioniert.
Habe die Box diese Nacht vom Netz getrennt und jetzt läuft alles wie es soll....

Zitat von: gadget am 27 April 2021, 09:11:00
Danke ! Wäre interessant. Ich könnte mir vorstellen, dass im Modul oder der API evtl. noch ein Bug ist und irgend ein anderer Messwert "einstreut" (z.B. der von einer einzelnen Phase)

So, bei mir sieht es anders aus.  :o
Es schwankt nicht, aber mehr als 9,9 kW sind an Ladeleistung nicht drin. Dafür aber konstant.
Was mich auch wundert, der go-eCharger (App und fhem) zeigen immer Spannungen je Phase knapp unter 220 V an. Mit jedem mir zur Verfügung stehenden Messgerät sind es aber 230 V oder etwas darüber, egal ob im belasteten oder unbelasteten Zustand.

Zitat von: Eckat am 02 Mai 2021, 18:47:30
So, bei mir sieht es anders aus.  :o
Es schwankt nicht, aber mehr als 9,9 kW sind an Ladeleistung nicht drin. Dafür aber konstant.

Danke für die Info.

Meiner lädt auch gerade, ich hab aber immer wieder diese Einbrüche auf 5kW.

Ich hab mal verbose 5  eingeschaltet und das kommt offenbar tatsächlich ab und zu so von  der Wallbox. Im nrg Array steht bei so einem Ausreißer:


"nrg":[221,219,221,1,74,72,72,16,15,15,0,473,97,97,98,1],


Und der Eintrag an 12. Stelle dividiert durch 100 ist offenbar das, was dann in KW_charging_measured landet, also 4,73 kW. Das Modul ist also unschuldig.

Schon merkwürdig. Vielleicht auch Box-Firmware-Abhängig. Ich bin noch auf der 0.33 wegen dem Soft-Reboot Problem in den neueren Versionen.
Vielleicht leihe ich mir  mal ein Zangenamperemeter aus und messe das direkt im Verteiler nach.

Grüße, gadget

Hallo zusammen,

ich habe hier im Forum vor einiger Zeit, als ich mich noch rein theoretisch mit dem Thema Überschuss-Laden beschäftigt habe, ein ziemlich ausgereiftes und übersichtliches DOIF gefunden, um die Ladeleistung an die PV-Erzeugung anzupassen.
Seit gestern ist nun mein Go-E angeschlossen, und ich finde den Beitrag nicht mehr :(
Weiß vielleicht jemand, welchen ich meinen könnte und kann mir den Link dazu geben?

edit:
ich glaub, das da war's, was ich gesucht hab (ist tatsächlich in diesem Thread  :P ): https://forum.fhem.de/index.php/topic,110282.msg1093448.html#msg1093448

@gadget
Ja, bei dir würde ich auch auf einen tatsächlichen Einbruch der Ladeleistung tippen.
Dazu passt ja auch die durchschnittliche Ladeleistung.
Ich habe bei mir die Firmware 0.40 installiert. Bisher habe ich den Soft-Reboot erst 2x benötigt, aber dann ist es natürlich nervig erst hinrennen zu müssen.

@wolliballa73
Der Beitrag würde mich auch interessieren.
Aber nach meinen Erfahrungen bin ich mir nicht mehr so sicher, ob es ein allgemeingültiges geben kann. Da spielen halt viele unterschiedliche Geräte zusammen.

Habe das Modul laufen und heute erstmals 9kWh Überschuss in meinen Enyaq geladen. Sind bei der Steuerung wirklich nur 1A Schritte möglich? 960W ist ganz schön grob, um sich an die Einspeisung ,,ranzutasten". 0.2A Schritte wären cool, dann könnte man die Einspeisung viel feiner ,,abfahren" durch rantasten in 140W Schritten

Habe grad die API Dokumentation gefunden, leider nur volle Ampere möglich. https://github.com/goecharger/go-eCharger-API-v1/blob/master/go-eCharger%20API%20v1%20DE.md

Hi, der go-ECharger (und die Spezifikation Typ2 AC  https://de.m.wikipedia.org/wiki/IEC_62196_Typ_2 (https://de.m.wikipedia.org/wiki/IEC_62196_Typ_2) ) gibt da Grenzen vor.
Es gehen nur 1A-Schritte ab 6A (je Phase, d.h. je Phase niedrigste Typ2-Ladeleistung 1380 W).

Bei dreiphasigem Betrieb also Start ab 4140 W in Schritten von 690W.

Geringer und feinstufiger geht es nur einphasig, z.B. mit einphasigem Typ2-Kabel: dann Start bei 6Ax230V= 1380W in Schritten von 230W...

Zitat von: Waldmensch am 08 Mai 2021, 19:29:48
Sind bei der Steuerung wirklich nur 1A Schritte möglich?

Ja, das liegt aber an der Norm für Typ2-Laden. Da ist das so definiert. Daher ist das bei allen Wallboxen und öffentlichen Ladesäulen gleich, also kein fehlendes Feature vom go-eCharger.

Zitat von: Waldmensch am 08 Mai 2021, 19:29:48960W ist ganz schön grob, um sich an die Einspeisung ,,ranzutasten". 0.2A Schritte wären cool, dann könnte man die Einspeisung viel feiner ,,abfahren" durch rantasten in 140W Schritten

Wie kommst du denn auf 960 W?  :o ;)
Also 1 A bei 230 V sind 230 W (1-phasig) bzw. 690 W (3-phasig). Da fällt mir beim schreiben auf, könnte es sich um einen Zahlendreher handeln?

Davon abgesehen ist das ein Nachteil, keine Frage.
Bei mir habe ich es aktuell noch so gelöst, dass ich zum Überschussladen ein 1-phasiges, kurzes Typ2-Kabel verwende. Dann kann man zwischen 1.380 W (6 A) und 3.680 W (16 A) in 230 W Schritten regeln.
Das hängt aber natürlich auch von den sonstigen Gegebenheiten ab. Ich habe eine 10 kWp PV-Anlage, mit ca. 1/3 nach Osten und 2/3 nach Westen. Das bedeutet ich habe nie mehr als ~ 6,5 kW Leistung. Dazu habe ich eine Tesla Powerwall 2 als Hausspeicher mit 13,5 kWh Netto-Kapazität.
Jetzt im Frühjahr führt es dazu, dass an halbwegs sonnigen Tagen (halt nicht durchgängig Sonnenschein) fast nichts ins Netz eingespeist wird, die Powerwall meistens > 90 % Ladezustand Abends beim Sonnenuntergang hat und das Auto schon ganz gut geladen wurde.

Eine Umschaltung zwischen 1- und 3-phasigem Laden kann der go-eCharger nicht.
Allerdings ist das Umschalten während des Ladevorgangs bei den Autos auch nicht ganz unproblematisch. Da gibt es mehrere Berichte, dass die OnBoard-Charger das nicht vertragen haben und kaputt gegangen sind. Das sind dann gleich Reparaturkosten > 1.000 €.
Ein sicheres Umschalten könnte man so realisieren:

• beenden des Ladevorgangs
• sicherstellen das kein, bzw. nur minimal, Strom fließt
• abschalten aller Phasen
• kurze Pause
• zuschalten von nur L1 oder L1-3
• starten des Ladevorgangs

Der go-eCharger kommt nämlich mit einer 1-phasigen Einspeisung (muss L1 sein) klar, kann/ soll/ darf aber nicht im Betrieb verändert werden.
Mir schwebt daher ein kleiner Controller vor (z. B. auf Basis ESP8266), der dann zum einen (über ein Lastrelais) die Phasen schaltet und auch den Stromfluss messen kann.
Denn der sollte meiner Meinung nach dann alles selbstständig machen und z. B. nur die Umschaltung durchführen, wenn der Ladevorgang wirklich gestoppt wurde.
Damit könnte man aus fhem heraus den Controller nur mit den Befehlen "schalte auf 1 Phase" oder "schalte auf 3 Phasen" steuern und man würde nicht Gefahr laufen, durch Änderung am fhem-Code doch eine Umschaltung im Betrieb durchzuführen.

Das ist aber noch nur eine Idee.  ;D

@Eckat: ja, war natürlich ein Zahlendreher 😉

Von gehimmelten OnBoard Ladern bei Phasenumschaltung habe ich gelesen. Besonders die Zoe soll da allergisch drauf reagieren. Es läuft 3phasig in 1A Schritten schon ganz gut. Jammern auf hohem Niveau. Das Modul arbeitet 1A. Ich werde für mich den Aufwand nicht betreiben, da noch Schütze in 2 Phasen einzubauen. Wenn ich über einen sonnigen Tag 10-15kWh absaugen kann, reicht mir das völlig. Soweit ich das an den bisherigen Daten überblicke scheint das absolut machbar. Das Auto steht bei mir auch noch in Konkurrenz zu einem 9,6kWh Solarwatt Hausspeicher. Dieser ist aber DC seitig gekoppelt und befindet sich dadurch schon quasi automatisch auf der Überholspur, da er sich direkt an einem String bedient.

Die gelieferten kWh können irgendwie nicht stimmen. Ich habe meine 77kWh Batterie heute von 20% auf 65% hochgeladen mit dem Go-E. Im Modul bekomme ich aber nur charged_last 11,8kWh angezeigt. Charged_total steht auf 21kWh. Wie komme ich auf einen reellen Tageswert? Sollte das auf die zu niedrig gemessene Phasenspannung des Go-E zurückzuführen sein? Nach SMA Portal müssten mindestens 25kWh an die Wallbox gegangen sein, wenn ich den Hausverbrauch großzügig von den 29kWh Eigenverbrauch abziehe.

Edit: es müssten sogar über 30kWh an die go-E gegangen sein. Das SMA Portal hat immer etwas Nachlauf bei den Daten. Der Eigenverbrauch beläuft sich auf 36kWh. Das Haus braucht maximal 6, bis zum vorläufigen Ende des Diagrammes

Die Abweichung der vom go-E gemessenen Leistung beträgt meiner Erfahrung nach so 4...7%. Eventuell können noch Leitungsverluste bis zum go-E dazukommen. Mit Deinen Zahlen stimmt so wie genannt tatsächlich irgendwas nicht. Von 20 auf 65% würde +45% bedeuten, also angeblich angekommene 34,65kWh... mmh. Hat der Akku einen Puffer? Zeigt das Auto nur % oder auch geladene kWh?
kWh_charged_total zeigt was jemals seit erster Nutzung geladen wurde
kWh_charged_last bleibt bis zum Abstecken stehen (wird mit Stop/Start kumuliert), mit neuem Anstecken geht es wieder bei 0 los... einen Tageswert hat man da in dem Sinne nicht.
Vergleiche nochmal Deine Angaben in Fhem, App, Auto und SMA. Ggf. mal woanders laden oder go-E kontaktieren ?!
Was sagt denn die go-E App?
Edit: Hast Du ggf eine abgebrochene Verbindung zum go-E und damit von ihm keine akt. Anzeige? Oder gab es einen Reboot zwischendurch, der - was ich noch nie erlebt habe - ggf den go-E internen Zähler genullt hat?

Die App zeigt, was FHEM auch zeigt, siehe Screenshot. Der Enyaq zeigt leider keine kWh an, sondern nur den SoC. Der liegt jetzt bei 65%. Die von dir angenommenen 34% decken sich in etwa mit dem, was ich am Sunnyportal anhand des Eigenverbrauch ablesen kann.
Was mir seltsam vorkommt ist, dass die App seit einiger Zeit nur noch eine Phase anzeigt. Kann es sein, dass die 11 angezeigten kWh x 3 genommen werden müssen? Dann würde es ja ungefähr passen. Die 34KWh können ja kaum über eine 16A abgesicherte Phase geflossen sein. Das Kabel ist auch 3phasig. Das Kabel war die ganze Zeit angeschlossen. Natürlich hat mein DOIF ab und zu die Ladung angehalten, nachdem trotz runtertaktung auf 6A nicht mehr genügend Leistungen zur Verfügung stand.
Firmware ist die 040.0, eine Neuere wird nicht angeboten.

Ich habe aus der App jetzt mal einen Neustart initiiert. Dabei hat sich die Box scheinbar völlig aufgehängt. Dann habe ich sie Stromlos gemacht und nach 30 Sekunden die Sicherung wieder reingemacht. Jetzt ist sie wieder da und zeigt 3 Phasen an. Die Sicherung ist ein 3fach Leitungsschutzschalter. 2 Phasen können also installationsseitig nicht verschwinden. Entweder sind alle 3 da oder alle 3 weg. Ich befürchte, dass die Firmware da einen Bug hat und denkt, es wäre nur eine Phase da. Entsprechend wird auch nur die Leistung einer Phase kumuliert.
App nach Kaltstart:

Die Anzeige von nur einer Phase obwohl die Box fix über 3-fach LS angeschlossen ist,  dürfte die Fehlerursache sein: da ist im Controller was falsch gelaufen und damit, weil Annahme nur einer Phase, dann auch falsche Messung. Geflossen ist ja offensichtlich die 3-fache Menge. Wende Dich doch mal an den Support... auch der Neustart sollte ja eigentlich gehen! Da sollte sich go-e mal äußern und was tun.

Zitat von: LR66 am 11 Mai 2021, 01:52:05
auch der Neustart sollte ja eigentlich gehen! Da sollte sich go-e mal äußern und was tun.

Der Hang-after-Soft-Reboot-Bug ist dort seit Dezember bekannt. Finde ich auch etwas merkwürdig, dass es da noch keinen Update gab. (Bedient aber ein wenig das Österreich-Klischee "I woooaaaas ah niiit. Siehst a Schneckn, bückst di... huschhusch, sans weg...")

Zitat von: gadget am 11 Mai 2021, 10:27:09
Der Hang-after-Soft-Reboot-Bug ist dort seit Dezember bekannt. ....

Sogar schon seit Oktober 2020, siehe https://forum.fhem.de/index.php/topic,110282.msg1095011.html#msg1095011 (https://forum.fhem.de/index.php/topic,110282.msg1095011.html#msg1095011)  und +2
Einige Zeit nach dem damaligen Downgrade-Support hatte ich nochmals wegen 040-Bugfixing nachgefragt, aber keine Antwort dazu bekommen.

Zitat von: gadget am 11 Mai 2021, 10:27:09
...
"I woooaaaas ah niiit. Siehst a Schneckn, bückst di... huschhusch, sans weg...")

ROFL   ;D

Nach dem Kaltstart scheint es korrekt zu zählen. Bei Phase avail wird jetzt 111111 angezeigt vorher stand da manchmal 1111 oder 1000.

Dann muss ich auch mal prüfen, wie meiner nach Neustart/Warmstart reagiert.

PS: Die verfügbaren Phasen werden von der API hier binär gezeigt: die letzten 3 Stellen sind die Phasen Richtung Auto, die 3 davor beziehen sich auf das, was am go-E anliegt (oder in Deinem Fall: was er glaubt, was anliegt  ;) ).
Also
111000 heißt: 3 Phasen liegen an, gehen aber (noch) nicht zum Auto
111111 dann beim Laden
Dein
1000 heißt: es liegt nur eine an und (noch) geht nix zum Auto
1111 zeigt den go-E Irrtum: 1 liegt angeblich nur an, aber 3 gehen zum Auto  ::)
Wie geht das? Und beim rechnen/messen nimmt er dann nur die eine...

Bitte mache da ein Servicethema auf, da auf Änderung zu hoffen wäre...

Hat eigentlich schon mal jemand versucht einen MEB (also Id.3/4 oder Enyaq) mithilfe eines extra Schütz vor dem Go-E während des Ladens zwischen 1phasig und 3phasig umzuschalten? Bei der Zoe konnte man damit ja den onboard Lader grillen. Wenn man zur Umschaltung erst den Ladevorgang unterbrechen muss, wird das eine ziemlich fummelige Geschichte in FHEM. Wenn man einfach nur über MQTT und bsp. Einen Sonoff Basic on the fly 2 Phasen zu- und wegschalten könnte, wäre das recht leicht über die bekannten DOIF aus dem Thread mit zu realisieren. Mir geht es um das Laden unterhalb 4kW Überschuss. Mit einem einphasigen Kabel zu hantieren lohnt sich vielleicht im Winter, wenn eh keine 4 kW zu erwarten sind. Im Sommer gibt es aber auch mal Wolken. Dann 3kW ins Netz zu schieben, nur weil man das 3 phasige Kabel dran hat ist blöd.

Ich habe kein MEB-Auto. Aber ich würde das auch nicht versuchen.

Aktuell gibt es ein paar Berichte zum Fronius Wattpiliot. Der sieht fast identisch zum go-eCharger aus, kann aber PV-Überschussladen und die Umschaltung 1- auf 3-phasig (und umgekehrt).
Bei einem Video war gut zu sehen, dass er bei der Umschaltung auch erst die Ladung beendet, die Phasen zu- oder wegschaltet und dann die Ladung neu startet.
Das ist natürlich komfortabler als mit dem go-eCharger über fhem und Zusatzhardware, aber verdeutlicht auch, dass die es auch nicht im Ladevorgang umschalten.

Mir wäre das Risiko auch zu hoch.

Mein Ansatz ist (für die Zukunft) einen kleinen Controller (ESP8266 o.ä.) zu nutzen, der dann von fhem getriggert wird und die Umschaltung (beenden, Stromüberwachung, Umschalten, starten) selbstständig macht.

Hallo @LR66,

ich hätte eine kleine Bitte: Könntest Du vielleicht in einer zukünftigen Modulversion einen Soft-Reboot-Befehl einbauen ?

Hier ist beschrieben (von P. Pötzi persönlich), wie das per API geht: https://github.com/goecharger/go-eCharger-API-v1/issues/31 (https://github.com/goecharger/go-eCharger-API-v1/issues/31)

Mit "http://192.x.x.x/mqtt?rst=1" hat es bei mir funktioniert (aber halt eben mit der FW033)
Ich muss eine meiner beiden Boxen immer mal wieder per Soft-Reboot auf den "stärksten" Accesspoint schubsen, weil das AVM-Mesh das nicht so recht hinkriegen will ...
Wäre super, vielen Dank  :)

BTW: vom go-e-Service habe ich bezgl. des Hang-after-Soft-Reboot-Bugs in der 040 die Auskunft bekommen,
(Zitat:) "dass der Fix in einem weiteren Software-Update (mit anderen Neuerungen) enthalten sein wird. Ein neues Update sollte wohl noch im Laufe des Sommers kommen, wodurch der Fehler dann auch behoben wird."
Dann hoffen wir mal ...  ;)

Nachdem ich lange nichts mehr dran gemacht hatte, habe ich nun in Version 0.2.2 das gewünschte set-Kommando set <device> restart eingebaut und mich mal wieder mit github beschäftigen müssen  ;).

Es wäre übrigens auch mit Version 0.2.1 gegangen: über payload-Kommando set <device> payload rst=1 - für solche Neu- oder Testfälle hatte ich das so angelegt.

(Github ... ::) warum auch immer hatte ich mit unterschiedlichen filesizes zwischen main-Github und lokal-Github zu kämpfen und musste entsprechend die controls...txt über runterladen und neuberechnen korrigieren -> es sollte jetzt passen)

Ich hab mir jetzt mal zum spielen eine 230V Relaisplatine mit ESP8266 und ein 2P Schütz bestellt. Ob und wie ich das eingebunden kriege weiß ich noch nicht. Vor allem, wie man auf den Stopp der Ladung wartet um die 2 Phasen an/abzuschalten. Im DOIF, was die PV Führung übernimmt, kann man ja die Schwellwerte irgendwie von Phase avail abhängig machen.

@LR66 kannst Du in das Modul ein Reading einbauen, was diese Binärangabe in einem einfachen 0/1 ausgibt? Also wenn der Go-e 111xxx sagt 3N=1 und bei 100xxx 3N=0? Ich denk mal, das macht sich im Perl leichter als in FHEM

Edit: oder noch besser, ein Reading, mit dem man gleich rechnen kann, also 1 oder 3 ausgibt, wenn eine oder drei Phasen anliegen

Ich denke man muss definitiv einfach nur Reihenfolge einhalten:
1. Laden stoppen: allow_charging=0
2. alles abschalten, also Phasen 3polig aus
3. Pause ? 1..5 sec bis Prozessor tot
4. ein- oder 3-polig zuschalten
Ob es 3- oder 1-phasig dran ist, solltest Du ja an Deinen Schaltdevice-Rückmeldungen sehen, und auch über KW_preset_calculated (wenn ich das richtig progr. habe ?) oder an KW_charging_measured feststellen können.
Achtung, nur einfach 2 Phasen weg- oder zuschalten wird nicht gehen - hab ich über Sicherungen/LS getestet. Das erkennt der go-E nicht korrekt und geht auf Fehler (oder liefert falsche Werte).

Oh, damit hast Du natürlich meine Hoffnung zerstört. Ich dachte, der Go-E wäre in der Lage, die Phasen ,,live" zu erkennen sodass mal L2 und L3 während seiner Laufzeit zu und abschalten kann und er das Automatisch merkt. Wenn man ihn erst allpolig trennen muss muss mindestens ein zweites Schütz rein und es kostet noch mehr Zeit umzuschalten. Ich glaube, ich lass das sein und besorge mir nach Ablauf des Förderzeitraums (der Go-E ist KFW gefördert) eine openWB. Da habe ich dann wohl aufs falsche Pferd gesetzt. Meine PV liefert zwar genug Überschuss, um im Sommer das Auto zu laden, aber im Winter wäre ich auf einphasig angewiesen. Die Lösung mit dem einphasigen Kabel ist eine Krücke, weil man ja nicht weiß, wie das Wetter wird und ich auch keine Lust hab, meiner Frau zu erklären, welches Kabel wann verwendet werden soll.  :(

Zitat von: LR66 am 14 Mai 2021, 20:19:23
Nachdem ich lange nichts mehr dran gemacht hatte, habe ich nun in Version 0.2.2 das gewünschte set-Kommando

Code Auswählen Erweitern

set <device> restart eingebaut und mich mal wieder mit github beschäftigen müssen  ;).

Es wäre übrigens auch mit Version 0.2.1 gegangen: über payload-Kommando

Code Auswählen Erweitern

set <device> payload rst=1 - für solche Neu- oder Testfälle hatte ich das so angelegt.
...

@LR66: Vielen Dank für das Restart-Kommando  :)
und auch Danke für den "payload"-Tipp.

Zitat von: Waldmensch am 15 Mai 2021, 06:15:50
Wenn man ihn erst allpolig trennen muss muss mindestens ein zweites Schütz rein und es kostet noch mehr Zeit umzuschalten.

Ich denke im Alltagsbetrieb wird man die Umschaltung nicht sehr häufig machen müssen.
Z. B. mein SMA Wechselrichter liefert nicht nur die aktuelle Leistung, sondern auch die durchschnittliche der letzten 15 Minuten. Damit könnte man abschätzen ob es viele kleine Wolken sind oder ob es strahlend blauer Himmel ist. Daraus dann ableiten, ob 1- oder 3-phasig geladen werden soll.
Wenn dann kurz mal was eingespeist oder aus dem Netz bezogen wird, würde ich das in Kauf nehmen bzw. der Speicher ist ja auch noch da und kann kurzzeitige Differenzen ausgleichen.

@LR66: könntest Du in das Modul ein Reading einbauen present = 0|1 was eindeutig anzeigt, das der Go-e verfügbar ist? Oder kann man das jetzt schon an einem anderen Reading erlesen? Hintergrund ist ein Restart Szenario, damit während eines Reboot keine Kommandos an den Go-e geschickt werden.

Noch besser wäre, wenn man ein lock Reading setzen könnte, das sämtliche anderen Befehle unterdrückt bzw. Ins Leere laufen lässt.

Ich bin gerade dabei ein Szenario zu entwickeln mit einem Sonoff 4CH der 2 Schütze schaltet. Die Zeitlichen Abläufe werden direkt in Tasmota gesteuert.
- 4fach Schütz aus
- 20 Sekunden warten
- 2fach Schütz ein/aus
- 4fach Schütz ein

Das werde ich über 2 MQTT Kommandos switchto1 und switchto3 triggern

Dann muss ich nur noch FHEM überreden zu
- Ladung beenden (und durch irgend einen lock nicht wieder starten)
- warten bis KW_charging_measured == 0
- switchto1 oder 3

Über ein present Flag könnte man im Steuer DOIF sämtliche Kommandos unterdrücken solange der go-E durch den reboot weg ist. Das present flag könnte man eventuell auch vor dem reboot selbst auf 0 setzen

Kann auch sein, das der Ansatz unsinnig ist, aber irgendwie muss sich die Phasenumschaltung doch sauber hinkriegen lassen. :)

Du könntest auch ein komplettes (PV-Lade-)DOIF über ein separates notify disablen, wenn der GoE nicht erreichbar ist (Prüfung des Http_state ob ready oder nicht, ggf. noch Interval anpassen). Allerdings seh ich auch kein Problem darin, dem goE einen Ladestrom zu senden wenn er stromlos ist ? Ich versteh das Problem an sich wohl nicht...

PS: muss N tatsächlich auch weggeschalten werden? Ich hab die Funktion 1-/3-phasig oder reboots allein über LS ein/aus in der Verteilung getestet, da bleibt ja der N verbunden und es ging m.E. auch. Dann reduziert sich das auf 3-fach Schütz und 1-fach Schütz.
Für mich bin ich unschlüssig: Ein Laden zwischen 1380VAund dem 3-phasigen 4140VA ist ja nicht nur langsam. Bei den meisten BEV läuft auch ein ganzer Teil Bordelektronik dann über zusätzliche Stunden, das ist m.E. nicht so toll und das können bei manchen schon 150-300W Verlust sein. Dein Schütz braucht dann ggf auch noch rund um die Uhr Strom (es sei denn, normally closed, die sind gleich nochmal teurer, weil seltener). Normale Steckdosenschalter mit Klein-Relais "bis 16A" würde ich wegen der Dauerlast nicht empfehlen - ist wie Schukosteckdose bei 16A Dauerstrom grenzwertig.
Ich seh natürlich auch das Ziel, soviel wie möglich selbst zu verbrauchen... (bin da aber dank Hausspeicher, der eher da war, nicht so unter Druck: der hält mir den Ladestrom noch Weile hoch, wenn es wolkig oder es weniger wird).

Ich will halt vermeiden, das über das große DOIF die Ladung neu gestartet wird, während ich den Ladestopp gesetzt habe und warte, das kein Strom mehr fließt. Das wären mit dem Standard Poll 60 Sekunden. Ich würde ungern das Schütz ausschalten, während noch Strom fließt. Http_state hatte ich nicht auf dem Schirm, das schau ich mir mal an. Ein Lock Flag könnte ich eventuell auch mit einem Dummy setzen.

Die günstigsten Schütze sind 4er und 2er, ob ich den Null mit drüber ziehe ist letztlich egal. Das 2er Schütz will ich in Fließrichtung vor das 4er setzen und blocken solange das 4er aktiviert ist. Das sollte sich über Tasmota Rules recht gut abfackeln lassen.

Ich habe auch einen 9,6kwh Speicher, den würde ich aber ungern ins Spiel bringen. Der fängt aber jetzt schon die Spitzen ab, wenn das DOIF nicht hinterherkommt. Das läuft mit 20 Sekunden Intervall was bei einer Wolke ganz schön lang sein kann. Zudem lass ich bei einer Wolke den Go-E erstmal sofort auf 6A gehen egal wo er war. Sollte das nicht gereicht haben, wird die Ladung erst im nächsten Doif Intervall deaktiviert. Ich bilde mir ein, dass das deaktivieren/aktivieren länger dauert, als Ladestrom Änderungen. Ich weiß auch nicht ob häufiges aktivieren/deaktivieren ungesund fürs Auto ist.

Das langsamere Hochfahren macht m.E. das BEV, runterfahren sollte auch per kleiner Wartezeit funktionieren - kannst Du in der App gut mal prüfen.
Wenn man ein schnelles Reagieren auf den goE braucht, kann man zusätzlich (oder wenn man die ganzen payloads kennt, auch alternativ) einen MQTT2-Server und -Device für den goE anlegen: der goE sendet die payloads bei Aktivierung MQTT im 5s-Takt, u.U. besser als Polling - siehe auch Thread-Verweis ganz oben im ersten Post...
Hat alles seine Vor- und Nachteile: Mqtt-Device ist schwieriger anzulegen und zu konfigurieren, braucht aber kein Polling, hat bei mir aber gelegentl. Verbindungstrennung - müsste man auch auffangen.

Ich weiß nicht, ob ihr es schon mitbekommen habt: die neuen Go-e mit Seriennummer CM-03 beginnend, können Phasenabschaltung. Da sind also nun scheinbar 2 Schütze verbaut, statt einem. Wer jetzt also eine Go-e kauft, dies unbedingt beachten. Es wird nicht groß beworben, damit die Restlichen noch verkauft werden können. Keine Ahnung, wie die Umschaltung dann per Api gesteuert werden kann.

Hatte schon von einer Fronius-Wallbox gelesen, die wie ein go-E aussehen soll und das kann (sicher von go-E für Fronius). Eine gute Weiterentwicklung, nur ärgerlich, dass das jetzt erst kommt. Deswegen sieht man in der neuen go-E App viell. auch explizit die HW-Version, bei meinen leider V2.

Dann werde ich meine schon begonnene eigene Schaltung (die im Trockentest einwandfrei funktioniert) verwerfen und mir die neue Version holen. Die alte Homefix wird dann auf Mobil umgebaut und kommt in den Kofferraum, wo sie dann vermutlich vergammelt, weil ich sie kaum brauchen werde. Eventuell finde ich auch einen Zoe Fahrer, der mir die Alte abkauft (für die ist es ja eher ein Risiko).

Eine go-E eigene Umschaltung ist natürlich immer besser, da man die Box nicht neu starten muss, um die Phasenanzahl zu erkennen. Auch wird vermutlich vor der Umschaltung der Ladevorgang sauber beendet.

Zitat von: Eckat am 14 Mai 2021, 08:00:11

Aktuell gibt es ein paar Berichte zum Fronius Wattpiliot. Der sieht fast identisch zum go-eCharger aus, kann aber PV-Überschussladen und die Umschaltung 1- auf 3-phasig (und umgekehrt).
Bei einem Video war gut zu sehen, dass er bei der Umschaltung auch erst die Ladung beendet, die Phasen zu- oder wegschaltet und dann die Ladung neu startet.
Das ist natürlich komfortabler als mit dem go-eCharger über fhem und Zusatzhardware, aber verdeutlicht auch, dass die es auch nicht im Ladevorgang umschalten.

Mir wäre das Risiko auch zu hoch.

Mein Ansatz ist (für die Zukunft) einen kleinen Controller (ESP8266 o.ä.) zu nutzen, der dann von fhem getriggert wird und die Umschaltung (beenden, Stromüberwachung, Umschalten, starten) selbstständig macht.

Die neune V3 des Go-E Charger unterstürzt auch das Umschalten von 1-3 Phasen und ist in der Lage wohl ,,alle" Kontakte des Steckers zu trennen.
Sehr hilfreich für störrische PSA Fahrzeuge die erwarten das bevor Strom kommt der Stecker gezogen wird.

Ich habe gerade ein Gerät zu testen da.
Es ist was das Modul angeht kompatibel, es gibt in den Readings ein paar kosmetische Fehler, aber grundsätzlich geht's.
Das smarte Laden über Awattar ist nun auch drin. Gut, ist mir aber persönlich egal.

Eigentlich bin ein riesiger Fan der go-e Wallboxen sowie der gesamten Firma, ABER ich finde das Verhalten gegenüber den Kunden in einigen Punkten nicht angemessen!

1. Seit Oktober 2020 gibt es KEIN Update für die Firmware V40, die bei allen go-e Wallboxen in meinem Besitz und Bekanntenkreis regelmäßig Abstürzte verursacht! Das ist ein 3/4 Jahr seit dem die Kunden von go-e sich mit dem Problem rumschlagen müssen.

2. Bis zu der Version V40 wurden die Daten die mit der App oder über die API eingestellt wurden z.B. der Ladestrom, im EEPROM (bei dem NodeMCU Modul im Charger ein simulierter EEPROM auf SPI Flash-Speicher) gespeichert. Das führt dazu, dass der Speicher viel schneller verschlissen ist, als notwendig. Ähnlich wie bei der Tesla MCU https://www.heise.de/autos/artikel/Teslas-Flash-Fehlkonstruktion-4563357.html

Dies hat man wie gesagt in der V40 still und heimlich geändert. Man hat es nicht für notwendig gehalten den Kunden zu informieren. Wenn dann die WallBox kurz nach den 2 Jahren Garantie kaputt geht, dann ist das halt so? Persönliches Pech? Wo ist da die Nachhaltigkeit?

Ich habe mehrfach mit der go-e GmbH geschrieben, man hat mir das Downgrade angeboten und ist NICHT auf die EEPROM Problematik eingegangen obwohl ich explizit danach gefragt habe.

Das finde ich nicht in Ordnung!

Ich habe danach nochmal dort angerufen, aber man konnte mir nicht verbindlich sagen, wann ich meine Wallboxen ohne ständige Abstürze benutzen kann.

Bei Tesla haben die Kunden dann geklagt und die NHTSA hat auch mal auf die Pauke gehauen:
https://www.heise.de/hintergrund/Tesla-ruft-135-000-Autos-wegen-moeglicher-Bildschirm-Fehlfunktion-zurueck-5043579.html

Vielleicht sollten man der KFW und den anderen Fördergebern in Deutschland mal von dem wenig nachhaltigen Verhalten der go-e GmbH berichten? Denn am Ende zahlen die ja derzeit die meisten der installierten Wallboxen...

Falls das jemand der go-e GmbH liest:

Ihr habt ein super spannendes Produkt! Ich finde die Firma super! Aber die beiden vorgenannten Punkten müssen dringend nachgebessert werden! Die Bestandskunden die schon früh Eure Produkte gekauft und weiterempfohlen haben so zu behandeln?

In meinem Bekanntenkreis haben sich nach dem ich mit den Firmware Versionen vor der V40 wirklich gute Erfahrungen gemacht habe, 10 weitere Leute aufgrund meiner Empfehlung die go-E Wallbox gekauft.

Danke go-e!  :-\

Sobald die Api Dokumentation für die neue Hardware da ist, werde ich mir die als Mobilversion mit Adapterkit holen. Dann mach ich am Kabel einen Kreuztausch mit meiner installierten HomeFix, die dann im Kofferraum landet.

@Basti-K: ist bei Deiner Box die Spannungsmessung genauer, oder geht die genauso nach dem Mond?

Hallo,

habe den goe schon einige Monate in der Garage am Laufen und muss mir nun einen 3poligen Unterbrecher einbauen, da ich keine Lust habe, die Box jedes mal im Haus über den LS zu resetten, wenn sie sich aufhängt (nach FW Update sowieso)

Das FHEM Modul habe ich heute eingerichtet und es lief sofort.
Den Thread habe ich gerade von vorne bis hinten gelesen, aber PV Überschussladen benötige ich bei meiner kleinen Anlage noch nicht.

Evtl. könnte mir bitte jemand bei den folgenden Fragen helfen:

1.)
was beinhaltet das Reading:  "ap_password"?

2.)
Ich würde gerne visualisieren, was täglich geladen wurde (2 PKWs).

Muss man hier den Weg über ein FileLog oder DBLog gehen und dann ElectricityCalculator nutzen und Plots erstellen, oder ist hier schon etwas eingebaut?

3.)
Kann man 2.) evtl aus FHEM als CSV exportieren?

4.)
Hat schon jemand Modbus over TCP getestet (rein ob es funktioniert)?

Vielen Dank für Hinweise

Ok, Thema hat sich bei mir erledigt
Konnte auf CM3-03 Hardware upgraden und da soll man die Historie in der Cloud sehen können.
Und für den Rest scheint OpenWB evtl. besser geeignet

Ohne API Dokumentation kann OpenWB genauso viel oder wenig wie FHEM

Zitat von: Waldmensch am 17 Juni 2021, 14:35:37
Ohne API Dokumentation kann OpenWB genauso viel oder wenig wie FHEM

Hallo Waldmensch. Die Dokus findest Du hier:

https://go-e.co/downloads/
HTTP API Dokumentation go-eCharger HOME+ und HOMEfix
Modbus TCP API Dokumentation go-eCharger HOME+ und HOMEfix
go-e Netzbetreiber API Dokumentation go-eCharger HOME+ und HOMEfix

Aber nicht für die neue HW mit Phasenumschaltung. Der aktuelle Stand ist immer noch für die Version mit einem 4fach Schütz https://github.com/goecharger/go-eCharger-API-v1

Hallo zusammen,

funktioniert bei der neuen Version noch das setzten des Ladestroms über das Modul ohne ihn in eeprom zu schreiben? Wenn ich in FHEM den Ladestrom anpasse ändert sich der Wert amp und amx im JSON  ???

VG
Christian

Für das Setzen des Stromes wird amx verwendet, damit wird gem. Api auch der amp-Wert im flüchtigen Speicher gesetzt (und über das json als Antwort gesendet), aber der amp-Wert wird in dem Fall  nicht in den Flash geschrieben. Um das alte amp-Setzen zu verwenden (mit Speichern im Flash, sinnvoll für Merken der Stromeinstellung für ein evtl. Reboot) gibt es das gesonderte Kommando.

Sorry, ich habe mich wohl etwas falsch ausgedrückt. Meine Frage zielt eher darauf ab ob das beim Go-E v3 immer noch so ist. Ich habe ein paar Tests gemacht aber da sieht es nicht so aus. Der Ladestrom hat nach einem reboot den letzten Wert den ich über das Modul gesetzt habe... das ist ja dann wohl nicht so gesund für das eeprom

Da ich weder einen Hardware v3 habe, noch eine neuere Api kenne, kann ich dazu leider wenig sagen. Ich vermute aber, dass go-E das amx noch so verwendet oder das amp da nicht mehr in den Flash geschrieben wird.
Schicke Deine Frage mal an den Support?
Auch wenn da mal eine neue Api kommt, werde ich weiteres mangels HW v3 schwer testen können. Ich hoffe ihr macht das oder jmd. macht einen extra Zweig in Github? Hat der v3 andere App-Einstellungen? Kannst Du da nun manuell  per App auf einphasig schalten oder gibt man eine niedrigere Ladeleistung vor?

Der Hauptgrund für das Modul war für mich die Realisierung von PV-Ladung und Kombinierung mit der SoC-Auswertung von den BEV und Lastmanagement. Ich muss gestehen, dass ich da gerade openWB-Standalone teste, was das - out of the Box - scheinbar leicht hinkriegt und mein Modul läuft eher für Überwachung oder nicht PV-Laden in Fhem mit.

Die Frage habe ich gerade mal raus geschickt.
Ja bei der v3 kann man zwischen 1- und 3phasig wechseln bzw. umschalten.
Ich möchte die Steuerung eigentlich in FHEM lassen - ich regle damit auch die Ladeleistung für PV Überschuss; aber FHEM steuert noch viel mehr bei mir. Deswegen ist das da ganz gut aufgehoben.

Moin zusammen,

nächste Woche kommt mein Go-E 11kW, für welchen ich auf Basis der tollen Arbeit hier entschieden habe. Gerne hätte ich auch die Wallbox von CFOS genommen, da wäre das Thema Überschussladen schon drin, aber die Lieferzeit war dagegen. Und es juckt ja auch in den Fingern das selber zu machen und komplett nach den eigenen Vorstellungen zu gestalten. Geladen wird ein E-Golf, der AC nur zweiphasig macht, was aber noch auf einphasig reduziert wird, damit das der kleinen PV mit 4,2kWp entgegen kommt. Die Vorbereitungen sind getroffen und daher habe ich jetzt schon einen kleinen Hinweis:

Zitat von: LR66 am 09 Mai 2020, 12:34:27
Ja, der go-E braucht starkes WLAN, hat nur schwachen Sender/Empfänger. Ich hab ein Repeater gebraucht und musste wieder lokal in den Hotspot und Neustart machen...

In unserer Garage fehlte auch das heimische WLAN und ich habe zu Devolo Power-Line (Magic WiFi Mini (https://www.devolo.de/magic-1-wifi-mini/variant/starter)) gegriffen. Vor Ewigkeiten hatte ich da schon durchwachsene Erfahrungen gemacht, aber jetzt bin ich begeistert. Ich habe auf beiden Seiten des Kabels (ca. 25m) eine Steckdose parallel zum Anschluss für die Wallbox und bekomme etwa 70 Mb/s durch. Hauptsache der Charger bekommt davon keine Bauchschmerzen ;-)

Niels

Kurze Info: Auch mit dem Charger in HW-Version 3 funktioniert das Modul einwandfrei, wenn man die HTTP API v1 auf dem Charger aktiviert. Danke LR66 für die tolle Arbeit.

Niels

Hallo zusammen,

ich habe den Thread erst jetzt gesehen. Was mir nicht klar ist: der go-e Charger kann scheinbar schon per APP von 3-phasig auf 1-phasig umgeschaltet werden. In der Dokumentation der API ist dieser Befehl aber noch nicht gelistet. Meine Frage: Ist das nur eine fehlende Dokumentation oder geht die Umschaltung derzeit per API nicht?

Danke + Gruß

Peter

Moin Peter,

die Phasenumschaltung kann der Go-e erst mit der HW-Version 3. Daher ist das nicht in der (alten) Web-API V1 drin, auf welche das Modul zugreift. Über die Web-API V2 ist das drin, aber die scheint mir recht unfertig. Ich kann die Funktion lesen, aber nicht setzen. Wenn Du mal etwas HTTP Web-API V2 schnuppern willst: https://forum.fhem.de/index.php/topic,122285.msg1168512.html

Niels

Hallo zusammen,

es gibt wohl die FW Version 041.
Welche Erfahrungen gibt es damit?
Auto wird noch gebaut und kann nicht testen ;-)

VG

Zitat von: vitolinker am 31 August 2021, 16:47:45
es gibt wohl die FW Version 041.

Für die HW-Version 3 ist die 0.51.1 aktuell.

Niels

Ich habe jetzt meine Überschussladung mit einem etwas reichlich umfangreich geratenen DOIF realisiert. Ich starte bei genug Überschuss mit 6A und packe immer ein Ampere drauf, wenn mehr Überschuss da ist und schalte ein Ampere runter wenn es zu eng wird. Bei 6A und fehlendem Überschuss schalte ich ab.
Leider ist das heute zum 2. Mal hängen geblieben. Scheinbar immer, wenn die Leistung von 10A auf 9A reduziert werden soll. Das DOIF wird ausgeführt und der Befehl funktioniert auch über die GUI, nur über das DOIF passiert nichts. Wie kann ich das debuggen? Erst einmal muss ich ja herausbekommen ob das Modul oder das DOIF hier nicht das machen was sie sollen...

Niels

Zitat von: Muschelpuster am 31 August 2021, 19:23:33
Wie kann ich das debuggen?

Hat der Charger nicht die Lichtorgel, mit der man den aktuellen Status des Ladestroms feststellen kann? Ggf. so konfigurieren, dass der Wechsel von 10 auf 9 A erkannt werden kann. Zumindest das sollte dann zeigen, wo ggf. das Problem liegt ...

Gruß Peter

Zitat von: PeMue am 31 August 2021, 19:41:05
Hat der Charger nicht die Lichtorgel...

Ja klar, aber da muss ich ja in die Garage gehen ;-)
Ich sehe das ja auch auf der App und in meinem Stromverbrauchsmonitor, welcher parallel auch nochmal die Werte vom Charger über die HTTP-API zieht. Und im Event Monitor sehe ich nichts. Von daher scheint es schon im FHEM zu klemmen. Ich werde jetzt erst einmal das DOIF etwas zerlegen und ein weiteres Rettungsanker-DOIF bauen, welches bei zu hohem Verbrauch ohne die vorherigen Abregelungen die Ladung abschaltet. Da kann ich dann ja auch sehen, ob das irgendwann zuschlägt.

Niels

Hallo,

in https://forum.fhem.de/index.php?topic=122285.0 ist beschrieben, wie man zwischen 1 und 3 phasigem Laden umschalten kann. Ein kurzer Test mit v3 HW war positiv :-)

Gruß, Jochen

Hallo zusammen,
hat schon jemand auf Firmware 051.3 (Hardware V3) aktualisiert?
Habe ich heute gemacht und seit dem gibt es nach kurzer Zeit einen Timeout in fhem zum go-eCharger. Die App hat weiterhin Verbindung und ich kann die Box darüber steuern.
Ich nutze Version 0.2.2 von 46_GoECharger.pm.

Edit: ich habe das Modul etwas beobachtet: nach 5-6 Intervallen (INTERVAL=60) kommt es zum Timeout. In diesem Fall war das Auto nur angeschlossen, es erfolgte kein Ladevorgang.

Gruß Ingo

Hallo Ingo,

Ähnliches habe ich mit der V051.1 auch schon gesehen, aber nicht weiter verfolgt. Ich habe mal das Update durchgeführt und werde es mal etwas beobachten.

Niels

Hallo Niels, Danke.
Habe gerade in der App gesehen, das wieder eine neue Version zum Update bereit steht: V 051.4
Habe das Update installiert, stand etwas mit hängenden Requests bei API V1.
Ich beobachte weiter.
Gruß Ingo

Oh Danke,
dann werde ich nochmal schnell Updaten. Mein Modul ist komplett offline. Ruft man die http://e-go/status im Webbrowser auf dauert das auch sehr lange. Im IP-Trace zeigt mein FHEM, dass 5 Sekunden nach dem http-get ein Reset auf die Verbindung geschickt wird - das ist wohl ein Timeout. Der Charger braucht aktuell 6-7 Sekunden um zu antworten.

Update: Jetzt antwortet der Charger wieder schnell und das Modul spricht wieder mit ihm.


Niels

Habe V 051.4 seit 25min aktiv und bisher kein Timeout des Moduls gehabt. Scheint damit wieder zu funktionieren....

Hallo,

bei mir läuft das GoECharger Modul. Momentan werden alle Events in ein separates FileLog geschrieben.

Für jeden PKW habe ich eine eigene RFID eingerichtet, an die komme ich leider mit fhem nicht direkt dran.

Ich würde gerne aus dem FileLog eine Art Ladehistorie erstellen. D.h., Ein Balken mit kWh am entsprechenden Datum/Uhrzeit mit den  kWh, die geladen wurden.

Hat hier jemand schon was in dieser Richtung gemacht?

Danke

Hallo,

ich würde mir noch wünschen, dass das Modul das attribut "disable" korrekt beachtet. Mein zweiter go-e ist derzeit offline und ich bekomme ständig Timeouts im Log obwohl disable auf 1 gesetzt ist.

Grüße, gadget.

Zitat von: vitolinker am 31 August 2021, 16:47:45
Hallo zusammen,

es gibt wohl die FW Version 041.
Welche Erfahrungen gibt es damit?
Auto wird noch gebaut und kann nicht testen ;-)

VG

Hallo,

ich greife die Frage von vitolinker nochmal auf:

Wer hat seine HW v2 schon auf die neue Firmware-Version 041 upgedated ?
Welche Erfahrungen habt ihr damit gemacht ?
Funktioniert der Neustart per App bzw. API jetzt wieder ?

Vielen Dank

Also zumindest der Neustart nach FW Update hat drei mal einwandfrei geklappt.

Zitat von: ThomasFh am 11 September 2021, 14:26:37Für jeden PKW habe ich eine eigene RFID eingerichtet, an die komme ich leider mit fhem nicht direkt dran.

Über die API V2 kommst Du ran. Über das JSON-Mod bekommst Du die Werte unter cards.X.energy ausgelesen.

Niels

https://forum.fhem.de/index.php/topic,122285.msg1169378.html

Hallo zusammen,

karpate und ich hatten gestern eine Diskussion, wie man das normale Laden von der PV Überschuss Ladung unterscheiden kann.
Meine Idee war, einen Homematic Taster daneben zu bauen, nach Tastendruck: FHEM weiß, dass jetzt PV Überschuss Laden erfolgen soll: Wallbox wird verriegelt, FHEM wartet, bis das Auto angesteckt ist, ggf. Umschaltung auf 1-phasig und startet dann die PV Überschussladung)
karpate's Vorschlag war, einen RFID Chip zu "missbrauchen". Jetzt sind natürlich ein paar zusätzliche Fragen aufgetaucht:

- Holt sich FHEM die Daten (pull) oder pusht die Wallbox die Daten, wenn zweiteres, in welchem Intervall? Gibt es Unterschiede zwischen der API (v1 oder v2) und MQTT?

- Gibt es die Möglichkeit, die LED Lichtorgel als Statusanzeige für PV Überschussladung zu programmieren (z.B: LED ganz links an: PV Überschussladung ist gestartet, LED in der Mitte an: PV Überschuss Ladung läuft, ggf. LED ganz rechts an: PV Überschuss Ladung ist fertig (hier würde ich vermutlich die Wallbox wieder in den Ursprungszustand versetzen).

Vielleicht hat ja jemand ein paar Tipps.

Danke + Gruß

Peter

Ich habe die Trennung von normalem Laden und Überschussladen 'relativ' einfach mit DOIFs gelöst. Die Box steht per Default auf 'Authentifizierung per RFID erforderlich'. Die Regel für den Start des Überschussladens geht nur los, wenn das der Fall ist, das Auto angeschlossen ist und genug Überschuss da ist:
([Zaehler:Ladesteuerung_Auto_15]<-1400 and
([myGoE:car_state]==3 or [myGoE:car_state]==4) and
[myGoE:access_control_state] eq "by_RFID_or_App")
Dann wird die Box umkonfiguriert:
(set myGoE amp_current 6) (set myGoE allow_charging 1) (set myGoE access_control_state access_open)

Die Reglung des Stroms erfolgt nur, wenn das Auto lädt und der Zugriff auf offen ist:
defmod di_ueberschussladen_reglung DOIF ## cmd_1: Erhöhe Ladung, wenn genug Überschuss vorhanden ist:\
([Zaehler:Ladesteuerung_Auto_05]<-250 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and \
[myGoE:amp_current]<16 and\
[myGoE:allow_charging]==1)\
(set myGoE amp_current {([myGoE:amp_current]+1)})\
DOELSEIF\
## cmd_2: Breche Timer für Erhöhung der Ladung ab, wenn Bedingung nicht stabil ist:\
([Zaehler:Ladesteuerung_Auto_05]>-250 and \
[myGoE:access_control_state] eq "access_open" and\
[di_ueberschussladen_reglung:wait_timer]=~"cmd_1") \
()\
DOELSEIF\
## cmd_3: Reduziere Ladung, wenn nicht genug Überschuss vorhanden ist:\
([Zaehler:Ladesteuerung_Auto_05]>50 and \
[myGoE:access_control_state] eq "access_open" and\
[myGoE:car_state]==2 and\
[myGoE:amp_current]>6 and\
[myGoE:allow_charging]==1)\
(set myGoE amp_current {([myGoE:amp_current]-1)})\
DOELSEIF\
## cmd_4: Breche Timer für Reduktion der Ladung ab, wenn Bedingung nicht stabil ist:\
([Zaehler:Ladesteuerung_Auto_05]<50 and \
[di_ueberschussladen_reglung:wait_timer]=~"cmd_3") \
()\
attr di_ueberschussladen_reglung do always
attr di_ueberschussladen_reglung wait 120:0:120:0


Beim Beenden der Ladung über das 1. DOIF wird die Box wieder auf Authentifizierung umgestellt.
([Zaehler:Ladesteuerung_Auto_05]>100 and
[myGoE:access_control_state] eq "access_open" and
[myGoE:car_state]==2 and
[myGoE:amp_current]<7 and
[myGoE:allow_charging]==1)
(set myGoE allow_charging 0)
(set myGoE amp_current 16)
(set myGoE access_control_state by_RFID_or_App)

Die Werte Zaehler:Ladesteuerung_Auto_05/15 bilden den Durchschnitt der ca. letzten 5 bzw. 15 Minuten Zählerwerte zuzüglich eines zusätzlichen Wertes für die Reglung der Empfindlichkeit. Meinen Zähler lese ich mit Node Red, wo ich auch die Durchschnittswerte bilde. Die Daten werden per MQTT an FHEM übermittelt. Im DOIF für Start & Stop habe ich ein Userreading für die Empfindlichkeit gebaut und über einen Slider abgebildet, was die Schaltgrenze definiert. Hier kann ich einstellen, ob ich im Sommer deutlich unter 0 arbeite (-460W oder -230W) oder versuche jeden Überschuss zu schürfen, auch wenn dann die Ladung mal Energie vom Versorger zieht (0W, 230W oder 460W).

Um nun manuell zu Laden habe ich 2 Optionen mit relativ hohem WAF. Entweder startet man die Ladung über den RFID-Chip direkt beim Parken oder mit Klick auf die Ladeschaltfläche in der Go-e-App. Das geht sicher auch noch aus FHEM, ist bei mir aber derzeit nicht umgesetzt. Auch fehlt mir noch die Phasenumschaltung, weil das Modul das noch nicht unterstützt und ich das mit dem HTTP-Mod mit dem ich parallel mit der API V2 spiele noch nicht hin bekomme. Auch möchte ich noch beim Start der Ladung den Startzeitpunkt in ein Userreading schreiben (was ich schaffe) um dann den Stopp-Vorgang erst zuzulassen, wenn X Minuten geladen wurde. Und hier stelle ich mich auch noch zu doof an zu prüfen, ob der aktuelle Linux-Timestamp minus der gewünschten Zeit X größer ist als der beim Start gespeicherte.
Aber bisher läuft es sehr zuverlässig. Anbei mal ein Bild von einem Tag mit Überschussladung. Hier sieht man schön, wie ich mit Waits in dem DOIFs das ganze träger gemacht habe, das würde eben noch mit der Steuerung über die Timestamps etwas zackiger aussehen.

Niels

Hallo,

ich war mal so frei FSP (force single phase, 1/3 Phasen Umschaltung) in das Modul von LR66 zu integrieren. Damit ist es auch nun für jeden möglich die Umschaltung mit einem go-e v3 vorzunehmen.

Meine Version im Anhang.
Vielleicht übernimmt es ja LR66 auch ;-)

Viel Spaß
Gruß
Björnar

Hallo,

gibt es im Modul die Möglichkeit, die Historie der Ladungen der einzelnen RFID-User, welche von der Abb bereits als CSV geliefert wird, mit diesem Modul herunterzuladen? Ich bräuchte das für die Visualisierung, da ich dies mit dem ElectricityCounter nicht hinbekomme.

Danke Euch

#0.2.5

Ich habe noch "W_preset_calculated" hinzugefügt, da ich überall mit Watt arbeite und nicht mit KW.
Zudem habe ich die Berechnung für die beiden werte korrigiert, da bei 1/3 Phasen Umschaltung sonst die falschen Werte angezeigt wurden.

Gruß
Björnar

Hallo Bjoernar,

ich habe deine Version bei mir drauf, allerdings kann ich nicht von 1 auf 3 Phasen via fhem umschalten. Die Umschaltung des GoE aus der App heraus, erkennt das Modell aber.

Viele Grüße
Thorsten

Hi,

welche Version hat denn dein Go-e?
API v1 und v2 aktiv?

Hi,
hab auf dem GoE die 051.1 und v1 sowie v2 sind aktiv.

Thorsten

Komisch ...
Hast du mal ein neues device mit meinem Modul angelegt?
Steht irgendwas im Log?

allerdings,
neues device angelegt - gleicher Fehler.
Im Log wird es mE richtig übergeben

2021.10.01 13:47:54 4: GoECharger (myGoE) - Send with URI: http://192.168.178.90/mqtt?payload=fsp=0 (host: 192.168.178.90, path: mqtt?payload=fsp=0 )

verrückte Sache

Ist das denn die aktuelle fw Version? Komme gerade nicht auf meinen um nachzusehen.
Es gab da ja einen Fehler 0/1 für fsp waren vertauscht.

Wenn du auf 1P umschaltest wechselt er auf 3p

Das ist es!
Ich muss die Werte genau andersrum setzen. Crazy. Und das ist mit einer neuen Version weg?
Ich mach mal das Update auf dem GoE.

und sage dann bescheid ;-)

Ja so ist es. Wurde bei Go-e falsch umgesetzt.

Das war es. Jetzt klappt es.
Demnach muss die Version mindestens 051.4 sein, sonst klappt die Logik nicht wie sie soll.

Besten Dank.

Gruß
Thorsten

PS: Jetzt geh ich erstmal Sonne tanken :-)

Hier noch mein doif das für mich die Steuern übernimmt.

Der Wert vom Überschuss ist ein Durchschnittswer
t der letzten 5min. ohne den Strom vom go-e

Bisher steuere ich damit nur ein Dummy da mein ev noch nicht da ist.

Aber vielleicht hilft es dir.


([AC_Einspeisung:Einspeisung__W_5min] >= 4140) {
   use Math::Round qw/round/;
   my $Temp = (ReadingsVal("AC_Einspeisung","Einspeisung__W_5min",0)/690);
   $Temp = POSIX::floor($Temp);
   $Temp = Math::Round::round($Temp);
   $Temp = 6 if($Temp < 6);
   $Temp = 16 if($Temp > 16);
   fhem("setreading goe1_Power A $Temp");
   fhem("setreading goe1_Power P 3");
}

DOELSEIF ([AC_Einspeisung:Einspeisung__W_5min] >= 1200) {
   use Math::Round qw/round/;
   my $Temp = (ReadingsVal("AC_Einspeisung","Einspeisung__W_5min",0)/230);
   $Temp = POSIX::floor($Temp);
   $Temp = Math::Round::round($Temp);
   $Temp = 6 if($Temp < 6);
   $Temp = 16 if($Temp > 16);
   fhem("setreading goe1_Power A $Temp");
   fhem("setreading goe1_Power P 1");
}

DOELSE (
   setreading goe1_Power A 0,
   setreading goe1_Power P 0
)


Schau ich mir an.


ich habe auch eine Ladestrategie entwickelt, dazu nutze ich die Photovoltaik-, Akku- und Autowerte und gleiche das minütlich ab.
Schick ich dir später auch mal


Thorsten

Da ist halt der Teil für die Phasen enthalten.

Ich hab in die myutils eine Funktion eingebaut:
PV: 4,45kwPeak, 9,6kw Akku, Twingo ZE 22kW, GoECharger
Ist aber noch nicht ganz rund :-), klappt aber mit 1Phase super

##Beladung des ZE Renault mit myGoECharger
sub beladen($$$){
my ($ZE, $GoE, $myAkku) = @_;
my $curr_amp_calc = 10;


#state: "finished" "ready_no_car" ,,charging"  "waiting_for_car"
###################

      ##1.Beladung Fz im Normalbeladungsfall bei 90% ?
      ##oder
      ##2.Beladung soll min 60% im Auto haben
      ##  UND SoC_Akku soll nicht unter 50% sein
      ##################################################

if (    (ReadingsVal("$GoE", "state", 0 ) eq "charging") &&
      ( (ReadingsVal("$ZE", "batteryLevel", 0) >= 90) ||      ##1.
        ((ReadingsVal("$ZE", "batteryLevel", 0 ) >= 60) &&    ##2.
         (ReadingsVal("$myAkku", "SData_SoC", 0) <= 50)))
   )
      ##dann stoppen
       {
        fhem("set $GoE off")
       }

      ##b1. bei über 80% SoC kompletten Überschuss ins Auto
      ##################################################
elsif ( (ReadingsVal("$GoE", "state", 0 ) eq "charging") &&
        (ReadingsVal("$myAkku", "SData_SoC", 0 ) >= 80)
      )
        {
         $curr_amp_calc = 2 + (ReadingsVal("$GoE", "amp_current", 0 )) + ((ReadingsVal("$myAkku", "U_PPV", 0 ) - ReadingsVal("$myAkku", "U_HOUSE", 0 ))/230);
         if ($curr_amp_calc >= 16) {
            fhem("set $GoE amp_current 16")}
         elsif ($curr_amp_calc < 8){
            fhem("set $GoE amp_current 8")}
         else {
            fhem("set $GoE amp_current $curr_amp_calc")}
        }


      ##b2. Zwischen 50% und 80% SoC nur teilweise ins Auto
      ##################################################
elsif ( (ReadingsVal("$GoE", "state", 0 ) eq "charging") &&
        (ReadingsVal("$myAkku", "SData_SoC", 0 ) < 80) &&
        (ReadingsVal("$myAkku", "SData_SoC", 0 ) >= 50))
       {
        ##345 entspricht 2/3 der Leistung (oder 1,5 mal 230 ;-)
        $curr_amp_calc = 1 + (ReadingsVal("$GoE", "amp_current", 0 )) +
                         ((ReadingsVal("$myAkku", "U_PPV", 0 ) - ReadingsVal("$myAkku", "U_HOUSE", 0 ))/345);
         if ($curr_amp_calc < 8)
             {fhem("set $GoE amp_current 8")}
         elsif ($curr_amp_calc >= 16)
             {fhem("set $GoE amp_current 16")}         
         else
             {fhem("set $GoE amp_current $curr_amp_calc")}
       
       }


      ##wenn eh keine Sonne und kein Akku, dann Max-Ladestrom einstellen
      ##################################################
elsif (ReadingsVal("$GoE", "state", 0 ) eq "charging")
        {
         fhem("set $GoE amp_current 16")
##TODO: hier noch 3-phasig + Vorauswahl manuell am GoE implementieren
##      ggf eigenen elsif Zweig
        }



      ##Auto dran,Autoakku unter 60%, aber startet noch nicht
      ##################################################
if (((ReadingsVal("$GoE", "state", 0 ) eq "waiting_for_car") || (ReadingsVal("$GoE", "state", 0 ) eq "finished")) &&
        (ReadingsVal("$ZE", "batteryLevel", 0 ) < 60)) ##todo elsif machen
        {
         fhem("set $GoE on")
        }

      ##Standard-Ladewert einstellen, wenn kein Auto dran
      ##################################################
if ((ReadingsVal("$GoE", "state", 0 ) eq "ready_no_car") && ((ReadingsVal("$GoE", "amp_current", 0 ) ne 10) ||           (ReadingsVal("vorAuswahl", "state", 0 ) ne 1_10)))
        {
         fhem("set $GoE amp_current 10");
         fhem("set vorAuswahl 1_10") ##kann weg, wenn single_force_phase implementiert ist
        }



###dummy log###
fhem("set curr_amp $curr_amp_calc");


}##sub

Hallo,

ich habe seit ein paar Tagen einen go-eCharger V3 und auf meinem Rasp4 das Modul 46_GoECharger.pm V 0.2.5 installiert.
Das Laden inklusive Umschalten auf ein-/dreiphasig funktioniert problemlos, ist ein tolles Tool.
Dennoch habe folgende Fragen.

Gestern konnte ich das Laden beim Golf vom Bekannten testen. Funktioniert im Prinzip auch, aber nur mit 2 Phasen, max ca. 7 kW, konnte leider nicht viel ausprobieren. Im Modul wird unter phases_available 111000 angezeigt. In der go-e App schaut auch alles ok aus.
Gibt es dafür eine Erkärung?
Wo finde ich die icons zum devStateIcon?

Gruß
Rolf

Dann kann der Golf wohl nur mit 7,2kw laden.

Hallo Bjoernar,

nach Auskunft vom Bekannten kann er 11 kW laden.

Gruß Rolf

Nein, ein Golf kann an AC nur 2-phasig laden. Bei seiner 35,8kWh-Batterie ist das ja auch nicht so ein Drama  ;)

Niels

https://ev-database.de/pkw/1087/Volkswagen-e-Golf

Danke,
das hätte ich auch selbst recherchieren können.

Bleibt noch meine Frage wo ich die Icons zum devStateIcons für das Modul 46_goecharger.pm. Mit den Hinwdisen meiner Recherche konnte ich nichts anfangen.

Gruß Rolf

Ja, die fehlen mir auch noch  ;)

Niels

Hier die Datei für die devstateicons.
Die lässt sich auf der GitHub Seite nicht einzeln downloaden. Einfach ins Verzeichnis kopieren (Ist auf der GitHub Seite erklärt wohin) und schon gehts.
Ich nutze zudem auch das electric_car_icon aus dem Standard für die Ereignisse, wo das Auto am Kabel mit der GoE verbunden ist.

Gruß
Thorsten

111000 bedeutet 3 Phasen angeklemmt (111) und 3 Phasen zum Laden bereit (000)
Wenn du einphasig lädst, wird daraus 111011, bei dreiphasig 111111 (etwas merkwürdig, aber so isses :-)

Gruß
Thorsten

Hallo Torsten,

vielen Dank für das icon.
Ich habe es zwischenzeitlich auch gefunden in https://github.com/LuRhe/fhem-46_GoECharger.

Gruß Rolf

Hallo, ich suche eine Möglichkeit, meine PV Überschuss DOIFs auszuhebeln durch eine Bedienung an der Box selbst. Die Box soll dann volle 11kW liefern und die DOIF werden disabled. Meine Idee ist, das über einen RFID Token zu machen, den ich an die Box halte. Gibt es ein Event/Reading, was ich im FHEM auswerten kann, wenn die Box eine RFID ID einliest? Nach abstecken sollen die DOIF dann wieder aktiviert werden.

Oder hat noch jemand eine ganz andere praktikable Lösung, einfach an der Box, ohne Zugriff auf FHEM, die volle Leistung abzurufen, ohne das FHEM dann dazwischenfunkt?

EDIT: In der MODBUS Dokumentation gibt es das register 203 "UNLOCKED_BY" ( https://github.com/goecharger/go-eCharger-API-v1/blob/master/go-eCharger%20Modbus%20TCP%20API%20v1%20DE.md ). Das scheint aber im Modul nicht herausgeführt zu sein. Dort steht die Nummer der Karte drin, die die Box aktiviert hat. Ist es ein großes Problem, dieses Reading mit einzubauen sofern es über die API auch verfügbar ist?
Ich gehe mal davon aus, dass die Wallbox sich auch über FHEM ganz normal steuern lässt, wenn die Access Control auf RFID gestellt wird. Übers Handy kann man den Ladevorgang ja auch ohne RFID aktivieren.

EDIT2: Ich habe rausgefunden, das man den Wert bekommt, wenn man die api keys manuell setzt und "uby" zufügt. Dann fang ich mal an zu basteln :)

Hallo Waldmensch,

mache es nicht so kompliziert. Du kannst doch einfach in Deinem DOIF den Status auswerten:
DOIF ([myGoE:car_state]==3 or [myGoE:car_state]==4) and [myGoE:access_control_state] eq "by_RFID_or_App" Das ist in meiner Solar-Startregel drin.
Im CMD programmiere ich den GoE dann um: (set myGoE access_control_state access_open)
Stopp und Leistungsregelung geht nur, wenn der GoE auf Open steht. Sobald ich mit RFID oder der App die Ladung manuell starte bleibt der access_control_state auf by_RFID_or_App und die Regeln greifen nicht.
Bei Interesse kann ich meine DOIFs für das Ganze bereitstellen. Das ist eher rustikale Kost, funktioniert inzwischen aber sehr zuverlässig. Das Ganze hat aus purem Eigennutz auch einige Kommentare drin  ;)

Niels

Hallo, hat sich schon jemand getraut Update 051.8 zu installieren?

Ja, läuft.

Hallo Zusammen,

ich habe 2 Go-E in Gebrauch die ich auch beide Benutzen über fhem auslesen kann. Das einzige was ich immer noch suche, ist einen Steuerung für PV Laden. HAbe ich das richtig verstanden, dass ich "amp_current" nur dann verändern kann wenn "access_control_state" im Staus  "access_open"  ist ?

Zitat von: noanda am 24 Oktober 2021, 12:32:42
Hallo Zusammen,

ich habe 2 Go-E in Gebrauch die ich auch beide Benutzen über fhem auslesen kann. Das einzige was ich immer noch suche, ist einen Steuerung für PV Laden. HAbe ich das richtig verstanden, dass ich "amp_current" nur dann verändern kann wenn "access_control_state" im Staus  "access_open"  ist ?

Nein, amp_current lässt sich auch in RFID-Modus ändern.

Ich habe meine Solar-Ladelösung mal veröffentlicht: https://forum.fhem.de/index.php/topic,123644.0.html

Niels

@Muschelpuster

Ich habe es jetzt so gemacht, dass ich im einem separaten DOIF beim aktivieren per RFID Karte 10 mein Regel DOIF disable und die amp auf 16 setze. Damit hat die Regelung keinen Einfluss mehr und es wird geladen, bis das Auto selbst beendet.
Wenn das Auto voll ist muss ich auch nicht mehr auf den Regelkreis umschalten, die Box bleibt einfach im Bereit Status für die eventuelle Vorklimatisierung am Morgen.
In einem weitern DOIF überwache ich den car status. Wenn der auf ,,angesteckt" geht, wird der Regelkreis wieder initialisiert. Ich versuche den Regelkreis weitestgehend disabled zu lassen, weil er vom SMA Energymeter jede Sekunde getriggert wird. Deshalb hat das DOIF zur carstate Überwachung auch noch ein Zeitfenster. Nachts braucht der PV Regelkreis nicht laufen.

Ich wäre aber sehr an Deiner Lösung interessiert. Vielleicht kann ich noch was optimieren. Ich habe leider noch die alte Hardware ohne Phasenabschaltung. Aktuell behelfe ich mir mit einem 1phasigen Kabel, da der Überschuss nicht mehr für 3phasiges Laden reicht. Wenn ich Netzstrom laden will, muss ich jetzt immer das Kabel tauschen. Ich habe jetzt nochmal die 440 beantragt und werde, wenn das Jahr im Februar rum ist, den Go-E gegen die V3 tauschen.

Zitat von: Waldmensch am 27 Oktober 2021, 01:30:28
Ich wäre aber sehr an Deiner Lösung interessiert.

Siehe Link #263 (https://forum.fhem.de/index.php/topic,110282.msg1181970.html#msg1181970).

Niels

Habt ihr irgend eine Möglichkeit gefunden, zu erkennen, ob ein einphasiges oder ein 3 phasiges Kabel verwendet wird, solange kein Ladevorgang läuft? Wenn kein Ladevorgang läuft, steht bei phases_available 111000. Wenn ein Ladevorgang läuft 111100 oder 111111, dann kann man es erkennen. Um aber herauszufinden ob ich den Ladevorgang bei 1x230x6 oder 3x230x6 Überschuss starte, nützt mir das nichts.

Zitat von: Waldmensch am 29 Oktober 2021, 16:43:35
Habt ihr irgend eine Möglichkeit gefunden, zu erkennen, ob ein einphasiges oder ein 3 phasiges Kabel verwendet wird, solange kein Ladevorgang läuft? Wenn kein Ladevorgang läuft, steht bei phases_available 111000. Wenn ein Ladevorgang läuft 111100 oder 111111, dann kann man es erkennen. Um aber herauszufinden ob ich den Ladevorgang bei 1x230x6 oder 3x230x6 Überschuss starte, nützt mir das nichts.

Der Wert "cbl" liefert dir den Wert in Ampere den du suchst.

Edit: ich glaube du meinst was anderes und zwar die Zuleitung und nicht das Ladekabel richtig? Dann kannst du vergessen was ich geschrieben habe

Im Grunde suche ich irgend eine Information, bei wieviel Überschuss ich die Box freischalten kann. Ist ein einphasiges Kabel dran, wäre die Einschaltschwelle 6A x 230V = 1380W. Ist ein 3phasiges Kabel dran, ist die Einschaltschwelle 6A x 230V x3 = 4140W. Bei ,,pha" sehe ich im Ruhezustand der Box nur 111000, was mir sagt, dass die Box mit 3 Phasen am Netz hängt. Was ich nicht sehe, ist, mit wieviel Phasen das Auto an der Box hängt. Das sehe ich erst, wenn die Ladung läuft. Dann wechselt pha auf 111111, wenn ein 3phasiges Kabel dran ist. Das ist dann aber zu spät. Es geht mir darum den Winter mit einphasigem Kabel zu überbrücken ( was ja sehr viele Leute immer gern vorschlagen). Gleichzeitig wird es aber auch Situationen geben, wo ich 3phasig laden muss. Bei Netzstrom ist das ja eh Wurst. Es wird also ein hin-/her gewechsel, bei dem man am Ende nicht mehr weiß, welches Kabel steckt. Wen FHEM vom 1 phasigen Kabel ausgeht und die Ladung bei 1380W Überschuss auf 6A startet und der Wagen dann aber 4140W zieht, schaltet der Regelkreis wieder ab. Dann wieder an, weil wieder 1380W Anliegen und wieder aus. Das geht dann so weiter, bis es jemand merkt. Ich muss also vorher wissen, welches Kabel angeschlossen ist.

Das wird sich mit der V3 erledigen, die kann ich aber erst im Februar montieren, da dann die BaFa Sperrfrist für die aktuelle V2 abläuft. Ich muss also mit der Kabel Rochade irgendwie über den Winter kommen möglichst ohne meiner Frau stundenlange Einweisungen geben zu müssen, welches Kabel wann zu nutzen ist.

Nutzt du die original Go-e Charger Kabel?

Eigentlich müsstest bei das mit dem Reading nrg1 nrg2 nrg3 lösen können. Das ist die Spannung je Phase. Wenn nur eine Phase dran ist müsste auch nur bei einem nrg Spannung zu messen sein.

In den Readings werden doch die Spannungen angezeigt, die die App auch angezeigt?! Da die Go-E Homefix 3 phasig fest angeschlossen ist, werden 3 x 230V angezeigt. (Screenshot) Das Auto ist aktuell mit 1phasigem Kabel verbunden. Die Typ2 Kabel sind keine Go-E Kabel sondern Standardware.

Edit: wenn ich ,,nrg" zufüge er halte ich ein reading ,,energy_sensors" mit dem Inhalt    ARRAY(0x585d230)
2021-10-29 21:56:42

Leider hatten deine vorherige Beiträge viel Raum für Spekulation gelassen. Dort stand nur einphasige Kabel, das hier aber das Typ2 Ladekabel gemeint ist konnte ich leider nicht heraus lesen. Denn ich kenne es eigentlich nur, das man entweder bei einem Go-e-Charger verschiedene Adapter hat, die man dann wechselt (sofern es ein HOME+ handelt) Denn das erkennt der Go-E anhand eines Reedkontaktes im Stecker und begrenzt die Leistung selbständig.
Die andere Variante ist dann eigentlich bei der Zuleitung die Phasen wegzuschalten und das würdest du dann über die Spannungen erkennen. Ich nutze den Go-E über MQTT und dort werden die Werte richtig umgerechnet das fehlt dann wohl noch vielleicht in dem Modul. Aber hilft dir ja sowieso nicht da du ja  nur das Typ2 Ladekabel tauscht und solange dort kein Strom fließt ist es m.E. nicht möglich zu erkennen wieviel Phasen genutzt werden. Mir ist nur bekannt, dass  die Wallbox beim Ladekabel erkennen kann, welcher Kabel Querschnitt verwendet wird und das würdest dann unter "cbl" auslesen können. Aber sofern dein 1 phasiges Kabel den gleichen Querschnitt hat wie dein dreiphasiges Kabel, wirst du vielleicht kein Unterschied erkennen. Aber das kann man schnell testen.

Ich bin davon ausgegangen, dass sich hier alles im groben um die fest angeschlossene Homefix dreht, da es kaum Sinn macht, eine mobile Wallbox per FHEM zu steuern. Da die V2 keine Phasenabschaltung kann, kommt immer wieder der Vorschlag ,,dann nimm doch ein einphasiges (Typ2) Kabel". Wie ich nun feststelle, war das aber eine voreilige bzw. Fehlinvestition, wenn ich mir damit die FHEM Steuerung zerlege. Eventuell muss ich mir eine RFID Karte neben die Box hängen, und den Kabeltyp (Startleistung) über die Karten ID festlegen (Beispiel: wenn mit Karte 1 aktiviert dann gehe von 1phasig aus). Das wäre den Nutzern noch irgendwie vermittelbar.

Hast du denn Mal geschaut ob du vielleicht Glück hast und sich cbl bei den Kabeln unterscheidet?
Es ist egal ob HOMEfix oder HOME+ von der Regelung sind die gleich. Ich habe beide im Einsatz. Ich nutze beide nicht als mobile Lösung da ich  beim HOME+ auch den Stecker entfernt und direkt angeschlossen habe. Habe gerade Mal geschaut, das kabel von meinen PHEV kann nur 20A und das von EV 32 A somit könnte ich das schon Mal unterscheiden sofern ich ein EV hätte was dreiphasig laden könnte ;-)

Da ich leider auch noch die V2 habe werde ich mir wohl was bauen das man die Phasen der Zuleitung umschalten kann aber natürlich nur wenn das Auto nicht geladen wird. Wen man den Preise eines Typ 2 Kabel und die Wechselei der Kabel dann kann man sich auch eine Steuerung bauen. Alleine wenn ich über Tag einphasig geladen habe und auf einmal morgen einen vollen Akku brauche hätte ich keine Lust raus zu gehen und das Kabel umzustecken.  Mit händischen Eingriff lässt sich auch nichts automatisieren was ja mein Ziel ist. Wenn ich meiner Frau z.B erst erklären muß wann sie welches Kabel anstecke muss dann sinkt die Motivation sehr schnell und der positive Effekt wäre weg.

Jo, meine Rede, Kabel-Rochade ist die dämlichste Methode. Phasenabschaltung vor der Box würde es aber auch nicht unbedingt verbessern. Ich biete meine Box über &Charge an. Sie muss also jederzeit und ohne Aufwand per Aktivierung mit RFID Karte 10 volle 11kW liefern. Dem Ladegast kann man noch vermitteln ,,nimm das gelbe Kabel und aktiviere mit der Karte, die an der Box hängt". Meiner Frau müsste ich aber erklären:
- Spätschichtwoche 1 phasiges Kabel
- Frühschichtwoche 3 phasiges Kabel
- Freier Tag bei schönem Wetter 3 phasiges, bei schlechtem Wetter 1 phasig, es sei denn der Akku ist schon sehr leer, dann 3 phasig

Die reicht die Scheidung ein

Zitat von: Waldmensch am 31 Oktober 2021, 05:15:47
Die reicht die Scheidung ein

Das wäre bei mir auch so. Meine holde Holde fragt mich jedes Mal wieder, wie sie die manuelle Ladung starten kann, wenn diese mal gebraucht wird. Und das ist Dank V3 nur ,Chip vor die Box halten'  :-X
Ich denke Du musst für die Übergangszeit bis zur V3 eine kurze Probeladung durchführen und schauen, wie viel Energie gezogen wird. Du schaust ,einfach' auf die Ladeleistung in einer gewissen Zeit mit abgeschalteten Regelkreis und weißt Bescheid. Z.B. immer wenn das 1. mal nach Stecken des Autos Überschuss da ist. Ich habe die API-Beschreibung durchgeschaut, da gibt es nichts - vermutlich ist diese Info auch für die Box nicht sichtbar, da per Definition nur der maximale Strom des Kabels ausgewertet werden kann.

Niels

Hat sich denn schon jemand einen schönen Plot für die go-eCharger Wallbox "gebaut"? Inkl. Datenauswertung was am Tag, Monat, Jahr geladen wurde.

Bevor ich das Rad neu erfinden muss. Die App und das Steuermodul geben das leider nicht her. Oder habe ich da was übersehen?

Die Verbrauchsdaten aus der Box zu holen macht wenig Sinn. Das sind nur Schätzwerte, so mies, wie die Spannungssensoren arbeiten. Meine pendeln zwischen 200 und 220V. Die sich daraus ergebene Leistungs- und Verbrauchsberechnung liefert immer zu niedrige Werte. Einen Spannungs- Korrekturwert, den man selbst eingeben könnte, gibt es nicht. Zur Verbrauchsmessung sollte man einen vorgelagerten S0 Zähler verwenden.

Hallo Zusammen, Danke für das Modul.

Habe gerade einen go-e Charger 11kw fix mit Hardware v3 und fw 052.1 in Betrieb genommen.
MQTT klappt auch schon.

Nun wollte ich diese Modul auch nutzen, bekomme aber:

Http_state
JSON error

JSON Error
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "This URI does not ex...") at ./FHEM/46_GoECharger.pm line 791.

Was mache ich falsch?

Ich musste ein Authentisierungs Passwort setzen, damit ich per App auch über das WLAN zugreifen kann. Das ist wohl seit HW v3 neu. Passwort statt Token.

Ich habe neben MQTT auch die lokale HTTP API v2 aktiviert.

API v1 und Modbus TCP API sind deaktiviert.

Wo liegt mein Fehler?

Danke Euch.

Aktiviere mal nur so zum Spaß API v1 und versuche es erneut. Vielleicht liegt es ja daran. Habe den v2, daher kann ich das nicht nachstellen.

auch mit API v1 und Neustart: JSON error

das Modul knallt mir seit ein paar Tagen das Log voll. Hat das sonst noch jemand?

2022.01.04 13:22:34 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 652.
2022.01.04 13:22:34 1: stacktrace:
2022.01.04 13:22:34 1:     main::__ANON__                      called by ./FHEM/46_GoECharger.pm (652)
2022.01.04 13:22:34 1:     main::GoECharger_Set                called by fhem.pl (3896)
2022.01.04 13:22:34 1:     main::CallFn                        called by fhem.pl (1930)
2022.01.04 13:22:34 1:     main::DoSet                         called by fhem.pl (1972)
2022.01.04 13:22:34 1:     main::CommandSet                    called by fhem.pl (2851)
2022.01.04 13:22:34 1:     main::getAllSets                    called by ./FHEM/01_FHEMWEB.pm (3271)
2022.01.04 13:22:34 1:     main::FW_devState                   called by ./FHEM/01_FHEMWEB.pm (3164)
2022.01.04 13:22:34 1:     main::FW_Notify                     called by fhem.pl (3896)
2022.01.04 13:22:34 1:     main::CallFn                        called by fhem.pl (3813)
2022.01.04 13:22:34 1:     main::DoTrigger                     called by fhem.pl (4911)
2022.01.04 13:22:34 1:     main::readingsEndUpdate             called by ./FHEM/46_GoECharger.pm (732)
2022.01.04 13:22:34 1:     main::GoECharger_ErrorHandling      called by FHEM/HttpUtils.pm (446)
2022.01.04 13:22:34 1:     main::__ANON__                      called by fhem.pl (781)

Zitat von: Tungsten am 04 Januar 2022, 13:49:42
das Modul knallt mir seit ein paar Tagen das Log voll. Hat das sonst noch jemand?

Also mein Log hat keine Einträge von dem Modul.

Niels

Ich habe begonnen, eine PV-Überschussregelung zu bauen um meinen Seat Leon PHEV zu laden.
Optimal wäre es, den aktuellen Ladezustand des Auto-Akkus zu bekommen, möglichst ohne über das Seat Portal gehen zu müssen.
Ziel ist es das Laden bei 80% SoC zu stoppen um den Akku zu schonen.

Gibt es hierzu eine Kommukation zwischen Auto und go-e Box bzw. einen (indirekten) Indikator?

Hallo Peter,

ich erledige das mit weConnect-MQTT:
https://github.com/tillsteinbach/WeConnect-mqtt

Die Kommunikation über Typ2 sieht die Ladeerfassung meines Wissens nicht vor.
Mit der obigen Lösung lese ich den SOC ein und kann damit auch den Akku schonen.

Danke für die schnelle Antwort, werde ich mir mal genauer ansehen.

Zitat von: PeterJH am 07 Januar 2022, 11:21:11
Ich habe begonnen, eine PV-Überschussregelung zu bauen um meinen Seat Leon PHEV zu laden.
Optimal wäre es, den aktuellen Ladezustand des Auto-Akkus zu bekommen, möglichst ohne über das Seat Portal gehen zu müssen.
Ziel ist es das Laden bei 80% SoC zu stoppen um den Akku zu schonen.

Gibt es hierzu eine Kommunikation zwischen Auto und go-e Box bzw. einen (indirekten) Indikator?

Über den Go-E bekommst du keinen SoC das ist bei den AC Ladern (noch) nicht möglich. Die Abfrage über das Seat Portal würde auch nicht auf Dauer empfehlen wäre aber technisch möglich. Aber falls du es doch möchtest, könntest du das mit diesem Projekt nutzen: https://github.com/dominikkarall/fhempy. Da habe ich es für SEAT/CUPRA bereitgestellt. Ich meine aber, dass das SEAT CONNECT nur im ersten Jahr umsonst ist und danach Kostenpflichtig wird, so ist es zumindest bei meinem Cupra PHEV.
Wenn du etwas pfiffig bist könntest du dir die Daten auch per OBD Schnittstelle ziehen. Als Beispiel könnte man evNotify nutzen.

PS: Die weConnect-MQTT geht leider nicht mit SEAT, da die noch eine alte API Schnittstelle nutzen.

So, meine Wallbox ist gestern montiert worden. Jetzt schaue ich mal, dass ich das Modul und im weiteren PV Überschussladung zum Laufen bekomme.

Gruß Peter

Ich hole mir den State of Charge SoC von unserem VW eUP mit einem WLAN fähigen OBD2 Adapter raus (CarTrend Mini OBD). Kostet fast gar nichts und ist nicht abhängig von irgendwelchen Android Händis, WallBoxen etc, nur WLAN.


Aufruf aus fhem / :

#eUP OBD abfragen als Python3 aufrufen,
# als separaten Thread weil socket laenger blockieren kann
sub eUpOBDbyELM327()
{
  #neue Daten abrufen, Kommunikation mit fhem erfolgt ueber MQTT
  my $thr = threads->create(\&eUpOBDbyELM327_Thread);
  $thr->detach();
}

sub eUpOBDbyELM327_Thread()
{
   my $Process = (`python3 /home/thomas/projects/eUpOBDbyELM327.py`);
}



Zur Abwechslung mal ein Python, eUpOBDbyELM327.py:


import socket
import datetime
import time
import sys
import os
import binascii
import platform
import subprocess

#MQTT Client https://www.eclipse.org/paho/index.php?page=clients/python/index.php
#install on host mit sudo damit alle user inkl. fhem das modul verwenden koennen: pip install paho-mqtt
#import paho.mqtt.client as mqtt
import paho.mqtt.publish as publish
   
#Verbindet eUp ueber den ELM327 und dessen WiFi_OBD2 per MQTT mit fhem
# Ziel: eUP Ladestand (SoC) auslesen und fhem bereitstellen.

ELM_PROMPT = '>'
host = '192.168.0.10'       #IP Adresse des ELM327 Servers, needs to be in quote
port = 35000

#korrekte python version sicherstellen (python3)
if not sys.version_info.major == 3 and sys.version_info.minor >= 6:
    print("Python 3.6 or higher is required.")
    print("You are using Python {}.{}.".format(sys.version_info.major, sys.version_info.minor))
    sys.exit(1)
print("Python Version: " + platform.python_version())
print('Tool File Name: ' + os.path.abspath(__file__))
print('last change: ' + time.ctime(os.path.getctime(__file__)))

#pruefen ob WLAN auf chili eingeschaltet ist
output_str = str(subprocess.run(["ip", "link", "show", "wlx001a13bec331"], capture_output=True))
#print (output_str)
index = output_str.find("state UP")
if(index > 0):
    print ("WLAN connected")
else:
    print ("WLAN not connected")
    sys.exit(1)

#WiFi_OBD2 Device anpingen um Verbindung zu kontrollieren
output_str = str(subprocess.run(["ping", host, "-c", "1"], capture_output=True))
#print (output_str)
index = output_str.find("0% Paketverlust")
if(index > 0):
    print ("ping ok")
else:
    print ("IP "+host+" nicht erreichbar")
    sys.exit(1)


#Verbindung auf ELM327 in eUP aufbauen
s = socket.socket()
s.settimeout(10)   #Set the default timeout in seconds (float)
try:
    s.connect((host, port))         #wartet bis Timeout, wenn nicht verbunden werden kann
except Exception as msg:
    s.close()
    print ('Socket not connected')
    print (msg)
    sys.exit(1)



#------FUNCTIONS--------------------------------------------------------------------
def byte_to_binary(n):
    return ''.join(str((n & (1 << i)) and 1) for i in reversed(range(8)))

def hex_to_binary(h):
    return ''.join(byte_to_binary(ord(b)) for b in binascii.unhexlify(h))

def send_cmd(cmd):
    print (cmd+": ", end = '')
    data=''
    cmd += "\r" # terminate
    s.send(cmd.encode())
    i=0
    while True:
        data=data+s.recv(64).decode()
        i=i+1
        if (data.endswith(ELM_PROMPT) or len(data)>128 or i>10):
            break
    # remove the prompt character
    data = data[:-1]
    # splits into lines while removing empty lines and trailing spaces
    data = data.replace('\r','')
    data = data [len(cmd)-1:]
    return data

def get_uds(SID, ReqDataParam):
    #zB. UDS Service 22 "22028C" --> SID=22, ReqDataParam=028C
    # Antwort enthält nur die Daten (ohne 62028C)
    # aus 62 02 8C AA BB wird AABB
    responce=send_cmd(SID + ReqDataParam)
    if('NO DAT' in responce or 'ERR' in responce):
        print("Error in: %s %s responce %s"% (SID, ReqDataParam, responce))
        return ''
    else:
        responceSID=int(SID, base=16)+64            #UDS responce SID ist 0x40 higher, add 0x40=64
        responceSID=format(responceSID, 'X')        #oder hex()
        responce=responce.replace(' ','')           #alle Leerzeichen weg
        if(responce.find(responceSID)==0):
            responce=responce.replace(responceSID,'',1) #nur erster gefundene Wert ersetzen
        else: return ''
        if(responce.find(ReqDataParam)==0):
            responce=responce.replace(ReqDataParam,'',1)
        else: return ''
        return responce


"""INIT ELM327 DONGLE-------------------------------------"""

print (send_cmd("AT Z"))    # reset to default settings to be sure what the base setting are
#print (send_cmd("AT I"))    # Print the version ID, unnoetig nach reset
print (send_cmd("AT SP6"))  # Set protokoll to 6 - ISO 15765-4 CAN (11 bit ID, 500 kbaud)
print (send_cmd("AT BI"))   # Bypass the initialization sequence to make sure it stays at protokoll 6
#print (send_cmd("AT CAF0")) # Turns off CAN automatic formating so that PCI bytes are not inserted in the messages, or expected in the response
print (send_cmd("AT L0"))   # Linefeeds off
print (send_cmd("AT DP"))   # xxxxxxxxx
#print (send_cmd("AT ST16")) # reduced timeout to 1, orig.16
#print (send_cmd("AT H1"))   #show headers --> 7ED, Debug Only
#print (send_cmd("ATSH17FC007B"))  #Sets header to 17 FC 00 7B  -> 0x17FC007B, funktioniert nicht

success=True
mqttMsgs =[]                       #Message list for mqtt.publish

result = (send_cmd('AT RV'))       #12VSpannung
print(result)
result=result.replace(' ','')
result=result.replace('V','')
mqttMsgs.append(("eUp/OBDELM327/Voltage", result, 0, False))

#Ladung muss eingeschaltet sein damit das BMS laeuft
#SoC, Ladezustand, A/2.55, Prozent
result = get_uds('22','028C')
if(len(result)==2):
    result = int(result, base=16) / 2.55
    result = "{:.1f}".format(result)
    print ("SOC: "+result)
    mqttMsgs.append(("eUp/HVBMS/SoC", result, 0, False))
else:
    success=False


#HV Battery voltage, Spannung der Hochvolt-Batterie, (A*256+B)/4, Volt
result = get_uds('22','1E3B')
if(len(result)==4):
    result = int(result, base=16) / 4
    result = "{:.1f}".format(result)
    print ("HV Battery voltage: "+result)
    mqttMsgs.append(("eUp/HVBMS/HVbattVoltage", result, 0, False))
else:
    success=False


#HV Battery cell number with highest voltage, 2 Byte Zellspannung, 2 Byte Cell Nummer
result = get_uds('22','1E33')
if(len(result)==8):
   voltage = "{:.2f}".format( int(result[0:4], base=16) / 4096 )
   cellNumber = int(result[4:8], base=16)
   cellNumber = "{:d}".format(cellNumber)     
   print ("HV Battery cell number "+cellNumber+" with highest voltage: "+voltage)
   mqttMsgs.append(("eUp/HVBMS/CellVoltageHighest", voltage, 0, False))
   mqttMsgs.append(("eUp/HVBMS/CellVoltageHighestNr", cellNumber, 0, False))
else:
   success=False

#HV Battery cell number with lowest voltage, 2 Byte Zellspannung, 2 Byte Cell Nummer
result = get_uds('22','1E34')
if(len(result)==8):
   voltage = "{:.2f}".format( int(result[0:4], base=16) / 4096 )
   cellNumber = int(result[4:8], base=16)
   cellNumber = "{:d}".format(cellNumber)     
   print ("HV Battery cell number "+cellNumber+" with lowest voltage: "+voltage)
   mqttMsgs.append(("eUp/HVBMS/CellVoltageLowest", voltage, 0, False))
   mqttMsgs.append(("eUp/HVBMS/CellVoltageLowestNr", cellNumber, 0, False))
else:
   success=False


#HV Battery HV Battery max temp and temp point, 2 Byte Temperatur, 2 Byte Cell Nummer
result = get_uds('22','1E0E')
if(len(result)==8):
   temperature = "{:.2f}".format( int(result[0:4], base=16) / 64 )
   cellNumber = int(result[4:8], base=16)
   cellNumber = "{:d}".format(cellNumber)     
   print ("HV Battery max Temp "+cellNumber+" with highest temperature: "+temperature+" °C")
   mqttMsgs.append(("eUp/HVBMS/ModulTemperatureHighest", temperature, 0, False))
   mqttMsgs.append(("eUp/HVBMS/ModulTemperatureHighestNr", cellNumber, 0, False))
else:
   success=False
   
#HV Battery HV Battery min temp and temp point, 2 Byte Temperatur, 2 Byte Cell Nummer
result = get_uds('22','1E0F')
if(len(result)==8):
   temperature = "{:.2f}".format( int(result[0:4], base=16) / 64 )
   cellNumber = int(result[4:8], base=16)
   cellNumber = "{:d}".format(cellNumber)     
   print ("HV Battery min Temp "+cellNumber+" with lowest temperature: "+temperature+" °C")
   mqttMsgs.append(("eUp/HVBMS/ModulTemperatureLowest", temperature, 0, False))
   mqttMsgs.append(("eUp/HVBMS/ModulTemperatureLowestNr", cellNumber, 0, False))
else:
   success=False



#send by MQTT to fhem
#{'topic':"<topic>", 'payload':"<payload>", 'qos':<qos>, 'retain':<retain>}
#qos: At most once (0), At least once (1), Exactly once (2).
#retain: Retained messages help newly-subscribed clients get a status update immediately after they subscribe to a topic.
# auf False, da sonst ei fhem neustart die alten SoC-Werte verwendet werden und nicht die Ladezeitabhaengigen seither
if(success):
    print("send MQTT message")
    #tuple, then it must be of the form: ("<topic>", "<payload>", qos, retain)
    publish.multiple(mqttMsgs, hostname="localhost", port=1883, client_id="", keepalive=60,
                     will=None, auth=None, tls=None, transport="tcp")
else:
    print("Errors found, no MQTT message send")

Hallo zusammen,
für PV-Überschuss sollte 'set amp_current' oder 'set amp_current_eeprom' verwendet werden. Ich tippe auf erstes. Eine kurze Bestätigung wäre nett.
Danke und Gruss

Hallo,

ich habe jetzt nicht den kompletten Thread gelesen und möge es mir nachsehen, falls es schon jemand geschrieben hat: für das Laden mit PV-Überschuss habe ich neben FHEM einen Raspi mit "OpenWB" laufen. Hier haben sie schon jahrelange Erfahrung mit der Steuerung von Wallboxen (auch natürlich die eigene HW) und es gibt viele Module für die SoC-Abfrage (man muss das Rad ja nicht immer nochmal erfinden).

Gruß
Blueberry63

Zitat von: karpate am 02 März 2022, 06:59:01
Hallo zusammen,
für PV-Überschuss sollte 'set amp_current' oder 'set amp_current_eeprom' verwendet werden. Ich tippe auf erstes. Eine kurze Bestätigung wäre nett.
Danke und Gruss

Du solltest ,,set_current" verwenden. Ohne den Eeprom zusatz. Sonst wird der Wert jedesmal in das Eeprom gespeichert. Dieses ist aber nur begrenzt beschreibbar und funktioniert dann nicht mehr zuverlässig.

Danke für die Bestätigung
Grüße

Zitat von: blueberry63 am 03 März 2022, 11:33:43
Hallo,

ich habe jetzt nicht den kompletten Thread gelesen und möge es mir nachsehen, falls es schon jemand geschrieben hat: für das Laden mit PV-Überschuss habe ich neben FHEM einen Raspi mit "OpenWB" laufen. Hier haben sie schon jahrelange Erfahrung mit der Steuerung von Wallboxen (auch natürlich die eigene HW) und es gibt viele Module für die SoC-Abfrage (man muss das Rad ja nicht immer nochmal erfinden).

Gruß
Blueberry63

Wenn du "nur" das Auto laden willst ist das ok. Wenn du aber mehr "Sachen" steuern willst brauchst du wohl eine andere Lösung. Ich steure z.B. meine Wärmepumpe, Poolpumpe und auch andere Verbraucher abhängig vom PV Ertrag. Weiß nicht ob das "OpenWB" auch kann.

VG
Chris

Wie ist denn der Status zum Phasen umschalten via Modul?
Wird das noch eingebaut?

Issue/Request via git?

@thomas1971

Moin,

ZitatIch hole mir den State of Charge SoC von unserem VW eUP mit einem WLAN fähigen OBD2 Adapter raus (CarTrend Mini OBD). Kostet fast gar nichts und ist nicht abhängig von irgendwelchen Android Händis, WallBoxen etc, nur WLAN.

wie greiftst Du auf den zu?
Steckt der immer im Auto?


Gruß

Sany

Hallo zusammen,
ich habe heute meine WB Version CM-03 bekommen und bin am Testen.

Anbindung per MQTT läuft. Allerdings erfolgt das Update 1* pro Sekunde, dass brauche ich aktuell nicht. Also MQTT erstmal in der App deaktiviert.

Die Einbindung über das FHEM Modul macht leider Probleme, siehe FM "JSON error" in den Readings :
Internals:
   DEF        192.168.178.98
   FUUID      623af6b5-f33f-27cb-3b16-7a945a3aa5b385a9
   HOST       192.168.178.98
   INTERVAL   60
   NAME       myGoE
   NOTIFYDEV  global
   NR         1135
   NTFY_ORDER 50-myGoE
   STATE      state
KW_charging_measured kW
   TYPE       GoECharger
   USED_API_KEYS al2 ust al1 rn9 ecd ec8 afi cid wst cdi loe uby car lon rne tds lch mck mcp nmo ec1 rc6 lof amt lot wke tme lbr rcr rn1 r1x mcs dwo aho rc5 rn8 mcu rc7 dto pha rc4 rca ec9 dws sse tof wak fwv tmp lom ec4 mcc eca rc9 ec5 wen rbc tma ec7 al5 al3 upd adi err al4 stp azo ecr rn6 cfi sch rnm txi rbt eto lop nrg ec6 rc1 amp cbl ast loa ama version sdp mce log alw cch rc8 rn5 wss rn7 rn4 rna rcd lse
   VERSION    0.2.2
   ActionQueue:
   OLDREADINGS:
   READINGS:
     2022-03-23 12:31:15   Http_state      JSON error
     2022-03-23 12:31:15   JSON Error      malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "This URI does not ex...") at ./FHEM/46_GoECharger.pm line 791.

   hmccu:
Attributes:
   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
   event-on-change-reading .*
   event-on-update-reading state
   eventMap   /allow_charging 1:on/ /allow_charging 0:off/
   interval   60
   kW_measured_corr_value 1.00
   room       Energie
   stateFormat state
KW_charging_measured kW
   used_api_keys all
   webCmd     on:off
In der App ist die "lokale HTTP API v2" aktiviert.

Fehlt noch irgendwas?


Vielen Dank,
Helmut

Vielen  Dank für das Modul!

OK, ich habe jetzt die API V1 aktiviert, damit kommen die Daten. Ich glaube es macht Sinn, alle Einstellungs-Notwendigkeiten ins Git oder in den 1. Beitrag hier im Thread aufzunehmen.

1. Wunsch: Wäre es möglich das Modul auf die V2 anzupassen?
2. Wunsch: Da es noch einige Zeit dauert, bis mein E-Auto kommt, habe ich die Go-E Box vom Netz getrennt. Dadurch wird jede Minute eine FM GoECharger (ga_myGoE) - RequestERROR: 192.168.178.98: Keine Route zum Zielrechner (113) ins Log geschrieben.
Schön (in diesem Test-Zusammenhang) wäre es, wenn man die Wallbox über ein "set enable oder set disable", ähnlich wie beim DOIF Modul, temporär deaktivieren könnte.


VG Helmut

Ich habe jetzt die WB auf verbose 0 gesetzt. Es gibt dadurch keine Log-Einträge mehr.
Das Pollen geht  jedoch weiter, daher habe ich das Att interval auch hoch gesetzt.
Das ist erstmal ein guter Workaround, denke ich.
Bessere Ideen sind willkommen!

attr ga_myGoE disable 1
Ist im Modul doch möglich. Ob man dafür extra ein setter braucht?

Eine Anbindung an v2 für Zukunft wäre nice. +1.
Und oder schon mal die Phasenumschaltung die auch in v1 gehen sollte ?!

Super und Danke für den Tipp. Hatte ich bislang nicht entdeckt.
Mehr braucht es nicht zum Test.

Moin zusammen,
ich hätte noch eine Frage bzgl. "Cloud" Notwendigkeit und GoE-Modul.

Wenn ich in der App die Cloud Anbindung abschalte, meldet das Modul trotz großer WLAN Feldstärke fast durchgängig
connect to http://192.168.178.98:80 timed out

Das Attr interval ist auf 60 eingestellt.

Eine Verbindung gelingt also nur ab und zu. Die App zeigt das Verhalten nicht, zumindest nicht in dem Ausmaß.
WLAN wird (habe ich im E-GO Support schon über mögliche Probleme gelesen) über FritzBox und Mesh bereitgestellt.
Ich habe dann einen neuen Repeater ohne Mesh und mit eigener SSID eingerichtet, die Verbindung gelingt sofort, ist aber genau so instabil.

Ist das bei euch auch so?

VG Helmut

Heute nach shutdown / restart im Log gefunden:
2022.03.26 22:30:04 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 825.
VG Helmut

Zitat von: isy am 25 März 2022, 09:46:37
Moin zusammen,
ich hätte noch eine Frage bzgl. "Cloud" Notwendigkeit und GoE-Modul.

Wenn ich in der App die Cloud Anbindung abschalte, meldet das Modul trotz großer WLAN Feldstärke fast durchgängig

Code Auswählen Erweitern

connect to http://192.168.178.98:80 timed out

Das Attr interval ist auf 60 eingestellt.

Eine Verbindung gelingt also nur ab und zu. Die App zeigt das Verhalten nicht, zumindest nicht in dem Ausmaß.
WLAN wird (habe ich im E-GO Support schon über mögliche Probleme gelesen) über FritzBox und Mesh bereitgestellt.
Ich habe dann einen neuen Repeater ohne Mesh und mit eigener SSID eingerichtet, die Verbindung gelingt sofort, ist aber genau so instabil.

Ist das bei euch auch so?

VG Helmut

Um dem ganzen mal Feedback zu geben ...

Ich guck morgen mal bei mir...

Zitat von: isy am 26 März 2022, 22:44:48
Heute nach shutdown / restart im Log gefunden:

Code Auswählen Erweitern

2022.03.26 22:30:04 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 825.
VG Helmut

Guck ich auch mal. Denke schlicht unsaubere Variablen Definition und kann ignoriert werden.

Ein Timed out habe ich auch gelegentlich. Keine festen Abstände
heute waren es , bis jetzt 20:00 - 33 timed out

Zur Zeile. 825, schreibt er hier readings die er empfängt. ungünstig dass diese hier wohl auch leer sein kann. eine prüfung könnte dies im vorfelde abfangen.
Wird aber zu keinen problemen fürs modul führen. ist schlicht unsauber.

Vielen Dank für die Info. Fehler scheint die Warning nicht zu verursachen, zumindest bemerke ich nichts. Das kann nur der Entwickler prüfen.

Hast du die Cloud aktiv?

Nein. Aktuell nur offline api.
Denke nicht dass das variablen Problem beim initial andere verursacht.

Überlege gerade noch ob ich api2 nutzen will. Ich hab ein Go e v3.
Bin noch innerlich zerrissen ob api1/2 , dieses Modul  , jsonmod oder eigenes

Danke für's Update!

Also mit "Cloud Verbindung erlauben" habe ich keine Abbrüche.
Beim Speichern der Einstellungen nach Ablehnung der Cloudverbindung geht schon die App (iOS) kurz auf Timeout, das go-e Modul ebenso.
In FHEM dauern dann die Updates des Moduls (derzeit alle 60 Sekunden) ein paar Sekunden und zeigt dieses hier an:
Http_state    fetch data - 0 entries in the Queue
danach wieder Timeout.

Also bei mir geht das Modul nur mit aktivierter Cloud, keine Ahnung, warum das so ist!
WLAN RSSI ist -56, also super.

Ich brauche vermutlich keine Implementierung der neuen API V2, da ich mit den aktuell zur Verfügung stehenden Werten und Einstellungen meine PV-Überschussladung per DOIF umsetzen konnte. Es sei denn, go-e schaltet bei zukünftigen Updates die V1 Unterstützung ab, das wäre möglich. Ich kann aber auch nicht abschätzen, was die Info in der App "beinhaltet aber nicht mehr alle Funktionen des go-eCharger" bedeutet.

Da ich auch mqtt einsetze, habe ich diese Verbindung zum go-e auch schon getestet. Der go-e feuert aber jede Sekunde, die Systemlast möchte ich eigentlich nicht haben. Allerdings bleibt das go-e Modul damit online, keine Timeouts.
Im Forum unter https://forum.fhem.de/index.php/topic,105457.75.html wurde Juli 2021 an den go-e Support geschrieben, die mqtt Implementierung dahingehend anzupassen. Geschehen ist wohl bis dato nichts.

Gruß

Schaltet dein doif auch die Phasen um?

Ich habe mich damit noch nicht beschäftigt, mein Auto lädt nur mit 1 Phase, also max 3,7 kW.

Der Stromzähler arbeitet saldierend, das bedeutet, es ist egal auf welcher Phase der SMA WR (3-phasig) gerade wieviel einspeist.
Über meine PV-Steuerung (SolarView mit D0 Kopf und SMA WR und dann per MQTT2 nach FHEM) bekomme ich den aktuellen Leistungswert DPAC des Hauses.

- Ein 1. DOIF schaltet in Abhängigkeit des PV-Überschusses das Reading amp_current auf den entsprechenden Wert
- Ein 2. DOIF schaltet nur die Ladung ein/aus in Abhängigkeit des Readings car_state und kleinstem PV-Überschuss.
Durch diese Arbeitsteilung, will ich mal sagen, sind die DOIF's gut überschaubar und ergänzbar.

Ich habe eben im goingelectric Forum gelesen, dass der Wunsch besteht, bei geringer Leistung der PV nur 1-phasig zu laden, also mit 1* 6A (so wie ich das mache), statt mit 3*6A.

In der App kann man auf ja 1-phasig umstellen.
Kann die API V1  (also das FHEM Modul) dieses Feature? Es müsste ja ein "set xxx" vorhanden sein oder?

Update: Mit der MQTT2 Anbindung lässt sich die Box auf 1-phasig umschalten.

Umschalten der Phasen können alle apis. Entscheidend ist die hw.
Wollt mir das erstellen einer Logik ersparen und klauen ;)
Auf 1phase hoch und runter je nach pv Reserve hab ich quick u Dirty umgesetzt. Möchte dennoch wenn vorhanden mit >4kw laden.
Dann schau ich mir das mal bei Gelegenheit bei nem Eis an.

Wie geht denn mit dieser Modulversion die Umschaltung?

Habe gefunden, wie die Phasenumschaltung im Modul funktioniert:

3-phasig
set <box> payload fsp=0
1-phasig
set <box> payload fsp=1

Hallo LR66,
ich habe evtl. einen kleinen Bug im Modul gefunden.

Es gibt ein "set" zum "led_save_energy" Reading auf "0" oder "1"
- Im Modul ist der Befehl im DropDown realisiert
- Das Set-Kommando wird nicht umgesetzt (zumindest bei mir ohne Funktion)
- In der Device specific help ist diese set Option nicht dokumentiert.

Viele Grüße, Helmut

P.S. Das Modul läuft super und ich kann alles umsetzen, was ich mir vorgestellt habe. Danke sehr!

@LR66,
hallo Lutz, hast du einen Plan, dein Modul offiziell einzuchecken?

VG Helmut

Hallo zusammen,

wollte meine Notification mit Euch teilen, mit der ich PV geführt lade. MQTT Anbindung weil zuverlässiger als ueber HTTP
Viel Spaß und gerne Verbesserungen teilen.

defmod Wallbox1PVladen_n notify WR_Status:Power_P_Grid:.* { ##immer wenn vom Wechselrichter der Netzsaldo aktualisiert wird\
  my $PowerGrid = ReadingsVal ("WR_Status","Power_P_Grid",0);; ##negative Wert Ueberschuss, positive Netzbezug\
  my $oldAmp = ReadingsVal ("Wallbox1MQTT","amp",0);;\
  my $carstatus = ReadingsVal ("Wallbox1MQTT","car",1);;\
  my $chargelogic = ReadingsVal ("Wallbox1MQTTlogic","state","pv");;\
  my $phasen = int(ReadingsVal ("Wallbox1MQTT","pha",0) / 8);; ## 56+ for three phases \
  my $newAmp = 0;;\
  my $deltaAmp = 0;; ##wir errechnen immer die Ampere die moeglich sind zur besten Nutzung\
  if ($phasen < 56) { ##wenn einphasig angeschlossen\
    $deltaAmp = int(-$PowerGrid / 250);; ##konservativ gerechnet, exakt waeren 230W pro Ampere\
  }\
  else { ##dreiphasiger Zweig\
    $deltaAmp = int(-$PowerGrid / 700);; ##exakt waeren hier 3x230 also 660W\
  };;\
  $newAmp = $oldAmp + $deltaAmp;; ##Berechnung der neuen Ampere\
  if ($newAmp > 16) {$newAmp = 16};; ## set max 16A\
  if ($newAmp < 6) {$newAmp = 6};; ## set min 6A\
  if ($chargelogic ne "max" and $oldAmp != $newAmp and $carstatus == 2) {fhem("set Wallbox1MQTT amp ".$newAmp)};; ##set new Amp to Wallbox, PV gefuehrtes Laden\
  if ($chargelogic eq "max" and $oldAmp  != 16 and $carstatus == 2) {fhem("set Wallbox1MQTT amp 16")};; ## set max amp, bei Maximaler Leistung\
  if ($chargelogic eq "pv" and $PowerGrid > 500 and $carstatus == 2) {fhem("set Wallbox1MQTT alw 0")};; ## stop charging, Laden bei PV beenden, wenn mehr als 500W vom Netz bezogen werden\
}
attr Wallbox1PVladen_n disabledAfterTrigger 30


Zitat von: vitolinker am 19 Juni 2022, 12:43:15
Hallo zusammen,

wollte meine Notification mit Euch teilen, mit der ich PV geführt lade. MQTT Anbindung weil zuverlässiger als ueber HTTP
Viel Spaß und gerne Verbesserungen teilen.

Code Auswählen Erweitern


defmod Wallbox1PVladen_n notify WR_Status:Power_P_Grid:.* { ##immer wenn vom Wechselrichter der Netzsaldo aktualisiert wird\
  my $PowerGrid = ReadingsVal ("WR_Status","Power_P_Grid",0);; ##negative Wert Ueberschuss, positive Netzbezug\
  my $oldAmp = ReadingsVal ("Wallbox1MQTT","amp",0);;\
  my $carstatus = ReadingsVal ("Wallbox1MQTT","car",1);;\
  my $chargelogic = ReadingsVal ("Wallbox1MQTTlogic","state","pv");;\
  my $phasen = int(ReadingsVal ("Wallbox1MQTT","pha",0) / 8);; ## 56+ for three phases \
  my $newAmp = 0;;\
  my $deltaAmp = 0;; ##wir errechnen immer die Ampere die moeglich sind zur besten Nutzung\
  if ($phasen < 56) { ##wenn einphasig angeschlossen\
    $deltaAmp = int(-$PowerGrid / 250);; ##konservativ gerechnet, exakt waeren 230W pro Ampere\
  }\
  else { ##dreiphasiger Zweig\
    $deltaAmp = int(-$PowerGrid / 700);; ##exakt waeren hier 3x230 also 660W\
  };;\
  $newAmp = $oldAmp + $deltaAmp;; ##Berechnung der neuen Ampere\
  if ($newAmp > 16) {$newAmp = 16};; ## set max 16A\
  if ($newAmp < 6) {$newAmp = 6};; ## set min 6A\
  if ($chargelogic ne "max" and $oldAmp != $newAmp and $carstatus == 2) {fhem("set Wallbox1MQTT amp ".$newAmp)};; ##set new Amp to Wallbox, PV gefuehrtes Laden\
  if ($chargelogic eq "max" and $oldAmp  != 16 and $carstatus == 2) {fhem("set Wallbox1MQTT amp 16")};; ## set max amp, bei Maximaler Leistung\
  if ($chargelogic eq "pv" and $PowerGrid > 500 and $carstatus == 2) {fhem("set Wallbox1MQTT alw 0")};; ## stop charging, Laden bei PV beenden, wenn mehr als 500W vom Netz bezogen werden\
}
attr Wallbox1PVladen_n disabledAfterTrigger 30


Weißt du, ob dieser Code auch mit der neuesten Version V3 des go-e Charger Homefix geht? Habe hier (https://shop.e-mobilio.de/products/go-echarger-homefix?_pos=3&_sid=3c4651471&_ss=r) keine Antwort leider bekommen können...

Das werde ich dir bald sagen können, da die V3 heute geliefert wird :-)

Beim V3 besteht die Möglichkeit welche API Versionen benutzt werden sollen, somit wäre diese auch abwärtskompatibel.
Das Umschalten der Phasen müsste man natürlich dann selber steuern und selber ergänzen.

Hey ich nutze seit langem das Modul zum Überschussladen.

Heute ist mir aufgefallen, dass die go-e v3 Box nicht mehr über 16A geht. Wie es in Technik so ist, hat es schon mal funktioniert. Hat sich was geändert? Denke eher nicht.

Der Parameter amp_current lässt einfach nicht mehr wie 16A zu.

set goe amp_current 32

Arg 32 not allowed for amp_current


List Readings:
     2022-06-27 13:20:20   amp_current     16
     2022-06-27 13:20:20   amp_lvl01       10
     2022-06-27 13:20:20   amp_lvl02       16
     2022-06-27 13:20:20   amp_lvl03       20
     2022-06-27 13:20:20   amp_lvl04       24
     2022-06-27 13:20:20   amp_lvl05       32
     2022-06-27 13:20:20   amp_max16A_adapter 0
     2022-06-27 13:20:20   amp_max_cable   32
     2022-06-27 13:20:20   amp_max_wallbox 32

Hab mich mal im Quelltext versucht aber mehr wie $maxamp nicht gefunden.

Hat jemand einen Tipp für mich?

Grüße

Zitat von: Juelo am 27 Juni 2022, 13:22:03
Hey ich nutze seit langem das Modul zum Überschussladen.

Heute ist mir aufgefallen, dass die go-e v3 Box nicht mehr über 16A geht. Wie es in Technik so ist, hat es schon mal funktioniert. Hat sich was geändert? Denke eher nicht.

Der Parameter amp_current lässt einfach nicht mehr wie 16A zu.

Code Auswählen Erweitern

set goe amp_current 32

Code Auswählen Erweitern

Arg 32 not allowed for amp_current


List Readings:

Code Auswählen Erweitern

     2022-06-27 13:20:20   amp_current     16
     2022-06-27 13:20:20   amp_lvl01       10
     2022-06-27 13:20:20   amp_lvl02       16
     2022-06-27 13:20:20   amp_lvl03       20
     2022-06-27 13:20:20   amp_lvl04       24
     2022-06-27 13:20:20   amp_lvl05       32
     2022-06-27 13:20:20   amp_max16A_adapter 0
     2022-06-27 13:20:20   amp_max_cable   32
     2022-06-27 13:20:20   amp_max_wallbox 32

Hab mich mal im Quelltext versucht aber mehr wie $maxamp nicht gefunden.

Hat jemand einen Tipp für mich?

Grüße

Welcher Wert steht denn bei dir unter dem Reading "ama" ?

Hey,

danke für die Rückfrage.

Ein Reading ama hab ich leider nicht.

     2022-06-27 13:08:30   Http_lastRequestError http://xx.x.x.x/status: empty answer received
     2022-06-27 16:25:24   Http_state      ready
     2022-06-27 16:25:24   KW_charging_measured 3.59
     2022-06-27 16:25:24   KW_preset_calculated 11.04
     2022-06-27 16:25:24   aWattar_zone    0
     2022-06-27 16:25:24   access_control_state access_open
     2022-06-27 16:25:24   allow_charging  1
     2022-06-27 16:25:24   amp_current     16
     2022-06-27 16:25:24   amp_lvl01       10
     2022-06-27 16:25:24   amp_lvl02       16
     2022-06-27 16:25:24   amp_lvl03       20
     2022-06-27 16:25:24   amp_lvl04       24
     2022-06-27 16:25:24   amp_lvl05       32
     2022-06-27 16:25:24   amp_max16A_adapter 0
     2022-06-27 16:25:24   amp_max_cable   32
     2022-06-27 16:25:24   amp_max_wallbox 32
     2022-06-27 16:25:24   ap_password     ********
     2022-06-27 16:25:24   byPrice_min_hrs_charge 0
     2022-06-27 16:25:24   byPrice_remain_hrs_start_charge 0.00
     2022-06-27 16:25:24   byPrice_till_oclock_charge 6
     2022-06-27 16:25:24   cable_lock_state_at_box locked_always
     2022-06-27 16:25:24   car_state       2
     2022-06-27 16:25:24   carstate        Charging
     2022-06-27 16:25:24   clock_time      2706221625
     2022-06-27 16:25:24   cloud_disabled  0
     2022-06-27 16:25:24   curr_sense_Typ2 ARRAY(0x557206a8d8)
     2022-06-27 16:25:24   daylights_time_offset 1
     2022-06-27 16:25:24   energy          2533.0
     2022-06-27 16:25:24   energy_card01   0
     2022-06-27 16:25:24   energy_card02   0
     2022-06-27 16:25:24   energy_card03   0
     2022-06-27 16:25:24   energy_card04   0
     2022-06-27 16:25:24   energy_card05   0
     2022-06-27 16:25:24   energy_card06   0
     2022-06-27 16:25:24   energy_card07   0
     2022-06-27 16:25:24   energy_card08   0
     2022-06-27 16:25:24   energy_card09   0
     2022-06-27 16:25:24   energy_card10   0
     2022-06-27 16:25:24   energy_sensors  ARRAY(0x5572e965d8)
     2022-06-27 16:25:24   error           0
     2022-06-27 16:25:24   firmware        053.3
     2022-06-27 16:25:24   gmt_time_offset 101
     2022-06-27 16:25:24   id_card01       1
     2022-06-27 16:25:24   id_card02       
     2022-06-27 16:25:24   id_card03       
     2022-06-27 16:25:24   id_card04       
     2022-06-27 16:25:24   id_card05       
     2022-06-27 16:25:24   id_card06       
     2022-06-27 16:25:24   id_card07       
     2022-06-27 16:25:24   id_card08       
     2022-06-27 16:25:24   id_card09       
     2022-06-27 16:25:24   id_card10       
     2022-06-27 16:25:24   kWh_charged_last 16.1
     2022-06-27 16:25:24   kWh_charged_total 2533.0
     2022-06-27 16:25:24   led_brightness  255
     2022-06-27 16:25:24   led_color_chg   00FFFF
     2022-06-27 16:25:24   led_color_fin   00FF00
     2022-06-27 16:25:24   led_color_idle  0000FF
     2022-06-27 16:25:24   led_save_energy 1
     2022-06-27 16:25:24   load_mgmt_cloud 0
     2022-06-27 16:25:24   load_mgmt_curramp 0
     2022-06-27 16:25:24   load_mgmt_fallbckamp 8
     2022-06-27 16:25:24   load_mgmt_grp   XXXXXXXX
     2022-06-27 16:25:24   load_mgmt_grpamp 32
     2022-06-27 16:25:24   load_mgmt_minamp 6
     2022-06-27 16:25:24   load_mgmt_prio  99
     2022-06-27 16:25:24   load_mgmt_sec   1742
     2022-06-27 16:25:24   name_card01     User 1
     2022-06-27 16:25:24   name_card02     User 2
     2022-06-27 16:25:24   name_card03     User 3
     2022-06-27 16:25:24   name_card04     User 4
     2022-06-27 16:25:24   name_card05     User 5
     2022-06-27 16:25:24   name_card06     User 6
     2022-06-27 16:25:24   name_card07     User 7
     2022-06-27 16:25:24   name_card08     User 8
     2022-06-27 16:25:24   name_card09     User 9
     2022-06-27 16:25:24   name_card10     User 10
     2022-06-27 16:25:24   norway_mode     0
     2022-06-27 16:25:24   phases_available 111001
     2022-06-27 16:25:24   power           3590
     2022-06-27 16:25:24   reboot_counter  133
     2022-06-27 16:25:24   reboot_timer    16041686
     2022-06-27 16:25:24   sched_dbl_press 0
     2022-06-27 16:25:24   schedule        AAAAAAAAAAAAAAAA
     2022-06-27 16:25:24   serial_nr       051010
     2022-06-27 16:25:24   state           charging
     2022-06-27 16:25:24   stop_at_num_kWh 18
     2022-06-27 16:25:24   stop_kWh_state_useless 0
     2022-06-27 16:25:24   unlocked_by_card 0
     2022-06-27 16:25:24   version         B
     2022-06-27 16:25:24   wifi_enabled    1
     2022-06-27 16:25:24   wifi_flags      2
     2022-06-27 16:25:24   wifi_state      3
     2022-06-27 16:25:24   wlan_key        ********
     2022-06-27 16:25:24   wlan_ssid       FritzSomebody

Attribute:
used_api_keys  = all

Grüße

Zitat von: Juelo am 27 Juni 2022, 16:30:32
Hey,

danke für die Rückfrage.

Ein Reading ama hab ich leider nicht.

Code Auswählen Erweitern

     2022-06-27 13:08:30   Http_lastRequestError http://xx.x.x.x/status: empty answer received
     2022-06-27 16:25:24   Http_state      ready
     2022-06-27 16:25:24   KW_charging_measured 3.59
     2022-06-27 16:25:24   KW_preset_calculated 11.04
     2022-06-27 16:25:24   aWattar_zone    0
     2022-06-27 16:25:24   access_control_state access_open
     2022-06-27 16:25:24   allow_charging  1
     2022-06-27 16:25:24   amp_current     16
     2022-06-27 16:25:24   amp_lvl01       10
     2022-06-27 16:25:24   amp_lvl02       16
     2022-06-27 16:25:24   amp_lvl03       20
     2022-06-27 16:25:24   amp_lvl04       24
     2022-06-27 16:25:24   amp_lvl05       32
     2022-06-27 16:25:24   amp_max16A_adapter 0
     2022-06-27 16:25:24   amp_max_cable   32
     2022-06-27 16:25:24   amp_max_wallbox 32
     2022-06-27 16:25:24   ap_password     ********
     2022-06-27 16:25:24   byPrice_min_hrs_charge 0
     2022-06-27 16:25:24   byPrice_remain_hrs_start_charge 0.00
     2022-06-27 16:25:24   byPrice_till_oclock_charge 6
     2022-06-27 16:25:24   cable_lock_state_at_box locked_always
     2022-06-27 16:25:24   car_state       2
     2022-06-27 16:25:24   carstate        Charging
     2022-06-27 16:25:24   clock_time      2706221625
     2022-06-27 16:25:24   cloud_disabled  0
     2022-06-27 16:25:24   curr_sense_Typ2 ARRAY(0x557206a8d8)
     2022-06-27 16:25:24   daylights_time_offset 1
     2022-06-27 16:25:24   energy          2533.0
     2022-06-27 16:25:24   energy_card01   0
     2022-06-27 16:25:24   energy_card02   0
     2022-06-27 16:25:24   energy_card03   0
     2022-06-27 16:25:24   energy_card04   0
     2022-06-27 16:25:24   energy_card05   0
     2022-06-27 16:25:24   energy_card06   0
     2022-06-27 16:25:24   energy_card07   0
     2022-06-27 16:25:24   energy_card08   0
     2022-06-27 16:25:24   energy_card09   0
     2022-06-27 16:25:24   energy_card10   0
     2022-06-27 16:25:24   energy_sensors  ARRAY(0x5572e965d8)
     2022-06-27 16:25:24   error           0
     2022-06-27 16:25:24   firmware        053.3
     2022-06-27 16:25:24   gmt_time_offset 101
     2022-06-27 16:25:24   id_card01       1
     2022-06-27 16:25:24   id_card02       
     2022-06-27 16:25:24   id_card03       
     2022-06-27 16:25:24   id_card04       
     2022-06-27 16:25:24   id_card05       
     2022-06-27 16:25:24   id_card06       
     2022-06-27 16:25:24   id_card07       
     2022-06-27 16:25:24   id_card08       
     2022-06-27 16:25:24   id_card09       
     2022-06-27 16:25:24   id_card10       
     2022-06-27 16:25:24   kWh_charged_last 16.1
     2022-06-27 16:25:24   kWh_charged_total 2533.0
     2022-06-27 16:25:24   led_brightness  255
     2022-06-27 16:25:24   led_color_chg   00FFFF
     2022-06-27 16:25:24   led_color_fin   00FF00
     2022-06-27 16:25:24   led_color_idle  0000FF
     2022-06-27 16:25:24   led_save_energy 1
     2022-06-27 16:25:24   load_mgmt_cloud 0
     2022-06-27 16:25:24   load_mgmt_curramp 0
     2022-06-27 16:25:24   load_mgmt_fallbckamp 8
     2022-06-27 16:25:24   load_mgmt_grp   XXXXXXXX
     2022-06-27 16:25:24   load_mgmt_grpamp 32
     2022-06-27 16:25:24   load_mgmt_minamp 6
     2022-06-27 16:25:24   load_mgmt_prio  99
     2022-06-27 16:25:24   load_mgmt_sec   1742
     2022-06-27 16:25:24   name_card01     User 1
     2022-06-27 16:25:24   name_card02     User 2
     2022-06-27 16:25:24   name_card03     User 3
     2022-06-27 16:25:24   name_card04     User 4
     2022-06-27 16:25:24   name_card05     User 5
     2022-06-27 16:25:24   name_card06     User 6
     2022-06-27 16:25:24   name_card07     User 7
     2022-06-27 16:25:24   name_card08     User 8
     2022-06-27 16:25:24   name_card09     User 9
     2022-06-27 16:25:24   name_card10     User 10
     2022-06-27 16:25:24   norway_mode     0
     2022-06-27 16:25:24   phases_available 111001
     2022-06-27 16:25:24   power           3590
     2022-06-27 16:25:24   reboot_counter  133
     2022-06-27 16:25:24   reboot_timer    16041686
     2022-06-27 16:25:24   sched_dbl_press 0
     2022-06-27 16:25:24   schedule        AAAAAAAAAAAAAAAA
     2022-06-27 16:25:24   serial_nr       051010
     2022-06-27 16:25:24   state           charging
     2022-06-27 16:25:24   stop_at_num_kWh 18
     2022-06-27 16:25:24   stop_kWh_state_useless 0
     2022-06-27 16:25:24   unlocked_by_card 0
     2022-06-27 16:25:24   version         B
     2022-06-27 16:25:24   wifi_enabled    1
     2022-06-27 16:25:24   wifi_flags      2
     2022-06-27 16:25:24   wifi_state      3
     2022-06-27 16:25:24   wlan_key        ********
     2022-06-27 16:25:24   wlan_ssid       FritzSomebody

Attribute:

Code Auswählen Erweitern

used_api_keys  = all

Grüße

Komisch bei mir steht direkt "ama" was aber eigentlich nicht richtig ist, denn laut Code sollte das "amp_max_wallbox" sein und das steht bei dir auf 32 somit sollte das auch funktionieren. Dann müssten wir mal auf @LR66 warten ob er noch einen Idde hat.

Habe diese Fehlermeldung im Log.

Habe es dem Entwickler auch schon in GizHub gemeldet, aber leider seit Januar keine Reaktion.

Hat jemand eine Idee wie ich das fixe?


2022.08.11 09:57:23 1: PERL WARNING: Use of uninitialized value $maxamp in concatenation (.) or string at ./FHEM/46_GoECharger.pm line 652.
2022.08.11 09:57:23 1: stacktrace:
2022.08.11 09:57:23 1:     main::__ANON__                      called by ./FHEM/46_GoECharger.pm (652)
2022.08.11 09:57:23 1:     main::GoECharger_Set                called by fhem.pl (3950)
2022.08.11 09:57:23 1:     main::CallFn                        called by fhem.pl (1947)
2022.08.11 09:57:23 1:     main::DoSet                         called by fhem.pl (1989)
2022.08.11 09:57:23 1:     main::CommandSet                    called by fhem.pl (2884)
2022.08.11 09:57:23 1:     main::getAllSets                    called by ./FHEM/01_FHEMWEB.pm (3297)
2022.08.11 09:57:23 1:     main::FW_devState                   called by ./FHEM/01_FHEMWEB.pm (1886)
2022.08.11 09:57:23 1:     main::FW_makeDeviceLine             called by ./FHEM/01_FHEMWEB.pm (2060)
2022.08.11 09:57:23 1:     main::FW_showRoom                   called by ./FHEM/01_FHEMWEB.pm (1204)
2022.08.11 09:57:23 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (608)
2022.08.11 09:57:23 1:     main::FW_Read                       called by fhem.pl (3950)
2022.08.11 09:57:23 1:     main::CallFn                        called by fhem.pl (781)

Sorry, war hier lang nicht mehr.
@Juelo
Du hast kein Reading ama mit Deiner Firmware-Version (die ich nicht habe)?
Kannst Du Dir bitte mal in Deinem Webbrowser die Textausgabe von
http://<deine_lokale_goE_IP>/status
ansehen, ob da tatsächlich nirgends sowas wie
,"ama":"16",
auftaucht?
(bitte hier nicht komplette Ausgabe listen)
@Tungsten:
In der lokalen Datei Zeile
my $maxamp;
in
my $maxamp=6;
ändern könnte eventuell die Warnung beim Start beseitigen.
Edit: Was bei Dir an Zeilen nach der Warnung kommt, kenne ich so nicht - musste gerade suchen was stacktrace ist:  wozu hast Du das standardmäßig an?
Ansonsten liegt es eher daran, dass ich kein gutes Fehlerhandling bei der Festlegung $maxamp programmiert habe. Vielleicht tritt es auf, wenn kein Kabel steckt... muss ich mir ansehen.
Bitte mal mit o.g. lokaler Webadresse die Werte für
"ama:xx" (max. Strom, den die Box kann)
"cbl":"xx" (max. Strom, den das gesteckte Typ2-Kabel kann)
"adi":"x" (hat aktives 16A Limit durch mobiles Adapterset oder nicht)
mitteilen.
Danke, Lutz

Habe wie vorgeschlagen
my $maxamp;
in
my $maxamp=6;
geändert. Perl Warning kommt wohl jetzt nicht mehr.

Was genau bedeutet $maxamp=6; jetzt genau in diesem Kontext nun bei einem 11kw Charger?

Danke Dir

Das $maxamp wird von mir intern als maximale über Kommando oder Slider einstellbare Stromstärke aus den o.g. Restriktionen und dem setzbaren amp_max_wallbox festgelegt, damit man nicht versehentlich mehr eingibt, als die Wallbox darf, das Typ2-Kabel hergibt oder wenn ein Adapter CEE32 auf CEE16. Kann sein, dass der goE das selber anpasst oder die App eine Fehleingabe verhindert. Bei mir z.B. kann aber die alte Wallbox 22kW garnicht wissen, dass sie hinter einer 20A Sicherung sitzt, daher hatte ich den setzbaren Parameter amp_max_wallbox (bei mir auf 16 gesetzt)mit reingebracht und die Limits verknüpft (niedrigstes zählt für Slider und Eingaben).

Ein tolles Modul von LR66, ich benutze es schon sehr lange.
Vor ein paar Wochen hat mein go-e Charger seinen Dienst eingestellt. Nach rund 2,5 Jahren war er plötzlich defekt   :( >:(
Go-e hat sich vorbildlich verhalten und mir auf Kulanz die neuste Version zugeschickt :) :) :)
Ich kann also go-e loben und auch weiterempfehlen!
Mit Version 3 des go-e unterstützt mein Charger jetzt auch API V2. Ich hätte somit nichts dagegen wenn das Modul zukünftig auch die V2 unterstützen würde.

Ja, bei mir genauso, nur das es nach 1,5 Jahren war.  :)

Das mit der API V2 habe ich mir auch gedacht, könnte da auch die Tage mal helfen.
LR66, wie sollte das am ehesten sein? Also ein neues Modul für die V2 API oder anders?

Habe nicht viel Erfahrung mit fhem-Modulen  ::)

Gruß, Carsten

Zitat von: isy am 01 April 2022, 15:49:43
Habe gefunden, wie die Phasenumschaltung im Modul funktioniert:

3-phasig

Code Auswählen Erweitern

set <box> payload fsp=0
1-phasig

Code Auswählen Erweitern

set <box> payload fsp=1

Könnte man das irgendwie in's Modul aufnehmen? Also dass man das Reading angezeigt bekommt und auch in FHEM umschalten kann?

Auch wenn ich auf die letzte Frage noch keine Antwort bekommen habe und mir per HTTPMOD geholfen habe und den aktuellen Phasenwert angreife, hier mal meine nächste Frage.

Ich hab einen Opel Mokka-e - dieser schläft ja immer nach einer gewissen Zeit ein und der Status vom Fahrzeug heißt dann "...warten auf Fahrzeug". Ich kann dann die Ladung aus FHEM heraus nicht starten....aus der App geht es aber, da sie dann erst das Aufwachsignal über "Ausstrecken simulieren" sendet. Kann ich das auch aus dem goE Modul schicken?

Gute Frage. Mein e-Niro schläft nicht so tief ein.

Mit welcher App machst du das denn? Mit der vom go-eCharger oder der von Opel?

Aus der go-E App lässt er sich problemlos wecken, da die ja dann ein "Ausstecken" und "Wiedereinstecken" des Kabels simuliert - geht aber meinesWissens erst ab der V3 Version vom go-E Charger, deshalb hatte ich mir auch bewusst die Version geholt.
Aber aus FHEM heraus kann ich die Ladung dann nicht starten, wenn das Auto "so tief" eingeschlafen ist.

Ich habe jetzt letztens eine V3 als Garantietausch bekommen, hatte aber noch keine Zeit mich näher mit den Unterschieden beschäftigen zu können.

Das aktuelle Modul in fhem ist für die damals einzige Version 1 der API geschrieben worden.
Soweit ich es mitbekommen habe, gibt es einige neue Funktionen der V2 API, die z.B. auch "einfacher" die Phasenumschaltung kann.
Meine Vermutung ist, dass dieses Problem mit dem Nicht-Aufwecken mit der V2 API machbar wäre.

Jetzt müsste "nur" jemand für die V2 ein fhem-Modul schreiben oder die neue Version in das bestehende integrieren, z.B. mit einer Einstellung, welche Version genutzt werden soll.
Ich habe bisher kaum was in Perl gemacht, würde mich grundsätzlich gerne damit beschäftigen. Aber aktuell fehlt einfach die Zeit.

Die API Version sagt nichts über die Umschaltmöglichkeit der Phasen, das ist bei beiden API´s möglich. Wichtig ist das man einen V3 hat.
Ich habe mal eine neue Version erstellt wo man mit set force_single_phase die Phasen umstellen kann. Zusätzlich gibt es nun das Reading force_single_phase wo man den Status sehen kann.
Bitte mal testen.

Zur Info: Bin kein Programmierer sondern versuche nur zu Helfen.

Zur Info:
Die neue Version (0.2.3) ist auch ab sofort über den FHEM Update Prozess installierbar, sofern ihr den Updateprozess wie auf Seite 1 beschrieben, hinzugefügt habt.

Hallo,

die Temperaturen des Controllers kann man ab V3 mit dem Parameter "tma" auslesen. (tma ist ein array[1])
Ich habe dafür folgenden Patch bei mir eingefügt. Könnte man das so oder ähnlich in das offz. Modul übernehmen? Danke.

}elsif($r eq 'tma'){
my @vtmp=@{$responsedata->{'tma'}};
$tmpr='tma1';
$tmpv=sprintf("%.1f",$vtmp[0]);
readingsBulkUpdate($hash,$tmpr,$tmpv);
$tmpr='tma2';
$tmpv=sprintf("%.1f",$vtmp[1]);
readingsBulkUpdate($hash,$tmpr,$tmpv);
$r="";
}

Hallo,

ich habe 2 Charger. Einer mit FW 053.3 und einer mit FW 054.7. Diese Verhalten sich im STATE unterschiedlich.
Ich vermute das mit FW 054.7 etwas am  Paramter alw geändert wurde. Und zwar wird ohne Auto (car=1) jetzt alw=0 vom charger zurückgegeben.
Daher bekomme ich im STATE (FW 054.7) jetzt ein "not_allowed" und nicht wie früher ein "ready_no_car".

Im Modul ist dafür diese Zeile verantortlich. Die Abfrage auf alw macht eigentlich keinen Sinn, oder ?

$tmpv=sprintf("%d",($responsedata->{car}));
   if ($tmpv ==1){
      if (($responsedata->{alw})==1){
         $tmpstate='ready_no_car';
      }else{
          $tmpstate='not_allowed';
      }

Guter Fund, kann ich bestätigen

Ich habe eine neue Version mit den o.g. Vorschlägen erstellt. Bitte wie auf Seite 1 beschrieben updaten und testen.

Ich habe jetzt die Version 0.2.4 vom git probiert:
---
"not_allowed" und "ready_no_car" funktionieren bei mir jetzt.
---
tma sind bei V3 nur 2 Werte, daher folgende Warnungen im log:
Use of uninitialized value $vtmp[2] in sprintf at ./FHEM/46_GoECharger.pm line 908
Use of uninitialized value $vtmp[3] in sprintf at ./FHEM/46_GoECharger.pm line 911
Use of uninitialized value $vtmp[4] in sprintf at ./FHEM/46_GoECharger.pm line 914
Use of uninitialized value $vtmp[5] in sprintf at ./FHEM/46_GoECharger.pm line 917
-----
Aber irgenwie funktionieren einige readings bei mir nicht mehr richtig. Alle readings sind doppelt vorhanden.
z.B. gibt es bei mir jetzt das reading "pha" und "phases_available" oder "rbc" und "reboot_counter".
So wirklich einen Fehler im Modul kann ich aber nicht finden.

setze Mal das Attribut used_api_keys neu, dann werden die Readings neue gesetzt. Bei mir sieht das alles gut aus. Und nach dem Update am besten einen FHEM Neustart durchführen.

Das tma reading für V2 und V3 schaue ich mir noch an.

Dankeschön. Ein neu setzen von used_api_keys und alles geht wieder.

Nochmal zum "tma". Im Modul steht "tma" jetzt 2x drin:
tma      =>   'temperature_tma',      #R# Temperatur des Controllers in °C (ersetzt ab V3 tmp)
tma      =>   'curr_sense_Typ2',      # Array 0,1,2,3,4 Stromsensoren Typ2

Ist das egal ?

Zitat von: DerTom71 am 28 Oktober 2022, 19:48:20
Dankeschön. Ein neu setzen von used_api_keys und alles geht wieder.

Nochmal zum "tma". Im Modul steht "tma" jetzt 2x drin:
tma      =>   'temperature_tma',      #R# Temperatur des Controllers in °C (ersetzt ab V3 tmp)
tma      =>   'curr_sense_Typ2',      # Array 0,1,2,3,4 Stromsensoren Typ2

Ist das egal ?

In der V1-API Doku habe ich nichts darüber gefunden das tma mal curr_sense_Typ2 war. Habe es entsprechend entfernt.
Neu ist euch eine einfache "Erkennung" ob es ein V3 oder V2 ist, damit es keine Probleme mehr beim "tma Array" gibt. Auch kann man nun nur noch die Phasen per set umschalten wenn ein V3 erkannt wurde.
Zur Info:Die Erkennung läuft jetzt erst mal einfach über das Auslesen der Firmware Version.
Welche HW erkannt wurde, kann man im reading "hardware" erkennen.

Viel Spaß beim testen.

Mit dem Update bekomme ich folgenden Fehler unter JSON:

Error malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Nothing matches the ...") at ./FHEM/46_GoECharger.pm line 807.


Zitat von: Stonemuc am 29 Oktober 2022, 19:21:05
Mit dem Update bekomme ich folgenden Fehler unter JSON:

Code Auswählen Erweitern

Error malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Nothing matches the ...") at ./FHEM/46_GoECharger.pm line 807.


Der Fehler sollte jetzt nach einem Update und FHEM Neustart wieder weg sein.
Sorry nochmal.

Ich habe jetzt die Version 0.2.7 probiert. Es gibt jetzt zwei if-Abschnitte "fsp" (ab Zeile 882 und Zeile 914).
Ich denke man muss die 2 Abschnitte Zusammenfügen, da sonst die Phasenanzeige nicht richtig funktioniert:

}elsif($r eq 'fsp'){
         if ($v==1){
            $tmpv='1_Phase';
            $calcphases=1;
         }else{ #($v==0)
            $tmpv='3_Phases';
            $calcphases = $numphases;
         }
         $v=$tmpv;

Zitat von: DerTom71 am 20 November 2022, 12:57:11
Ich habe jetzt die Version 0.2.7 probiert. Es gibt jetzt zwei if-Abschnitte "fsp" (ab Zeile 882 und Zeile 914).
Ich denke man muss die 2 Abschnitte Zusammenfügen, da sonst die Phasenanzeige nicht richtig funktioniert:

}elsif($r eq 'fsp'){
         if ($v==1){
            $tmpv='1_Phase';
            $calcphases=1;
         }else{ #($v==0)
            $tmpv='3_Phases';
            $calcphases = $numphases;
         }
         $v=$tmpv;

Danke für die Rückmeldung. Habe die Änderungen eingebaut (0.2.8)

Ich habe festgestellt, das mit car=4 immer alw=0 wird. (Das ist wahrscheinlich ab FW 054.7 so.)
Somit wurde bei mir anstelle state=finished immer state=not_allowed angezeigt.

Das liegt an den folgenden Zeilen. Ich habe diese bei mir auskommentiert:

#if (($responsedata->{alw})==0 && $tmpv !=1 ){
   #   $tmpstate='not_allowed';
    #}
   if ($tmpv ==1)


Edit 2023-02-20:
Mit FW 55.0 ist das alte Verhalten wieder da. Der Patch ist daher nicht mehr notwendig. 

Moin,

Habe mal zum testen die Wallbox in fhem eingebunden.
Was ich Vermisse oder nicht finde ist die Möglichkeit auszulesen welches Fahrzeug an der Box per RFID angemeldet ist.

Hintergrund den ich mir damit erhoffe....
Über Nacht automatisch das Aufladen zu starten wenn über Tag nicht genügend Sonne war - dieses Natürlich nur wenn das richtige Auto angeschlossen ist.


Gruß
Carsten

Zitat von: stenny am 12 Januar 2023, 08:52:52
Moin,

Habe mal zum testen die Wallbox in fhem eingebunden.
Was ich Vermisse oder nicht finde ist die Möglichkeit auszulesen welches Fahrzeug an der Box per RFID angemeldet ist.

Hintergrund den ich mir damit erhoffe....
Über Nacht automatisch das Aufladen zu starten wenn über Tag nicht genügend Sonne war - dieses Natürlich nur wenn das richtige Auto angeschlossen ist.


Gruß

Carsten

Den Parameter den du suchst, der nennt sich "uby".
Der wird aber standardmäßig nicht angefragt. Somit müssest du das Attribute "used_api_keys" auf "all" stellen.

Danke

Teste ich am WE mal durch

Schönen Abend

Nachdem ich am WE meinem GoE vergeblich versucht habe eine Kommunikation per MQTT zu entlocken bin ich aus das Modul hier gestossen. Nach dem Anlegen bekomme ich aber leider nur:

JSON Error
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Nothing matches the ...") at ./FHEM/46_GoECharger.pm line 805.


Es handelt sich und die Version 0.2.8 und der Charger hat sie FW 0.55.0

Hat jemand einen Rat? Danke Gruß. Lukas

Zitat von: Cujo am 05 Februar 2023, 20:42:59
Schönen Abend

Nachdem ich am WE meinem GoE vergeblich versucht habe eine Kommunikation per MQTT zu entlocken bin ich aus das Modul hier gestossen. Nach dem Anlegen bekomme ich aber leider nur:

Code Auswählen Erweitern

JSON Error
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Nothing matches the ...") at ./FHEM/46_GoECharger.pm line 805.


Es handelt sich und die Version 0.2.8 und der Charger hat sie FW 0.55.0

Hat jemand einen Rat? Danke Gruß. Lukas

Hallo sind dir die Grundlagen bekannt das man die API´s bzw.MQTT in der goe App erst konfigurieren bzw. aktivieren muss und wenn ja welche sind aktiv?

Du kannst auch einfach mal deine IP Adresse des go-eCharger nehmen und folgenden Aufruf im Browser abschicken, dann solltest du die Antwort als JSON Format zurückbekommen.
Aufruf:

http://192.168.xxx.xxx/status

Hallo

Danke für die Antwort. In der App habe ich den API V1 nicht aktiviert. Nun tut es. Sorry.

Lukas

Ich habe im LOG immer wieder folgende Warnung: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841
Das kommt immer dann wenn ein api-key nicht in $goevar definert ist. Ein besserer Code für Zeile 841 wäre z.B. :

if(!defined $newreadingname) {
$newreadingname=$r;
Log3 $name, 4, "GoECharger ($name) - $r api-key not defined";
}

Der Fehlende api-key ist im übrigen folgender. (Wobei für was der sein soll ist mir nicht ganz klar.)

amx => 'ampx_current',


Hallo zusammen,

nach einiger Zeit "muss" ich mich mit dem Thema auch mal wieder beschäftigen.

Aktueller Stand:
- go-eCharger V3 22 kW
- Kia e-Niro mit 11 kW Lader

Bei meinem alten Setup mit dem go-eCharger V2 konnte ich aus phases_available die Anzahl der abgehenden Phasen zum Auto auslesen.
Mit einem 1-phasigen Kabel war der Wert 111100 und mit einem dreiphasigen 111111.

Nun steht auch mit dem einphasigen der Wert 111111 drin  :o

Gibt es eine andere Möglichkeit die Anzahl der Phasen im Kabel zu erkennen oder muss ich meine PV-Überschuss-Logik dahin ändern, dass ich immer mit einem 3-phasigen Kabel lade und die Umschaltung (1- auf 3-phasig) nutze?

Danke und Gruß
Carsten

hallo.
heute erstmals wieder DOIF für go-e angelegt.
im Device aknn man Stromstärke von 1-32A einstellen, will ich aber nur 5A einstellen, bekomm ich errormeldung nicht möglich.
Erst ab 6A klappts. Fehler im template,oder wirklich nicht möglich?

Zitat von: satprofi am 03 Juni 2023, 10:19:02hallo.
heute erstmals wieder DOIF für go-e angelegt.
im Device aknn man Stromstärke von 1-32A einstellen, will ich aber nur 5A einstellen, bekomm ich errormeldung nicht möglich.
Erst ab 6A klappts. Fehler im template,oder wirklich nicht möglich?

Der g-oe kann nicht weniger wie 6 Ampere.

Zitat von: xerion am 03 Juni 2023, 10:23:37

Zitat von: satprofi am 03 Juni 2023, 10:19:02hallo.
heute erstmals wieder DOIF für go-e angelegt.
im Device aknn man Stromstärke von 1-32A einstellen, will ich aber nur 5A einstellen, bekomm ich errormeldung nicht möglich.
Erst ab 6A klappts. Fehler im template,oder wirklich nicht möglich?

Der g-oe kann nicht weniger wie 6 Ampere.

ok, dann fehler im template.er könnte aber 32A, auswahl aber nur max.22A. danke

Zitat von: Eckat am 13 Mai 2023, 18:41:02Bei meinem alten Setup mit dem go-eCharger V2 konnte ich aus phases_available die Anzahl der abgehenden Phasen zum Auto auslesen.
Mit einem 1-phasigen Kabel war der Wert 111100 und mit einem dreiphasigen 111111.

Nun steht auch mit dem einphasigen der Wert 111111 drin  :o


Danke und Gruß
Carsten

die phasen werden mit
pha   "63"

angezeigt. musst dir userreadings anlegen:
Phasen_vorhanden:pha.* { my $val = ReadingsVal($name,"pha","none");; my %rets = ("none" => "-1","8" => "1/0","12" => "1/1","56" => "3/0","63" => "3/3",);; $rets{$val}}

6A liegt an der Box

Das ist nicht nur beim go-eCharger so, sondern liegt an der IEC 62196 Typ 2 (Normung für Typ2 Stecker). Darin ist ein Mindestladestrom von 6 A vorgesehen. Daher kann man an Typ2 grundsätzlich nur ab 6 A (1-phasig sind das dann 1.380 W) laden. Egal ob go-eCharger oder öffentliche Ladesäule.

tesla kann selbst mit nur 5A, wollte das auch mit goE einstellen. tesla steuern mit fhem ist nicht so toll

OK, kann sein, ich habe keinen Tesla.
Aber die IEC 62196 Typ 2 ist nun mal die Norm und man sollte nicht erwarten, dass eine Standard-Wallbox die nicht Standard-Ladung eines Auto-Anbieters kann.  ;)

go-eCharger HW V2: Vorsicht vor Firmware-Update v0.42 !


Hallo,

mir hat die go-e-App heute ein Firmware-Update für meine alte HW V2 auf die FW 0.42 angeboten.
Ich habe daraufhin sicherheitshalber erstmal den go-e-Support angefragt, was es damit auf sich hat.

....
ich betreibe noch 2 ältere HW V2 go-e's mit Firmware 0.41 auf API-Level.
Seit neuestem wird mir in der App in FW-Update auf 0.42 angeboten.
Leider finde ich nirgends irgendeine Info über die FW 0.42, geschweige denn ein Change Log.

Fragen:
1.)    Könnt ihr mir ein Change Log für die FW 0.42 zukommen lassen ?
2.)    Wurde irgendwas auf API v-1-Level geändert ?
3.)    Ist der von @peterpoetzi vor Langem versprochene Lademgt-Fix für die HW V2 in der neuen Firmware 0.42 enthalten ? siehe Github:  https://github.com/goecharger/go-eCharger-API-v1/issues/95#issuecomment-1602360252

und habe folgende Antwort bekommen:

....
vielen Dank für Ihre Nachricht!
Die Firmware-Version 042 fügt im Grunde nur die Unterstützung für den go-e Controller hinzu.
Wenn Sie die API v1 derzeit verwenden, würde ich empfehlen das Update vorerst nicht zu installieren, da wir hier noch einen Bug für den Parameter amx haben.

Bezüglich des Lastmanagement:
Das war eine Änderung welche sich auf die Logik des Lastmanagement bezieht und nicht direkt auf dem go-e Charger geschieht.
Die Änderung wurde in unserem bereits Backend vorgenommen.
Für weitere Frage und Anliegen stehe ich Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen
Alija Zecic
go-e GmbH
support@go-e.com
go-e.com

Office:  +43 4276 624 001 0

go-e GmbH . Satellitenstraße 1 . 9560 Feldkirchen Kärnten . Austria .
UID: ATU70018303 . ATEOS 10000 72708 . Landesgericht Klagenfurt .
442 126k . CEO: Susanne Palli
This email may contain confidential and/or privileged information. If you are not the intended recipient or have received this email in error please notify the sender immediately and delete this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.

Also als API v1-User erstmal die Finger von der FW 0.42 lassen !!!

Zitat von: xerion am 29 Oktober 2022, 21:58:31

Zitat von: Stonemuc am 29 Oktober 2022, 19:21:05Mit dem Update bekomme ich folgenden Fehler unter JSON:

Code Auswählen Erweitern

Error malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Nothing matches the ...") at ./FHEM/46_GoECharger.pm line 807.


Der Fehler sollte jetzt nach einem Update und FHEM Neustart wieder weg sein.
Sorry nochmal.

Ich hab den Fehler übrigens immernoch...woran liegt das denn?

Zitat von: sigma415 am 22 Juni 2023, 20:31:20go-eCharger HW V2: Vorsicht vor Firmware-Update v0.42 !


Hallo,

mir hat die go-e-App heute ein Firmware-Update für meine alte HW V2 auf die FW 0.42 angeboten.
Ich habe daraufhin sicherheitshalber erstmal den go-e-Support angefragt, was es damit auf sich hat.

Code Auswählen Erweitern

....
ich betreibe noch 2 ältere HW V2 go-e's mit Firmware 0.41 auf API-Level.
Seit neuestem wird mir in der App in FW-Update auf 0.42 angeboten.
Leider finde ich nirgends irgendeine Info über die FW 0.42, geschweige denn ein Change Log.

Fragen:
1.)    Könnt ihr mir ein Change Log für die FW 0.42 zukommen lassen ?
2.)    Wurde irgendwas auf API v-1-Level geändert ?
3.)    Ist der von @peterpoetzi vor Langem versprochene Lademgt-Fix für die HW V2 in der neuen Firmware 0.42 enthalten ? siehe Github:  https://github.com/goecharger/go-eCharger-API-v1/issues/95#issuecomment-1602360252

und habe folgende Antwort bekommen:

Code Auswählen Erweitern

....
vielen Dank für Ihre Nachricht!
Die Firmware-Version 042 fügt im Grunde nur die Unterstützung für den go-e Controller hinzu.
Wenn Sie die API v1 derzeit verwenden, würde ich empfehlen das Update vorerst nicht zu installieren, da wir hier noch einen Bug für den Parameter amx haben.

Bezüglich des Lastmanagement:
Das war eine Änderung welche sich auf die Logik des Lastmanagement bezieht und nicht direkt auf dem go-e Charger geschieht.
Die Änderung wurde in unserem bereits Backend vorgenommen.
Für weitere Frage und Anliegen stehe ich Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen
Alija Zecic
go-e GmbH
support@go-e.com
go-e.com

Office:  +43 4276 624 001 0

go-e GmbH . Satellitenstraße 1 . 9560 Feldkirchen Kärnten . Austria .
UID: ATU70018303 . ATEOS 10000 72708 . Landesgericht Klagenfurt .
442 126k . CEO: Susanne Palli
This email may contain confidential and/or privileged information. If you are not the intended recipient or have received this email in error please notify the sender immediately and delete this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.

Also als API v1-User erstmal die Finger von der FW 0.42 lassen !!!

verwendest du amx? ich lass auto den ladestrom regeln.

Hallo zusammen,
ich nutze das GoECharger Modul V0.2.8 mit einem Go-ECharger 11kW V3 mit Firmware V055.0.
Wenn ich auf die aktuelle Firmware V055.5 wechsle, erhalte folgende Fehlermeldungen im Log

2023.07.21 06:12:01 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=amx=6: empty answer received
2023.07.21 06:12:01 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=alw=1: empty answer received
2023.07.21 06:12:01 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=fsp=1: empty answer received
2023.07.21 06:12:01 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=amx=6: empty answer received
2023.07.21 06:12:03 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=amx=6: empty answer received
2023.07.21 06:12:03 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=amx=6: empty answer received
2023.07.21 06:12:03 3: GoECharger (myGoE) - RequestERROR: http://xxx.xxx.x.xxx/mqtt?payload=alw=1: empty answer received
MQTT ist dabei im GoE gar nicht aktiviert. Wechsele ich wieder auf Firmware V055.0 zurück, sind die Fehlermeldungen verschwunden.
Kann jemand das Verhalten bestätigen?

Ich nutze die V2 Box mit der Firmware 055.5
Keine Meldung dieser Art.

VG Helmut

Hallo zusammen,

aufgrund von technischem Defekt bekomme ich als Ersatz für meinen alten GoE-Charger einen (bzw. 2) neuen Gemini - wird der vom Modul ebenfalls unterstützt? Ich gehe mal davon aus, dass die bisherigen Parameter (v.a. amp_current, allow_charging etc.) unverändert sind und weiterhin funktionieren sollten, oder?

Das würde mich auch brennen interessieren.

Ich bekomme diese Woche mein E-Auto und jetzt bin ich auf der Suche nach einem passenden Charger, der PV-Überschussladen per fhem kann.
Dazu hatte ich zwar schon ins Solarforum gepostet, aber ich denke hier wird mir eher geholfen.

Ich bekomme einen KIA EV6. Bei mir zu Hause darf ich maximal eine 11kw Wallbox installieren.

Auf dem Dach ist eine PV Anlage mit 15 kWh und ein Speicher der Firma Sonnen mit 10kw.
Ausserdem fhem auf einem Pi und per Tasmota lese ich meinen Zähler im Schrank aus, bzw. bekomme ich die Werte vom Wechselrichter der Sonnenbatterie.

Jetzt würde ich gerne mein Auto zu Hause anstecken und nur wenn der Akku zwischen 80-100% hat, das Haus mit seinen Verbrauchern versorgt ist, den Rest der Energie ins Auto laden.
Ist das mit dem go-echarger machbar? Auch mit dem Gemini, den es nur noch zu geben scheint?

Was ist mit der automatischen Umschaltung zwischen 1 Phase und 3 Phasen laden? Kann ich das benfalls realisieren mit diesem Modul?

Für ein entsprechendes DOIF wie so etwas aussieht, wäre ich euch wirklich dankbar.

Gruss
Dennis

Hallo Dennis,

Zitat von: dennis_n am 16 August 2023, 20:57:30Das würde mich auch brennen interessieren.

Alle API-Werte, die mein alter go-e geliefert hat, liefert auch der Gemini - von daher ist aus meiner Sicht erstmal alles gut :-)

Zu deinen anderen Fragen würde ich sagen, dass du mit dem Ding nix falsch machst; das liefert die über die API praktisch alle Werte, die du brauchst (und noch viel mehr). Wenn du die anderen Werte (Speicher, PV-Ertrag, aktueller Überschuss etc.) auch irgendwie in FHEM bekommst, ist der Rest "nur" noch Kopfarbeit ;-)

Ich kann dir gerne (am Wochenende) mein DOIF zur Verfügung stellen - das ist zwar nicht optimal, aber für meine Zwecke völlig ausreichend; allerdings habe ich keinen Speicher:
Ich bekomme von meinem SolarLog den PV-Ertrag und den aktuellen Verbrauch und berechne daraus, ob noch was für's Auto übrig ist. Wenn ja, erhöhe ich alle 2 Minuten die Stromstärke für den Ladevorgang um 2A. Wenn es zu wenig ist, dann wieder in 2A-Schritten nach unten bzw. "Ladestopp" (dadurch verhindere ich, dass es bei wechselnder Bewölkung im Sekundentakt hoch und runter geht)
Unter der Woche wird nachts vollgeladen, oder wenn ich über KNX meinen Lademodus auf "jetzt laden, egal was kommt" stelle.
Das Ganze ist dann beliebig ausbaubar.

Hey,

dein DOIF würde ich mir gerne mal anschauen.
Habe auch gerade noch die Software evcc.io gefunden.

Die macht ja im Prinzip das gleiche, nur grafisch etwas aufgepimmt, oder?

Gruss
Dennis

Hallo zusammen,
seit einiger Zeit schreibt das Modul bei jeder Abfrage diese Zeilen ins Log:

2023.10.30 13:11:33 1: PERL WARNING: Use of uninitialized value $newreadingname in string eq at ./FHEM/46_GoECharger.pm line 841.
2023.10.30 13:11:33 1: stacktrace:
2023.10.30 13:11:33 1:     main::__ANON__                      called by ./FHEM/46_GoECharger.pm (841)
2023.10.30 13:11:33 1:     main::GoECharger_WriteReadings      called by ./FHEM/46_GoECharger.pm (818)
2023.10.30 13:11:33 1:     main::GoECharger_ResponseProcessing called by ./FHEM/46_GoECharger.pm (793)
2023.10.30 13:11:33 1:     main::GoECharger_ErrorHandling      called by FHEM/HttpUtils.pm (755)
2023.10.30 13:11:33 1:     main::__ANON__                      called by fhem.pl (781)
2023.10.30 13:11:33 1: PERL WARNING: Use of uninitialized value $calcphases in multiplication (*) at ./FHEM/46_GoECharger.pm line 951.
2023.10.30 13:11:33 1: stacktrace:
2023.10.30 13:11:33 1:     main::__ANON__                      called by ./FHEM/46_GoECharger.pm (951)
2023.10.30 13:11:33 1:     main::GoECharger_WriteReadings      called by ./FHEM/46_GoECharger.pm (818)
2023.10.30 13:11:33 1:     main::GoECharger_ResponseProcessing called by ./FHEM/46_GoECharger.pm (793)
2023.10.30 13:11:33 1:     main::GoECharger_ErrorHandling      called by FHEM/HttpUtils.pm (755)
2023.10.30 13:11:33 1:     main::__ANON__                      called by fhem.pl (781)

Funktions Einschränkungen oder fehlende daten kann ich nicht feststellen. Es nerven eigentlich nur diese Zeilen. Irgendeine Idee, wie ich das abstellen kann ? Braucht es mehr Infos ?
Gruß
Torsten

Zitat von: topsecret99 am 30 Oktober 2023, 13:46:45Irgendeine Idee, wie ich das abstellen kann ?

So kann man das abstellen: https://forum.fhem.de/index.php?topic=110282.msg1264666#msg1264666

Zitat von: DerTom71 am 02 November 2023, 18:52:25

Zitat von: topsecret99 am 30 Oktober 2023, 13:46:45Irgendeine Idee, wie ich das abstellen kann ?

So kann man das abstellen: https://forum.fhem.de/index.php?topic=110282.msg1264666#msg1264666

Danke dir, Fehler ist weg

So, E-Auto ist bestellt, ich suche jetzt wie andere auch eine gute und weitgehend steuerbare Wallbox. Über den FAZ-Test aus dem Sommer bin ich auf den go-eCharger Gemini gestoßen.

Ich hab noch ein paar Fragen an diejenigen, die das Ding schon betreiben:

1. Das Modul greift über die REST-Schnittstelle auf die Wallbox zu. Hat schon jemand ausprobiert, die Wallbox über MQTT anzubinden?
2. Wie alle Wallboxen kommt das Ding mit einer proprietären App. Ich nehme an, von außen funktioniert die nur, wenn der Cloud-Zugang aktiviert ist? Wie sieht es aus, wenn Smartphone und Wallbox ohne Cloud-Aktivierung im gleichen lokalen Netz sind?
3. Als ordnungsgemäßer FHEM-Nutzer will ich natürlich das Lastmanagement in FHEM realisieren. Hat jemand damit Erfahrung? Damit meine ich nicht irgendwelche DOIF-Devices, sondern einen klugen Perl-Code.
4. Weiß jemand, ob bei der Montage das mitgelieferte Anschlusskabel auch komplett entfallen kann? Ich habe nämlich eigentlich nicht vor, eine Extradose für den Anschluss meines NYM-J5x6mm² Kabels zu setzen.
5. Im Datenblatt steht, dass die Box nur bis zu einer Umgebungstemperatur von 40°C betrieben werden kann und darüber hinaus den Ladestrom reduziert. Das Teil soll bei mir unter einem Vordach montiert werden, im Hochsommer kann es da schon mal 40°C haben. Ist da irgendjemandem schon mal passiert, dass die Leistung abgeregelt wurde?

LG

pah

Nutze nicht die Gemini Version, sondern das Modell aus 2021 (V2).
Damit ging mqtt, habe aber jetzt das Modul hier im Einsatz.

VG Helmut

Update: Meine V2 Box läuft natürlich ohne Cloud. Zugang über VPN.
Ich habe die Box mit Kabel und das steckt an der Wandsteckdose. Ich kann die Box auch mitnehmen, um bei Freunden zu laden.

Moin  :)

Ich nutze den go-eCharger v3 mit dem aktuellen Modul aus fhem.

Mit MQTT kenne ich mich kaum aus. Aber ist das nicht nur eine Ein-Weg-Schnittstelle? Also um Daten abzufragen? Dann wäre damit eine Steuerung ja nicht möglich.

Die App von Außen braucht (natürlich) den Cloud Zugriff.
Eine Alternative wäre es evtl. über VPN ins lokale Netz zu verbinden und so den Zugriff zu machen oder einen im lokalen Netz befindlichen Reverse-Proxy zu nutzen.
Beides war mir zu umständlich.  ;D

Lastmanagement habe ich in fhem mit perl Code über die Jahre meinen Bedürfnissen angepasst.
Mittlerweile ist mein Stand ganz grob wie folgt.

Ein "Modul" kümmert sich um die Berechnung PV-Produktion, Hausverbrauch usw. um den "echten" Überschuss zu berechnen.
Das ist sehr individuell je Anlage. So habe ich z.B. eine Tesla Powerwall 2 AC und Wechselrichter und HomeManager von SMA. Beide Hersteller kommunizieren nicht miteinander, sodass manche Werte aus der PW2 kommen, andere aus den SMA Geräten und die nächsten aus beiden berechnet werden.
Bei meinem go-eCharger (keine Ahnung ob das bei den gemini Modellen anders ist) ist halt eine zeitliche Differenz zwischen dem Einstellen der Stromstärke und der tatsächlichen Ladeleistung. Die Geräte schalten alle (soweit ich weiß) halt nicht hart, sondern regeln die Leistung langsam (einige Sekunden) hoch.
Das führte z.B. bei sonnigem Wetter mit vielen kleinen Wolken und damit stark schwankender Leistung der PV-Anlage dazu, dass der go-eCharger erst die Stromstärke erhöhte, die Leistung noch nicht ganz auf dem kalkulierten Wert war, aber die nächste Wolke schon wieder eine Reduktion "notwendig" machte.
Alles zu lösen, aber in der realen Welt halt zu beachten, an das man in der Theorie vorher vielleicht nicht denkt.

Dann kalkuliert ein Modul in fhem die maximale Gesamtladeleistung (habe 2x go-eCharger).
Das nächste dann je nach Belegung der go-eCharger und SoC der Autos die jeweilige Ladeleistung, unter Berücksichtigung der insg. zulässigen maximalen Stromstärke (habe bis jetzt auf eine Erhöhung der Anschlussleistung meines Hausanschlusses verzichtet (klappt bisher auch ohne Probleme)).

Dann kann ich noch über Dummy-devices ein paar Sachen einstellen, wie geplantes Laden über Nacht, Laden bis der SoC der PW2 einen kalkulierten Wert erreicht hat (damit die PW2 noch die Nacht schafft) [Winter] bzw. erst das Laden beginnt, wenn die PW2 einen SoC erreicht hat [Sommer] und "manuelles" Laden so schnell wie möglich.

Die aktuelle Konfiguration klappt für mich jetzt sehr gut.

Bei der Montage des go-eCharger v3 kann man das Gehäuse nicht öffnen, da dort so eine Art Sicherungsschrauben aus weichem Kunststoff verbaut sind. Ich vermute wenn die beschädigt sind, verliert man die Garantie oder hat zumindest mehr Diskussionen. Einer von meinen war mal defekt und go-e hat den ohne jegliche Probleme getauscht.
Daher wird das Ersetzten des Kabels nicht gut gehen.

Zu der maximalen Umgebungstemperatur kann ich nichts sagen, bei mir sind die in den Garagen (mit dunklem Tor). Im Sommer wird das direkt dahinter auch knackig warm, aber mir ist noch keine Drosselung aufgefallen. Evtl. kannst du den Charger so montieren, das er nicht direkte Sonneneinstrahlung (oder nur früh morgens) bekommt. Dann müsste das doch gehen.

Gruß, Carsten

MQTT ist auch in der Lage, Befehle zu übermitteln. Sonst könnte man ja damit z.B. keine Lampen oder Steckdosen steuern. :)
Ob das auch in der Wallbox implementiert ist, kann ja ausprobiert werden.

Normalerweise kann man über MQTT auch steuern - das mache ich bei diversen Geräten.

ZitatDie App von Außen braucht (natürlich) den Cloud Zugriff.

Das war ja nicht gemeint - sondern genau der Fall, dass Smartphone und Wallbox im gleichen (privaten) Netz sind. Ich habe eine ziemlich ausgefeilte Installation sowohl von VPN, als auch von Reverse Proxies für meine Sprachservices.

ZitatIch habe die Box mit Kabel und das steckt an der Wandsteckdose. Ich kann die Box auch mitnehmen, um bei Freunden zu laden.

Prima. Und das Ding auch installiert ohne Elektriker. Muss das dann überhaupt beim Netzbetreiber angemeldet werden? Soweit ich das sehe, nicht. Vielleicht verlege ich einfach meine vorhandene Drehstromsteckdose aus dem Keller nach außen und stecke das Ding an. Ist das Kabel tatsächlich so kurz, wie auf dem Bild zu sehen?

LG

pah

Wenn du etwas eher spezielles zu VPN / Cloud-Zugriff etc. wissen möchtest, solltest du genauer fragen  ;)

Bei den "alten" nicht-gemini Chargern war das Kabel von der mobilen "+" Version relativ kurz (geschätzt 0,5 m) und bei der Home-Fix Version eher lang (geschätzt 1,5 m).
Ich habe mir an die Home-Fix Version einfach einen CEE-Stecker machen lassen.

Die Montageart hat nichts mit der Anmeldepflicht zu tun. Jeder Dauerhochstromverbraucher ist anmeldepflichtig, das gilt für Wallboxen genauso wie für große Maschinen.
Anmeldepflicht gilt für <= 11 kW und darüber ist eine Genehmigungspflicht.
Ich habe nach Rücksprache mit meinem Netzbetreiber die 22 kW Versionen gekauft und auf maximal (zusammen) 11 kW eingestellt (weil die Autos eh nur 11 kW können und quasi nie gleichzeitig laden).
Bis 11 kW muss der Netzbetreiber das "dulden" und ggfs. auf seine Kosten das Netz ertüchtigen.
Ich finde diese Anmeldepflicht auch in der Praxis gut. Denn wir wollen alle ja auch ein ausfallsicheres Netz und natürlich ist fast nirgendwo eine Wallbox ein Problem, jedoch sollen E-Autos mehr werden und damit auch mehr Leute zuhause laden. Daher ist es m.M.n. sinnvoll, dass die Netzbetreiber das wissen und rechtzeitig reagieren können.
Achja, das gilt für Deutschland  ;)

Gruß, Carsten

ZitatWenn du etwas eher spezielles zu VPN / Cloud-Zugriff etc. wissen möchtest, solltest du genauer fragen

Hm... Meine diesbezügliche Frage war eigentlich ganz präzise.

LG

pah

hallo.
würde das auch mit fronius wattpilot klappen?

Zitat von: satprofi am 19 Dezember 2023, 18:18:00hallo.
würde das auch mit fronius wattpilot klappen?

Auf was genau bezieht sich die Frage?

Gruß, Carsten

Ob fronius auch über mqtt an fhem sendet u. Man dann den fronius steuern kann?

Zitat von: satprofi am 19 Dezember 2023, 21:46:22Ob fronius auch über mqtt an fhem sendet u. Man dann den fronius steuern kann?

Das kann ich dir nicht beantworten.

Dieser Thread bezieht sich auf das FHEM Modul 46_GoECharger.pm. Zur Anbindung über mqtt steht im Ausgangsposting folgendes:

ZitatAnmerkung: Den go-ECharger kann man auch über MQTT oder HTTPMOD einbinden, siehe Thread https://forum.fhem.de/index.php?action=post;topic=105457.30;last_msg=1043399 !

danke, das wusste ich . frage war ob der baugleiche wattpilot auch mqtt übetragen kann, und jemand das hier weiss.

Modul 46_GoECharger.pm sind 2 kleine Fehler - dadurch kann die led-farbe nicht gesetzt werden....

Zeile 522: statt 'led_color_charge' sollte 'led_color_chg' stehen
und
Zeile 529: statt 'led_color_finish' sollte 'led_color_fin' stehen


der bug der GoE-Api, dass das Setzten der led-Farben für finished (cfi) und charging (cch) immer idle (cid) überschrieben haben, wurde von GoE mit Version 56.1 gefixed

Leider wird dieses Modul wohl nicht mehr gepflegt.

Heute morgen fiel mir auf, dass das Reading "unlocked_by_card" bei mir nach Vorhalten des mitgelieferten RFIF Chips nicht mehr auf "1" wechselt. Die Anzeige an der Box geht allerdings auf "Grün".

Könnte das jemand von euch mal testen?
goE Version hier 055.8

VG Helmut

Hallo zusammen,
ich habe mal eine Frage wie ihr euer DoIF gemacht habt. Bei mir will es einfach nicht abschalten:
## 2 ## decr
DOELSEIF (([SolarEdge:Bezug_Einspeiung:d] > -100)   
and ([GoECharger:car_state] == 2)
and ([GoECharger:allow_charging] == 1)
and ([GoECharger:amp_current] > 6))
  (set GoECharger amp_current [GoECharger:amp_current:d:$1-1])
##
## 3 ## stop
DOELSEIF (([SolarEdge:Bezug_Einspeiung:d] > -10)       
and ([GoECharger:car_state] == 2)
and ([GoECharger:amp_current] == 6))
  (set GoECharger allow_charging 0)
Irgendwie kapiert er bei mir nicht das er mit amp_current schon auf 6A ist und will auf 5A reduzieren was zu einem Fehler führt. Hat jemand eine Idee was ich da falsch mache? In den Zweig mit Stop will er nicht abbiegen. Ich habe den Go-E v3

VG
Christian

Tippfehler "Einspeiung"?

pah

Zu meiner Schande muss ich gestehen das Reading heißt tatsächlich so. Also ja: Falsch geschrieben aber nicht mein Fehler hier.

Hallo Christian,

meins sieht völlig anders aus.
Ich habe das im Laufe der Zeit immer erweitert, um mich der perfekten Nutzung des Überschusses anzunähern.
Da sind recht viele spezielle Dinge drin, die vermutlich kein anderer Nerd hat  8)

Also ich habe bei mir meistens irgendwelche Logikprobleme gehabt, wenn etwas nicht funktionierte.
Daher habe ich eine Art Debugging mit eingebaut, der abhängig von einem Attribute (debug 0/1) die Werte in ein dummy-Device schreibt (an dem ein FileLog hängt), die an der Stelle genutzt werden.

Von außen hier kann man das nur versuchen logisch auseinander zu nehmen.
Dazu kann ich zu den Werten vom Solaredge nichts sagen. Bei mir sind das Werte von SMA (SmartMeter und Wechselrichter) und Tesla Powerwall 2.

Ich versuche das mal zu beschreiben, was ich in den beiden Blöcken verstehe.

No 2:
Wenn Bezug_Einspeisung > -100 ist und ein Auto angeschlossen ist und Laden grundsätzlich erlaubt ist und der aktuelle Ladestrom größer als 6 ist, dann soll der Ladestrom um 1 reduziert werden.

Das klingt erstmal logisch.

No 3:
Wenn Bezug_Einspeisung > -10 ist und ein Auto angeschlossen ist und der aktuelle Ladestrom 6 entspricht, dann soll der Ladevorgang beendet werden.

Nicht falsch, aber mir fallen zwei Dinge auf:
1.) Du prüfst nicht mehr, ob allow_charging noch 1 ist. Sollte kein Problem machen, aber ich habe versucht nur "Änderungsbefehle" zu schicken, wenn wirklich eine Änderung passieren soll.
2.) Du prüfst auf amp_current == 6. Evtl. würde ich auf <= 6 prüfen. Ist aber nur ein Bachgefühl.

Insgesamt sehe ich keinen Fehler an sich.
Evtl. sowas wie, dass das auslösende Event zwei mal so schnell hintereinander kommt, dass der go-eCharger noch nicht umgeschaltet hat.
Die Umschaltungen (Ladung an/aus, Ladestrom ändern ...) passieren ja nicht schlagartig in Echtzeit, v.a. auch um das Stromnetz zu schützen. Sondern wenn man z.B. den Ladestrom ändert, wird die Ladeleistung langsam herauf- bzw. heruntergefahren.

Was evtl. auch sein könnte, was ich auswendig nicht weiß, ob die Readings (z.B. amp_current) direkt nach dem Ändern auch geändert sind.
Also amp_current ist 8, dann mit set auf 7 geändert. Steht dann sofort 7 drin oder dauert es bis zur nächsten Abfrage bis das Reading aktualisiert wird?!?

Mein Vorschlag wäre es, sich protokollieren zu lassen, in welchen If-Zweig (if, elseif, else) er mit welchen Werten (also warum) "abgebogen" ist.
Vermutlich wird man es daraus erkennen können, was das Problem ist.

Gruß, Carsten

Hallo Carsten,

läuft bei mir ähnlich. Ich habe meine Anlage letzten Winter um einen Speicher erweitert und jetzt versuche ich das so gut wie möglich zu optimieren....

Bei No. 3 gebe ich dir recht. Das ist nicht wirklich konsequent.
<= Werde ich morgen mal testen.

Zu deinem anderen Erklärungsversuch: Ja habe ich mir auch gedacht aber dann hätte er es ja nach der 4ten oder 5ten Runde schnallen müssen. Aber er will immer wieder die amp_current auf 5 setzten.

Wie hast du das Debugging aktiviert? Das habe ich noch nicht wirklich gemacht.

VG
Christian

Debugging kann ich meine Lösung nicht nennen.  ;D

Ich habe für solche Fälle es wie folgt gelöst.

1.) Attribut "verbose" vom Steuerungs-Device (hier mal steuer-doif genannt) genutzt, um im Code darauf zu prüfen, ob etwas ausgegeben werden soll. [Ich mache das meiste im Perl-Code, sollte aber auch anders gehen.]

2.) dummy-Device (bspw. "steuer-doif-text_dummy") anlegen.

3.) FileLog Device für das dummy-Device anlegen
defmod steuer-doif-text_filelog FileLog ./log/steuer-doif-log_%Y_%m_%d.log steuer-doif-text_dummy:.*
Wann immer man jetzt den Wert vom steuer-doif-text_dummy ändert, wird der ins FileLog geschrieben.

Ich mache es meistens dann so, das ich mir in einer Zeile die Quelle (bspw. "DOELSEIF #2") und die jeweils dort verwendeten Werte ausgeben lasse (aus dem jeweiligen Zweig heraus).
Symbolisch sowas (der Code funktioniert so nicht, nur zur Verdeutlichung):
## 1 ## incr
DOIF (([SolarEdge:Bezug_Einspeiung:d] > -1000)   
and ([GoECharger:car_state] == 2)
and ([GoECharger:allow_charging] == 1)
and ([GoECharger:amp_current] > 6))
  (
set GoECharger amp_current [GoECharger:amp_current:d:$1+1],
set steuer-doif-text_dummy doif #1, <wert vom SolarEdge>, <wert car_state>, <wert allow_charging>, <wert amp_current>
)
## 2 ## decr
DOELSEIF (([SolarEdge:Bezug_Einspeiung:d] > -100)   
and ([GoECharger:car_state] == 2)
and ([GoECharger:allow_charging] == 1)
and ([GoECharger:amp_current] > 6))
  (
set GoECharger amp_current [GoECharger:amp_current:d:$1-1],
set steuer-doif-text_dummy doelseif #2, <wert vom SolarEdge>, <wert car_state>, <wert allow_charging>, <wert amp_current>
)
## 3 ## stop
DOELSEIF (([SolarEdge:Bezug_Einspeiung:d] > -10)       
and ([GoECharger:car_state] == 2)
and ([GoECharger:amp_current] == 6))
  (
set GoECharger allow_charging 0,
set steuer-doif-text_dummy doelseif #3, <wert vom SolarEdge>, <wert car_state>, <wert amp_current>
)
Dann kann man im Log nachher in einer Zeile erkennen, in welchem DOIF, DOELSEIF, ELSE Zweig er abgebogen ist und wie die Werte waren.

Hoffe das habe ich nicht zu wirr erklärt. Sonst frag gerne!

Gruß, Carsten

Hallo Carsten,

danke für den Tipp. Ich habe es eingerichtet, es logt mit und jetzt blicke ich noch weniger durch. Log habe ich wie folgt eingerichtet:
## 2 ## decr
DOELSEIF (([SolarEdge:Bezug_Einspeiung:d] > -100)    # alter wert 300
and ([GoECharger:car_state] == 2)
and ([GoECharger:allow_charging] == 1)
and ([GoECharger:amp_current] > 6))
  (set GoECharger amp_current [GoECharger:amp_current:d:$1-1],
   set du_debug_dummy doelseif 2, set du_debug_dummy SolarEdge [SolarEdge:Bezug_Einspeiung],
   set du_debug_dummy GoECharger:car_state [GoECharger:car_state],
   set du_debug_dummy GoECharger:allow_charging [GoECharger:allow_charging],
   set du_debug_dummy GoECharger:amp_current [GoECharger:amp_current])
Und jetzt das Logfile dazu:
2024-03-04_09:54:58 du_debug_dummy doelseif 2
2024-03-04_09:54:58 du_debug_dummy SolarEdge -94
2024-03-04_09:54:58 du_debug_dummy GoECharger:car_state 1
2024-03-04_09:54:58 du_debug_dummy GoECharger:allow_charging 1
2024-03-04_09:54:58 du_debug_dummy GoECharger:amp_current 6

Also eigentlich alle Werte wie ich sie erwartet habe nur interessiert ihn das 'Größer als' gar nicht. Das amp_current scheint aber als Zahl anzukommen sonst könnte er auch nicht ausrechnen das er es auf 5 setzen will. ???

VG
Christian

Ja, das mit amp_current ist merkwürdig. Auf Anhieb fällt mir dazu auch nichts ein.

Aber was mir auffällt, warum geht er überhaupt in den #2 Zweig?
Denn laut deinem Log ist car_state = 1 und du prüfst auf car_state == 2  :o
Ist dein Auto am Laden? Wenn ja, stimmt hier irgendwas auch nicht.

Aus der Doku:
1 = bereit - kein Fz.
2 = Fz. lädt
3 = Warte auf Fz.
4 = Ladung Ende - Fz. noch da

Ändert aber nicht so richtig was an dem Problem. Denn damit wären zwei Bedingungen nicht erfüllt und er geht trotzdem rein.

Rein auf blauen Dunst, weil mir sonst nichts mehr einfällt: Kannst du mal die mit "and" verknüpften Bedingungen in eine Zeile, statt in mehrere, schreiben?
Denn wenn fhem nur die erste Bedingung ([SolarEdge:Bezug_Einspeiung:d] > -100) prüfen würde, würde das das "Überspringen" der anderen Bedingungen erklären.

Gruß, Carsten

Da hast du vollkommen recht. Er ignoriert die AND Verknüpfung komplett. Alles in eine Zeile hat leider nix gebracht.

Und weil das noch nicht reicht um mich zu verwirren noch was Verrücktes: Ich habe zwei Go-E. Einen v2 und einen v3. Ich habe gerade mal den v2 verwendet. Schleife schaut gleich aus. Bei dem klappt alles.

Muss man bei der v3 irgendwas spezielles aktivieren?


VG
Christian

Bin mir nicht mehr ganz sicher ob es damit zusammenhängt, aber über die go-e App habe ich die lokale HTTP API v2 aktiviert.

Aber selbst wenn deswegen nicht die Aktualisierungen klappen, müssten doch die "and" Verknüpfungen funktionieren.

Vielleicht hat ja ein anderer noch eine Idee.

Gruß, Carsten

Danke dir. Http API v2 habe ich nun auch mal aktiviert. Ich schau mal was passiert sobald ich wieder lade.

VG
Christian

Das ist unnötig kompliziert, sowohl was die Abläufe beim Laden angeht, als auch betreffend die Verwendung von FHEM.

Wenn man ein FileLog hat, das auf events "KomischesDevice:IrresReading.*" lauscht, brauch man keineswegs einen Dummy "KomischesDevice" anzulegen. Es reicht vollkommen, in FHEM einen Befehl
trigger KomischesDevice IrresReading Tralalaabzusetzen, um diese Zeile in das FileLog zu bekommen.

LG

pah