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

sct14675 · 21 Juli 2016, 07:41:39

Das Modul ist bei mir jetzt die Nacht über fehlerfrei (d.h. ohne Absturz) gelaufen. Wie schauts bei euch aus?

@Stargazer
Ich nehm an, du kopierst die Ausgabe aus einem Terminal-Fenster. Das hat nur begrenzten Speicherplatz, daher werden die ersten Zeilen "vergessen".
Einfacher ist es, die komplette Ausgabe in eine Datei umzuleiten:

Code Auswählen

./SBFspot -nocsv -d5 -v5 > output.txt
Die Datei kannst du entweder hier ins Forum reinhängen oder mir schicken. Ich schau sie mir dann an, was da anders läuft als bei mir.

@all
Wegen den Namen der Readings bin ich offen für alles. Ich bin da eh mit fast grenzenloser Phantasielosigkeit gesegnet...
Ich kann gern einen "Detailed Info" Modus einbauen, der durch einen Parameter aktiviert wird und dann mehr ausliest (und mehr Readings generiert).
(Sobald ich rausgefunden hab, wie man einen Parameter definiert)
Ich komm allerdings heute nicht mehr dazu. Morgen gehts wieder weiter!

tschüss,
Thomas

Waldmensch · 21 Juli 2016, 08:37:23

Zitat(Sobald ich rausgefunden hab, wie man einen Parameter definiert)

1) Globale Variable definieren
2) Den Parameter in der Liste Zeile 85 bekannt machen
3) Darunter die Validierung der Eingabe und Zuweisung zur Variablen (Das gilt für den Modulstart)
4) Ab Zeile 229 nochmal Validierung und Zuweisung (die Funktion wird angesprungen, wenn ein Parameter zur Laufzeit geändert wird)

Kannst ja copy/paste von einem anderen booleschen Parameter machen (Bsp. suppress Parameter)

Volker Kettenbach · 21 Juli 2016, 08:41:07

Zitat von: Waldmensch am 20 Juli 2016, 20:31:36
Ich verstehe nicht, wozu man die ganzen Daten im Minutentakt ins Log oder die Datenbank meißeln wollt. Wozu 1mio mal die Seriennummer? Das wird doch alles extrem träge beim erstellen der Diagramme etc. Ihr könnt gern einen extended Mode einbauen. Mit diesen vielen einzelabfragen wird das Modul sehr langsam werden. Oder baut doch einfach ein separates Modul, was SBFspot komplett simuliert. Dieses Modul war als lightweight geplant. Aus diesem Grund habe ich auch auf extreme Sparsamkeit an Datenmüll geachtet (Inaktivitätsmodus und sleepmodus) Du willst das jetzt ins Gegenteil verkehren? Da bin ich raus.

Schau Dir mal DbLogInclude an.

DS_Starter · 21 Juli 2016, 08:43:04

Morgen Thomas,

ganz kurze Info. Das originale eingecheckte Modul läuft bei mir tadellos.
Dein Modul bringt bei mir Fehler:

Code Auswählen


2016.07.21 08:30:20.414 0: : Started with sleepmode from 22:0 - 5:0
2016.07.21 08:30:34.475 2: STP5000: Sending query to inverter 192.168.2.40:9522
2016.07.21 08:30:39.483 1: STP5000 query timed out
2016.07.21 08:30:39.483 1: STP5000: Too little data received (Len:NaN/timeout)
2016.07.21 08:31:39.552 2: STP5000: Sending query to inverter 192.168.2.40:9522
2016.07.21 08:31:44.557 1: STP5000 query timed out
2016.07.21 08:31:44.557 1: STP5000: Too little data received (Len:NaN/timeout)

Habe momentan keine Zeit weiter zu schauen, weshalb usw.
Die Idee eines erweiterten (full) Mode für weitere Readings würde m.M. nach den Einwänden von Waldmensch gestern Rechnung tragen und jeden Bedürfnissen genügen.
Man steuert so etwas über Attribute.
Hab momentan keine Zeit zu mehr ....

viele Grüße
Heiko

Volker Kettenbach · 21 Juli 2016, 08:47:05

Zitat von: DS_Starter am 20 Juli 2016, 18:42:18
Hallo Thomas,

super, wollte mich auch noch mit dem Modul beschäftigen ... aber wenn du schon mal dabei bist ....

Es wäre evtl. reizvoll wenn das Modul die bisher von SBFSpot gelieferten Readings auch bereitstellen könnte, auch mit den entspr. Namen.
Das hätte m.M. nach den Vorteil dass bisherige und historische Auswertungen nicht geändert werden müssen. die Daten quasi nicht "verloren" gehen.

