Hallo,

ich habe auf meinem PC den Datenverkehr zwischen den Wechselrichtern und dem Datenlogger mitschreiben lassen.

Wechselrichter sind SMA SB 4000TL-20 (Firmware 3.01)
Datenlogger ist ein Solarlog 500 (Firmware 2.0.4 Build 24)
Geräteverbindung über RS485

Mit Hilfe der frei zugänglichen Dokumentation "SMA-Data Spezifikation - Definition und Beschreibung des Telegrammformats und Kommunikationsprotokolls" Ausgabe 1.25,
konnte ich einen Teil des Datenaustauschs zwischen den Geräten nachvollziehen.

Es ist dabei wohl so, dass der Solarlog die Wechselrichter erst mal dazu Auffordert zur aktuellen Uhrzeit die momentanen Messwerte einzufrieren.
Danach fordert der Solarlog nacheinander die Wechselrichter zur Übertragung der Messwerte auf, was von den Wechselrichtern durch ein Antworttelegramm bestätigt wird.
Dieses Antworttelegramm enthält erst mal ein paar Protokolldaten woran sich dann eine Menge (ca. 225 Byte) Nutzdaten (Messwerte) anschließen.
Es ist mir aber leider bisher nicht gelungen mit Hilfe der o.g. Dokumentation die Nutzdaten zu entschlüsseln. Lediglich Datum, Uhrzeit und die Seriennummer der WR konnte ich zuordnen.
Dabei enthält dieser Datensatz einige interessante Messwerte wie Netzspannung, Netzfrequenz, Isolationswiderstand des Generators u.v.a.m.

Kann mir jemand dabei helfen die Nutzdaten zu entschlüsseln, oder mir gar eine komplette Beschreibung der Datenstruktur liefern?

Upva=(unsigned int)(SMAbuf[14]*256+SMAbuf[13]);
Upvn=(unsigned int)(SMAbuf[16]*256+SMAbuf[15]);
Iaca=(unsigned int)(SMAbuf[18]*256+SMAbuf[17]);
Iacn=(unsigned int)(SMAbuf[20]*256+SMAbuf[19]);
Uac=(unsigned int)(SMAbuf[22]*256+SMAbuf[21]);
Fac=(unsigned int)(SMAbuf[24]*256+(int)SMAbuf[23]);
Pac=(unsigned int)(SMAbuf[26]*256+SMAbuf[25]);

AntonHartmann hat geschrieben:Upva=(unsigned int)(SMAbuf[14]*256+SMAbuf[13]);
Upvn=(unsigned int)(SMAbuf[16]*256+SMAbuf[15]);
Iaca=(unsigned int)(SMAbuf[18]*256+SMAbuf[17]);
Iacn=(unsigned int)(SMAbuf[20]*256+SMAbuf[19]);
Uac=(unsigned int)(SMAbuf[22]*256+SMAbuf[21]);
Fac=(unsigned int)(SMAbuf[24]*256+(int)SMAbuf[23]);
Pac=(unsigned int)(SMAbuf[26]*256+SMAbuf[25]);

für die Auskunft.
Diese Angaben decken sich mit meiner oben genannten Beschreibung des SMA-Protokolls.
Die ersten 25 Byte sind klar und mit Hilfe der Beschreibung zu entschlüsseln. Mein Problem ist es aber die Beschreibung auf das empfangene Telegramm nach dem 25. Byte anzuwenden.
Bei den restlichen ca. 220 Byte passt die Beschreibung meiner Meinung nach nicht zum empfangenen Telegramm oder ich habe ein Verständnisproblem bei der Anwendung der Beschreibung.

Verstanden habe ich den Anfangsbereich: 7E FF 03 40 41 01 00 00 00 40 00 0B 0F 09 00 01 00 B4 1A 6C 4C 01 00 00 00. (Protokollkopf, Uhrzeit und Zeitbasis)

Danach sollte laut Beschreibung Upv-Ist und Upv-Soll kommen. Im Telegramm steht für diese beiden Werte aber 00 00 und 00 00. Das passt schon irgendwie nicht zusammen, da die Wechselrichter zum Zeitpunkt der Aufzeichnung des Telegramms eingespeist haben.

Hier ein komplettes Anworttelegramm von WR1:

Code: Alles auswählen

