go-echarger als mqtt-device - meine Konfig

[blueberry63]

Hallo,

ich wollte Euch meine Konfiguration des go-echarger als MQTT2_DEVICE inkl. dem Schalten von "Laden: EIN/AUS" vorstellen:

Code Auswählen Erweitern


define MQTT2_goecharger MQTT2_DEVICE go_eCharger_xxxxxx_yy
attr MQTT2_goecharger DbLogExclude .*
attr MQTT2_goecharger IODev mqtt2srv
attr MQTT2_goecharger event-on-change-reading .*
attr MQTT2_goecharger readingList go-eCharger/xxxxxx/status:.* { json2nameValue($EVENT) }\
go-eCharger/xxxxxx/ip:.* { json2nameValue($EVENT) }
attr MQTT2_goecharger room Aussen,Energie,MQTT2_DEVICE
attr MQTT2_goecharger setList Laden_EIN:noArg go-eCharger/xxxxxx/cmd/req alw=1\\
Laden_AUS:noArg go-eCharger/xxxxxx/cmd/req alw=0\

attr MQTT2_goecharger stateFormat Status: Stecker_Kabel P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr MQTT2_goecharger userReadings Stecker_Kabel  { if(ReadingsVal("MQTT2_goecharger","car","") eq "1") { return "Bereit" } elsif\
(ReadingsVal("MQTT2_goecharger","car","") eq "2") { return "Fzg laedt" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "3") { return "Warte auf Fzg" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "4") { return "Laden beendet" }\
else { return -1 } }, temperature { ReadingsVal("MQTT2_goecharger","tmp",0) }, energy_total { ReadingsVal("MQTT2_goecharger","eto",0)*0.1 }, energy_akt { ReadingsVal("
MQTT2_goecharger","dws",0)*2.77 }


Weitere Schaltmöglichkeiten können in der API-Beschreibung auf der Herstellerseite nachgelesen werden.

Gruß
Blueberry63

[Beta-User]

Danke für's teilen.

Habe mal versucht, daraus ein attrTemplate zu basteln, feedback wäre willkommen.
Wäre nett, wenn ich kurzfristig Rückmeldung dazu bekäme, sonst kommt es "auf Verdacht" demnächst per update.

(Zum Testen kannst du eine Kopie deines Devices nehmen, das template hat teilweise etwas andere Benennungen usw.):

Code Auswählen Erweitern

#source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924
name:go_eCharger
filter:TYPE=MQTT2_DEVICE
desc:See source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924 for details.
order:W_02
par:BASE_ID;BASE_ID typically is go-eCharger;{ AttrVal("DEVICE","readingList","") =~ m,(go-eCharger)[/][^/]+[/].*:, ? $1 : undef }
par:DEVNAME;Device name as configured;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]([^/]+)[/].*:, ? $1 : undef }
par:ICON;ICON as set, defaults to mqtt;{ AttrVal("DEVICE","icon","mqtt") }
attr DEVICE icon ICON
attr DEVICE event-on-change-reading .*
attr DEVICE readingList BASE_ID/DEVNAME/status:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/ip:.* { json2nameValue($EVENT) }
attr DEVICE setList Charge_ON:noArg BASE_ID/DEVNAME/cmd/req alw=1\
  Charge_OFF:noArg BASE_ID/DEVNAME/cmd/req alw=0
attr DEVICE stateFormat Status: charger_state P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr DEVICE userReadings charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none"  => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished");; $rets{$val}}, temperature:temp.* { ReadingsVal($name,"tmp",0) }, energy_total:eto.* { ReadingsVal($name,"eto",0)*0.1 }, energy_akt:dws.* { ReadingsVal($name,"dws",0)*2.77 }
attr DEVICE model go_eCharger

Gruß, Beta-User

[blueberry63]

Hallo Beta-User,

danke für Deine Mühe. Ich kann frühestens morgen versuchen, das Template zu testen. Ich habe allerdings noch nie mit Templates gearbeitet  . Wie kann ich das Testen?

Und noch etwas: Eine nützliche Schaltfunktion ist wohl das Einstellen der Ampere-Zahl und das wollte ich noch einbauen, hatte aber noch keine Zeit.

Gruß
Blueberry63

[Beta-User]

Hallo,

Danke für die schnelle Antwort.

Da sollte auch der setter für den Ladestrom funktionieren (ob die wählbaren Werte sinnvoll sind, kann ich aber nicht sagen...):

Code Auswählen Erweitern

#source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924
name:go_eCharger
filter:TYPE=MQTT2_DEVICE
desc:See source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924 for details.
order:W_02
par:BASE_ID;BASE_ID typically is go-eCharger;{ AttrVal("DEVICE","readingList","") =~ m,(go-eCharger)[/][^/]+[/].*:, ? $1 : undef }
par:DEVNAME;Device name as configured;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]([^/]+)[/].*:, ? $1 : undef }
par:ICON;ICON as set, defaults to mqtt;{ AttrVal("DEVICE","icon","mqtt") }
attr DEVICE icon ICON
attr DEVICE event-on-change-reading .*
attr DEVICE readingList BASE_ID/DEVNAME/status:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/ip:.* { json2nameValue($EVENT) }
attr DEVICE setList Charge_ON:noArg BASE_ID/DEVNAME/cmd/req alw=1\
  Charge_OFF:noArg BASE_ID/DEVNAME/cmd/req alw=0\
  amp:selectnumbers,1,1,22,1,lin BASE_ID/DEVNAME/cmd/req alw=$EVTPART1
attr DEVICE stateFormat Status: charger_state P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr DEVICE userReadings charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none"  => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished");; $rets{$val}}, temperature:temp.* { ReadingsVal($name,"tmp",0) }, energy_total:eto.* { ReadingsVal($name,"eto",0)*0.1 }, energy_akt:dws.* { ReadingsVal($name,"dws",0)*2.77 }
attr DEVICE model go_eCharger

Zum Testen findest du unter https://wiki.fhem.de/wiki/AttrTemplate#Eigene_Templates_entwickeln eine kurze Anleitung mit weiteren Links.

Grüße und viel Spaß damit!

EDIT: widget für amp geändert.

[blueberry63]

Ich habe das Template eingebunden, aber das Topic stimmt nicht:

Beispiel:
Mit Template (falsch): go-eCharger/go-eCharger/007353/status:.* { json2nameValue($EVENT) }
ohne Template (richtig): go-eCharger/007353/status:.* { json2nameValue($EVENT) }

Bei setlist ist die Zeile für "amp" falsch:
Falsch:   amp:selectnumbers,1,1,22,1,lin go-eCharger/007353/cmd/req alw=$EVTPART1
Richtig:   amp:selectnumbers,1,1,22,1,lin go-eCharger/007353/cmd/req amp=$EVTPART1

Mit den entsprechenden Korrekturen sieht es aber gut aus!!!

Gruß
Blueberry63

[Beta-User]

Thx, habe die zwei Dinge (hoffentlich) noch repariert, das kommt dann ab morgen früh via update .

[blueberry63]

Hallo Beta-User,

wegen dem Mix der Readings durch das Kopieren des Gerätes habe ich etwas Wesentliches übersehen: das UserReading für "charge_state" funktioniert nicht, ich finde aber den Fehler nicht. Fakt ist, dass das Reading nicht angelegt wird:

