Neu: 77_SMAEM - Modul für SMA Energie Meter. Alternative zum Sunny Home Manager.

Begonnen von Volker Kettenbach, 30 März 2016, 12:42:05

Vorheriges Thema - Nächstes Thema

Volker Kettenbach

#225
Zitat von: cerberus am 21 Juli 2016, 15:36:13
Nein, habe sie nicht, nur der Multigate hat eine IP. Die Modulwechselrichter tauchen unter SBFspot nur mit ihrer jeweiligen S/N auf.

siehe mein Beitrag weiter vorn https://forum.fhem.de/index.php/topic,51569.msg473761.html#msg473761

Grüße
cerberus

Mit dem Multigate hat sich bisher niemand beschäftigt.
Aber wenn Sunny Tripower und Sunny Boy klappen, könnte das mit dem Multigate auch hinhauen.

Waldmensch ist ja der Experte im Entschlüsseln des SMA Protokolls. Es wäre vermutlich sinnvoll, mal einen Dump zu machen und hier zu posten. Genauso, wie es in den letzten Tagen bei Sunny Bo gemacht wurde (siehe also hier im Forum). Damit dürfte es machbar sein, noch eine weitere Geräteklasse zu SMASTP hinzuzufügen.

Vielleicht wäre es auch ganz gut, dafür einen eigene Thread zu starten und hierzu verlinken. Topic: "Erweiterung 77_SMASTP um Support für SMA Multigate".

Dann geht's hier nicht so durcheinander.

Stargazer

Hallo,

ich möchte doch hier für alle nochmal mein Output von SBFSpot liefern.

Viele Grüße

Andre

sct14675

@stargazer: Ich schau mir die Daten morgen an und geb dir Bescheid.

@all
Gibt es eine Protokoll-Beschreibung von der Speedwire Schnittstelle? Soweit ich gesehen hab, nennt sie sich SMA Data 2+...

Waldmensch

Die interessante Stelle ist wohl die für PAC Total. Allerdings ist ein Fork über Device Class nicht möglich, da es auch als 8001 geführt ist

--------: 00 01 02 03 04 05 06 07 08 09
00000000: 53 4D 41 00 00 04 02 A0 00 00
00000010: 00 01 00 26 00 10 60 65 09 A0
00000020: FF FF FF FF FF FF 00 00 7D 00
00000030: 9D CB E8 31 00 00 00 00 00 00
00000040: 13 80 00 02 00 51 00 3F 26 00
00000050: FF 3F 26 00 00 00 00 00
58 Bytes sent to IP [192.168.178.25]
ethGetPacket()
Received 86 bytes from IP [192.168.178.25]
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 53 4D 41 00 00 04 02 A0 00 00
00000010: 00 01 00 42 00 10 60 65 10 90
00000020: 7D 00 9D CB E8 31 00 A0 8A 00
00000030: C7 1A F7 7E 00 00 00 00 00 00
00000040: 13 80 01 02 00 51 00 00 00 00
00000050: 00 00 00 00 01 3F 26 40 26 D8
00000060: 90 57 A6 06 00 00 A6 06 00 00
00000070: A6 06 00 00 A6 06 00 00 01 00
00000080: 00 00 00 00 00 00
<<<====== Content of pcktBuf =======>>>
--------: 00 01 02 03 04 05 06 07 08 09
00000000: 00 00 10 60 65 10 90 7D 00 9D
00000010: CB E8 31 00 A0 8A 00 C7 1A F7
00000020: 7E 00 00 00 00 00 00 13 80 01
00000030: 02 00 51 00 00 00 00 00 00 00
00000040: 00 01 3F 26 40 26 D8 90 57 A6
00000050: 06 00 00 A6 06 00 00 A6 06 00
00000060: 00 A6 06 00 00 01 00 00 00 00
00000070: 00 00
<<<=================================>>>
SPOT_PACTOT : 1702 (W) Thu Jul 21 16:11:50 2016
SUSyID: 138 - SN: 2130123463
AC Spot Data:
Phase 1 Pac :   1.706kW - Uac: 240.92V - Iac:  7.068A
Phase 2 Pac :   0.000kW - Uac:   0.00V - Iac:  0.000A
Phase 3 Pac :   0.000kW - Uac:   0.00V - Iac:  0.000A
Total Pac   :   1.702kW


der Wert 1702 steht als A606 hinten ein paar mal drin in der Antwort

534D4100000402A00000000100420010606510907D009DCBE83100A08A00C71AF77E0000000000001380010200510000000000000000013F264026D89057A6060000A6060000A6060000A60600000100000000000000

cerberus

Hallo,

ich habe auch mal eine Output von SBFSpot für den Multigate erstellt.

Grüße
cerberus
Banana PI mit Bananian + Fhem 5.5, 2x SCC SlowRF/Homematic + RS485 LAN Gateway HMW-LGW-O-DR-GS-EU + RPI2 I2C to 1-Wire Host Adapter for Raspberry Pi

