76_SMAInverter.pm - Abfrage von SMA Wechselrichter

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

Vorheriges Thema - Nächstes Thema

kdeb

Einen Neustart von fhem hab ich gemacht. Hat aber nicht geholfen. Und für den zweiten WR geht es, daher bin ich recht sicher, dass Dein Modul richtig eingebunden wurde.
Was ich jetzt nicht gemacht habe ist ein Neustart des WR, weil SBFSpot mit dem gleichen PW funktioniert.
ZitatAuch der Hänger beim logout ist komisch > irgendwie wird da nicht wirklich was rausgeschickt hab ich das gefühl...
Ich werde heute Abend mal einen tcpdump machen um zu sehen, ob Daten fließen - ich bin da aber recht zuversichtlich, denn ich bekomme ja ein "WR_SBS: Logged in now"

kdeb

So, mein SBS hat noch weitere Probleme. SMA will ihn Ende der nächsten Woche tauschen. Bis dahin mache ich erstmal nichts, vielleicht ist der Fehler dann ja von selber weg.
Ich werde berichten.

Bis dahin

Kai

DS_Starter

Hallo zusammen, hallo Thomas,

Es gibt in diesem Thread: https://forum.fhem.de/index.php/topic,57287.0.html  eine Diskussion zur Synchronschaltung von SMAEM & SMAInverter.
Ich habe endlich die Zeit gefunden und das SMAInverter-Modul zu diesem Zweck angepasst und einiges geändert. An der Grundfunktionalität hat sich natürlich nichts geändert.
Aber es ist eine get-Funktion implementiert mit der man die Werte manuell abfragen kann.

Weiterhin gibt es  Attribute:

* disable -  schaltet das Modul in den disabled Modus
* mode - manual oder automatic (automatic fragt das Modul wie bisher gemäß Intervall ab)
* SBFSpotComp - stellt den Style wie bei SBFSpot um

Wenn du magst und dir die Änderungen zusagen, dann übernimm die Version gerne in dein Git.
Damit ist es nun möglich die Synchronität mit dem SMAEM wie in dem angegebenen Thread  beschrieben mit SMAInverter.pm zu erreichen.

Weiterhin habe ich noch vor das Modul zunächst für mich komplett auf non-blocking umzubauen. Mal sehen wann ich das schaffe.
Wenn Interesse besteht, stelle ich es gern wieder zur Verfügung.

Grüße
Heiko
ESXi@NUC+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

DS_Starter

#33
Habe noch etwas verändert / erweitert:

* die Textwerte der Readings wie z.B. für INV_CLASS werden in Abhängigkeit vom global Attribut "language" entweder englisch (Standard) oder in deutsch gesetzt
* für ca. 80 WR-Geräte habe ich die entsprechenden Gerätetypen und Klassen hinterlegt. Dadurch werden in den Readings die richtigen Gerätetypen statt der Codenummern ausgegeben sofern für den speziellen Typ hinterlegt.
* weitere Anpassungen im SBFComp-Modus (z.B. kW statt W, 3 Nachkommastellen usw.) entsprechend dem SBFSpot-Style

@Thomas, wenn alles passt, nimm es gern wieder mit in dein Git auf.

Grüße
Heiko
ESXi@NUC+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

Waldmensch

ich fand die Durchschnittswerte (5,10,15 Min) im Originalansatz nicht schlecht, da man nicht bei jeder Wolke einen Schaltvorgang auslöst. Da lässt sich in FHEM schlecht nachbauen und war im Modul eigentlich ganz gut aufgehoben.

Datenmüll Vermeidung in Log und DBLog (Nachts nur Nullwerte) geht mit dem Modul nur über die FHEM Bordmittel?

DS_Starter

Zitatch fand die Durchschnittswerte (5,10,15 Min) im Originalansatz nicht schlecht ...