Code Auswählen Erweitern

charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none"  => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished");; $rets{$val}},
temperature:[b]temp[/b].* { ReadingsVal($name,"tmp",0) }

Das Reading für die Temperatur hat auch noch einen Fehler: richtig ist "temperature:tmp.* { ReadingsVal($name,"tmp",0) }"

Gruß
Blueberry63

[Beta-User]

Thx für die Info.

Hatte das von woanders geklaut und mit temp wohl nicht richtig hingesehen...

So sollte es klappen:

Code Auswählen Erweitern


charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none"  => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished",);; $rets{$val}}, temperature:tmp.* { ReadingsVal($name,"tmp",0) }, energy_total:eto.* { ReadingsVal($name,"eto",0)*0.1 }, energy_akt:dws.* { ReadingsVal($name,"dws",0)*2.77 }

[blueberry63]

"temperature" wird jetzt angelegt, aber "charge_state" noch nicht. Ich sehe aber auch keinen Unterschied zu vorher?

[Beta-User]

Na ja, ich hatte das erst mal (auch wg. tmp) geändert, dann an einem dummy-Device ausgetestet und dabei nochmal verändert (bzw. versucht, wieder auf das Minimum zu kommen). Am Dummy hat das funktioniert, wenn ich z.B. für car eine 1 oder 2 gesetzt habe...

Wird/wurde denn das Reading "car" bei dir aktualisiert?

[blueberry63]

Hallo Beta-User,

mein Fehler beim Testen: es funktioniert so, wie Du es "gecoded" hast.

Dafür hätte ich noch ein UserReading für das Sperren/Entsperren des Gerätes:

Code Auswählen Erweitern

device_state:alw.* { my $val = ReadingsVal($name,"alw","none");; my %rets = ("none"  => "-1","0" => "Locked","1" => "Open",);; $rets{$val}},

"Setlist" müsste logischerweise etwa so aussehen, da das Sperren/Entsperren des Gerätes zunächst nichts mit dem Ladevorgang zu tun hat:

Code Auswählen Erweitern


Device_OPEN:noArg go-eCharger/007353/cmd/req alw=1\
Device_LOCK:noArg go-eCharger/007353/cmd/req alw=0\
Ampere:selectnumbers,1,1,22,1,lin go-eCharger/007353/cmd/req amp=$EVTPART1


Gruß
Blueberry63

[Beta-User]

Danke vorab für die Rückmeldung zu device_state.

Was alw angeht, neige ich (ohne das ausgetestet zu haben, daher vorläufig...) dazu, das über das reading abzuwickeln und den Zustand "nur" über ein Icon zu visualisieren:
setList-Eintrag:

Code Auswählen Erweitern

alw:0,1 go-eCharger/007353/cmd/req alw=$EVTPART1\

stateFormat und devStateIcon:

Code Auswählen Erweitern

attr DEVICE stateFormat Status: charger_state \
ALW:alw\
P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr DEVICE devStateIcon ALW.1:status_open:alw+0 ALW.0:status_locked:alw+1
Auch die Bezeichnung Ampere ist evtl. ungünstig, sollte tendenziell auch zu amp werden, oder wir setzen JSONMAP ein, dann können beide Readings "schönere" Namen bekommen?
(Einfaches Beispiel wäre in zigbee2mqtt_ContactSensor zu finden).

[blueberry63]

Code Auswählen Erweitern

attr DEVICE devStateIcon ALW.1:status_open:alw+0 ALW.0:status_locked:alw+1

Ich habe mal Deinen Vorschlag für devStateIcon ausprobiert, aber es funktioniert irgendwie nicht: wenn ich es richtig verstanden habe, sollte im Status ein wechselndes Icon - je nach dem Wert von "alw" - erscheinen. Bei mir wird aber nut "ALW: 1" angezeigt.

Ich habe es auch schon mit anderen Icons ausprobiert, aber ohne Erfolg.

Oder habe ich hier etwas falsch verstanden?

Gruß
Blueberry63

[Beta-User]

Da ist entweder ein Leerzeichen zu viel oder je ein Punkt zu wenig....

[blueberry63]

wenn das "stateFormat" nur "ALW alw" ist, dann funktioniert devStateIcon, aber sobald man mehrere Werte in "stateFormat" packt, dann wird kein Icon angezeigt.

Aber das ist ja auch irgendwie OT. Ich werde mal an andere Stelle in die Runde fragen, wie man mehrere Werte+Icons ins "stateFormat" bringt. Das kann ich für andere Geräte auch gebrauchen.

Gruß
Blueberry63   

[Beta-User]

Der Trick ist: du mußt in stateFormat nach jedem Wert, der in ein Icon umgewandelt werden soll, auch einen Zeilenumbruch machen. In jeder Zeile darf nur das stehen, was der Regex für das jeweilige Icon entspricht. Kann es sein, dass du das beim Kopieren meiner Vorschläge nicht recht wahrgenommen hattest?

Und dann war da

Bei mir wird aber nut "ALW: 1" angezeigt.

Das ist _mit_ einem (bei meinem Code noch nicht vorhandenen) Leerzeichen, dann mußt du noch einen weiteren dot (=beliebiges Zeichen) in die regexe einfügen, oder den wieder entfernen.

[blueberry63]

Der Trick ist: du mußt in stateFormat nach jedem Wert, der in ein Icon umgewandelt werden soll, auch einen Zeilenumbruch machen.

...das habe ich noch nicht gewuß! Hätte mir einige Nerven gerettet 

DANKE!

[Beta-User]

Danke  für die Rückmeldung, hatte es schon "auf Verdacht" eingecheckt .

Auch die Bezeichnung Ampere ist evtl. ungünstig, sollte tendenziell auch zu amp werden, oder wir setzen JSONMAP ein, dann können beide Readings "schönere" Namen bekommen?
(Einfaches Beispiel wäre in zigbee2mqtt_ContactSensor zu finden).

Willst du dazu noch was sagen?
Mit JSONMAP könnte man amp zu Ampere umbenennen und alw auch etwas "sprechender" benennen, falls gewünscht. MMn. wäre das das "i"-Tüpfelchen...

[blueberry63]

Wenn Du die Readings umbennen kannst, dann würde ich
- amp zu "Ampere" umbennen (so ist es auch in der App genannt)
- alw zu "Aktivierung" umbennen ("")

[Beta-User]

"Ich" kann schon, aber das war eigentlich als kleine Aufgabe gedacht...
Aber als Schubser dann halt ein Auszug aus readingList:

Code Auswählen Erweitern

go-eCharger/007353/status:.* { json2nameValue($EVENT,'',$JSONMAP) }
Das notwendige Umbenennungs-Attribut:

Code Auswählen Erweitern

attr DEVICE jsonMap alw:Aktivierung amp:Ampere
Kannst du das Testen (die Namen müssen in setList und im jsonMap zueinander passen) und dann als template-Code wieder komplett liefern, bitte?

[blueberry63]

Hallo Beta-User,

im Anhang ist das Template mit den entsprechenden Änderungen. Bitte prüfe nochmal auf Syntax-Fehler 

Gruß
Blueberry63

[Beta-User]

Hi blueberry63,

