76_SMAInverter.pm - Abfrage von SMA Wechselrichter

Begonnen von sct14675, 28 Juli 2016, 11:01:16

Vorheriges Thema - Nächstes Thema

bismosa

Hallo!

Zitat von: MadMax am 04 Mai 2025, 13:21:17Bitte mal auf Verbose 5 stellen und dan ein Log einstell wo der Fehler auftritt.

Gruß
Max

Ist ja schon ein paar Tage her. Da ich noch ein paar anderen Fehlern auf der Spur war und vermutet habe, das dies auch durch ein blockierendes FHEM verursacht werden könnte, habe ich mich erst damit beschäftigt.
Die hier oft genannte Netzwerkanbindung sollte eigentlich gut sein (mit iPerf getestet - GBit kommt an). Der Switch steht ca. 10m entfernt und ich habe überall GBit.
Ich glaube eher, das der WR manchmal keine Lust hat zu antworten, da er in der Zeit beschäftigt ist. Ich benötige auch einen sehr kurzen Abfrageintervall.

Ich habe festgestellt, das die Antworten an unterschiedlicher Stelle vom WR unterbleiben. Hier ein Auszug von gestern. Zwischendurch lief es problemlos durch:
2025.06.05 10:59:07 5: SMAInverter -> sup_GridRelayStatus
...
2025.06.05 10:59:21 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 10:59:22 5: SMAInverter -> sup_GeneralOperatingStatus
...
2025.06.05 10:59:36 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 10:59:52 5: SMAInverter -> sup_GridRelayStatus
...
2025.06.05 11:00:06 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 11:02:07 4: SMAInverter -> EM 3
...
2025.06.05 11:02:21 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 11:02:22 4: SMAInverter -> EM 2
...
2025.06.05 11:02:36 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 14:01:11 5: SMAInverter -> sup_TypeLabel
...
2025.06.05 14:01:25 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated

2025.06.05 14:05:41 4: SMAInverter - Send login to ...
...
2025.06.05 14:05:55 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated


So sieht es bei dem anderen Fehler aus:
2025.06.05 10:55:22 5: SMAInverter -> sup_SpotDCVoltage
2025.06.05 10:55:22 3: SMAInverter - Send request 00028053001F4500FF214500 to ...
2025.06.05 10:55:22 5: SMAInverter - send: 534D4100000402A00000000100260010606509A098018760D7B30000E900...000000000000088000028053001F4500FF21450000000000
2025.06.05 10:55:22 5: SMAInverter - Received: 534d4100000402a00000000100420010606510a0e900...00a098018760d7b30000000000000680010200510000000000000000013f2640795b4168ab090000ab090000ab090000ab0900000100000000000000
2025.06.05 10:55:22 3: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 10:58:22 4: SMAInverter -> EM 1
2025.06.05 10:58:22 3: SMAInverter - Send request 0002005400244600FF284600 to ...
2025.06.05 10:58:22 5: SMAInverter - send: 534D4100000402A00000000100260010606509A098018760D7B30000E900...00000000000011800002005400244600FF28460000000000
2025.06.05 10:58:22 5: SMAInverter - Received: 534d4100000402a00000000100420010606510a0e900...00a098018760d7b3000000000000078001020051230000002300000001c246002d5c4168640a0000640a0000640a0000640a00000100000000000000
2025.06.05 10:58:22 3: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 14:02:41 4: SMAInverter - Send login ...
2025.06.05 14:02:41 5: SMAInverter - Send: 534D4100000402A000000001003A001060650EA098018760D7B30001E900...00010000000001800C04FDFF07000000840300006187416800000000DBF5F7F4F601BAB8BABCA98800000000
2025.06.05 14:02:41 5: SMAInverter - Received: 534d4100000402a000000001007a001060651ea0e900...00a098018760d7b30000000000000a80010200511300000015000000015346406187416853230000532300005323000053230000010000000154464061874168212300002123000021230000212300000100000001554640618741684d2300004d2300004d2300004d2300000100000000000000
2025.06.05 14:02:41 1: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 14:21:27 4: SMAInverter - Send login ...
2025.06.05 14:21:27 5: SMAInverter - Send: 534D4100000402A000000001003A001060650EA098018760D7B30001E900...00010000000001800C04FDFF0700000084030000C78B416800000000DBF5F7F4F601BAB8BABCA98800000000
2025.06.05 14:21:27 5: SMAInverter - Received: 534d4100000402a00000000100420010606510a0e900...00a098018760d7b30000000000000680010200510000000000000000013f2640c78b4168550700005507000055070000550700000100000000000000
2025.06.05 14:21:27 1: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 14:22:12 5: SMAInverter -> sup_SpotDCPower
2025.06.05 14:22:12 3: SMAInverter - Send request 00028053001E2500FF1E2500 ...
2025.06.05 14:22:12 5: SMAInverter - send: 534D4100000402A00000000100260010606509A098018760D7B30000E900...000000000000048000028053001E2500FF1E250000000000
2025.06.05 14:22:12 5: SMAInverter - Received: 534d4100000402a00000000100420010606510a0e900...00a098018760d7b30000000000000b8001020051160000001600000001574600f48b4168871300008713000087130000871300000100000000000000
2025.06.05 14:22:12 3: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 14:22:42 5: SMAInverter -> sup_SpotACVoltage
2025.06.05 14:22:42 3: SMAInverter - Send request 0002005100484600FF564600 ...
2025.06.05 14:22:42 5: SMAInverter - send: 534D4100000402A00000000100260010606509A098018760D7B30000E900...00000000000009800002005100484600FF56460000000000
2025.06.05 14:22:42 5: SMAInverter - Received: 534d4100000402a000000001007a001060651ea0e900...00a098018760d7b3000000000000058001020051090000000b00000001404640128c4168b8020000b8020000b8020000b80200000100000001414640128c4168b0020000b0020000b0020000b00200000100000001424640128c4168b7020000b7020000b7020000b70200000100000000000000
2025.06.05 14:22:42 3: SMAInverter - Inverter answer does not match our parameters.