7E FF 03 40 41 01 00 00 00 40 00 0B 0F 09 00 01 00 B4 1A 6C 4C 01 00 00 00 00 00 00 00 00 4A 06 47 00 80 A4 43 00 2E B0 46 00 00 92 42 00 4A 06 47 00 00 94 43 00 7D 32 B5 46 00 00 88 42 00 00 7D 31 43 85 7D 33 00 00 00 00 7D 31 43 00 00 00 00 84 02 00 00 00 00 00 00 00 00 00 00 B4 58 00 00 00 00 00 00 00 00 00 00 00 00 7D 31 43 00 00 00 00 00 00 00 00 00 EB 0C 47 00 80 14 44 00 00 66 43 00 00 EB 43 00 00 B5 43 00 00 00 41 C0 C6 2D 00 97 7D 5E 2E 00 84 50 86 00 63 C5 89 00 97 7D 5E 2E 00 84 50 86 00 34 C5 89 00 D9 00 00 00 D9 00 00 00 00 00 00 00 8C 29 2E 7D 5D 29 00 00 00 22 00 00 00 01 00 00 00 A6 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 02 00 00 00 01 00 00 00 01 00 00 00 1D D5 7E

Ich bin mir auch nicht sicher ob die Messwerte wirklich unsigned int (16Bit) übertragen werden. Ich vermute eher Floating Point (32Bit) nach IEEE-754, kann mich aber auch irren.

Könnte es sein, dass SMA das Telegramm in Teilen geändert hat? Die veröffentlichte Protokollbeschreibung stammt immerhin schon aus dem Jahr 2003.

Vorschlag: man holt sich die letzte Unix-Implementierung von SMA vom yasdi und studiert die Dokumentation in den C-Sourcen und Header-Includes (1.8.1):
http://www.sma.de/de/produkte/software/yasdi.html
Viel Glück.

Hier gibt es dann noch die Interpretationsquelle der letzten smap Korrektur über Manfred Richter (ManfredR).

Hoffe es hilft ein wenig weiter
Grüße

Hallo,

Fals irgendwer in diesem codewirrwarr findet wo die definiton der bytes samt positionen stehen würde mich das sehr interessieren.

Ist das SMA - Multistring Porotocol da auch schon Implementiert?

Gibt es irgendwo einen codeteild er wirklich NUR des wr abfragt und die Antwort Interpretiert?

LG
Anton

Nei es gibt keinen isolierten Codeteil, der NUR Wrs abfragt.
Im Kern geht es ja um die Interpreation der Eingangstelegramme und dabei wohl auch nur um den SMAnet-Data-Anteil mit den Zeitstempeln. Hier muss man sich dann schon etwas im bereich
smanet.c, smadata_layer.c (& .h), netchannel.c und tools.c orientieren, um eine Idee der Strukture zu bekommen. Es werden irgendwann die Einzelwerte isoliert und typbezogen (BYTE, WORD, DWORD, FLOAT) zu convertieren und zu übernehmen.
Man muss allerdings diese Zeitgestempelten Werteketten hinsichtlich der WR-Zeit mit Vorsicht genießen, da die Zeit vom WR stark driften können. YASDI selbst nutzt für die Anfragezyklen dann irgendwann nicht mehr die Telegrammzeiten sondern die local Rechnerzeit, auf dem die Decodierungs-Software läuft. Ruhig auch einmal die Kommentare von Herrn Prüssing lesen, da wird die "wahre" Geschichte hinter der Doku-Theorie etwas mehr beleuchtet.

Man kann auch die smap Umgebung ruhig einmal nutzen um die Abfragereigenfolge im eigenen WR-Umfeld einmal punktuell abzufragen, dort wird im Kern der gesamte SMA-Stack durchlaufen (Thema: Format Spotwertanforderung) und dies in lesbare Zeich umgeformt. Hierbei könnte man zumindest schon mal den selbst geloggten Binärdatenstrom gegen das Ausgabeergebnis von SMA halten um korrespondierende Wert-Typen und Formate (Byteanzahl usw.) besser zu "erraten".

Ich finde die Erklärungen des Autors auch ganz hilfreich: http://www.heiko-pruessing.de/projects/yasdi/yasdi.php

Grüße

PS: wenn dies nicht wirklich hilft dann mal eine PN an ManfredR mit den Fragen.

Vielen Dank für die antwort, Was mich interessieren Würde ist ob das YASDI auch diea dressvergabe am rs485 bus übernimmt und ob das abfragen auch mit den ganz neuen wechselrichtern von SMA funktioniert.

Wird YASDI von noch gewartet und updated?

Wie seihts mit dem SMAData2 aus?

LG
Anton

Yasdi macht nichts mit Adressvergabe sondern scanned mit dem SMAP (Proxy-Programm) eine erwartete Anzahl an WRs am Netzwerk.
Details auch in folgender Doku:
http://www.amhamberg.de/SMAP_Installieren.pdf

Die neueren WRs von SMA laufen dann über YASDI wenn es über RS485 angeschlossen wird. Bluetooth geht nicht und ist nicht geplant. Der Logger von Manfred Richter nutzt das intern als Protokollschicht. Vergleiche:
datenlogger-f5/solarviewatfritzbox-fuer-sma-t45014-s30.html


SMA pflegt das Thema NICHT mehr, es ist dem Entwickler oder der Community (ist alles da) überlassen. Letzte Änderungen gibt es aber aus dem letzten Jahr (für dieses Jahr war auch etwas geplant).