habe nochmal etwas dran rumgeschraubt, bitte (ggf. mit einer Kopie deines aktuellen Geräts) testen:

Code Auswählen Erweitern

#source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924
name:go_eCharger
filter:TYPE=MQTT2_DEVICE
desc:See source post: https://forum.fhem.de/index.php/topic,105457.msg993924.html#msg993924 for details. For complete MQTT-API see https://go-e.co/app/api.pdf
order:W_02
par:BASE_ID;BASE_ID typically is go-eCharger;{ AttrVal("DEVICE","readingList","") =~ m,(go-eCharger)[/][^/]+[/].*:, ? $1 : undef }
par:SERIAL;Serial number;{ AttrVal("DEVICE","readingList","") =~ m,go-eCharger[/]([^/]+)[/].*:, ? $1 : undef }
par:ICON;ICON as set, defaults to mqtt;{ AttrVal("DEVICE","icon","mqtt") }
attr DEVICE icon ICON
attr DEVICE event-on-change-reading .*
attr DEVICE readingList BASE_ID/SERIAL/status:.* { json2nameValue($EVENT,'';$JSONMAP) }\
  BASE_ID/SERIAL/ip:.* { json2nameValue($EVENT) }
attr DEVICE setList Activation:0,1 BASE_ID/SERIAL/cmd/req alw=$EVTPART1\
  Ampere:selectnumbers,1,1,22,1,lin BASE_ID/SERIAL/cmd/req amp=$EVTPART1
attr DEVICE jsonMap alw:Activation amp:Ampere tmp:temperature
attr DEVICE stateFormat Status: charger_state \
ALW:Activation\
P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr DEVICE devStateIcon ALW.1:status_open:Activation+0 ALW.0:status_locked:Activation+1
attr DEVICE userReadings charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none" => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished",);; $rets{$val}}, energy_total:eto.* { ReadingsVal($name,"eto",0)*0.1 }, energy_akt:dws.* { ReadingsVal($name,"dws",0)*2.77 }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model go_eCharger

[blueberry63]

Die "Spannungen" würde ich aus dem stateFormat rausnehmen (V1: nrg_1 V2: nrg_2 V3: nrg_3). Das ist wohl doch nicht so interessant. Ich hatte es mal eingebaut, weil ich mangels Auto (Lieferverzögerung) noch keine anderen Werte geliefert bekomme.

[Beta-User]

Kein Ding. Rest funktioniert (und ist soweit auch vollständig)?

[blueberry63]

Ich kann erst heute Abend testen, melde mich.

[blueberry63]

Das ist zwar jetzt OT, aber ich habe Probleme mit dem Update des Templates. Ich habe die Datei "goecharger.template" in "/opt/fhem/FHEM/lib/AttrTemplate" überschrieben und mit "{ AttrTemplate_Initialize() }" neu eingelesen. Anschließend werden aber nach Benutzung des Templates beim Device die alten Attribute gesetzt (das fällt mir sofort auf, da ich die 3 Spannungen aus dem Template entfernt habe).

Nach Aufruf von "{ AttrTemplate_Initialize() }" kommt folgende Ausgabe, ist das normal?

Code Auswählen Erweitern


<script type="text/javascript">
    $(document).ready(function() {
      $("select.set").change(attrAct);
      function
      attrAct(){
        if($("select.set").val() == "attrTemplate") {
          $('<div id="attrTemplateHelp" class="makeTable help"></div>')
                .insertBefore("div.makeTable.internals");
          $("select.select_widget[informid$=attrTemplate]").change(function(){
            var cmd = "{AttrTemplate_Help('"+$(this).val()+"')}";
            FW_cmd(FW_root+"?cmd="+cmd+"&XHR=1", function(ret) {
              $("div#attrTemplateHelp").html(ret);
            });
          });
        } else {
          $("div#attrTemplateHelp").remove();
        }
      }
      attrAct();
    });
  </script>
  <script type="text/javascript">
    $(document).ready(function() {
      $("select.set").change(attrAct);
      function
      attrAct(){
        if($("select.set").val() == "attrTemplate") {
          $('<div id="attrTemplateHelp" class="makeTable help"></div>')
                .insertBefore("div.makeTable.internals");
          $("select.select_widget[informid$=attrTemplate]").change(function(){
            var cmd = "{AttrTemplate_Help('"+$(this).val()+"')}";
            FW_cmd(FW_root+"?cmd="+cmd+"&XHR=1", function(ret) {
              $("div#attrTemplateHelp").html(ret);
            });
          });
        } else {
          $("div#attrTemplateHelp").remove();
        }
      }
      attrAct();
    });
  </script>


Kann es sein, dass er 2 Template-Inhalte hat???

[Beta-User]

UPS, sorry, ist in der Vorversion im svn...

[blueberry63]

So, ich hatte mal wieder Zeit zum Testen. Meine eigene Template-Datei habe ich gelöscht, "{ AttrTemplate_Initialize() }" ausgeführt und dann das Template angewendet. Danach kommen folgende Meldungen:

Code Auswählen Erweitern


Replace
BASE_ID: with the BASE_ID typically is go-eCharger
SERIAL: with the Serial number


Code Auswählen Erweitern


syntax error at (eval 1340482) line 1, at EOF
syntax error at (eval 1340482) line 1, near "$JSONMAP) "


Gruß
Blueberry63

[Beta-User]

Moin,

habe grade ein update dazu ins svn geschubst.

Die ersten Meldungen kamen vermutlich davon, dass die readingList nicht vorhanden war (?), für die beiden anderen war ein ";" statt "," verantwortlich... Sorry.

Jetzt (bzw. ab 7:50 Uhr) sollte es aber passen.

Gruß, Beta-User

[blueberry63]

Jetzt sieht es gut aus  . Ich denke, das kann man so lassen. Falls ich im Betrieb sinnvollere Ausgaben finde, melde ich mich.

Gruß
Blueberry63

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

[Mitch]

@Rudi: wie Beta-User schreibt, ich hole alle 60 sek. die Werte und will nur ein Event, falls sich etwas geändert hat.

Wäre es denn grundsätzlich von Vorteil auf MQTT zu gehen?

[Beta-User]

Hmm, schwierig. Tendenziell würde ich annehmen, dass MQTT
- leichtgewichtiger ist und gut programmierte Geräte den Verkehr auf Änderungen beschränken. Klares Plus.
- Dann ist MQTT als Kommunikationsprotokoll gemacht für "schwierige Fälle" und per se weniger anfällig gegen Störungen, Verbindungsabbrüche etc. (ob MQTT2_SERVER das alles in vollem Umfang kann, müßte Rudi beantworten, gehe aber mal davon aus, dass die Grundzüge jedenfalls passen).

Es ist halt "was anderes" und von daher müßtest du dich in die "Spezialitäten" etwas eindenken, was aber kein Hexenwerk ist, v.a. dann nicht, wenn du sowieso MQTT irgendwo anders verwendest/verwenden willst. (Das wird immer mehr, kommt also früher oder später vermutlich sowieso).

Ansonsten vermutlich: Geschmackssache...

[Mitch]

MQTT ist kein Neuland 