Welchen Ansatz meinst du ? Ich habe Thomas seinen Entwicklungsstand aus dem Git vom 03.08. als Grundlage verwendet.
In dem Release sind mir diese Durchschnittswerte nicht untergekommen. Wie gesagt, an der verhandenen Funktionalität habe ich nichts verändert/eingeschränkt, lediglich erweitert.

Die Vermeidung von Nachtmessungen geht momentan nur über FHEM-Mittel. Ich benutze zur Zeit ein Notify für die Synchronisierung mit dem SMAEM zzgl. einer dort eingebauten Abhängigkeit zu sunrise(), sunset().

Vllt. könnte man sowas auch ins Modul mit integrieren wenn das Sinn machen würde.

Thomas hat sich lange nicht zu Wort gemeldet. Somit weiß ich auch momentan nicht ob er selbst auch noch am Modul arbeitet.
Das nonblocking finde ich noch wichtig, aber das dauert ....


ESXi@NUC+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

Waldmensch

im 77_SMASTP wars noch drin. Ich blicke bei den mittlerweile fragmentierten Threads nicht mehr durch und nutze immernoch, das Modul, was ich selber angepasst hab. Der Code den ich meine

if ( (int(hex(substr($averagebuf,0*8,8)))) eq 0)
{
for my $count (0..15)
{
# fill with new values
substr($averagebuf,$count*8,1*8) = substr(sprintf ("%08X",$AlltimeTotal),0,8);
}
}

# average buffer shiften und mit neuem Wert füllen
substr($averagebuf,1*8,15*8) = substr($averagebuf,0*8,15*8);
# und mit neuem Wert füllen
substr($averagebuf,0*8,1*8) = substr(sprintf ("%08X",$AlltimeTotal),0,8);
$AvP01 = int( ( (hex(substr($averagebuf,0*8,8))) - (hex(substr($averagebuf,1*8,8)))  ) * ((3600 / 01) / $interval) );
$AvP05 = int( ( (hex(substr($averagebuf,0*8,8))) - (hex(substr($averagebuf,5*8,8)))  ) * ((3600 / 05) / $interval) );
$AvP15 = int( ( (hex(substr($averagebuf,0*8,8))) - (hex(substr($averagebuf,15*8,8))) ) * ((3600 / 15) / $interval) );

$statusval = "SP:$SpotPower W  AvP1:$AvP01 W  TTP:$TodayTotal Wh  ATP:$AlltimeTotal Wh";

sct14675

Servus zusammen,
sorry fuer die schlechte erreichbarkeit zur Zeit >> bei mir ist privat grad einiges los...

@DS_Starter
Ich schau mir das Modul an, wenns laeuft nehm ich die am Wochenende ins Git auf

@Waldmensch
Die Mittelwertbildung hab ich relativ frueh rausgenommen, da die nicht funktionierte wenn man mehrere Wechselrichter gleichzeitig betreibt.

tschuess,
Thomas

Waldmensch

verstehe ich nicht wirklich, weil PDC wird ja immer irgendwie gemessen und dafür einen Durchschnitt zu berechnen sollte auch irgendwie möglich sein. Ich hätte jetzt AdHoc keinen Ansatz, wie man diese Durchschnittswerte auf einfache Art in FHEM erzeugen sollte um, bei einer vorbeiziehenden Wolke, nicht gleich panisch Schaltvorgänge auslöst.


DS_Starter

#39
Ich habe mich mit einer Möglichkeit der Nachtsteuerung auseinandergesetzt und in der Version 1.6 das Modul so erweitert dass die WR-Abfrage bei Sonnenaufgang beginnt und bei Sonnenuntergang endet. Dazu verwende ich Funktionen von 99_SUNRISE_EL.pm welches automatisch geladen wird. Damit es richtig funktioniert setzt longitude und latitude im global device, falls ihr es bis jetzt nicht benutzt habt. Sonst wird der Standort Frankfurt angenommen. Näheres steht in der Commandref zu SUNRISE_EL bzw. Wiki.