Stargazer

Alles klar,

da freue ich mich drauf.

Nun haben wir ja eigentlich fast alles an Bord, was so mit SMA und dem täglichen Leben zu tun hat.

Dann wären wir derzeit auf dem Stand, dass keine Auto-Erkennung des Devices stattfinden kann, oder ?
Mal eine dumme Frage... . Könnte man da nicht eine Art Database einpflegen ?
Heißt, man gibt das Modell ein und konfiguriert so das Modul durch die Eingabe.
Klar müsste man den Datenbestand pflegen, aber die Modellreihen sind ja relativ ausgereitzt.

VG

André

DS_Starter

Hallo Thomas,

dein modifiziertes Modul läuft jetzt bei mir auch. Weiß nicht was heute früh los war. Nach einem neuen restart klappt es jetzt.

@Volker,  mir ist aufgefallen dass das Log in Zeile 409 (bei dir 422 Thomas)


Log3 $name, 2, "$name: Sending query to inverter $Host:9522";


wohl besser nach verbose 3 oder 4 geändert werden sollte.  "2" ist für bedeutende Ereignisse und das ist die Mitteilung über eine versendete Query  wohl nicht.  ;)

viele Grüße
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

sct14675

@DS_Starter
bei mir half auch oft nur ein Neustart >> hatte endlose Hänger, keinen Empfang, ..., keine Ahnung ob da intern einfach was abgeschmiert ist

@Stargazer
Ich konnte das Logfile noch nicht anschauen, kommt noch. Kannst du zusätzlich bitte in FHEM beim SMASTP das Attribut "verbose" auf "5" setzen und dann im Logfile die Einträge hier rein kopieren?
Im Logfile erscheinen dann nämlich die Antworten auf die Anfragen vom Modul und man kann nachvollziehen, warum das Modul abbricht.
Nach dem Test kannst "verbose" wieder entfernen, sonst wird dein Logfile geflutet...
Da SBFspot funktioniert kann es kein Hexenwerk sein und muss auch nativ in FHEM funktionieren!

@all
Performance: Ist ein wichtiger Punkt! Ich lass über Nacht mal "apptime" mit verschiedenen Konfigs laufen um zu sehen, was viel Laufzeit schluckt.

Insgesamt ist das Modul SMASTP aktuell so aufgebaut:
Es werden der Reihe nach fest definierte Kommandos geschickt und die Antworten ausgewertet. Nur wenn ALLE Antworten ok sind, werden die Readings aktualisiert.
SBFspot ist da flexibler aufgebaut: Es werden verschiedene Kommandos ausprobiert. Die Kommandos sind auch nicht fest definiert, sondern werden dynamisch aufgebaut. Da ich im Internet keine Spezifikation vom Protokoll SMA Data 2+ finde, bleibt nur Reverse Engineering von SBFspot.
Mir würde ein Ablauf analog zu SBFspot besser gefallen: Komandos ausprobieren, bei negativen Ergebnis wird kein Reading erzeugt.
Würde aber mehr Aufwand beim Umschreiben des Moduls bedeuten und kommt auch auf die Performanceauswertung an.

Stargazer

Hi,

hier die Werte von Verbose 5 bei SMASMTP:

2016.07.21 20:40:27 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:40:28 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:41:28 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:41:28 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:41:35 3: SB4000TL: Set verbose to 5
2016.07.21 20:42:28 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:42:28 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:42:28 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:42:28 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:43:14 3: SMAspot called
2016.07.21 20:43:32 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:43:32 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:43:32 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:43:32 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:44:32 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:44:32 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:44:32 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:44:32 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:45:32 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:45:32 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:45:32 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:45:32 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:46:34 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:46:34 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:46:34 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:46:34 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:47:34 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:47:34 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:47:35 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:47:35 1: SB4000TL: Too little data received (Len:58)
2016.07.21 20:48:14 3: SMAspot called
2016.07.21 20:48:35 2: SB4000TL: Sending query to inverter 192.168.178.25:9522
2016.07.21 20:48:35 5: SB4000TL: Received: (534d4100000402a000000001003a001060650ed07800c8e8033800018a00c71af77e00010001000004800d04fdff07000000840300004c20cb5100000000b8b8b8b8888888888888888800000000)
2016.07.21 20:48:35 5: SB4000TL: Received Garbage: (534d4100000402a00000000100260010606509d07800c8e8033800e08a00c71af77e0000ffff0000068001020058001e8200ff20820000000000)
2016.07.21 20:48:35 1: SB4000TL: Too little data received (Len:58)


VG

André

sct14675

Guten Morgen!
Hier das Ergebnismeiner Performance-auswertung:
Testsystem ist ein Intel NUC mit Core i5, Ubuntu 16.04 installiert und jede Menge Services im Hintergrund (Mailserver, MySQL, Traccar, Webserver, ...)