Wie gesagt, hatte auch den Charger schon über MQTT angebunden, war sogar Betatester der FW.
Was mit nicht gefallen hat, es gibt keine Einstellungsmöglichkeiten.
Das Ding schickt im Sekundentakt Werte. (Das ist auch etwas, was mit beim ebusd nicht gefällt, da kann man aber wenigstens nur geänderte Werte schicken lassen).

Vielleicht schau ich mir es nochmal an.
Wie du schreibst, es wird immer mehr in die Richtung gehen.

[rudolfkoenig]

Als weitere Alternative haetten wir noch JsonMod, fuer den Fall, dass man noch nicht unsicher genug ist

[Beta-User]

...deswegen hatte ich geschrieben: "gut programmierte Geräte schicken...". Das ständige Aktualisieren beliebiger Werte ist iMo ein bug, den man dem Hersteller ggf. um die Ohren hauen sollte (bitte nicht betreffend ebus, da reicht vermutlich ein ganz höflicher Hinweis an den wirklich netten Autor, der sich auch erst in das Thema hat eindenken müssen )...

In der MQTT-Welt gibt es einen Mechanismus: "last will". Nutzt der Programmierer des Geräts den, braucht er nicht ständig alles mögliche in die Welt brüllen, nur um zu sagen "bin noch da" und kann das Prinzip der Datenvermeidung besser beherzigen... (sonst brauchen wir alle irgendwann einen Mainframe-Rechner, nur um das bißchen Hausautomatisierung abzufackeln .

Als weitere Alternative haetten wir noch JsonMod, fuer den Fall, dass man noch nicht unsicher genug ist

Jup, aber da gibt es noch keinen Freiwilligen für attrTemplates (und afaik auch noch nicht die Funktionalität?).

[Mitch]

...bitte nicht betreffend ebus, da reicht vermutlich ein ganz höflicher Hinweis an den wirklich netten Autor, der sich auch erst in das Thema hat eindenken müssen )...

Ich weis, hatte mit ihm schon ein paar mal Kontakt. 

[Beta-User]

Bei mir waren es nicht ein paar Mal, sondern nur eine kurze Phase, als es um die Entwicklung der attrTemplate zum ebus an sich ging. Da waren wir alle noch am Üben , aber der Kontakt war bei allen Widrigkeiten (ich keine Ahnung von den Geräten und deren Funktion und nur ein diffuses Gefühl, wohin das gehen soll, er hat sich da geduldig Zeit genommen, das irgendwie zu errätseln, was ich denn vielleicht meinen könnte...).

[Waldmensch]

Auch wenn im Thread länger nichts geschrieben wurde, vielleicht kann jemand helfen. Ich habe ein MQTT device angelegt, welches das JSON Objekt zuverässig vom Mosquito bekommt. Wie gewöhlich bei meinen Tasmota Devices, würde ich nun gern mit expandJSON die Readings erzeugen. Bei Tasmota funktioniert das zuverlässig. Beim go-E passiert gar nichts. Ich habe bei raw DEV mal angehangen, und eine Message, die alle 5 Sekunden im Eventmonitor kommt. Sieht jemand einen Fehler? Wie gesagt, das MQTT device bekommt alle 5 Sekunden ein neues Reading DATA, nur expandJSON scheint nichts zu tun.


Device:

Code Auswählen Erweitern

defmod stadtweg.GoE MQTT_DEVICE
attr stadtweg.GoE DbLogExclude .*
attr stadtweg.GoE IODev myBroker
attr stadtweg.GoE event-on-update-reading .*
attr stadtweg.GoE room MQTT
attr stadtweg.GoE subscribeReading_DATA go-eCharger/xxxxxxxx/status

expandJson

Code Auswählen Erweitern

defmod ejDATA expandJSON stadtweg.GoE:DATA:.\{.*\}

Eventmonitor:

Code Auswählen Erweitern

2021-05-21 09:30:04 MQTT_DEVICE stadtweg.GoE DATA: {"version":"B","tme":"2105210930","rbc":"11","rbt":"902601139","car":"2","amp":"6","err":"0","ast":"0","alw":"1","stp":"0","cbl":"20","pha":"63","tmp":"0","tma":[18.13,17.63,17.50,18.00],"amt":"32","dws":"28923","dwo":"0","adi":"1","uby":"0","eto":"1230","wst":"3","txi":"2","nrg":[221,222,213,1,60,61,60,13,13,12,0,401,100,100,100,2],"fwv":"040.0","sse":"023547","wss":"iot24","wke":"****************","wen":"1","cdi":"0","tof":"101","tds":"1","lbr":"49","aho":"3","afi":"7","azo":"0","ama":"16","al1":"10","al2":"16","al3":"20","al4":"24","al5":"32","cid":"255","cch":"65535","cfi":"65280","lse":"0","ust":"0","wak":"","r1x":"2","dto":"0","nmo":"0","sch":"AAAAAAAAAAAAAAAA","sdp":"0","eca":"0","ecr":"0","ecd":"0","ec4":"0","ec5":"0","ec6":"0","ec7":"0","ec8":"0","ec9":"0","ec1":"0","rca":"04C8727A","rcr":"","rcd":"","rc4":"","rc5":"","rc6":"","rc7":"","rc8":"","rc9":"","rc1":"","rna":"","rnm":"","rne":"","rn4":"","rn5":"","rn6":"","rn7":"","rn8":"","rn9":"","rn1":"","loe":0,"lot":0,"lom":0,"lop":0,"log":"","lon":0,"lof":0,"loa":0,"lch":0}                                               


[Beta-User]

[Spekulationsmodus ein]
Probleme mit den (völlig überflüssigen! und) leeren json-Keys?

Falls es daran liegt und du bei MQTT-"classic" bleiben willst: nimm MQTT_GENERIC_BRIDGE (mit "expression", das erzeugt beim Auspacken auch nur eine Event-loop) oder notfalls (!) ein notify) und ein dummy und packe den JSON mit json2nameValue() aus, das sollte das "können".

Besser/einfacher wäre vermutlich ein MQTT2_CLIENT+M2D...
[Spekulationsmodus aus]

Ergänzend:

Code Auswählen Erweitern

attr stadtweg.GoE event-on-update-reading .*ist mAn. keine "vorbildliche" Idee bei so einem "Spammer"-Device.

[Waldmensch]

Das update-on-event habe ich nur drin,
um sicherzugehen (Fehlersuche), dass das expandJSON wirklich getriggert wird. Wenn ich MQTT2 verwende, kann ich Mosquitto nicht verwenden. Ich will aber auch, das andere Geräte auf den Go-E subscriben können. Stichwort Phasenumschaltung, Wartezeit bis kein Strom mehr fließt. Das will ich direkt in Tasmota Rules abfackeln, Sodas FHEM nur den 1/3 Phasen umschalt Impuls geben muss und der Rest vom Tasmota Device selbst gemanaged wird. (Ladung deaktivieren, warten bis kein Strom mehr fließt, GoE Schütz trennen und wieder verbinden.) Das will ich nicht von FHEM aus machen.

[Beta-User]

Den Einwand mit Mosquitto verstehe ich nicht. Vorschlag war MQTT2_CLIENT (parallel!) zu 00_MQTT (für den Rest) zu verwenden (= beide hören auf den Mosquitto), und (nur) die Daten von diesem einen Device dann als MQTT2_DEVICE auszugestalten. Es gibt btw. auch eine myUtils dazu, die (afaik zumindest halbwegs) sinnvoll zwischen Daten unterscheidet, die triggern sollen und anderen, die man nur eher gelegentlich aktualisieren will...

