Modul für Ecoflow-Komponenten (über HTTP-REST)

[MasterRay]

Hallo,

ich bekomme seit Anfang August von meine rRiver 2 Max keine Daten mehr ...

Habe ich bei meiner Delta 3 auch. Wie ich gelesen habe, ist das die EF-Antwort auf eine (noch) unveröffentliche API.

Alternativ ggf. MQTT verwenden.

[KölnSolar]

Hi Knut,
ich habe nun das Modul für meine powerstream u. delta2 im Einsatz. Funktioniert grundsätzlich. Danke.

Leider musste ich regelmäßige minimale freezes feststellen, was mir mit meinem freezemon das Log zuballert.
Bei der Suche bin ich im Code auf

Code Auswählen Erweitern

my @ev_on_change_reading=Ecoflow_CleanArray(split(",",AttrVal($name,"event-on-change-reading","")));
my @ev_on_update_reading=Ecoflow_CleanArray(split(",",AttrVal($name,"event-on-update-reading","")));
.
.
.
if((Ecoflow_StrInArr($vname,@ev_on_update_reading)) || (Ecoflow_StrInArr(".*",@ev_on_update_reading)) || (Ecoflow_StrInArr($vname,@ev_on_change_reading)) || (Ecoflow_StrInArr(".*",@ev_on_change_reading))){
Ecoflow_Log($param->{hash}, 5, "Ecoflow_Response(): Forced Update $vname");
readingsBulkUpdate($param->{hash},$vname,$v{$rname});
}
else
{
readingsBulkUpdateIfChanged($param->{hash},$vname,$v{$rname});
}
gestoßen. Eine etwas eigentümliche Implementierung der event-on-Attribute. Warum ?

Außerdem scheint die Schleife

Code Auswählen Erweitern

foreach my $key(sort keys %{$Ecoflow_Vars{$model}->{Adjustments}}){
Ecoflow_Log($param->{hash},6,"Ecoflow_Response(): \$key = $key | \$rname = $rname");
if($key eq $rname){
$v{$rname}=$v{$rname}/$Ecoflow_Vars{$model}->{Adjustments}->{$rname};
}
}
die freezes zu verursachen, da sie für jedes Feld aufgerufen wird. Warum nicht durch

Code Auswählen Erweitern

$v{$rname}=$v{$rname}/$Ecoflow_Vars{$model}->{Adjustments}->{$rname} if($Ecoflow_Vars{$model}->{Adjustments}->{$rname});ersetzen ?

Für die Delta2 gibt es ja noch keine Adjustments. Welche Einheiten sollen denn ausgegeben werden ? V,A,W,Wh,h ? Dann kann ich mich an die Definition machen.

Grüße
Markus

[KölnSolar]

...und wie wäre es mit einem Attribut no_data_20_134 ?

Die time-schedules braucht doch eigentlich niemand in FHEM. Frisst unnötig Leistung und macht ne Masse nichtssagender readings.
...

[Neolux]

Moin zusammen,

sorry war den Sommer über mit anderen Sachen beschäftigt.