Ich denke SMAData2 ist das wonach man hier sucht - oder habe ich da was falsch verstanden?

Meine Empfehlung, sich mal mit der FritzBox-Lösung dieses Umfeldes probehalber vertraut machen (smap und yasdi reicht), um ein Gefühl zu entwickeln. Auch Hilfen sind hierzu bereits verfasst:
http://www.amhamberg.de/solarview_smap.aspx

Hallo,

AntonHartmann hat geschrieben:Hallo,
Fals irgendwer in diesem codewirrwarr findet wo die definiton der bytes samt positionen stehen würde mich das sehr interessieren.
...

Genau das ist der Punkt der mich auch interessiert.

AntonHartmann hat geschrieben:...
Ist das SMA - Multistring Porotocol da auch schon Implementiert?
...

Wenn mit Multistring Protokoll das Protokoll eines Multistring Wechselrichters gemeint ist, dann ja.

AntonHartmann hat geschrieben:...
Gibt es irgendwo einen codeteild er wirklich NUR des wr abfragt und die Antwort Interpretiert?

LG
Anton

Ich habe danach gesucht aber nichts gefunden.
YASDI ist für meine bescheidenen C-Kenntnisse recht verworren programmiert. Ich hangele mich durch über etliche Funktionen, Include- und Headerdateien, dreh mich im Kreis und finde nicht was ich suche.
Das ist keine Kritik am Author sondern hängt einzig und allein an meinen besch... Fähigkeiten.

P.Voltologe hat geschrieben:Nei es gibt keinen isolierten Codeteil, der NUR Wrs abfragt.
Im Kern geht es ja um die Interpreation der Eingangstelegramme und dabei wohl auch nur um den SMAnet-Data-Anteil mit den Zeitstempeln. Hier muss man sich dann schon etwas im bereich
smanet.c, smadata_layer.c (& .h), netchannel.c und tools.c orientieren, um eine Idee der Strukture zu bekommen. Es werden irgendwann die Einzelwerte isoliert und typbezogen (BYTE, WORD, DWORD, FLOAT) zu convertieren und zu übernehmen.
...

Ich vermute so einfach ist das nicht. YASDI fordert erst vom WR über "CMD_GET_CINFO" eine Kanalliste samt zugehöriger Parameter an und verwendet dann das Ergebnis um das Messwerttelegramm zu interpretieren.
Das Antworttelegramm auf die Funktion "CMD_GET_CINFO" könnte ein Weg zum Ziel sein, das habe ich aber nicht.
Der Datenlogger hat diese Kanalliste vermutlich bei der WR-Erkennung angefordert und dann in seiner Konfiguration abgespeichert. Im normalen Betrieb fordert der SolarLog die nicht nochmal an.
Ich könnte mich jetzt mit dem PC statt nur zum lesen auch zum lesen und schreiben an den RS485-Bus hängen, YASDI die Kanalliste anfordern lassen und den Datenstrom mitloggen. Ich habe aber erhebliche bedenken dabei etwas kaputt zu machen.

P.Voltologe hat geschrieben:...
Man muss allerdings diese Zeitgestempelten Werteketten hinsichtlich der WR-Zeit mit Vorsicht genießen, da die Zeit vom WR stark driften können. YASDI selbst nutzt für die Anfragezyklen dann irgendwann nicht mehr die Telegrammzeiten sondern die local Rechnerzeit, auf dem die Decodierungs-Software läuft.
...

Der Solarlog sendet mit jeder Datenabfrage an die WR die aktuelle Uhrzeit mit. Ob der WR diese Uhrzeit nutzt um seine interne Uhr zu synchronisieren weiß ich jedoch nicht.

P.Voltologe hat geschrieben:...
Ich denke SMAData2 ist das wonach man hier sucht - oder habe ich da was falsch verstanden?
...

Wenn ich nach SMA-Datenprotokollen suche finde ich folgende Begriffe:
SMAData
SMAData1
SMAData2
SMAData2Plus
Es könnte auch sein, dass mit SMAData und SMAData1 das gleiche gemeint ist.
Da ich jedoch mit der Beschreibung von SMAData nicht so recht weiter komme ist es schon möglich dass bei mir SMAData2 läuft.
Andererseits glaube ich mal gelesen zu haben, dass SMAData2 nur bei der Bluetooth-Schnittstelle verwendet wird. Bei mir läuft aber RS485.

Hallo Strom aus Sonne

Scheinbar wird für die rs485 Kommunikation SunnyNet bzw SMAData1 verwendet, Sunnynet ist scheinbar veraltet jedoch bin ich schon auf WR gestoßen aus dem jahr 2004 der dieses auch noch verwendet hat

SMAData2 und SmaData+ wird scheinbar für Bluetooth verwendet und ist soweit mir bekannt nicht offen

LG
Der Hartl