76_SMAInverter.pm - Abfrage von SMA Wechselrichter

[anstroe]

Hallo Marcel & Heiko,
beide liefern jetzt Daten, es hat also wirklich nur an dem vergessenen "Nein" gelegen...
Bei SunnyIsland werden zwar nicht alle in der commandref angegebenen Readings angezeigt, ich vermute, dass das aber abhängig vom Typ ist, welche angezeigt/ausgelesen werden?!

Danke für eure Hilfe!
Anne

[DS_Starter]

Hallo Anne,

proma dass nun alles klappt.

Bei SunnyIsland werden zwar nicht alle in der commandref angegebenen Readings angezeigt, ich vermute, dass das aber abhängig vom Typ ist, welche angezeigt/ausgelesen werden?!

Ja, so ist es.

LG
Heiko

[DocCyber]

@Klaus, ich habe noch eine Idee.

Hallo Heiko,

es scheint, als ob hier massiv der Wurm drin ist, denn es geht NICHTS mehr.
SMAEM liefert keine Werte mehr; letzte geloggte Werte von gestern Mittag.

Der Sunny Explorer liefert genau so wenig Daten wie die SMA Android App: keine!
Bei sunnyportal.com gibt es eine Fehlermeldung: Die Kommunikation mit dem Sunny Home Manager ist zurzeit nicht möglich.

Überflüssig zu erwähnen, das auch tcpdump nichts liefert.   

Kann es sein, dass der SHM eine Fehlfunktion hat und dadurch alles weitere stört?

[DocCyber]

Teilweise Entwarnung.   

Die Kommunikation mit dem SHM funktioniert nach einem Reset wieder.

tcpdump liefert Werte des EM im Sekundentakt, so wie du es beschrieben hast.

Ergebnis mit  tcpdump udp port 9522 -vv -X | grep 192.168.178.36 sieht so aus wie bei dir.
Wenn ich das Resultat richtig deute, dann werden Werte vom Raspi rausgeschickt (auch wenn da etwas klemmt), und es kommen Werte zurück.


Die Module IO::Socket::INET  und  Datetime waren übrigens okay; also korrekt installiert.

[Xguide]

Hallo Klaus,

das klingt ja alles sehr komisch.
Liefert der WR denn wieder Werte ins Portal?
Ich kann mich noch an einen Fall bei mir erinnern, da habe ich durch einem falsch konfigurierten WLAN-Repeater ordentlich Schwung ins Netz gebracht und die Ethernetschnittstelle vom WR hat sich aufgehängt. Ich habe daraufhin mit SMA gesprochen und die kannten das Problem. Anmerkung, der WR hat auch keine Daten mehr über den SHM ins Portal geliefert.
Die Lösung war, nicht ganz naheliegend, den WR über den FI in der Nacht abzuschalten und mindestens 3h in diesem Zustand ohne Energieversorgung durch PV, deshalb in der Nacht, zu belassen. Am nächsten Morgen habe ich den FI wieder reingenommen und alles lief wieder.
Ein Versuch ist es wert, macht ja nichts kaputt wenn Du den FI heute Nacht rausnimmst und rechtzeitig wieder einschaltest.

Gruß Marcel

PS: Hat Anne den gleichen WR wie Du?

[DocCyber]

Hallo Marcel,

nein, Anne hat einen anderen WR - leider. Wäre ja sonst alles zu einfach...

Ja, bei mir läuft so weit wieder alles.
Nachdem ich den SHM von der Wand genommen hatte, um die Bluetooth-NetID auf Null zu setzen, habe ich danach das Netzteil wohl nicht kräftig genug eingestöpselt.
Als ich das endlich gemerkt und einen Rest durchgeführt hatte, ging's dann wieder. Hab also unnötige Panik verusacht.

Ich habe alles nochmals gecheckt, auch mittlerweile mal ein "echtes" password angelegt    und die DEF in FHEM angepasst.
Nur sehe ich leider noch immer keine Daten in FHEM via SMAInverter.
Bin schon "froh", dass tcpdump Traffic zwischen Raspi und WR registriert.

Du meinst also, ich sollte den WR über Nacht mal komplett vom Strom trennen?
Klar, das ist einen Versuch wert.

Aber es bleiben jede Menge Fragen offen.

[DS_Starter]

Hallo zusammen,

Ergebnis mit  tcpdump udp port 9522 -vv -X | grep 192.168.178.36 sieht so aus wie bei dir.
Wenn ich das Resultat richtig deute, dann werden Werte vom Raspi rausgeschickt (auch wenn da etwas klemmt), und es kommen Werte zurück.

Das ist ein wichtiges Ergebnis. Für mich stellt es sich nun so dar als dass die Netzwerkkommunikation prinzipiell funktioniert.
Entweder funktioniert nun etwas mit dem Socketaufbau nicht, oder aber für deinen speziellen WR-Typ braucht das Modul eine Anpassung weil der Befehlsaufbau/die Datagramme anders sind (wohl der schlechteste Fall).