[Waldmensch]

Ich war bis dato der Meinung, das MQTT2 einen eigenen Broker abbildet, den man dann im goE angeben muss. Wenn das nicht so ist, schau ich mit das nochmal an.

[Beta-User]

Es gibt 2 IO Module:
MQTT2_SERVER bildet einen eigenen "Broker" ab, das hier vorgeschlagene MQTT2_CLIENT ist die "modernere" Konkurrenz zu 00_MQTT (und kann u.a. SSL).

[Waldmensch]

Okay, Habe einen MQTT2 Client angelegt und ein MQTT2 Device nach Vorschlag im ersten Beitrag. Auch hier scheint das JSON parsing nicht zu klappen.

Code Auswählen Erweitern

2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0

Code Auswählen Erweitern

defmod MQTT2_goecharger MQTT2_DEVICE
attr MQTT2_goecharger DbLogExclude .*
attr MQTT2_goecharger IODev GoEClient
attr MQTT2_goecharger readingList go-eCharger/023547/status:.* { json2nameValue($EVENT) }\
go-eCharger/023547/ip:.* { json2nameValue($EVENT) }
attr MQTT2_goecharger room MQTT2_DEVICE
attr MQTT2_goecharger setList Laden_EIN:noArg go-eCharger/023547/cmd/req alw=1\\
Laden_AUS:noArg go-eCharger/023547/cmd/req alw=0\\
Ampere:selectnumbers,1,1,22,1,lin go-eCharger/023547/cmd/req amp=$EVTPART1\

attr MQTT2_goecharger stateFormat Status: Stecker_Kabel P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr MQTT2_goecharger userReadings Stecker_Kabel  { if(ReadingsVal("MQTT2_goecharger","car","") eq "1") { return "Bereit" } \
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "2") { return "Fzg laedt" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "3") { return "Warte auf Fzg" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "4") { return "Laden beendet" }\
else { return -1 } }, \
temperature { ReadingsVal("MQTT2_goecharger","tmp",0) }, \
energy_total { ReadingsVal("MQTT2_goecharger","eto",0)*0.1 }, \
energy_akt { ReadingsVal("MQTT2_goecharger","dws",0)*2.77 }
attr MQTT2_goecharger verbose 5

[Beta-User]

An json2nameValue() liegt es nicht, wenn ich das hier manuell publishe, werden die Readings angelegt und sind dann nach einem Browser-Refresh sichtbar. Klingt eher danach, als würde die Verbindung M2C <-> mosquitto nicht klappen - warum auch immer. (credentials?)

Kurz-Kurs noch für Neueinsteiger in M2D: Für die Umbenennungen usw. nutzt man besser jsonMap, und (ganz allgemein:) für userReadings sind trigger zu empfehlen (bei "all-in-one"-Aktualisierungen wie hier nicht so wichtig, aber das kann man kaum vorher wissen...).
Der Beitrag mit der letzten myUtils-Fassung zu dem Charger ist der hier: https://forum.fhem.de/index.php/topic,115620.msg1099706.html#msg1099706. Leider wollte den Ball wohl niemand so recht aufgreifen, ist aber echt "interessant", das Ding (besser gesagt: schlampig programmierte MQTT-Schnittstelle, man muss viel "reparieren"...).

[Waldmensch]

Wenn ich mir den GoE direkt auf der Konsole des mosquito subscribe, sehe ich alle 5 sekunden eine valide message. Das MQTT2 Device aktualisiert ebenfalls alle 5 Sekunden. Ist json2nameValue wine Standardfunktion, oder muss es ch die noch irgendwo in myUtiös einbauen?

[Beta-User]

Wenn ich mir den GoE direkt auf der Konsole des mosquito subscribe, sehe ich alle 5 sekunden eine valide message.

Der Weg Charger->mosquitto funktioniert also.

Das MQTT2 Device aktualisiert ebenfalls alle 5 Sekunden.

Den Satz verstehe ich nicht: Du meinst das alte MQTT_DEVICE, oder?

Ist json2nameValue wine Standardfunktion, oder muss es ch die noch irgendwo in myUtiös einbauen?

json2nameValue() kommt aus fhem.pl und sollte auf jeder halbwegs akutellen Installation vorhanden sein. FHEM ist aktuell, nehme ich an? (version MQTT2_.*)

Zeigst du bitte mal ein list von dem MQTT2_CLIENT?
(Dessen CID/ClientId (oä.) sollte unterschiedlich sein zu dem, was du bei 00_MQTT verwendest).

[LR66]

Bei mir ging es sofort mit MQTT2-Server in default-Einstellungen & das in der App vom goE so eingegeben. Dann erscheint der Charger automatisch als Device mit angehängter Nummer (durch das autocreate). Im Device kann man dann auch das template für go-ECharger wählen und versuchen ein dauerhaftes Device daraus zu machen (Entfernung Nummer in readinglist genaueres s. Hilfe & dann rename), die readings gem. Api sind implementiert. Der payload-Befehl amx (statt amp, ohne speichern im Flash) sollte ggf angepasst werden. Gelegentlich Fehlermeldungen

Code Auswählen Erweitern

: ERROR: Unhandled packet CONNACK, disconnecting m2s_192.168.0...
2021.05.04 21:39:32 1: ERROR: Unhandled packet PUBREL, disconnecting m2s_192.168.0.....
2021.05.04 21:45:12 1: ERROR: Unhandled packet CONNACK, disconnecting m2s_192.168.0....
2021.05.04 22:06:39 1: ERROR: Unhandled packet PUBREL, disconnecting m2s_192.168.0.....

[Beta-User]

Bei mir ging es sofort mit MQTT2-Server [...]

Das ist ja nett gemeint, aber in diesem Fall soll die Einbindung über einen externen Server laufen .

An sich sollte es da keine größeren Unterschiede geben, nur dass eben autocreate nicht (so einfach) genutzt werden kann, wenn diverses anderes Zeug über den Server geht...

[Waldmensch]

Die Alten MQTT versuche sind gelöscht, es gibt nur noch den MQTT2 Ansatz

Ich bekomme alle 5 Sekunden events von den Userreadings aus dem MQTT2 Device. Daher gehe ich davon aus, dass die Messagequeue GoE->Mosquito->MQTT2_CLIENT->MQTT2_DEVICE funktioniert

Code Auswählen Erweitern

2021.05.21 16:53:00 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:05 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:10 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:20 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0

List vom MQTT2 Client

Code Auswählen Erweitern

Internals:
   BUF       
   CFGFN     
   DEF        localhost:1883
   DeviceName localhost:1883
   FD         37
   FUUID      60a797f5-f33f-d6b4-504e-425be4fbd5f1e694
   NAME       GoEClient
   NR         639744
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   GoEClient
   lastMsgTime 1621608304.52933
   nextOpenDelay 5
   READINGS:
     2021-05-21 13:22:29   state           opened
Attributes:
   room       MQTT2_device

So ganz neu ist FHEM nicht, da ich mich bei Updates schon ein paar mal in die Nesseln gesetzt habe und komplett neu aufsetzen musste: NCARS