Weiterhin kann mit dem Attribut "offset"  der Sonnenaufgang / Sonnenuntergang logisch vorgezogen bzw. verzögert werden um so bei Bedarf die effektive Abfragezeit verlängern zu können (Wertebereich 0 ... 7200s). Das Attribut "suppressSleep" lässt den Nachtmodus unterdrücken und den WR unabhängig von der Tageszeit abfragen.

Leider konnte ich nicht alles bis ins letzte Detail testen weil es heute Abend schon dunkel war, aber es sollte alles funktionieren.
Die Doku habe ich auch (halbherzig) ergänzt und dabei auf UTF-8 umgestellt. Die Umlaute werden nun richtig dargestellt.

Zu dem Thema "Durchschnittswert":
Prinzipiell finde ich dieses Feature hilfreich und es wäre schön wenn wir eine solche Möglichkeit implementieren könnten. Thomas, ich weiß nicht was das Problem war.
Vielleicht kannst du es mal kurz darlegen was dir aufgefallen ist, bzw. woran es scheiterte.
Ich kenne auch Meßverfahren die z.B. den höchsten Wert der letzten x Meßzyklen ausgeben. Auch dadurch kann man eine gewisse Glättung erreichen mit dem Vorteil dass der User in Abhängigkeit seines individuellen Abfrageintervalls die Glättungsperiode selbst bestimmen kann.
Muß man sich mal durchdenken.

Ich komme frühestens nächste Woche wieder dazu an dem Modul weiter zu arbeiten.

Bis dahin ...
Heiko
ESXi@NUC+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

DS_Starter

Kurze Info , Version 1.6 läuft bei mir einwandfrei so wie erwartet. Die Steuerung abhängig vom Sonnenaufgang, Untergang klappt.
ESXi@NUC+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

Waldmensch

Also ich fand den Ansatz mit dem Ringbuffer jetzt nicht so verkehrt. Ich weiss nicht warum der Ansatz nicht über ein normales Array lief, aber vielleicht kann man das nicht im Speicher halten? Jedenfalls sind alle anderen Ansätze aufwändiger (bsp. letzte werte aus DB oder Log lesen)

Stargazer

Hallo zusammen,

im Gegensatz zum SMASTP-Modul läuft dieses jetzt auch mit unserem SB 4000TL-11 und Speedwire !

Parallel läuft noch SBFSpot.

Dieses Modul hier habe ich nur zum testen genommen. Da habt ihr ganze Arbeit geleistet !


Viele Grüße

André

sct14675

kurzes Update:
Die Version 1.5 von DS_Starter lief bei mir jetzt eine Woche problemlos.
Hab die Aenderungen in Github aufgenommen, aber noch kein Release erzeugt > Die Datei kann trotzdem direkt runtergeladen werden!

https://github.com/Rincewind76/SMAInverter/blob/master/76_SMAInverter.pm

tschuess
Thomas

Xguide

Hallo Heiko,

ich bin gestern nach einer langen Auslandsreise auch mal dazu gekommen dein Modul zu implementieren.
Ich habe die von Dir veröffentlichte Version 1.6 genutzt, nicht die 1.5 die Thomas ins Git gepackt hat.
Läuft soweit prima, vorallem die Synchronität über den "get data" Befehl ist klasse.
Mir ist aufgefallen, dass mein PV-Wechselrichter allerding falsch erkannt wird. Ich habe einen STP 10000-TL20, erkannt wird ein STP 5000TL-20. Das hat natürlich alles nichts mir der Funktionalität zu tun und ist nur Kosmetik. Dummerweise sehe ich den entsprechenden Parameter auch nicht mehr in den Readings ("SMAInverter_devtypes"), werde es mir aber auch noch einmal in Ruhe ansehen.
Einen weiteres Device magst du vielleicht ergänzen, und zwar: 9278 => "Sunny Island 3.0M"

Danke und viele Grüße,

Marcel
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -