76_SMAInverter.pm - Abfrage von SMA Wechselrichter

DS_Starter · 15 August 2019, 08:30:10

Moin miteinander,

ich habe den STP6.0-3AV-40 und noch ein paar andere in den known Types nachgetragen in der Hoffnung dass Waldmensch recht hat.

Ich hoffe es und es klingt für mich auch schlüssig, sonst würde SBFSpot auch nicht so schnell auf neue Typen reagieren können.

Bitte aus meinem contrib ziehen.
Wenn das klappt, müssen wir einfach mal den Type-Hash aufpeppen.

Grüße,
Heiko

Waldmensch · 15 August 2019, 08:35:14

@DS_Starter: guck Dir mal den 2 Beiträge weiter oben verlinkten Patch an. Der Zahlentyp der Serial wurde geändert und die Einsprungadresse. Eventuell sind die neuen Seriennummern länger, was jetzt erst aufgefallen ist.

Gesendet von iPhone mit Tapatalk

Dersch · 15 August 2019, 08:45:47

Zitat von: DS_Starter am 14 August 2019, 23:20:55
Hallo Dirk,

du könntest mal beim SMAInverter-Modul verbose 5 einschalten und das Ergebnis posten.
Aber ich vermute, dass Marcel leider recht hat bezüglich der momentanen Inkompatibilität des Moduls mit dem WR.

Grüße,
Heiko

Das spuckt er mir aus:

Code Auswählen

2019.08.15 08:36:10 3: SMATRIPOWER: unknown attribute DbLogExclude. Type 'attr SMATRIPOWER ?' for a detailed list.
2019.08.15 08:36:10 3: nDbLogExclude return value: SMATRIPOWER: unknown attribute DbLogExclude. Type 'attr SMATRIPOWER ?' for a detailed list.
2019.08.15 08:36:15 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:37:02 3: SMAInverter SMATRIPOWER - WARNING - old process 1586 will be killed now to start a new BlockingCall
2019.08.15 08:37:02 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:37:02 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:37:47 1: Timeout for MilightBridge_DoPing reached, terminated process 1656
2019.08.15 08:37:47 3: BlockingCall for MilightBridgeKu was aborted
2019.08.15 08:38:02 3: SMAInverter SMATRIPOWER - WARNING - old process 1614 will be killed now to start a new BlockingCall
2019.08.15 08:38:02 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:38:06 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:39:05 3: SMAInverter SMATRIPOWER - WARNING - old process 1694 will be killed now to start a new BlockingCall
2019.08.15 08:39:05 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:39:06 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:39:19 3: CUL_HM set AkFensterkontakt getConfig
2019.08.15 08:40:08 3: SMAInverter SMATRIPOWER - WARNING - old process 1743 will be killed now to start a new BlockingCall
2019.08.15 08:40:08 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:40:09 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:40:20 3: SMAInverter SMATRIPOWER - WARNING - old process 2217 will be killed now to start a new BlockingCall
2019.08.15 08:40:20 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:40:20 4: SMATRIPOWER - ###############################################################
2019.08.15 08:40:20 4: SMATRIPOWER - ##########  Begin of new SMAInverter get data cycle  ##########
2019.08.15 08:40:20 4: SMATRIPOWER - ###############################################################
2019.08.15 08:40:20 4: SMATRIPOWER - timeout cycles since module start: 5
2019.08.15 08:40:20 4: SMATRIPOWER -> Start BlockingCall getstatus_DoParse
2019.08.15 08:40:20 4: SMATRIPOWER - current time: 15.08.2019 08:40:20
2019.08.15 08:40:20 4: SMATRIPOWER - operation time begin: 15.08.2019 05:37:59
2019.08.15 08:40:20 4: SMATRIPOWER - operation time end: 15.08.2019 21:21:24
2019.08.15 08:40:20 4: SMATRIPOWER - Send login to 192.168.10.70 on Port 9522 with password XXXX 
2019.08.15 08:40:20 5: SMATRIPOWER - Send: 534D4100000402A000000001003A001060650EA0FFFFFFFFFFFF0001E90023BB590700010000000001800C04FDFF070000008403000054FE545D00000000B9C0C0B9888888888888888800000000 
2019.08.15 08:41:20 3: SMAInverter SMATRIPOWER - WARNING - old process 2220 will be killed now to start a new BlockingCall
2019.08.15 08:41:20 1: SMAInverter SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated
2019.08.15 08:41:20 4: SMATRIPOWER - ###############################################################
2019.08.15 08:41:20 4: SMATRIPOWER - ##########  Begin of new SMAInverter get data cycle  ##########
2019.08.15 08:41:20 4: SMATRIPOWER - ###############################################################
2019.08.15 08:41:20 4: SMATRIPOWER - timeout cycles since module start: 6
2019.08.15 08:41:20 4: SMATRIPOWER -> Start BlockingCall getstatus_DoParse
2019.08.15 08:41:20 4: SMATRIPOWER - current time: 15.08.2019 08:41:20
2019.08.15 08:41:20 4: SMATRIPOWER - operation time begin: 15.08.2019 05:37:59
2019.08.15 08:41:20 4: SMATRIPOWER - operation time end: 15.08.2019 21:21:24
2019.08.15 08:41:20 4: SMATRIPOWER - Send login to 192.168.10.70 on Port 9522 with password XXXX
2019.08.15 08:41:20 5: SMATRIPOWER - Send: 534D4100000402A000000001003A001060650EA0FFFFFFFFFFFF0001E90023BB590700010000000001800C04FDFF070000008403000090FE545D00000000B9C0C0B9888888888888888800000000 
2019.08.15 08:41:20 5: SMATRIPOWER - Received: 534d4100000402a000000001002e001060650be0e90023bb590700017a0158bd10b300010000000001800d04fdff070000008403000090fe545d0000000000000000
2019.08.15 08:41:20 4: SMATRIPOWER - logged in to inverter serial: 3004218712, susyid: 378
2019.08.15 08:41:20 5: SMATRIPOWER - Logged in now
2019.08.15 08:41:20 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 08:41:20 5: SMATRIPOWER - send: 534D4100000402A00000000100260010606509A0FFFFFFFFFFFF0000E90023BB5907000000000000028000020058001E8200FF20820000000000