Code Auswählen Erweitern


File               Rev   Last Change

00_MQTT2_CLIENT.pm 19463 2019-05-25 13:02:46Z rudolfkoenig
10_MQTT2_DEVICE.pm 19262 2019-04-25 07:50:19Z rudolfkoenig

[Beta-User]

Aua, das ist doch "ziemlich alt" (bezogen auf die MQTT2-Welt)... Du müsstest mal schauen, was zum Thema json2nameValue() in deiner fhem.pl zu finden ist. Tendenziell müsste da was im log zu finden sein, und wenn du updates scheust, dann wäre es ggf. den Versuch wert, nur die Funktion gegen den aktuellen Code auszutauschen.

(Ich würde aber mal ein update wagen, vorher ein backup und CUL_HM (+ggf. WeekdayTimer, falls du noch Heating_Control hast) ausklammern, das ist ein spezielles Thema, falls du das im Einsatz haben solltest).

[rudolfkoenig]

Du müsstest mal schauen, was zum Thema json2nameValue() in deiner fhem.pl zu finden ist.

json2nameValue kam mit 17140 rein, sie wird also vorhanden sein.
Allerdings haben wir seitdem etliche Bugs entfernt und die Funktion deutlich erweitert, laut svn blame entstand etwa ein drittel der Funktion nach 19463.

[Beta-User]

"Wir" ist lustig...

Von Interesse scheint v.a. das toJSON-Kombabilitätsthema zu sein, da wurde um den Dreh rum was ergänzt.

Aber (@waldmensch) ernsthaft: Dauerhaft ohne updates (oder irgendwelche Frickeleien) ist m.E. ein nogo, wenn man halbwegs aktuelle Hardware haben will (v.a. aus der MQTT-Welt, aber nicht nur). Früher oder später fliegt dir die Murmel um die Ohren (anzunehmen, dass es mit dem OS auch so ist, dass das irgendwann outdated ist), und da würde es m.E. Sinn machen, mal einen update-Plan zu machen oder zumindest bestimmte Teile parallel in einer neueren Infrastrukur zu betreiben. Ist zwar schön, dass FHEM zuverlässig auch so vor sich hin läuft, aber "irgendwann" holt einen sowas ein...

(MQTT ist btw. ein probates Mittel, um einen gewissen Abstraktionslayer einzuschieben).

[Waldmensch]

Die beiden Module updaten reicht sicher nicht, wenn die toJSON Funktion im FHEM.pl steckt. Bei bisherigen Updates hat es mit regelmäßig bei den FS20 und im TabletUI ,,eingeschlagen" (Nicht gut für den WAF, wenn alle 3 Tablets in der Wohnung nicht mehr anzeigen was sie sollen). Die Hauptsächlichen ,,Dinge" laufen mittlerweile über MQTT (alt) und Tasmota. Die komplette FHEM Installation wird nächtens auf ein NFS Laufwerk als Backup kopiert. Habe das aus Raspi Zeiten beibehalten, weil ich ein paar mal SD Karten verloren hab.
Dann werde ich mal die Backups prüfen und ein Update angehen.

[Muschelpuster]

Moin zusammen,

hat schon jemand mit der Hardware V3 und der Firmware 0.51.1 MQTT aktivieren können? Ich kann das zwar einschalten und auch die MQTT-URL anpassen aber nach dem Speichern ist bei erneutem Aufruf der Einstellungen wieder die Default-URL hinterlegt.

[Sany]

Hallo Muschelpuster,

habe die selbe Hardware/App-Konfig wie Du, und stehe in Kontakt mit go-e:
Die MQTT-Adresse wird momentan nicht gespeichert, ist ein Bug und soll in der nächsten Version der App (in Kürze) gefixt sein.

Es gilt also auf die nächste App-Version zu warten, dort im Changelog sollte die Korrektur des Bugs erkennbar sein.

Falls Name/Passort für den MQTT Broker erforderlich dann so eintragen:

Code Auswählen Erweitern

mqtt://username:password@server:port

Bin gespannt, wann die App rauskommt....


Gruß

Sany

[Muschelpuster]

Danke Sany,

das habe ich fast befürchtet 
Alternativ kann man natürlich auch einen statischen DNS-Record für die Default-Adresse machen, welcher auf FHEM zeigt. Aber das kann Onkel Fritz ja nicht.
Oder man nimmt das Modul von LR66...
Na ja, Go-e hat jetzt noch ein Ticket dazu 

Niels

[Sany]

die WebApp ist übrigens auch noch nicht kompatibel zur Hardware v3. Das soll auch noch kommen, aber es wurde kein Datum genannt. Und zur API v2 gibts noch keine Dokumentation.

Das ist zwar alles etwas seltsam, aber für mich gerade nicht sooo wichtig. Die Box wurde halt im Zuge meiner PV installiert, ich hab aber nicht mal n Kabel, geschweige denn ein eAuto

Irgenwann demnächst werden die ihre Software aktualisieren und dann kommt das Teil ins fhem, zu späteren Nutzung.

[Muschelpuster]

Die MQTT-URL bekommt man eingestellt, auch wenn der Support sagt, dass das nicht geht 
1. HTTP-API V2 aktivieren
2. http://go-e-ip/api/set?mcu=%22mqtt://MQTT-IP:1883%22 im Webbrowser der Wahl abfeuern
Und schon schlagen die MQTT-Meldungen auf 
Ein Blick auf die Uhr verrät mir aber, dass ich jetzt nicht mehr schaue, ob diese mit den bisherigem Format übereinstimmen 

Niels

[Sany]

Guten Morgen,

vielen Dank für den Tipp. Habs mal probiert, aber wieder gelöscht. Warum?
1. mein MQTT2 Server ist per Username/Passwort abgesichert. Wenn ich den Befehl im Browser absetzte, mit den Credentials, dann stehen diese nachher im Klartext in der App.
2.

Und schon schlagen die MQTT-Meldungen auf

Das ist sehr wörtlich zu nehmen: da kamen hunderte Meldungen an, das angelegte Device (autocreate) hatte ca 220 Readings angelegt die öfter als sekündlich übertragen wurden. Selbst mit event-on-change-reading .* wurde immer noch soviel Last im System erzeugt, dass diverse andere MQTT2-Devices sich peu-à-peu abgemeldet haben. Im Log sind innerhalb 12 min ca 22000 Messages aufgezeichnet worden.
Ich hab das jetzt erst mal alles wieder rausgenommen. Jetzt ist wieder Ruhe.
Im Moment habe ich keine Zeit, mich damit intensiv zu beschäftigen. Ich warte erst mal ab, was an Updates von go-e kommt und wenn es passt werde ich die "Forschungen" wieder aufnehmen.

Gruß


Sany

[Muschelpuster]

