go-echarger als mqtt-device - meine Konfig

[LR66]

Es gibt ein neues Modul für den go-eCharger inkl. Steuerung vielleicht könnt Ihr das auch mal testen?
https://forum.fhem.de/index.php/topic,110282.msg1043223.html#msg1043223
Vg Lutz

[Beta-User]

Hi LR66,

vielleicht magst du in deinem Thread auch einen Querverweis auf diese Lösung hier setzen?

Ich habe zwar keinen dieser Charger, aber wenn ich einen hätte, würde mich interessieren, wo die Unterschiede zwischen beiden Varianten liegen (außer, dass man für MQTT eben einen Broker braucht).

Grüße und viel Erfolg bei der Modul-Weiterentwicklung,

Beta-User

[LR66]

Ja sorry - der Unterschied ist, dass das Modul kein MQTT braucht, sondern direkt über LAN/WLAN auf die API des go-e zugreift. Ich mache einen Verweis auf die MQTT-Einbindung.
Danke für den Hinweis!

[rudolfkoenig]

Laeuft MQTT direkt, oder ueber ein node.js/etc Softwarestueck wie bei zigbee2mqtt?
Anders gefragt: kann man im go-eCharger MQTT wie in Tasmota aktivieren, und einen Broker angeben?

[Beta-User]

Ab firmware Version 030 ist es built-in, siehe letzter Punkt in https://go-e.co/app/api.pdf.

Man braucht also wirklich nur einen MQTT2_SERVER, dann lüppt das afaik. Und es scheint auch keine Unterschiede zu einer anderen API zu geben bzw. noch besser: man braucht nicht zu pollen, sondern ist gleich up-to-date.

Von daher würden mich auch die funktionalen Dinge interessieren, da hatte ich "auf Verdacht" manches in das template eingebaut, und das scheint auch zur vollen Zufriendenheit zu funktionieren - bei derzeit allerdings nur einem User, der via FHEM-statistics erkennbar ist...

[rudolfkoenig]

Der Vorteil des expliziten Moduls fuer den Benutzer ist (soweit ich es sehe) die Uebersetzung der Kuerzel in vestaendlichere Texte.

Es waere interessant einen Weg zu finden, diese Uebersetzung in beiden Modulen gemeinsam verwenden zu koennen.
Und ich meine nicht nur %goevar, sondern auch die anderen Werte/Pruefungen.

[Beta-User]

Das mit den Kürzeln ist korrekt, wobei jsonMap und userReadings dies teils bereits verbessern.

Stimme aber voll zu, dass es Sinn machen würde, im Bereich dieser recht neuen Geräte (Charger-Module allgemein) irgendwie eine einheitliche Nomenklatur zu etablieren. Es gibt ja bereits einige andere Wallboxes (min. Tesla?); vielleicht sollte man sich da zusammentun?

Will das aber nicht koordinieren, aber wer auch immer hier was sinnvolles vorschlägt: Ich versuch's jedenfalls an der Stelle hier gern umzusetzen!

[LR66]

Ihr lieben Spezi's,
meine bescheidene Meinung: für mich, als ein einfacher und nicht sehr Perl erfahrener User, ist es immer schön, ein vorhandenes Modul einfach mit define zu nutzen.
HttpMod o.ä. nehme ich nur, wenn es garnix gibt - da ist die Einstiegshürde zur Wiedereinarbeitung zu hoch.
Es ist toll, dass es viele Wege in Fhem gibt, aber manches ist dann eher für Erfahrenere. 

Also m.E. möglichst für jede Gerätesorte ein Modul und nicht komplizierter einzugebende Syntax.

Das werden dann natürlich viele Module, aber das macht ja einen weiteren Vorteil gegenüber anderen Automatisierungslösungen...
Viele Grüße, Lutz

[Beta-User]

Zum einen bin ich auch nicht der Held, was Perl angeht, zum anderen verstehe ich den Hinweis auf HTTPMOD nicht (hier ist es MQTT2_DEVICE) und zuletzt: Man muß nicht MQTT nutzen, aber wenn man es tut, ist das auch nicht wesentlich anders als ein define:

Du wendest ein attrTemplate an und gut ist... Das Device sieht so aus, wie es soll, hat (hoffentlich...) vernünftige setter und Readings und du mußt dich um nichts kümmern...