Um den Socketaufbau zu testen würde ich dich bitten andere Module, die den UDP-Stack verwenden, in der fhem.cfg vorübergehend auszukommentieren, vor allem SMAEM (vieleicht auch andere, weiß nicht was du so hast).  Dann brauchst du die Devices nicht zu löschen.
Wie oft darauf hingewiesen wird soll man die fhem.cfg nicht manuell bearbeiten, aber in diesem speziellen Fall ist es wohl die einfachste Lösung um das zu testen.

Danach FHEM restarten und dann schauen wir wieder ob sich etwas tut .....

[DocCyber]

Hallo Heiko,

Ich habe mal ein wenig gestöbert. Es sieht so aus, als ob das Problem mit bad udp cksum "normal" ist. Leider kenne ich mich mit Netzwerk-Details nicht aus, aber ich meine, dass dieser kurze Artikel die Ursache ganz gut erklärt:
https://sokratisg.net/2012/04/01/udp-tcp-checksum-errors-from-tcpdump-nic-hardware-offloading/

Zwischenzeitlich habe ich die SMAEM auskommentiert und den FHEM-Server neu gestartet.
Änderungen haben sich dadurch aber nicht ergeben; tcpdump liefert regelmäßig alle 60s das selbe Resultat wie gestern.

Übrigens:
In meiner Fritzbox finde ich u.a. das SMA-Energy Meter und den SMA Home Manager in der Liste der aktiven Verbindungen, während u.a. der WR bei den ungenutzten Verbindungen aufgeführt ist. Ist das bei dir auch so? (Anm: RX-V779 ist mein Pioneer AV-Receiver)

[DS_Starter]

Ist das bei dir auch so?

Ja, scheint so. Ich habe vor meinem Speedport Hybrid einen DDWRT-Softwarerouter eingebaut  (ohne diesen bekomme ich ständig Timeouts der SMA-Komponenten, mit dem alten Speedport 901V hatte ich das Prob nicht).
Aber auch hier fehlt der WR in der Liste der aktiven Clients.
Von den SMA-Komponenten taucht nur der Sunny Home Manager ...42, in der Liste auf.
Dennoch läuft alles super.

Grüße
Heiko

[DocCyber]

Dennoch läuft alles super.

Schade ... 
ich dachte, ich hätte eine mögliche Ursache meiner Probleme gefunden.

Eine potenzielle Fehlerquelle gibt es aber noch:
Derzeit nehme ich an einem Feldversuch mit PV-Anlagen teil, die von der RWTH Aachen durchgeführt wird. Die Mitarbeiter haben eine komplexe Installation diverser Messinstrumente bei mir installiert.
Jetzt frage ich mich natürlich, ob die Messmimik mit meinen Problemen zusammen hängt.
Ich habe schriftlich nachgefragt und warte auf Antwort.

Klaus

[DS_Starter]

Hallo Klaus,

naja, das wäre zumindest eine Abweichung einer normalen PV-Installation. Aber da die bidirektionale Kommunikation irgendwie doch zu funktionieren scheint, habe ich dir mal ein Testmodul gemacht.
Wenn du die angehängte Datei runterlädst, umbennenst und fhem restartest dann solltest du mit verbose 4 auf jeden Fall eine Zeile  im Log finden die so aussieht:

2017.07.16 15:32:55.738 4: MySTP_5000 - ###############################################################
2017.07.16 15:32:55.738 4: MySTP_5000 - ##########  Begin of new SMAInverter get data cycle  ##########
2017.07.16 15:32:55.738 4: MySTP_5000 - ###############################################################
2017.07.16 15:32:55.738 4: MySTP_5000 - timeout cycles since module start: 15
2017.07.16 15:32:55.744 4: MySTP_5000 -> Start BlockingCall getstatus_DoParse
2017.07.16 15:32:55.806 4: MySTP_5000 - current time: 16.07.2017 15:32:55
2017.07.16 15:32:55.806 4: MySTP_5000 - operation time begin: 16.07.2017 04:29:50
2017.07.16 15:32:55.806 4: MySTP_5000 - operation time end: 16.07.2017 22:05:00
2017.07.16 15:32:55.807 4: MySTP_5000 - Send login to 192.168.2.40 on Port 9522 with password ...........
2017.07.16 15:32:55.839 4: MySTP_5000 - Received Size: 78

Das ist die Länge der empfangenen Zeichen nach dem Login-Kommando.

[DocCyber]

Hallo Heiko,

leider schon wieder eine Enttäuschung:

Code Auswählen Erweitern