Ja, ich bin mit dem MQTT vom go-e auch gerade überhaupt nicht glücklich. Nun hat meine Büchse genug Power um das zu verdauen, aber irgendwann ist auch Ende und ich will die Power nicht für so grottige umgesetzte MQTT-Schnittstellen verschwenden.
Zu allem Übel gibt es ja noch die Readings 0-X die mehrfach belegt sind und so munter ihre Werte wechseln. Wobei das ist sicher ein Thema für die MQTT-Experten hier, denn das sind Inhalte von Arrays. Die müssten also eher als Arrayname.X angelegt werden und nicht stumpf als X.
Ich tendiere gerade stark zum JsonMod um die Daten via HTTP-API V2 zu lesen und zu visualisieren. Das Lesen mit dem Anlegen aller Werte als Readings klappt einwandfrei, auch bei den Arrays. Nun mangelt es auch nur an der Zeit und der Erfahrung das vernünftig zu visualisieren. Ich kann auch schon die Stromstärke über die API einstellen, es ist aber mal wieder ein steiniger Weg für mich.

Niels

[Beta-User]

Es gäbe da auch noch (zu finalisierenden) myUtils-Code, um die Event-Flut ggf. einzudämmen...

[Sany]

um die Event-Flut ggf. einzudämmen...

go-e sollte seine Firmware so schreiben, dass diese Flut erst gar nicht entsteht. Es geht hier um eine "Steckdose" für ein e-Auto, da wird kein sicherheitskritisches Atomkraftwerk überwacht.

Also Meldungen bei Änderungen, zyklisch (alle x minuten?) ein paar Statusmeldugen, das reicht völlig. Und eben noch die Gegenrichtung um der Box Befehle zu schicken.
Das scheint aber alles noch "in Entwicklung" zu sein, evtl. kann man da ja Hinweise geben.

[Beta-User]

...bin da völlig bei dir und kann auch nicht nachvollziehen, was der Autor sich dabei denkt...

[Sany]

@Niels:
hast Du schon mal go-e-IP/api/status aufgerufen, bei eingeschalteter API v2?
Schon da wird man erschlagen mit allen möglichen Daten. Sogar eine Liste der umliegenden WLAN-Netze.
Ich hab go-e mal über mein Experiment heute früh informiert und darum gebeten, die MQTT Datenflut auf sinnvolle Daten und Intervalle zu "verkleinern".

Bin mal gespannt.

[Muschelpuster]

hast Du schon mal go-e-IP/api/status aufgerufen, bei eingeschalteter API v2?

Ja, da habe ich mich mal etwas umgeschaut. Das habe ich mit dem JsonMod gemacht, dann ist das nicht mehr so unübersichtlich

Um diesen Thread nicht zu torpedieren habe ich die Ergebnisse meiner Tätigkeit mal in einen eigenen Thread gepackt: https://forum.fhem.de/index.php/topic,122285.0.html

Niels

[Beta-User]

Es gäbe da auch noch (zu finalisierenden) myUtils-Code, um die Event-Flut ggf. einzudämmen...

Fyi: Aus gegebenem Anlass habe ich dann mal die letzte Version der myUtils-File aus https://forum.fhem.de/index.php/topic,115620.msg1099706.html#msg1099706 ins svn/contrib eingecheckt und ein (hoffentlich) dazu passendes attrTemplate "neu" (unter Berücksichtigung des zusätzlichen Setters, den @PeMue in https://forum.fhem.de/index.php/topic,122285.msg1169116.html#msg1169116 angedeutet hat.

Stark anzunehmen, dass da noch ein paar Enden (setter/Readings) nicht so recht zusammenpassen...
Kurz: das ist alles noch etwas experimentell, und falls jemand was zur Verbesserung beitragen kann/mag: gerne!

[isy]

Moin,
da ich jetzt auch eine GO-E habe hänge ich mich mal hier dran, auch wenn länger nichts geschrieben wurde.
Die Box feuert jede Sekunde, ich habe daher die Einbindung über mqtt erstmal deaktiviert.
VG Helmut

[Prof. Dr. Peter Henning]

Es gibt eine neue Unterkategorie zu Wallboxen, "FHEM - Energiemanagement und Energieerzeugung" -> Wallboxen.

Und ja: Nach dem ersten Test meiner neuen go-e mit MQTT habe ich das schnellstens wieder deaktiviert - irrwitzige Datenflut, die kein Mensch braucht.

LG

pah

[Beta-User]

Und ja: Nach dem ersten Test meiner neuen go-e mit MQTT habe ich das schnellstens wieder deaktiviert - irrwitzige Datenflut, die kein Mensch braucht.

Habe zwar keine solche Box, aber dass das kompletter Unfug ist, wie das da umgesetzt ist, hatten wir ja schon direkt zu Beginn hier mal angesprochen.

Falls du - als "qualifizierter Kunde" - mal irgendwann Zeit findest, dich beim Hersteller darüber zu beschweren wäre das klasse!

[isy]

Ich hatte den Support vor 1 1/2 Jahren mal diesbezüglich angeschrieben und man hat auch schnell reagiert.
Man wolle den Datenverkehr über MQTT nicht einschränken.

Nachtrag. Ich hatte nach einem Parameter für Sende-Intervalle gefagt und nach Filterung auf bestimmte Felder.

[Prof. Dr. Peter Henning]

Ich habe so den Verdacht, dass das irgendwie mit deren eigener Hardwarebox zur Überschussladung in Zusammenhang steht.

LG

pah

[Beta-User]

Ich habe so den Verdacht, dass das irgendwie mit deren eigener Hardwarebox zur Überschussladung in Zusammenhang steht.

LG

pah

Meinst du? Braucht die alle Sekunde die SSID?!?

Glaube eher, da hat man "den Lehrling" mal machen lassen, ohne im genauere Anweisungen zu geben, dann gesehen, dass es funktioniert und es dabei belassen... Jedenfalls glaube ich nicht, dass sich da irgendjemand wirklich einen Kopf gemacht hat (außer vielleicht, wie man das Problem löst, irgendwie schnell diese Art Schnittstelle bereitzustellen).

[Guzzi-Charlie]

Hallo zusammen,

nachdem ich nun einen zweiten go-eCharger installiert habe wollte ich diesen genauso wie den Ersten per MQTT in FHEM integrieren. Leider funktioniert das Ganze überhaupt nicht. Obwohl ich in den erweiterten Einstellungen des go-eChargers "MQTT API aktivieren" eingeschaltet UND IP/Port meines RasPi eingetragen habe liefert der Charger keine Daten/hat er nicht (wie üblich) automatisch ein MQTT-Device angelegt.

