Modul für Steuerung einer Go-ECharger Wallbox [= go-e oder go-echarger]

[didi-fritz]

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

[isy]

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

[Chris_XXX]

Hallo zusammen,
ich habe mal eine Frage wie ihr euer DoIF gemacht habt. Bei mir will es einfach nicht abschalten:

Code Auswählen Erweitern

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

[Prof. Dr. Peter Henning]

Tippfehler "Einspeiung"?

pah

[Chris_XXX]

Zu meiner Schande muss ich gestehen das Reading heißt tatsächlich so. Also ja: Falsch geschrieben aber nicht mein Fehler hier.

[Eckat]

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 

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

[Chris_XXX]

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

[Eckat]

Debugging kann ich meine Lösung nicht nennen. 

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[Chris_XXX]

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:

Code Auswählen Erweitern

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

[Eckat]

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

[Chris_XXX]

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

[Eckat]

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

[Chris_XXX]

Danke dir. Http API v2 habe ich nun auch mal aktiviert. Ich schau mal was passiert sobald ich wieder lade.

VG
Christian

[Prof. Dr. Peter Henning]

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

Code Auswählen Erweitern

trigger KomischesDevice IrresReading Tralalaabzusetzen, um diese Zeile in das FileLog zu bekommen.

LG

pah