2025.06.05 14:27:28 4: SMAInverter -> EM 4
2025.06.05 14:27:28 3: SMAInverter - Send request 0002005100E84600FFED4600 ...
2025.06.05 14:27:28 5: SMAInverter - send: 534D4100000402A00000000100260010606509A098018760D7B30000E900...00000000000014800002005100E84600FFED460000000000
2025.06.05 14:27:28 5: SMAInverter - Received: 534d4100000402a000000001009e0010606527a0e900...00a098018760d7b30000000000000280010200580100000003000000011e821018074168...000000000000000000000000000000000000011f820818074168411f0001feffff0000000000000000000000000000000000000000000000000001208208180741688324000084240001feffff00000000000000000000000000000000000000000000000000
2025.06.05 14:27:28 3: SMAInverter - Inverter answer does not match our parameters.
(Ich hoffe ich habe Seriennummern richtig maskiert...)

Insgesamt stört es mich nur, das sehr viele Meldungen in der FHEM Logdatei ankommen. Das mal Werte fehlen ist nicht weiter schlimm.
Könnte man das vielleicht reduzieren, das man z.B. erst ab einer gewissen Anzahl an Fehlern protokolliert? Vielleicht per Attribut?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

MadMax

Das Halte ich für sehr schwierig.
Da müsste ich ja für jede meldung einen Counter anlegen der zählt wie oft eine Meldung kommt.
Außerdem würde das ja auch die Fehlersuche ersachwären.

Setz das Module auf Verbose 0 und duc hast ruhe.

Gruß
Max
Lenovo M910Q Tiny Debian 12, FHEM 6.3, 2x Siemens Logo 0BA7, Homematic CCU3, Philips HUE, 6x SMA Wechselrichter, BYD HVM, BYD HVS, SMA EVCharger, KEBA Wallbox, 2x HMS800W, Daikin Wärmepumpe über CAN, viele ESPs

Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/MadMax

300P

Hallo Zusammen,

auch ich bin für ein sehr "cleanes" Logbuch.....aber....:

Aktuell gibt es nur folgende Einträge bei einem gesetzten verbose "2" im Code
Zeile    Code
1719    Log3 $name, 1, "$name - ERROR - Can't open socket to inverter: $!";
1442    Log3 $name, 1, "$name - Nothing received...";
2595    Log3 $name, 1, "$name - ERROR - Can't open socket to inverter: $!";
2621    Log3 $name, 1, "$name - Nothing received...";
2638    Log3 $name, 1, "$name - Inverter answer does not match our parameters.";
2646    Log3 $name, 1, "$name - Format of inverter response does not fit.";
2743    Log3 $name, 1, "$name - ERROR - Can't open socket to inverter: $!";

Eventuell kann Mad_Max  O:-) ja noch in Zeile 2638 von "1" auf "3" umstellen (wie es in Zeile 1756 ist ;), aber die anderen (aktuellen mit "1") sollten schon so bleiben. ("2"-er hab ich garnicht gesehen)