Das wäre diese Liste:

Code Auswählen Erweitern
current_inverter_time 20.07.2016 18:25 device_class Solar-Wechselrichter device_name SN: 304978710 device_status Ok device_temperature 58.0°C device_type STP 5000TL-20 etoday 31.552 etotal 10.416.575 feed-in_time 7257.19h getenergyproduction_returned_an_error -1 getgridrelaystatus_returned_an_error -1 getmaxacpower_returned_an_error -1 getspotacpower_returned_an_error -1 getspotactotalpower_returned_an_error 1 grid_freq. 49.96 gridrelay_status Geschlossen inverter_sleep_time 20.07.2016 18:25 inverter_wake-up_time 20.07.2016 05:33 operation_time 7306.49h pac_max_phase_1 5000 pac_max_phase_2 5000 pac_max_phase_3 5000 phase_1_iac 1.058 phase_1_pac 0.248 phase_1_uac 234.68 phase_2_iac 1.049 phase_2_pac 0.247 phase_2_uac 235.20 phase_3_iac 1.044 phase_3_pac 0.246 phase_3_uac 235.49 reading_events 2016-Jul-01 serial_number 304978710 software_version 02.54.00.R state active string_1_idc 1.665 string_1_pdc 0.689 string_1_udc 443.46 string_2_idc 0.000 string_2_pdc 0.000 string_2_udc 0.00 summary enabled susyid 181 - SN: 304978710 total_pac 0.693

Was meinst du dazu ? Und vor allem Volker, er ist ja schließlich der Modul-Maintainer.
Aber prima würde ich es finden ....

Grüße
Heiko

Man könnte einen Switch einbauen: NameReadingsBy = (SBFSpot|SHM).
Dann kann jeder einstellen, wie er es haben will.

Ich hätte auch kein Probleme einfach beides auszugeben. Man kann mit DbLogInclude steuern, was in die DB soll.
Aber: der Performanceaspekt, den Waldmensch anführt, ist nicht von der Hand zu weisen.
Wenn man sehr viele Readings bearbeitet, wird das deutlich spürbar.

Mir persönlich ist es egal. Ich habe diese WR ja nicht.
Mir wäre sehr wichtig, dass das ganze sauber programmiert, getestet und dokumentiert ist. SMASTP hat da noch ziemlich Nachholbedarf ich kann das Modul mangels diese WR nicht testen.

Volker Kettenbach · 21 Juli 2016, 08:55:04

Zitat von: Volker Kettenbach am 21 Juli 2016, 08:47:05
Ich hätte auch kein Probleme einfach beides auszugeben. Man kann mit DbLogInclude steuern, was in die DB soll.
Aber: der Performanceaspekt, den Waldmensch anführt, ist nicht von der Hand zu weisen.
Wenn man sehr viele Readings bearbeitet, wird das deutlich spürbar.

Mir persönlich ist es egal. Ich habe diese WR ja nicht.
Mir wäre sehr wichtig, dass das ganze sauber programmiert, getestet und dokumentiert ist. SMASTP hat da noch ziemlich Nachholbedarf ich kann das Modul mangels diese WR nicht testen.

Noch ein Nachtrag: es sollten auf jeden Fall alle Parameter, die der WR ausgibt, auch verarbeitet werden.
Was sinnvoll ist oder nicht, können nicht wir entscheiden, sondern das entscheidet der Anwender des Moduls und der sollte alles zur Verfügung haben, was geht.

In welcher Form (SHM vs. SBF) diese dargestellt werden, da kann man gerne ein Switch einbauen.

Generell halte ich es auch für wichtig, Rückwärtskompatibel zu sein. Also sollte das SBF-Format auf jeden Fall ausgegeben werden.

@Waldmensch: der Raspberry 3 ist schneller als der 2 und *wesentlich* schneller als der 1. Einfach auf den 3er upgraden. Das bringt enorm viel.

Waldmensch · 21 Juli 2016, 09:01:07

Zitat von: Volker Kettenbach am 21 Juli 2016, 08:41:07
Schau Dir mal DbLogInclude an.

Ja kenne ich, aber das findet hinter dem Modul statt. Das Modul ackert trotzdem die ganze Zeit am WR rum. Ich weiß nicht, ob ein 60 Sekunden Intervall bei so vielen Abfragen inkl. Netzwerk Latenz mit Aufarbeitung noch ausreicht. Wir haben 5 Sekunden Timeout glaube ich. Also sollte der Basis Intervall nicht kleiner sein als Anzahl der Abfragen * 5. Ansonsten wird das im Chaos enden, wenn der Timer zuschlägt und einen neuen Zyklus initiiert, obwohl, worst case, der alte Zyklus noch nicht durch ist. Gibt ne wunderbare Racecondition.