Das mit "hoffentlich" ist genau der Punkt: wenn der Vorschlagende (hier @blueberry63) was via MQTT einbindbares daherbringt, sind wir in der Gestaltung aller möglichen Dinge so frei, wie es kaum mehr freier geht (credits: Rudi!). Daher nimmt der Vorschlagende in der Regel erst mal das, was aus der Vorgabe des externen Geräts kommt. Das kann "gut" (im Sinne von sprechenden, häufig verwendeten standardisierten Begriffen) sein, meistens ist es das nicht in jedem Punkt, also müssen wir uns was einfallen lassen.

Mit den attrTemplate machen wir also genau das, was du innerhalb des Moduls machst: wir versuchen "good Reading names" zu generieren...

Das hat von der Herangehensweise her auch nichts mit Perl-Kenntnissen zu tun (die Umsetzung teils schon), oder übersehe ich was?

[Mitch]

Ich finde gerade mit httpmod und mqtt hat man zwei mächtige Tools.
Das ist mir (als Perl Depp) lieber wie ein Modul, da flexibler.

Mein go-eCharger ist über httpmod angebunden (mqtt hatte ich kurz mal angetestet).
Ich habe das stateformat genau so wie ich es haben möchte.

Ich nutze auch nie, trotzdem Danke für die tolle Arbeit, irgend welche Templates.
Ich machen mir immer alle Devices, wie ich es gerade brauche. Einige sind gleich, da gehe ich über Raw Definition und mache Copy-Paste.

Des weiteren schalte ich den Charger anhand von Dingen wie Auto vorhanden, angeschlossen, Personen anwesend und lasse mich per Push benachrichtigen.

Besser geht es nicht 

[Beta-User]

Gegen ein Modul ist absolut nichts einzuwenden...

@Mitch:
Du darfst gerne dein HTTPMOD-Device zeigen oder direkt selbst in ein attrTemplate umsetzen, das gibt's ja auch für diesen TYPE. Dann können wir das gerne für "easy-peasy-plug-and-play" auch auf diesem Weg allen anderen zur Verfügung stellen und haben ggf. auch die Möglichkeit, das wenigstens für dieses Gerät zu vereinheitlichen?

Super wäre, wenn das gleich zu den Tesla-Dingern passen würde (oder was es sonst noch so an möglichen Orientierungspunkten gibt...)?

[Mitch]

Nicht falsch verstehen, ich möchte niemand davon abhalten, ein Modul zu programmieren oder eines zu benutzen 

Gerne teile ich mein Device:

Code Auswählen Erweitern