Als Empfehlung gilt es bekanntlich eigentlich "attr global verbose 2" zu setzten.
Bei einem "neu" eingesetzten Modul sollte man einige Zeit mit für das Modul extra separat gesetztem "attr <devicename> verbose 3" das Modul beobachten bzw. nur bei der Fehlersuche dann auf 4 oder 5 setzen.

verbose
Setzt den Schwellwert für die Logfile-Meldungen. Mögliche Werte sind:
0 - Server start/stop
1 - Fehlermeldungen oder unbekannte Pakete
2 - bedeutende Ereigbisse/Alarme.
3 - ausgesendete Kommandos werden gelogged.
4 - von den einzelnen Geräten empfangene Daten.
5 - Fehlersuche.
Der für die global Instanz gesetzte Wert gilt als Voreinstellung für die Instanzen, die dieses Attribut nicht gesetzt haben

Ansonsten sollte es so bleiben wie es ist. :-[

Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

bismosa

Hallo!

Derzeit lasse ich es weiterhin ganz normal laufen und lebe einfach mit den vielen Logeinträgen. Ist ja auch kein Problem.
Letztendlich hat es ja was im Log zu suchen. Verbindung funktioniert nicht - Meldung.
Es lässt sich nur nicht wirklich abgrenzen ob die Verbindung mal ganz verloren gegangen ist. Aber selbst das lässt sich auf anderen Wegen problemlos lösen.

Nach einiger Zeit meldet sich ja auch schon das Sunny Portal wenn die Internetverbindung oder eben die Verbindung weg ist  :)

Die Logs bereinige ich meist mit Notepad++ und schmeiße die Zeilen einfach raus. Dann kann ich schneller sehen, was sonst im System so los ist...aber auch wie oft es hier nicht funktioniert hat.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

cwagner

Dankenswerterweise hast, glaube ich Du MadMax, vor einiger Zeit die Übernahme einiger Readings vom SMAEM-Device (HomeManager) eingefügt: Meter_.*
Unklar ist mir der Grund für Meter_TOTAL_Consumation und METER_Total_Grid_Consumation bzw. Meter_TOTAL_FeedIn und Meter_TOTAL_Grid_Feedin. Sie haben bei mir jeweils den gleichen Wert des entsprechenden Zählers vom HomeManager.
Ich hätte eher erwartet, das es so etwas wie ein Meter_Total_FeedinDay gäbe, also einen vom Zähler abgeleiteten Tageszähler.

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

300P

Bei mehr als einem WR ist der eingespeiste Strom m.M.n nicht auseinander zu halten - also als Datenquelle kann der EM/HM für die Einspeisung der einzelnen WR-Anteile da nicht zutreffend sein.
Mag zwar sein, dass dies für "nur" einen WR sauber paßt weil alles an Einspeiseleistung von diesem ist.
Aber das scheidet dann ab 2+x WR sicherlich aus, vor allem wenn diese 2+x WR evtl. mit 3 Phasen angebunden und somit (teilweise) mit mehr als einer Phase am NÜP einspeisen können ?!?  :o
Oder liege ich falsch mit meiner Sicht ? ;)
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

cwagner

Um die Einspeisung mehrerer WR auseinanderzuhalten, muss man auf die Zähler der einzelnen Wechselrichter zurückgreifen, solange man mit einem einzigen Home Manager arbeitet.
Die Einspeisung interessiert ja nmM nach aus mindestens 2 Gründen: Gegenkontrolle zum amtlichen Zähler, der ja sowieso alle einspeisenden Geräte über alle Phasen saldiert, aber vor allem, um maschinell die Größe des gerade anliegenden Überschuss zu
erkennen und für Steuerungsaufgaben zu nutzen. Beispielsweise über das Modul SolarForecast.

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

300P

Kontrollwerte sind schon vorhanden:
(Je nach Wechselrichter bei mir zu sehen ;) )

Siehe Reading...
Meter_Grid_Consumation_phase_1_pac
Meter_Grid_Consumation_phase_2_pac
Meter_Grid_Consumation_phase_3_pac
Meter_Grid_FeedIn_phase_1_pac
Meter_Grid_FeedIn_phase_2_pac
Meter_Grid_FeedIn_phase_3_pac
Meter_TOTAL_Consumation
Meter_TOTAL_FeedIn
Meter_TOTAL_Grid_Consumation
Meter_TOTAL_Grid_FeedIn
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.