Waldmensch · 21 Juli 2016, 09:07:35

Volker, wenn Du alles abbilden willst, wäre es auch konsequent die TagListDE-DE.txt mit 4000 Einträgen aus SBFSpot zu integrieren um den Devicetyp im Klartext auszugeben. Natürlich kann man SBFSpot komplett nachbauen, dann sollte man aber das Design des script überarbeiten und auf ein OO Modell umschwenken. Prozedural stößt das jetzt schon langsam an die Grenze "Spaghetticode"

Stargazer · 21 Juli 2016, 09:13:43

Moin zusammen,

@Thomas: Vielen Dank für die Befehlszeile bei SBFspot. Ich denke, ich schicke dir die Datei heute Abend per PM.

Sonst störe/nerve ich euch wahrscheinlich zu sehr hier. Ist für Anfänger halt schwierig reinzukommen.
Nur wäre es für mich blöd gewesen, wenn ich im Anfängerforum einen extra Thread wegen dem Modul eröffnet hätte. So hat man das Thema direkt mit diesem Thread auf dem Schirm.

Viele Grüße

André

Volker Kettenbach · 21 Juli 2016, 09:17:40

Zitat von: Waldmensch am 21 Juli 2016, 09:07:35
Volker, wenn Du alles abbilden willst, wäre es auch konsequent die TagListDE-DE.txt mit 4000 Einträgen aus SBFSpot zu integrieren um den Devicetyp im Klartext auszugeben. Natürlich kann man SBFSpot komplett nachbauen, dann sollte man aber das Design des script überarbeiten und auf ein OO Modell umschwenken. Prozedural stößt das jetzt schon langsam an die Grenze "Spaghetticode"

Die TagListDE-DE.txt kannst Du ja einfach als Datei beilegen und aus dem Modul abfragen.

Und eine Überarbeitung wäre sowieso sinnvoll, denn schon jetzt ist das ganze unübersichtlich.
Also nur zu!

Waldmensch · 21 Juli 2016, 10:44:48

Also ich nicht, weil ich es nicht für sinnvoll zur Verwendung in einem FHEM Modul bzw. zur Hausautomation erachte und es SBFSpot ja als Sorglospaket bereits gibt, mit Anbindung an FHEM. Nicht alles was man machen kann, ist auch in jeder Situation sinnvoll.

Aber ich merk schon, ich steh mit dieser Meinung ziemlich alleine. Zum Glück kann ich es mir selber für mich optimal und schlank hinbiegen.

DS_Starter · 21 Juli 2016, 12:37:57

Persönlich würde ich es sehr schade finden wenn du (oder andere Mitstreiter) sich abgehängt fühlen würdest und wir es nicht schaffen eine gemeinsame und den verschiedenen Sichtweisen / Anforderungen entsprechende Lösung zu finden.
Deswegen finde ich den Vorschlag von Thomas gut, für das Modul verschiedene Level (nenne ich sie mal mode0, mode1, Mode 2) zu definieren. Diese Modes generieren mehr oder weniger Abfragen / Readings. Mode 0 entspräche der jetzigen leichten Variante. Wenn der Nutzer sich entscheidet mehr Readings haben zu wollen, kann er die höheren Modes einschalten mit der Konsequenz evtl. mehr Systemlast zu generieren.

In einer solchen Vorgehensweise sehe ich nur Vorteile. Der User kann entscheiden was er möchte/benötigt und du hättest nach wie vor deine schlanke Variante.

Und auch für Volker als Maintainer des Moduls hat es Vorteile. Da er ja diesen WR selbst nicht hat braucht er Unterstützung bei Tests etc. Je mehr Unterstützung er bekommt desto besser ist es für ihn und letztlich für das Modul.

So zumindest ist meine Sicht.

Grüße,
Heiko

cerberus · 21 Juli 2016, 12:44:02

Hallo, habt ihr denn eine Idee wie man den SMA Multigate mit einer unbestimmten Anzahl an Modul-Wechselrichtern mit in das Modul einbinden kann?

Grüße
cerberus

Waldmensch · 21 Juli 2016, 13:30:05

Wenn die alle eine eigene IP haben, würde ich mehrere Instanzen des Moduls laufen lassen. Dann in einem Dummy in FHEM über userreadings alle Werte zusammenholen.

cerberus · 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