@Xguide
SBFSpot schaue ich mir mal an. Das klingt ja sehr interessant.

Grüße
Dirk

Wzut · 15 August 2019, 08:59:01

Es ist eigentlich nicht meine Art ein FHEM Modul klein zureden, immerhin steckt der Autor i.d.R. da richtig Zeit und Herzblut rein.
Aber hier wird das zur never ending story gerade wie man jetzt schön sieht mit neuen Typen.
Warum tut ihr das euch an ? Wenn schon SMA warum dann nicht gleich via Modus ?
Die Register sind bei SMA gut dokumentiert, auch für die neusten Typen.

Dersch · 15 August 2019, 09:46:50

Zitat von: DS_Starter am 15 August 2019, 08:30:10
Moin miteinander,

ich habe den STP6.0-3AV-40 und noch ein paar andere in den known Types nachgetragen in der Hoffnung dass Waldmensch recht hat.
Ich hoffe es und es klingt für mich auch schlüssig, sonst würde SBFSpot auch nicht so schnell auf neue Typen reagieren können.

Bitte aus meinem contrib ziehen.
Wenn das klappt, müssen wir einfach mal den Type-Hash aufpeppen.

Grüße,
Heiko

Moin Heiko,

auch mit deinem Modul aus deinem Contrib sieht es so aus:

Code Auswählen

2019.08.15 09:45:48 4: SMATRIPOWER -> Start BlockingCall getstatus_DoParse
2019.08.15 09:45:48 4: SMATRIPOWER - current time: 15.08.2019 09:45:48
2019.08.15 09:45:48 4: SMATRIPOWER - operation time begin: 15.08.2019 05:37:59
2019.08.15 09:45:48 4: SMATRIPOWER - operation time end: 15.08.2019 21:21:24
2019.08.15 09:45:48 4: SMATRIPOWER - Send login to 192.168.10.70 on Port 9522 with password XXXX 
2019.08.15 09:45:48 5: SMATRIPOWER - Send: 534D4100000402A000000001003A001060650EA0FFFFFFFFFFFF0001E90023BB590700010000000001800C04FDFF0700000084030000AC0D555D00000000B9C0C0B9888888888888888800000000 
2019.08.15 09:45:49 5: SMATRIPOWER - Received: 534d4100000402a000000001002e001060650be0e90023bb590700017a0158bd10b300010000000001800d04fdff0700000084030000ac0d555d0000000000000000
2019.08.15 09:45:49 4: SMATRIPOWER - logged in to inverter serial: 3004218712, susyid: 378
2019.08.15 09:45:49 5: SMATRIPOWER - Logged in now
2019.08.15 09:45:49 3: SMATRIPOWER - Send request 00020058001E8200FF208200 to 192.168.10.70 on port 9522
2019.08.15 09:45:49 5: SMATRIPOWER - send: 534D4100000402A00000000100260010606509A0FFFFFFFFFFFF0000E90023BB5907000000000000028000020058001E8200FF20820000000000

Grüße
Dirk

DS_Starter · 15 August 2019, 11:10:30

Hallo Dirk,