Ich habe nun schon alle möglichen Einstellungen im Einstellungsmenü des go-eChargers ausprobiert (inkl. die "alte" v1-API aktiviert, aber Alles ohne Erfolg.

• Der alte go-eCharger ist eine HW-Version V2
• Der neue go-eCharger ist ein "Gemini" HW-Version V4

Aufgefallen ist mir der etwas unterschiedliche Aufbau der MQTT-Parametrierung in den Einstellungen:

• beim V2
  ==> MQTT-Server: "192.xxx.xxx.xxx"
  ==> Port: "1883"
  ==> Benutzername: ist leer
  ==> Passwort: ist leer
• beim V4
  ==> alles in einer Zeile "MQTT://Benutzer:PW@192.xxx.xxx.xxx:1883"
  ==> im FHEM MQTT2-Server ist keine authentification eingerichtet, deshalb ist für Benutzer/PW nichts eingetragen. Eingetragen habe ich "192.xxx.xxx.xxx:1883"
  ==> aber das "MQTT://" läßt sich nicht entfernen. Nach dem Speichern ist es trotz Löschung wieder da.

Kann das evtl. die Ursache sein?

Wenn Jemand eine Idee hat was das Problem ist bzw. wie man es lösen kann, dann immer her damit.

DANKE

[Prof. Dr. Peter Henning]

Kann ich nicht nachvollziehen. Ich habe auch einen V4, mit der Beta-Firmware 56.1. Die Verbindung über MQTT hat auf Anhieb funktioniert - ich habe sie wegen der gigantischen Datenflut aber gleich wieder deaktiviert. Und zwar mit genau den gleichen Einträgen.

Kann das evtl. die Ursache sein?

Nein, definitiv nicht. Der Präfix mqtt:// definiert nur das Protokoll, das hier gefahren wird (eben MQTT).

LG

pah

[Guzzi-Charlie]

Guten Morgen,

vielen Dank für die schnelle Antwort.

Ich habe Gestern Abend noch gesehen, daß der go-eCharger wohl tatsächlich doch eine Verbindung zu FHEM aufgebaut hatte. Es wurde nämlich ein FHEM-Server angelegt der auch im Status "connected" war. Das war mir erst aufgefallen als ich auf der Suche war warum mein FHEM auf einmal ziemlich am "Anschlag" lief. Es wurde nur kein Device angelegt. Das hatte ich zuvor schon versuchsweise als Kopie meines V2 Chargers manuell angelegt. Das hatte aber auch nicht funktioniert. Daraufhin habe ich MQTT beim V4 wieder abgeschaltet und das manuell angelegte Device gelöscht.

Heute Morgen habe ich das Ganze nochmal nachvollzogen und das Gleiche Verhalten bestätigt: Ein FHEM MQTT-Server wurde angelegt und FHEM offensichtlich wieder mit Daten überflutet, aber wieder kein Device automatisch angelegt. Danach habe ich MQTT des V4 wieder abgeschaltet.

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. Das ging aber beim V4 nicht weil es ja kein Device gab.

Über welche Schnittstelle/API haben Sie denn den go-eCharger eingebunden?

[Beta-User]

Guten Morgen,

vielen Dank für die schnelle Antwort.

Ich habe Gestern Abend noch gesehen, daß der go-eCharger wohl tatsächlich doch eine Verbindung zu FHEM aufgebaut hatte. Es wurde nämlich ein FHEM-Server angelegt der auch im Status "connected" war. Das war mir erst aufgefallen als ich auf der Suche war warum mein FHEM auf einmal ziemlich am "Anschlag" lief. Es wurde nur kein Device angelegt. Das hatte ich zuvor schon versuchsweise als Kopie meines V2 Chargers manuell angelegt. Das hatte aber auch nicht funktioniert. Daraufhin habe ich MQTT beim V4 wieder abgeschaltet und das manuell angelegte Device gelöscht.

Heute Morgen habe ich das Ganze nochmal nachvollzogen und das Gleiche Verhalten bestätigt: Ein FHEM MQTT-Server wurde angelegt und FHEM offensichtlich wieder mit Daten überflutet, aber wieder kein Device automatisch angelegt. Danach habe ich MQTT des V4 wieder abgeschaltet.

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. Das ging aber beim V4 nicht weil es ja kein Device gab.

Über welche Schnittstelle/API haben Sie denn den go-eCharger eingebunden?

Jeder der charger hat ein eigenes Prefix? (Also unterschiedliche topics?

Ansonsten bitte einfach beim Hersteller wegen der besch.... Schnittstelle beschweren!

[Prof. Dr. Peter Henning]

Ich habe das über HTTPMOD angebunden. Geht hervorragend und ist viel besser steuerbar:

https://forum.fhem.de/index.php?topic=136856.0

Der finale Code für das HTTPMOD-Device ist dort noch ein wenig verstreut, weil ich derzeit noch etwas experimentieren muss (WallBox habe ich, Auto noch nicht).

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. 

Das ist aber in die Tasche gelogen, weil die Daten natürlich trotzdem beim MQTT-Server ankommen und verarbeitet werden. Außerdem das WLAN ziemlich stark belasten.

Ansonsten bitte einfach beim Hersteller wegen der besch.... Schnittstelle beschweren!

Nutzt nichts, ist in anderen Foren schon mehrfach gemacht worden. Der Hersteller beharrt darauf, MQTT-Daten im Sekundentakt zu versenden. Die steuern offenbar auf eine komplexe Infrastruktur mit mehreren Wallboxen, Speichern und Erzeugern zu. Und wollen natürlich ihren eigenen "Controller" vermarkten.

LG

pah

P.S.: Dieser Thread sollte ebenfalls in die neue Kategorie "Wallboxen" verschoben werden.

[Beta-User]

Der Hersteller beharrt darauf, MQTT-Daten im Sekundentakt zu versenden. Die steuern offenbar auf eine komplexe Infrastruktur mit mehreren Wallboxen, Speichern und Erzeugern zu. Und wollen natürlich ihren eigenen "Controller" vermarkten.

So bescheuert wie das umgesetzt ist, wird das m.E. auf diese Weise  nicht klappen... Hoffen wir, dass die das auch noch merken und die verantwortliche Person ersetzen.

[Guzzi-Charlie]

Jeder der charger hat ein eigenes Prefix? (Also unterschiedliche topics?

Ja, haben einen unterschiedlichen Prefix

Die Eventflut habe ich ja bei meinem V2 go-eCharger mittels "event-on-change-reading" drastisch eingeschränkt, aber trotzdem belastet die Flut der ankommenden Daten doch wahrscheinlich den RasPi erheblich, zumal ich ja noch ca. 110 weitere MQTT-Devices, sowie nochmal ca. genauso viele andere Devices (Modbus, EC3000, IEC1107, HmIP, AVM-DECT, E-Autos, Hausspeicher, Tibber, etc.) habe die Daten liefern. Das treibt meinen RasPi 4 schon ganz schön an seine Grenzen.

Ich werde es also mal mit alternativen Wegen versuchen.

Danke nochmal für die schnellen Antworten.

[Guzzi-Charlie]

So, ich habe den neuen go-eCharger (Gemini) nun auch über HTTPMOD eingebunden. Funktioniert auf den ersten Blick schon so wie es soll UND verursacht keine Datenflut. Das eigentlich schöne an MQTT, daß man normalerweise für die Einbindung nichts tun muß hat ja diesmal mit dem Gemini nicht funktioniert, warum auch immer. Mit dem go-eController hat es es allerdings auf Anhieb funktioniert diesen per MQTT mit FHEM zu verbinden.

In Anbetracht der Tatsache der horrenden Datenflut (von dann jetzt drei go-e Geräten) habe ich mich aber entschieden den go-eController ebenfalls per HTTPMOD einzubinden. Das werde ich die nächsten Tage angehen. Dazu schreibe ich dann im Thema https://forum.fhem.de/index.php?topic=136856.0 etwas. Auch meinen alten V2 werde ich wohl auf HTTPMOD oder das alte fhem-Modul umstellen um noch etwas mehr Last von meinem RasPi zu nehmen.

Da (oder vielleicht später auch in einem separaten Thema) werde ich dann auch etwas zu den Themen automatisches Überschußladen, V2H, etc. schreiben.