76_SMAInverter.pm - Abfrage von SMA Wechselrichter

[DS_Starter]

das ist auch nicht non-blocking.
Das ist sehr seltsam. Ändere die Zeile

Code Auswählen Erweitern

RemoveInternalTimer($hash, "SMAInverter_GetData");

in

Code Auswählen Erweitern

RemoveInternalTimer($hash);

Ob das bei dir funktioniert bin ich gespannt. Das ist die "alte" Methode.

[DS_Starter]

Morgen Hermann,

kleine Ergänzung noch zu deinem Problem.
Auch wenn du mit der Veränderung der erwähnten Zeile in "RemoveInternalTimer($hash);" Erfolg haben solltest wäre nur das Symptom ausgeräumt aber nicht die Ursache. Wenn andere Module ebenfallls die funktionsabhängige Timerlöschung verwenden kommst du an dieselbe Stelle.

Meiner Meinung nach muß es immer noch einen Versionsunterschied der fhem.pl zw. deinem Windows-System und dem Linux geben.
Die RemoveInternalTimer Funktion wird von fhem.pl bereitgestellt und war in der älteren Version nur mit einem Parameter, in der neueren Version aber mit zwei Parametern (nämlich der betroffenen Funktion) aufrufbar. Und genau das wird bei deinem Linux verweigert.

Du kannst es ja mal mit "version" vergleichen.
Du kannst ggf. noch ein "update force" verwenden oder sogar die fhem.pl von deinem Windows übernehmen.

Auf jeden Fall würde ich an deiner Stelle der Sache auf den Grund gehen weshalb du auf einem deiner System dieses Problem hast.

viele Grüße und einen schönen zweiten Advent,
Heiko

[Xunil66]

Moin,

nach viel suchen bin ich gestern auf SMAInverter gestossen. Bei meiner Installation musste ich noch  Date::Time nachinstallieren (  apt-get install libdatetime-perl ) dann lief alles ohne Probleme.

Aktuelles FHEM auf Pi

[DS_Starter]

Morgen Xunil66,

willkommen im Bunde. Super ... danke für die Rückinfo.
Habe deinen Hinweis zu Date::Time in die Commandref mit aufgenommen.

Grüße
Heiko

[JoWiemann]

Morgen Xunil66,

willkommen im Bunde. Super ... danke für die Rückinfo.
Habe deinen Hinweis zu Date::Time in die Commandref mit aufgenommen.

Grüße
Heiko

Man könnte auch so im Modul laden:

Code Auswählen Erweitern


    my $rc = eval {
        require Date::Time;
        Date::Time->import();
        1;
    };

    unless($rc)
    {
        return "Error loading Date::Time. May be this module is not installed. Install for Debian with: sudo apt-get install libdatetime-perl";
    }


Grüße Jörg

[kdeb]