ja schade, einen Versuch war es wert. Da ist dann noch mehr zu tun.

Der Einwand von Wzut ist berechtigt. Thomas (der Modulersteller) hat sich leider auch schon längere Zeit nicht mehr zu Wort gemeldet. Bin da momentan unschlüssig wie weiter verfahren werden sollte. Weiß auch nicht ob ich selbst die Zeit finden werde mich intensiv mit dem SMA Protokoll zu beschäftigen. Das war bis jetzt immer der Part von Thomas.

Grüße,
Heiko

Dersch · 15 August 2019, 11:57:17

Ok, dann ist das wohl erstmal so.

Denkst du dieses HowTo https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung wäre auch mit SMAPortal anstelle vom SMAInverter umsetzbar?

Grüße
Dirk

DS_Starter · 15 August 2019, 12:28:51

Ja, davon gehe ich aus. Ich hatte dieses How To mal geschrieben als Beispiel für Datenbankauswertungen in diesem Kontext. Im Prinzip ist ja egal welches Modul den Input liefert wenn der Inhalt stimmt. Sicher muss man bezüglich der Synchronisation zwischen den Modulen etwas kreativ werden, aber machbar sollte es sein.

Grüße,
Heiko

Dersch · 15 August 2019, 13:35:52

OK, dann probiere ich mich mal daran aus. Ist alles noch recht Neuland für mich. Aber erstmal stelle ich alles auf DBlog um was schon ganz gut anfängt

Wenn ich mir nächstes Jahr noch einen Speicher leiste wird es noch interessanter (und komplexer)

Waldmensch · 15 August 2019, 13:56:11

Wenn ich das Log von @Dersch richtig interpretiere klappt das Login und die Serial wird ausgelesen. Als nächster Aufruf kommt 58000200 00821E00 008220FF was sup_TypeLabel entspricht. Bei diesem bleibt es dann hängen, das Log von @Dersch endet dort. Mir fehlt allerdings der Timeout, der dort kommen sollte, wenn der WR nicht antwortet

Mein erster Versuch wäre nun, einfach mal auf diesen Aufruf zu verzichten, indem man ihn auskommentiert oder aus dem Array entfernt. Wie es scheint, antwortet der Wechselrichter ja überhaupt nicht auf dieses Kommando, wenn @Dersch uns da nichts unterschlagen hat.
Zeile 557

Code Auswählen

     # Aufbau Command-Array
     my @commands = ("sup_TypeLabel",                  # Check TypeLabel
                     "sup_EnergyProduction",           # Check EnergyProduction
		    		 "sup_SpotDCPower",                # Check SpotDCPower
			    	 "sup_SpotACPower",                # Check SpotACPower
				     "sup_SpotACTotalPower",           # Check SpotACTotalPower
				     "sup_ChargeStatus"                # Check BatteryChargeStatus
				     );

Ich habe wie gesagt den neuen WR noch nicht und kann diesbezüglich nichts testen. Ich würde vermutlich erstmal eine 2.FHEM instanz aufsetzen mit nur diesem Plugin. Dann kann man schon mal Fremdeinflüsse ausschließen

EDIT: die ganzen anderen Timeouts sind aber auch ungewöhnlich. Hast Du eventuell ein Netzwerk/Latenzproblem zum Wechselrichter hin? Powerlan kannst Du gleich vergessen, das hatte ich durch. Ich häng jetzt per Kabel direkt dran

Dersch · 15 August 2019, 14:08:00

Der WR hängt im WLAN mit einer Signalstärke von 64% (-65 dBm). Unterschlagen habe ich von meinem Log nichts

DS_Starter · 15 August 2019, 14:10:44

Mir geht es eben genauso, habe noch einen STP5000 und kann mit einem neuen Typ nicht probieren. Das ist so echt anstrengend.

Waldmensch · 15 August 2019, 14:23:50

@Dersch: es gibt aber, wenn ich den Code richtig interpretiere, nur 3 Möglichkeiten. Entweder Timeout wenn der WR nicht antwortet oder eine Meldung, dass die Antwort nicht auswertbar ist oder es funktioniert.
Die 4. Möglichkeit ist dann Dein Log, bzw. Das Ende davon

Edit: falls Du noch einen Raspi liegen hast, pack ein FHEM drauf mit dem Plugin und geh mit Kabel über Switch direkt dran. Dann mal gucken.

Gesendet von iPhone mit Tapatalk

Xguide · 15 August 2019, 18:09:04

Zitat von: Waldmensch am 15 August 2019, 14:23:50
@Dersch: es gibt aber, wenn ich den Code richtig interpretiere, nur 3 Möglichkeiten. Entweder Timeout wenn der WR nicht antwortet oder eine Meldung, dass die Antwort nicht auswertbar ist oder es funktioniert.
Die 4. Möglichkeit ist dann Dein Log, bzw. Das Ende davon