Folgende zwei Werte sind auffällig:
Zwei unterschiedliche Instanzen von SMASTP, einmal 10 Readings und einmal 15 Readings. Allerdings hab ich einmal die Mittelwertbildung der letzten 15min nur bei den 10 Readings aktiviert und beim anderen durch eine IF Abfrage einfach übersprungen.
Wenn ich die 15min Durchschnittsbewertung einschalte, dann hab ich eine Average Laufzeit von ca. 92ms
Wenn ich sie abschalte, dann hab ich eine Average Laufzeit von 38ms
Zum Vergleich: Die Abfrage von einem Webservice von Withings dauert 800ms, ein Fritzbox Readout ca 12ms

Anscheinend hat bei meinem System die Mittelwertbildung einen größeren Einfluss als mehr Readings...
Das ganze gilt jetzt nur für mein System, und irgendwie zweifel ich da noch ein bisserl dran...

sct14675

@Stargazer:
Hab mir dein Logfile und den Output von SBFspot angesehen.
Eigentlich sollte das unmodifizierte SMASTP bei dir laufen, die Kennung ist ein "Solar Inverter".
Laut Logfile wird gleich das erste Kommando nicht akzeptiert, hier wird die Gesamtproduktion SPOT_ETOTAL und SPOT_ETODAY abgefragt.
Bei SBFspot funktioniert aber das Kommando, wo bei SMASTP ein Fehler (0xFFFF) und deswegen eine zu kurze Antwort zurück kommt.
Der Unterschied ist im Detail:
SBFSpot: Kommando 0x54000200, First 0x00260100, Last 0x002622FF
SMASTP: Kommando 0x54000200, First 0x00260000, Last 0x0026FFFF

Ich hab SMASTP umgeschrieben und an diesen Post angehängt. Darin hab ich das Kommando ausgetauscht, schau mal bitte, ob es jetzt weiter läuft.
Diese neue Version läuft bei meinem STP trotzdem wie gewohnt.

tschüss,
Thomas

Waldmensch

Ich denke, das die Mittelwertberechnung durch die vielen Typkonvertierungen suboptimal ist. Vielleicht wäre ein Ringbuffer Array mit Integer Werten performanter. Aber ich kenne Perl zu wenig als zu wissen wo der Interpreter Schwächen hat. Ich habe die Mittelwertberechnung im Modul nie angefasst.

Sinn des aktuellen Ansatzes war glaube ich, den Ringbuffer abspeichern zu können, das er einen Modul Neustart überlebt. Persönlich finde ich das unnötig.

Stargazer

Hi !

Alles klar, Thomas. Werde das heute mal testen und dann berichten. Kann ich das SMAUtils und SBFspot trotzdem währenddessen laufen lassen, oder wäre es besser das alles zu stoppen ?

VG

André

sct14675

@cerberus:
Ich hab mir den SBFlog mal angeschaut.
dein System wird über eine IP-Adresse gesteuert (192.168.178.33). Allerdings erkennt SBFspot das Multigate und fragt alle angehängten Geräte ab.
Die Antwort enthält alle SusyIDs und Seriennummern.
Im weiteren Verlauf werden die Abfragen dann zwar immer an die IP Adresse 192.168.178.33 geschickt, allerdings kann man im Protokoll einen speziellen Empfänger über die SusyID und Seriennummer definieren.
Aktuell wird der Empfänger vom Modul SMASTP immer auf 0xFFFF... gesetzt, d.h. keinen speziellen Empfänger > Das Modul wird mit dem aktuellen Design kein Multigate unterstützen können

@Stargazer
Prinzipiell kann der Inverter auf mehrere Empfänger reagieren (macht meiner auch grad). Wenn zwei Empfänger auf der gleichen Maschine laufen > keine Ahnung. Ich hoffe da ist eine KOllisionserkennung irgendwie implementiert, hab da aber keine Ahnung davon.

Volker Kettenbach

#239
Zitat von: DS_Starter am 21 Juli 2016, 20:25:00
Hallo Thomas,

dein modifiziertes Modul läuft jetzt bei mir auch. Weiß nicht was heute früh los war. Nach einem neuen restart klappt es jetzt.

@Volker,  mir ist aufgefallen dass das Log in Zeile 409 (bei dir 422 Thomas)


Log3 $name, 2, "$name: Sending query to inverter $Host:9522";


wohl besser nach verbose 3 oder 4 geändert werden sollte.  "2" ist für bedeutende Ereignisse und das ist die Mitteilung über eine versendete Query  wohl nicht.  ;)

viele Grüße

Einfach Patch erstellen. An besten als pull request auf github. Dann gebe ich es einfach frei und es wandert automatisch von GitHub ins svn.

https://help.github.com/articles/using-pull-requests/