defmod go_eCharger HTTPMOD http://192.168.0.81/status 60
attr go_eCharger userattr device_timeout set01IMap set01Name set01URL
attr go_eCharger DbLogInclude Charge_Netto,CostPerDay,CostTotal,Leistung_gesamt,nrg_0,Charge_Last,Charge_Cost,day
attr go_eCharger alias e-goCharger Mobil
attr go_eCharger event-on-change-reading car,alw,err,upd,fwv,tmp,nrg_.*,CostTotal,Cost_ID1,Cost_ID2,Charge_Already,Reichweite,Charge_Last,Charge_Cost,Charge_Netto,eto,eca,ecr
attr go_eCharger event-on-update-reading nrg_11,Leistung_gesamt,nrg_0
attr go_eCharger extractAllJSON 1
attr go_eCharger group Outlander
attr go_eCharger icon eco34
attr go_eCharger room Outlander
attr go_eCharger set01IMap 0:off, 1:on
attr go_eCharger set01Name Ladung
attr go_eCharger set01URL http://192.168.0.81:80/mqtt?payload=alw=$val
attr go_eCharger sortby 1
attr go_eCharger stateFormat {\
my $state = lc ReadingsVal($name, "car", "1");;\
my $devStateIcon = 'eco20.svg';;\
\
if ($state eq "2")\
{\
$devStateIcon = 'eco25.svg';;\
}\
\
if ($state eq "3")\
{\
$devStateIcon = 'eco26.svg';;\
}\
            \
if ($state eq "4")\
{\
$devStateIcon = 'eco24.svg';;\
}\
\
"<div><img width='32px' height='32px' src='/fhem/images/fhemSVG/" . $devStateIcon . "'>" . sprintf(\
        "&nbsp;;&nbsp;;%s - %s<br/>%s<br/>Strom: %d A - aktuell: %d A, %.1f kW<br/>Ladung Total: %.1f kWh/%.2f € - Ladung ID1: %.1f kWh/%.2f €, ID2: %.1f kWh/%.2f €<br/><br/>Bereits geladen: %.1f kWh entspricht ca. %s km<br/>Letzte Ladung: %.1f kWh/%.2f € - Netto: %.1f kWh<br/><br/>Temperatur: %d °C<br>Firmwareversion: %s %s",\
ReadingsVal($name,"car",0)==1?"Ladestation bereit, kein Fahrzeug":\
ReadingsVal($name,"car",0)==2?"Fahrzeug lädt":\
ReadingsVal($name,"car",0)==3?"Warte auf Fahrzeug":\
ReadingsVal($name,"car",0)==4?"Ladung beendet, Fahrzeug noch verbunden":"unknown",\
ReadingsVal($name,"alw",0)==1?"Ladung freigegeben":\
ReadingsVal($name,"alw",0)==0?"Ladung nicht freigegeben":"",\
ReadingsVal($name,"err",0)==1?"Fehler RCCB (Fehlerstromschutzschalter)":\
ReadingsVal($name,"err",0)==3?"Fehler PHASE (Phasenstörung)":\
ReadingsVal($name,"err",0)==8?"Fehler NO_GROUND (Erdungserkennung)":\
ReadingsVal($name,"err",0)==10?"Fehler INTERNAL (sonstiges)":"",\
ReadingsVal($name,"amp",0),\
ReadingsVal($name,"nrg_4",0)/10,\
ReadingsVal($name,"nrg_7",0)/10,\
ReadingsVal($name,"eto",0)/10,\
ReadingsVal($name,"CostTotal",0),\
ReadingsVal($name,"eca",0)/10,\
ReadingsVal($name,"Cost_ID1",0),\
ReadingsVal($name,"ecr",0)/10,\
ReadingsVal($name,"Cost_ID2",0),\
ReadingsVal($name,"Charge_Already",0),\
ReadingsVal($name,"Reichweite",0),\
ReadingsVal($name,"Charge_Last",0),\
ReadingsVal($name,"Charge_Cost",0),\
ReadingsVal($name,"Charge_Netto",0),\
ReadingsVal($name,"tmp",0),\
ReadingsVal($name,"fwv",0),\
ReadingsVal($name,"upd",0)==1?" - Update verfügbar!":"",\
)}
attr go_eCharger userReadings CostPerDay, CostTotal {ReadingsVal($name,"eto","")* 0.0292}, Cost_ID1 {ReadingsVal($name,"eca","")* 0.0292}, Cost_ID2 {ReadingsVal($name,"ecr","")* 0.0292}, Leistung_gesamt {ReadingsVal($name,"nrg_11","")*10}, summe monotonic {ReadingsNum($name,"eto",0)/10}, Charge_Already {ReadingsNum($name,"eto",0) / 10 - ReadingsNum($name,"Charge_Start",0)}, Reichweite {ReadingsVal($name,"Charge_Already","")*5.56}
attr go_eCharger verbose 0
attr go_eCharger webCmd Ladung

Ist halt auf meine Bedürfnisse zugeschnitten.

Anbei noch ein Screenshot vom Device und einer readingsGroup.

Dazu gibt es dann noch einen DOIF:

Code Auswählen Erweitern