Da stolper ich auch gerade irgendwie drüber. Finde es nicht ganz schlüssig, beide Logs enden sehr abrupt. Imho hätten sie mit SMATRIPOWER -> BlockingCall getstatus_DoParse Timeout: process terminated nach einer Minute enden müssen.
@Dersch, was hälst du von einem "attr global verbose 1" und "attr SMATRIPOWER verbose 5"?
Das würde vermutlich dafür sorgen, dass mehr oder minder nur SMATRIPOWER logs im Logging stehen. Dann mal ein wenig laufen lassen.

Zitat von: Waldmensch am 15 August 2019, 08:21:48
Wenn die Register anders wären, könnte der alte Homemanager ja auch nicht mehr mit den neuen WR kommunizieren. Dies wurde mir vom Solarteur aber hoch und heilig versprochen. (Das ich keinen neuen Homemanager brauche) Das etablierte Protokoll komplett umzuwerfen wäre auch seitens SMA ziemlich dämlich

Edit: okay habe gerade mal in den verlinkten Patch geschaut- der Typ der Serial wurde verändert und anders adressiert. Das könnte aber auch ein Bug sein, der erst jetzt auffällt, weil die Serials anders/länger sind.

Die könnten aber per Update nachgeliefert worden sein, so dass der SHM auch mit den neuen Modellen sprechen kann, oder?

Wenn SBFspot geht, dass will Dersch ja testen, dann könnte man es schon nachpflegen. Ich gebe zu, ohne ein Test-WR macht das nicht wirklich Spaß, wäre aber machbar.
Gehen wir erst einmal von der These aus, dass nur der Typ nicht korrekt ermittelt werden kann und der Rest verworfen wird. Das wäre doch lohnenswert das zu fixen... Wobei ich im Vergleich SBFspot code und 76_SMAInverter nur die gleichen Adressen finden kann

Zitat von: Wzut am 15 August 2019, 08:59:01
Es ist eigentlich nicht meine Art ein FHEM Modul klein zureden, immerhin steckt der Autor i.d.R. da richtig Zeit und Herzblut rein.
Aber hier wird das zur never ending story gerade wie man jetzt schön sieht mit neuen Typen.
Warum tut ihr das euch an ? Wenn schon SMA warum dann nicht gleich via Modus ?
Die Register sind bei SMA gut dokumentiert, auch für die neusten Typen.

Ohne es selber ausprobiert zu haben, meine ich mich aber an Kommentare zu errinnern, dass es ein sehr steiniger Weg ist dort zu Ergebnissen zu kommen. Oder irre ich mich? Sonst sicher eine Alternative. Dieses Modul, wenn es denn dann funktionieren würde, überzeugt durch seine Einfachheit.

Waldmensch · 15 August 2019, 18:41:35

Modbus machen die älteren WR nicht. Mein STP10000-TL10 zum Beispiel kann das noch nicht. Der muss bei mir raus, weil er nicht 100% mit dem Solarwatt Speicher harmoniert. Er geht öfter auf Störung und stellt sich tot.

Für Modbus gibt es ein iOBroker Plugin und lt. Google auch Leute, die SMA WR damit abhorchen. Da könnte man evtl. spicken. Wobei ich dann aber eher die Werte vom iOBroker direkt per MQTT ins Netz schwemmen würde als ein FHEM Plugin für Modbus zu bauen. Der Broker läuft sowieso bei mir, um die Mähroboter zu überwachen.

Schöner wäre es allerdings, wenn das FHEM Plugin funktionieren würde. Ich habe auch vorhin im SBFSpot Code geschaut. Das command, was hier anscheinend nicht beantwortet wird, ist genau so auch im SBFSpot. Das muss also richtig sein. Wenn es dort funktioniert, wovon ich ausgehe (sonst gäbe es Tickets) muss der WR auch auf das command vom FHEM Plugin antworten. Ich gehe immer noch von einem Netzwerkproblem aus. Diese vielen Timeouts sind unüblich. Sowas hatte ich am Anfang, als ich versucht habe über Powerlan zu verbinden. Es hat erst vernünftig funktioniert, mit einer Kabelverbindung.

Im übrigen ist der Code dem SBFSpot nachempfunden und sollte ,,unknown Inverter" mit der ID ausgeben, wenn die ID nicht im Hash ist. Müsste im Typen Hash als 0 abgelegt sein, ohne jetzt nachgeschaut zu haben. Es bleibt also mysteriös

Gesendet von iPhone mit Tapatalk