Also, zunächst mal:
[quote [quote

Hallo,

ich bekomme seit Anfang August von meine rRiver 2 Max keine Daten mehr ...

Habe ich bei meiner Delta 3 auch. Wie ich gelesen habe, ist das die EF-Antwort auf eine (noch) unveröffentliche API.

Alternativ ggf. MQTT verwenden.

Delta 3- und River-Geräte: Hierzu wurde seitens Ecoflow keine API veröffentlicht. Wie auch bei anderen neueren geräten von Ecoflow werden hier wohl "Google Protocol Buffers" benutzt, dazu wurde keine Schnittstelle bekanntgegeben, und aufgrund der Verschlüsselung kommt man da auch nicht so hemdsärmelig weiter.

Code Auswählen Erweitern

foreach my $key(sort keys %{$Ecoflow_Vars{$model}->{Adjustments}}){
Ecoflow_Log($param->{hash},6,"Ecoflow_Response(): \$key = $key | \$rname = $rname");
if($key eq $rname){
$v{$rname}=$v{$rname}/$Ecoflow_Vars{$model}->{Adjustments}->{$rname};
}
}


Ja, ändere ich, kein Thema. Ich bin kein Perl-Profi, von daher bin ich mit diesem Modul von 0 auf 100 gegangen. Von daher bin ich für jede Optimierung dankbar.

...und wie wäre es mit einem Attribut no_data_20_134 ?

Die time-schedules braucht doch eigentlich niemand in FHEM. Frisst unnötig Leistung und macht ne Masse nichtssagender readings.

Naja, die werden einfach über den HTTP-Request mit zurückgegeben. Ich bin mir nicht sicher, ob das die Leistung des Moduls verbessert, wenn ich die rausfiltere.

[KölnSolar]

Hi Knut,

Ich bin kein Perl-Profi, von daher bin ich mit diesem Modul von 0 auf 100 gegangen.

Frag mich, ich stehe mit Perl auch eher auf Kriegsfuß. Und manche Perl-Dinge in Deinem Modul verstehe ich mangels Wissen nicht.

Ich bin mir nicht sicher, ob das die Leistung des Moduls verbessert, wenn ich die rausfiltere.

Die Schleife wird 70% performanter.  Mir geht's es aber mehr um die Übersicht bei den readings. 125 sind schon unübersichtlich genug, aber 350....  
Bei

event-on-Attribute.

kann ich ja vielleicht weiterhelfen...
Grüße Markus

[Neolux]

Für die Delta2 gibt es ja noch keine Adjustments. Welche Einheiten sollen denn ausgegeben werden ? V,A,W,Wh,h ? Dann kann ich mich an die Definition machen.

Richtig, ich hab die alle normiert auf V,A,W... etc.
Ecoflow hat da so lustige Ausgaben wie milliVolt, deziWatt, etc. Das will doch keiner Wissen.

Nachtrag: Ich hab angefangen, die Schleifen zu optimieren. brauch aber wohl noch ein paar Tage bis zum Release.

[KölnSolar]

Schon einmal das, was ich im Augenblick liefern kann

Code Auswählen Erweitern

"DELTA 2" => {
"Adjustments" => {
"data_inv.acInAmp" => 1000,
"data_inv.acInVol" => 1000,
"data_inv.cfgAcOutVol" => 1000,
"data_mppt.outVol" => 1000,
"data_inv.invOutVol" => 1000,
"data_inv.invOutAmp" => 1000,
},
"Gets" => {},
"Sets" => {},
"SetCmdCodes" => {},
},
da meine delta2 im Augenblick zur Reparatur ist.
Es gibt noch 19 readings zu Zellspannungen(3-3,3V,differenz 0,001V). Aber da machen dann glaube ich die mV Sinn, oder ?

Code Auswählen Erweitern

"data_bms_bmsStatus.cellVol_1 => 1000,
"data_bms_bmsStatus.cellVol_2 => 1000,
"data_bms_bmsStatus.cellVol_3 => 1000,
"data_bms_bmsStatus.cellVol_4 => 1000,
"data_bms_bmsStatus.cellVol_5 => 1000,
"data_bms_bmsStatus.cellVol_6 => 1000,
"data_bms_bmsStatus.cellVol_7 => 1000,
"data_bms_bmsStatus.cellVol_8 => 1000,
"data_bms_bmsStatus.cellVol_9 => 1000,
"data_bms_bmsStatus.cellVol_10 => 1000,
"data_bms_bmsStatus.cellVol_11 => 1000,
"data_bms_bmsStatus.cellVol_12 => 1000,
"data_bms_bmsStatus.cellVol_13 => 1000,
"data_bms_bmsStatus.cellVol_14 => 1000,
"data_bms_bmsStatus.cellVol_15 => 1000,
"data_bms_bmsStatus.cellVol_16 => 1000,
"data_bms_bmsStatus.maxCellVol => 1000,
"data_bms_bmsStatus.minCellVol => 1000,
"data_bms_bmsStatus.maxVolDiff => 1000,

Habe ich Deine gets richtig verstanden, dass Du nur das Reading ausliest und anzeigst ?
Das würde keinen Sinn machen. Ein get bezieht sich auf das physische Device(in dem Fall die Cloud), also z.B. get update/request, um sofort Daten vom device zu holen, weil man nicht auf den Ablauf des Intervalls warten möchte. Oder um Daten zu ermitteln, die nicht mit dem Standardzyklus übertragen werden.

Grüße Markus

edit:

brauch aber wohl noch ein paar Tage bis zum Release

Nur kein Stress. Ist nur ein Hobby.

[MasterRay]

Delta 3- und River-Geräte: Hierzu wurde seitens Ecoflow keine API veröffentlicht. Wie auch bei anderen neueren geräten von Ecoflow werden hier wohl "Google Protocol Buffers" benutzt, dazu wurde keine Schnittstelle bekanntgegeben, und aufgrund der Verschlüsselung kommt man da auch nicht so hemdsärmelig weiter.

Hallo,

bei "Google Protocol Buffers" handelt es sich nicht um eine Verschlüsselung, sondern um eine Umkodierung in (bzw. aus) ein kompaktes, binäres Format (siehe Google). Programmtechnisch ist das nicht schwierig. Man benötigt allerdings die .proto-Files dazu und die rückt EF nicht raus. Habe angefragt. Sei "internal".

Allerdings haben die "Kollegen" anderer Systeme sich schon damit erfolgreich beschäftigt und man kann deren Dateien aus diversen Foren (googeln!) beziehen -und/oder- selbst reengineeren. Ich habe für meine Delta3 eine Mischung aus beidem gemacht und das läuft seit März hervorragend. Schließlich wird dieses Format von der EF-Äpp verwendet, was eine gewisse Stabilität und Unabhängigkeit bedeutet.

Ich kann gerne "Anschubhilfe" geben, wenn jemand sein EF-Gerät über protobuf an Fhem anbinden und in das Thema einsteigen möchte. Aber ein fertiges Modul habe ich nicht, zumal ich die Programmierung nur mit Node.js geschafft habe.

Schönen Abend und Grüße

[Neolux]

So, ich habe Performance-Optimierungen vorgenommen und einige foreach-Schleifen beseitigt.
Auch das Attribut "no_data_20_134" ist drin, die Tasks der Powerstream werden nicht mehr ausgelesen, wenn  "no_data_20_134" = 1 ist.
Um die Readings loszuwerden, einmal ein "set <devicename> DeleteReadings

Schon einmal das, was ich im Augenblick liefern kann

Code Auswählen Erweitern

"DELTA 2" => {
"Adjustments" => {


Danke für die Mühe, die baue ich dann als nächstes ein, zusammen mit eventuellen Get- und Set-Cmds für die Delta 2.

Habe ich Deine gets richtig verstanden, dass Du nur das Reading ausliest und anzeigst ?
Das würde keinen Sinn machen. Ein get bezieht sich auf das physische Device(in dem Fall die Cloud), also z.B. get update/request, um sofort Daten vom device zu holen, weil man nicht auf den Ablauf des Intervalls warten möchte. Oder um Daten zu ermitteln, die nicht mit dem Standardzyklus übertragen werden.

Jein. Da die Requests an die Cloud asynchron laufen, liefern die Gets zwar das letzte Readings zurück, lösen aber auch einen Request an die Cloud aus, das Reading wird nach Rückmeldung des Requests aktualisiert.
Die Requests an die Cloud laufen über HttpUtils_Nonblocking, damit FHEM nicht stehenbleibt, wenn keine Antwort kommt und der HTTP-Request erst auf einen Timeout warten muss.
Ich könnte für die Gets eine Routine mit HttpUtils schreiben, die blockierend auslöst, aber dann steht im Fall der Fälle FHEM erstmal still. Da hatte ich mich erstmal dagegen entschieden.

Allerdings haben die "Kollegen" anderer Systeme sich schon damit erfolgreich beschäftigt und man kann deren Dateien aus diversen Foren (googeln!) beziehen -und/oder- selbst reengineeren. Ich habe für meine Delta3 eine Mischung aus beidem gemacht und das läuft seit März hervorragend. Schließlich wird dieses Format von der EF-Äpp verwendet, was eine gewisse Stabilität und Unabhängigkeit bedeutet.

Ich hatte vor einiger Zeit nur einen Blogpost über die Protocolbuffers gelesen, und da war von Verschlüsselung die Rede, hab mich da nicht weiter mit befasst. Das wäre insofern interessant, wenn man damit alle Geräte ansteuern kann, und nicht nur die neuen.

Wenn es nur die neueren Modelle unterstützen, dann ist da wohl ein weiteres Modul fällig...
 

[KölnSolar]

Danke, geladen u. getestet.
Ich bekomme massenhaft

Use of uninitialized value $value in string eq at fhem.pl line 5026.

im Log.
Kannst Du das bestätigen ?

Jein. Da die Requests an die Cloud asynchron laufen, liefern die Gets zwar das letzte Readings zurück, lösen aber auch einen Request an die Cloud aus, das Reading wird nach Rückmeldung des Requests aktualisiert.
Die Requests an die Cloud laufen über HttpUtils_Nonblocking, damit FHEM nicht stehenbleibt, wenn keine Antwort kommt und der HTTP-Request erst auf einen Timeout warten muss.
Ich könnte für die Gets eine Routine mit HttpUtils schreiben, die blockierend auslöst, aber dann steht im Fall der Fälle FHEM erstmal still. Da hatte ich mich erstmal dagegen entschieden.

Bloß nicht Blocking ! 
Deshalb meinte ich auch, nur ein z.B. get device update, dann sieht man ja im entsprechenden reading den aktuellen Wert.
Grüße Markus

[Neolux]

Danke, geladen u. getestet.
Ich bekomme massenhaft

Use of uninitialized value $value in string eq at fhem.pl line 5026.

im Log.
Kannst Du das bestätigen ?

Check ich mal.
Hm, nein, ich hab das nicht. Weder bei meiner Delta2Max, noch bei meinem Powerstream.

Bloß nicht Blocking ! 
Deshalb meinte ich auch, nur ein z.B. get device update, dann sieht man ja im entsprechenden reading den aktuellen Wert.

Ja, könnte ich auch machen. Ich dachte nur, aus Datensparsamkeit ist es geschickter, gezielt einen Wert abzufragen, statt immer den ganzen Rotz von der Cloud zurückgemeldet zu bekommen, wie z.B. unnötige data_20_134, die dann überlesen werden.