defmod go_echarger.Aktor DOIF ([go_eCharger:car] eq "2")(set Pushover msg 'FHEM' 'go-eCharger: Fahrzeug lädt',{outiCostStart()})\
DOELSEIF ([go_eCharger:car] eq "3" and [Anwesenheit] eq "Zuhause")(set Pushover msg 'FHEM' 'go-eCharger: Warte auf Fahrzeug - Ladung automatisch aktiviert',set go_eCharger Ladung on)\
DOELSEIF ([go_eCharger:car] eq "3")(set Pushover msg 'FHEM' 'go-eCharger: Warte auf Fahrzeug')\
DOELSEIF ([go_eCharger:car] eq "4")({outiCostCalc()})\
DOELSEIF ([go_eCharger:car] eq "1")(set go_eCharger Ladung off)\
DOELSEIF ([go_eCharger:err] eq "2")(set Pushover msg 'FHEM' 'go-eCharger: Fehler RCCB - Fehlerstromschutzschalter')\
DOELSEIF ([go_eCharger:err] eq "3")(set Pushover msg 'FHEM' 'go-eCharger: Fehler PHASE - Phasenstörung')\
DOELSEIF ([go_eCharger:err] eq "8")(set Pushover msg 'FHEM' 'go-eCharger: Fehler NO_GROUND - Erdungserkennung')\
DOELSEIF ([go_eCharger:err] eq "10")(set Pushover msg 'FHEM' 'go-eCharger: Fehler INTERNAL')
attr go_echarger.Aktor DbLogExclude .*
attr go_echarger.Aktor event-on-change-reading .*

Berechnungen habe ich in die myUtils ausgelagert:

Code Auswählen Erweitern

sub outiCostCalc() {
  my $eto_stop=(ReadingsNum("go_eCharger","eto",0)/10);
  my $eto_start=(ReadingsNum("go_eCharger","Charge_Start",0));
  my $charge=$eto_stop-$eto_start;
  my $cost=($charge*0.23);
  my $netto=($charge-(($charge/100)*5));
  fhem ("setreading go_eCharger Charge_Last $charge");
  fhem ("setreading go_eCharger Charge_Cost $cost");
  fhem ("setreading go_eCharger Charge_Netto $netto");
  fhem ("setreading go_eCharger Charge_Start $eto_stop");
  fhem ("set Pushover msg 'FHEM' 'go-eCharger: Ladung beendet - Fahrzeug noch verbunden -> $charge kWh / $cost €' ");
}

[Beta-User]

Vorerst mal Danke!

Sieht nach viel Arbeit aus, das ggf. zu vertemplaten. Mal schauen, ob und wann ich ggf. dazu komme oder ob sich da jemand anderes ranwagt. Für Interessierte: Es gibt die Möglichkeit, speziellen myUtils-Code zu einem template auch aus dem svn nachzuladen... Würde hier vermutlich Sinn machen.

@Rudi: Kannst du das abtrennen und ggf. unter anderem Titel nach "sonstiges" (hoffe, das ist das richtige für HTTPMOD) verschieben und einen link dahin hier einfügen?

(Wenn ich mich manchmal noch besser zusammenreisen könnte, wäre es evtl. eine Idee, entsprechende Moderationsrechte anzufragen...).

[rudolfkoenig]

@Mitch: dein stateFormat und userReadings duerfte doch ohne Aenderung auch bei der MQTT2 Variante funktionieren, da in beiden Faellen das gleiche JSON vermutlich identisch nach Readings konvertiert wird.
Aus welchem Grund wird event-on-change-reading gesetzt?

@Beta-User: ich kann zwar abtrennen, oder dir Moderatorenrechte geben (melde Dich explizit), aber da diese Attribute auch bei MQTT2 verwendbar sind, finde ich den Beitrag hier nicht off-topic

[Beta-User]

@Rudi: auch wieder wahr (den Rest bei Gelegenheit)...

Das mit event-on dürfte mit dem Pollen zu tun haben. Es wird regelmäßig aktualisiert, aber tendenziell gibt es keine "neuen Meßwerte", sondern eben nur die unveränderten Zustände...

Da hier jsonMap eingesetzt wird, sind die Readingnamen wohl andere, aber man könnte das übertragen. Und es gibt afaik auch bei HTTPMOD erweiterte Möglichkeiten, Readingnamen umzubenennen. Nur: ich bin dafür der falsche, und scheinbar weiß das auch nur eine Minderheit der User...

Weil ich HTTPMOD selbst kaum nutze und mich zu wenig da auskenne, suche ich ja so dringlich nach einem "ersten Mann", der das attrTemplate-Thema für HTTPMOD (mit) übernimmt. Das wäre zielführender, um da das Maximum rauszuholen (und jedenfalls nach meiner Wahrnehmung) auf einen vergleichbar guten Stand zu mqtt2.template zu kommen...