Hallo,
ich hatte mich im September schon mal gemeldet (Beitrag #25), weil ich zu meinem SBS 2.5 keine Verbindung bekommen habe.
In der Zwischenzeit habe ich den WR getauscht bekommen und das aktuelle 76_SMAInverter.pm installiert. Leider kriege ich nach wie vor keine Daten vom Wechselrichter (mein TP10000 funktioniert hingegen tadellos). Hier noch mal die Definition:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        xxxxxx 192.168.99.60
   Host       192.168.99.60
   INTERVAL   60
   LASTUPDATE 04.12.2016 / 17:27:09
   NAME       WR_SBS25
   NR         115891
   Pass       xxxxxx
   STATE      Login failed
   TYPE       SMAInverter
   Readings:
     2016-12-04 06:21:25   INV_STATUS      Ok
     2016-12-04 17:28:19   SUSyID          128
     2016-12-04 17:28:19   Serialnumber    2110343772
     2016-12-04 17:28:46   modulstate      login failed
     2016-12-04 17:28:46   state           Login failed
Attributes:
   detail-level 2
   room       Keller,Photovoltaik
   verbose    5


Mit SBFSpot bekomme ich bei gleichen Zugangsdaten anstandslos die Daten.
Ich habe mal für ne Stunde die Events mitgeschnitten und finde zwischendurch immer mal wieder:

Code Auswählen Erweitern


2016-12-04 17:22:10.618 SMAInverter WR_SBS25 modulstate: login failed
2016-12-04 17:22:16.231 SMAInverter WR_SBS25 Login failed
2016-12-04 17:22:16.231 SMAInverter WR_SBS25 modulstate: login failed
2016-12-04 17:23:58.900 SMAInverter WR_SBS25 modulstate: normal
2016-12-04 17:23:58.900 SMAInverter WR_SBS25 SUSyID: 128
2016-12-04 17:23:58.900 SMAInverter WR_SBS25 Serialnumber: 2110343772
2016-12-04 17:24:05.766 SMAInverter WR_SBS25 Login failed
2016-12-04 17:24:05.766 SMAInverter WR_SBS25 modulstate: login failed
2016-12-04 17:24:10.918 SMAInverter WR_SBS25 Login failed
2016-12-04 17:24:10.918 SMAInverter WR_SBS25 modulstate: login failed


Allerdings habe ich gesehen, dass bei beiden WR sowohl die gleiche SUSyID als auch die gleiche Seriennummer (und zwar die vom TriPower) angezeigt wird. Kann es sein, dass da was durcheinander geht?

Schönen Gruß

Kai

[DS_Starter]

Hallo zusammen,

@Jörg ... guter Hinweis  
Danke , habe ich in der angehängten V.2.7.4 für die beiden Module IO::Socket::INET und  DateTime so umgesetzt.

@Kai ... die ursprüngliche Ausgangsversion SMAInverter habe ich "nur" dahingehend umgebaut dass die internen Modulabläufe auf nonblocking umgestellt wurden. An der eigentlichen Kommandostruktur in Richtung WR hat sich nichts geändert. -> es kann sich demzufolge für dein spezielles Problem keine Änderung ergeben haben.

M.M. nach müßte das gesetzte Attribut "target-serial" u.U. in Verbindung mit Attr "target-susyid" auf die entsprechende Seriennummer/SUSyID des WR für den die jeweilige Device-Definition angelegt wurde ausreichen um den zugeordneten WR zu identifizieren und nichts durcheinanderkommen zu lassen.

Allerdings bin ich mit der Befehlsstruktur Richtung WR nicht so vertraut und möchte Waldmensch bzw. Thomas insofern bitten in die Diskussion dieses Problems einzusteigen. Ich helfe gern mit entsprechende Erkenntnisse im Modul umzusetzen.

Grüße
Heiko

[Waldmensch]

Da hört es leider mit meinen Kenntnissen über das Protokoll auch auf. Ich habe nur sehr selektiv in sbfspot rumgestochert.


Gesendet von iPhone mit Tapatalk

[Xguide]

Guten Morgen zusammen,

ich habe mir am Samstag mein fhem ziemlich zerschossen, inzwischen habe ich alles wieder in Ordnung.
Somit bin ich mit der Testerei ein wenig hintendran. Jetzt aber 
@Heiko, Danke für die Implementierung von processingtime, ich denke damit komme ich dem Timing-Problem auf die Spur. Ferner bin ich deinem Ratschlag mit einem nicht blockierenden sleep gefolgt, das Notify des EnergyMeter sieht jetzt so aus:

Code Auswählen Erweitern


SMA_EnergyMeter:Einspeisung_Wirkleistung:.* { 
  Log 3, "Notify_SMA_EnergyMeter: Notify triggert with event: ".$EVENT;
  fhem "get SMA_TriPower10 data;sleep 1.0;get SMA_SunnyIsland data"; 
}

Ich werde nun ein wenig mit den Zeiten spielen, 1s ist mein Initialparameter - mit der Asynchronität könnte ich ohnehin leben, nur möchte ich gerne die Meldung "Timeout for getstatus_DoParse reached, terminated process xxxx"aus dem Log eliminieren.
Außerdem habe ich für die processingtime für den Bat-WR und PV-WR ein notify angelegt, exemplarisch das für den PV-WR:

Code Auswählen Erweitern


SMA_TriPower10.(background_processing_time|inverter_processing_time):.* { 
  my $processingtime = 0.0;
  $processingtime = $EVTPART1;
  Log 5, "Notify_SMA_TriPower10_Debug: processing time: ".$EVENT;
  Log 5, "Notify_SMA_TriPower10_Debug: processing time: ".$EVTPART1;
  if ($processingtime > 1.0) {
     Log 1, "Notify_SMA_TriPower10_Debug: processing time: ".$EVTPART0." = ".$processingtime;
  }
}


Bisherige Ergebnisse:
PV-WR@detail-level2:
inverter_processing_time: 0.3683
background_processing_time: 0.5985

Bat-WR@detail-level2:
inverter_processing_time: 0.1088
background_processing_time: 0.3403

Testkonfiguration:
1. Energymeter läuft im 45s Zyklus mit einem timeout von 40s
2. Energymeter hat als attribute event-on-update-reading Einspeisung_Wirkleistung gesetzt.
    Somit wird bei jedem Lesen, also alle 45s das getdata vom PV-WR und Bat-WR mit o.g. notify angestoßen

Mal sehen welche Aufschlüsse das bringt

Euch einen sonnigen Tag,

Marcel

Hallo,

hier nochmal eine kleine Verbesserung in V2.7.1. 
Die processing_time Readings werden selektiv gelöscht wenn das Attribut "showproctime" nicht mehr gesetzt wird.
In der sleep-Phase trat auch eine "unitialized"-Meldung in der V2.7 auf, die durch die Berechnung der Prozesstime-Readings hervorgerufen wude -> gleich mit gelöst.

@Marcel, mir sieht das recht eigenartig aus dass die Timeouts so gut wie immer gleichzeitig bei beiden WR auftreten. Zumindest wenn ich das richtig in deinem Log interpretiere. Es scheint recht unwahrscheinlich dass beide WR gleichzeitig keine rechtzeitige Antwort senden.
Vorschlag: versuche doch mal in deinem Notify das "get data" eines der beiden WR gegenüber dem anderen zu verzögern (z.B. mit einem nicht blockierenden sleep oder AT).

[Xguide]

Hallo Heiko,

ich noch einmal.
Ich habe trotz der oben beschriebenen Maßnahmen wieder einen Eintrag im Log erhalten. Natürlich ohne einen Eintrag des erweiterten Loggings, was mich doch sehr verunsichert.
Jetzt zweifel ich gerade an mir selbst, ich habe sowohl 76_SMAInverter als auch 77_SMAEM.pm nach einer Stelle durchsucht, bei der ein LogEintrag für verbose = 0 wie "Timeout for getstatus_DoParse reached, terminated process XXXX" erzeugt wird. --> Natürlich vergeblich...

Jetzt ist mir klar das der Eintrag aus Blocking.pm kommt, allerdings fehlen mir komplett die Zusammenhänge. Das Einzige was ich sagen kann, die Meldung tritt auf, ohne das 76_SMAInverter eine Laufzeit > 1s hatte. Kann mich bitte noch mal jemand in die richtige Richtung stubsen? Danke!

Grüße Marcel

[Xguide]

Noch mal ein wenig darüber nachgedacht und nach nochmaligem Lesen der alten Threads, ist mir nun klar das die processingtimes nicht geschrieben werden können, wenn der Prozess zuvor abgeschossen wird. Da es bei mir nun wirklich nur noch sporadisch auftaucht, habe ich die von Dir genannte Stelle mal in das LogLevel 0 übernommen und versuche nun herauszufinden ob es der PV oder Bat-WR ist, der für den Abbruch sorgt. LogLevel 0 damit das Log trotzdem übersichtlich bleibt.

Code Auswählen Erweitern

Log3 ($name, 0, "SMAInverter $name - WARNING - old process $hash->{HELPER}{RUNNING_PID}{pid} will be killed now to start a new BlockingCall");

Naja, es wird aber jetzt schon mit verbose 3 ein Logeintrag erzeugt wenn ich explizit einen Vorläufer kille.
Sieht so aus:

Code Auswählen Erweitern

Log3 ($name, 3, "SMAInverter $name - WARNING - old process $hash->{HELPER}{RUNNING_PID}{pid} will be killed now to start a new BlockingCall");

das hilft schonmal Ursachen zu ergründen.  Verbose = 3 !

[DS_Starter]

Hallo zusammen,

die von Kai gemeldeten Ungereimtheiten bei der Verwendung von 2 Invertern hat mir keine Ruhe gelassen und so habe ich mir doch mal den Aufbau der Befehlssektionen angeschaut.
Ich bin da auch fündig geworden was möglicherweise das Problem lösen könnte. Meiner Meinung nach war die Zuordnung der empfangenen Daten zu der entsprechenden FHEM-Definition ungenügend, auch die login/logout-Sequenzen sprachen alle vorhandenen Inverter an.

Das habe ich (hoffentlich) in der angehängten Version 2.8 gefixt.

Ihr müßt auf jeden Fall die Attribute target-serial und target-susyid richtig setzen wenn ihr mehrere Inverter definiert habt. Ist nur einer (wie bei mir) vorhanden brauchen die nicht gestzt sein, schadet aber auch nicht. Nur richtig müssen sie dann sein !
(Wenn die Attribute nicht gesetzt sind werden alle Inverter im Netz angesprochen)

Die Ausschriften für verbose 4 habe ich auch verbessert. So wird auch die Anzahl der seit FHEM Start aufgetretenen Timeouts für dieses Device im Log angezeigt und die Serial des betreffenden Geräts mit ausgegeben. Ihr seht das dann schon.

Bei mir funktioniert das Ganze sauber, allerdings habe ich nur einen WR und kann den Erfolg nicht testen.
Aber ich hoffe euch geholfen zu haben.

Bitte FHEM restarten !

Grüße
Heiko

[kdeb]

Hallo Heiko,

wo finde ich denn die richtigen susyid für meine WR?

Kai

[DS_Starter]

Hallo Kai,

Ich habe die noch aus der SBFSpot-Zeit. Aber möglicherweise steht die auf dem Typenschild bzw. Im SMA Portal unter den Anlageneigenschaften des WR. Bin grad unterwegs und kann nicht selbst schauen.

Du kannst auch erstmal nur mit serial arbeiten. Vllt ist susyid bei allen WR gleich 181. Probiere es mal aus.

VG
Heiko

[DS_Starter]

Hab im SMA Portal geschaut.
Unter Konfiguration - Geräteübersicht - WR - Parameter findest du die susyid der Kommunikationsbaugruppe und die Seriennummer des Hauptprozessors.