2017.07.16 16:07:11 0: Server shutdown
2017.07.16 16:07:14 1: Including fhem.cfg
2017.07.16 16:07:14 2: eventTypes: loaded 2065 events from ./log/eventTypes.txt
2017.07.16 16:07:14 1: HMLAN_Parse: HM_CFG_LAN new condition disconnected
2017.07.16 16:07:14 1: HMLAN_Parse: HM_CFG_LAN new condition init
2017.07.16 16:07:17 1: Including ./log/fhem.save
2017.07.16 16:07:20 2: FB_CALLMONITOR (callMonitor) - read 52 contacts from remote phonebook "Telefonbuch"
2017.07.16 16:07:20 2: FB_CALLMONITOR (callMonitor) - read 56 contacts from remote phonebook "Beruflich"
2017.07.16 16:07:20 0: Featurelevel: 5.7
2017.07.16 16:07:20 0: Server started with 267 defined entities (fhem.pl:13411/2017-02-14 perl:5.020002 os:linux user:fhem pid:14103)
2017.07.16 16:07:20 1: HMLAN_Parse: HM_CFG_LAN new condition ok
2017.07.16 16:07:22 4: sunnyBoy - ###############################################################
2017.07.16 16:07:22 4: sunnyBoy - ##########  Begin of new SMAInverter get data cycle  ##########
2017.07.16 16:07:22 4: sunnyBoy - ###############################################################
2017.07.16 16:07:22 4: sunnyBoy - timeout cycles since module start: 0
2017.07.16 16:07:22 4: sunnyBoy -> Start BlockingCall getstatus_DoParse
2017.07.16 16:07:22 4: sunnyBoy - current time: 16.07.2017 16:07:22
2017.07.16 16:07:22 4: sunnyBoy - operation time begin: 16.07.2017 04:54:09
2017.07.16 16:07:22 4: sunnyBoy - operation time end: 16.07.2017 22:26:24
2017.07.16 16:07:22 4: sunnyBoy - Send login to 192.168.178.36 on Port 9522 with password xxxxxxxxxx
2017.07.16 16:07:22 5: sunnyBoy - Send: 534D4100000402A000000001003A001060650EA0FFFFFFFFFFFF0001E......

Mehr kommt nicht!!

Ich habe noch nicht auf FHEM 5.8 umgestellt. Kann das ein Problem mit Blick auf SMAInverter darstellen?
(Meine FTUI-Installation ist seit Kurzem fertig. Sie läuft wirklich schön rund, aber eine Umstellung auf FHEM 5.8 würde einige Nacharbeit bedeuten, für die aktuell keine Zeit habe.)

Ich habe gelesen, dass man mit UDP generell keine "Garantie" erhält, dass die Datenpakete, die verschickt werden, auch wirklich beim gewünschten Empfänger ankommen.
Ist da etwas dran?

[DS_Starter]

Hallo Klaus,

Ich habe noch nicht auf FHEM 5.8 umgestellt. Kann das ein Problem mit Blick auf SMAInverter darstellen?

Ich denke nicht, das Modul läuft schon lange und auch schon mit 5.7. Außerdem finden sich bei dir auch keinerlei Fehlermeldungen.

Die UDP-Pakete kommen laut tcpdump bei dem Raspi an, nur werden diese offensichtlich nicht an den vom Modul geöffneten Socket weitergegeben.
Für die Insider unter uns... die relevante Stelle ist diese:

# Create Socket and check if successful
$socket = new IO::Socket::INET (PeerHost => $host, PeerPort => 9522, Proto => 'udp',); # open Socket

if (!$socket) {
     # in case of error
     Log3 $name, 1, "$name - ERROR - Can't open socket to inverter: $!";
     return 0;
};

# Send Data
$data = pack("H*",$cmd);
$socket->send($data);
Log3 $name, 4, "$name - Send login to $host on Port 9522 with password $pass ";
Log3 $name, 5, "$name - Send: $cmd ";
   
# Receive Data and do a first check regarding length
eval {
     $socket->recv($data, $hash->{HELPER}{MAXBYTES});
     $size = length($data);
     Log3 $name, 4, "$name - Received Size: $size";
};


Wenn der Socket hätte nicht geöffnet werden können müste normal ein Fehler geworfen werden -> ist bei dir nicht so. Ergo sollte der Socket offen sein.
Es werden nur, aus welche Gründen auch immer, keine Daten von der Schnittstelle an den Socket weitergegeben (der rote Bereích).

Ich schlage dir vor folgendes zu machen. Um deine produktive Umgebung nicht weiter zu stören installiere dir auf einem Windows-PC Virtualbox. Installiere darin dann ein Debian und ein nackiges FHEM. In dieser Installation kann man dann nach herzenslust experimentieren. Wenn du noch einen anderen Raspi/Rechner haben solltest dann würde ich den nehmen.

Momentan gehen mir gerade die Ideen etwas aus, aber vllt. haben unsere Mitstreiter noch etwas beizusteuern, vor allem was die Socket-Kommunikation betrifft.

Grüße
Heiko

[DocCyber]

Danke, Heiko, für deine fortwährende Unterstützung.

Ich habe in der Tat noch einen weiteren Raspi.
In den nächsten Tagen werde ich mich mal daran geben, eine Testumgebung darauf zu installieren.
Leider bin ich zeitlich nicht ganz so flexibel wie nötig.

[thor3]

Hallo,
Vor ca 6. Monaten hatte ich mal mit einem Sunny Boy 1.5 zu tun. Der tat erst dann mit fhem, nachdem  am WR unter Externe Kommunikation modbus tcp-Server   aktiviert wurde und bei Port 9522 eingetragen wurde. Vielleicht hilft es  ja.


Gesendet von iPad mit Tapatalk