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

[DS_Starter]

Hallo Volker, hallo zusammen,

ich habe an dem bestehenden Modul 77_SMAEM ein bisschen weiter gewerkelt und einiges ergänzt und geändert was ich als sinnvoll erachtet habe.
Das sind die Änderungen:

 * die Intervallzeit wird über Attribut "intervall" festgelegt. Dadurch wird eine Fehlermeldung vermieden. Der Def-String ist nun nur noch "define <name> SMAEM"
 * die Zählerwerte GRIDIN_SUM, GRIDOUT_SUM werden beim auslesen im File UniqID auf die Platte geschrieben -> wenn  FHEM oder das Modul längere Zeit nicht aktiv sind bzw. nach Restart startet das Modul mit den gespeicherten Werten (liest von Platte ein)
 * zwei Internals GRIDIN_SUM, GRIDOUT_SUM sowie die Readings Bezug_WirkP_Zaehler_Diff, Einspeisung_WirkP_Zaehler_Diff ->
    mit Hilfe dieser Readings/Internals werden die Differenzen zur letzten Messung berechnet und können geloggt werden.
    Wenn man DbLog für das Logging benutzt kann man sehr schön über SQL-Abfragen durch Aufsummierung über die Zeiträume entsprechende Auswertungen des
   verbrauchten bzw. eingespeisten Stroms anfertigen.  Vielleicht kann man auch noch ein schönes Auswertungstool schreiben wenn es das noch nicht geben soltte.
 * das Internal "LASTUPDATE" zeigt die lesbare Zeit des letzten Updates

Durch dieses Änderungen gehen die Meßwerte auch nicht verloren wenn der Meter mal zurückgesetzt wird (z.B. durch Stromausfall wie bei mir geschehen).  Ich habe das nun schon recht lange gestet und es läuft prima bei mir.
Vielleicht gefällt es dir/euch in dieser Form ebenfalls und es könnte bald eingcheckt werden da die anderen SMA-Geräte wahrscheinlich nicht mit integriert werden können und eher in einem separaten Modul (Waldmensch) einfließen.

viele Grüße
Heiko

[Volker Kettenbach]

Hallo Volker, hallo zusammen,

ich habe an dem bestehenden Modul 77_SMAEM ein bisschen weiter gewerkelt und einiges ergänzt und geändert was ich als sinnvoll erachtet habe.
Das sind die Änderungen:

 * die Intervallzeit wird über Attribut "intervall" festgelegt. Dadurch wird eine Fehlermeldung vermieden. Der Def-String ist nun nur noch "define <name> SMAEM"
 * die Zählerwerte werden beim auslesen im File UniqID auf die Platte geschrieben -> wenn  FHEM oder das Modul längere Zeit nicht aktiv sind bzw. nach Restart startet das Modul
   mit den gespeicherten Werten (liest von Platte ein)
 * zwei Internals GRIDIN_SUM, GRIDOUT_SUM sowie die Readings Bezug_WirkP_Zaehler_Diff, Einspeisung_WirkP_Zaehler_Diff ->
    mit Hilfe dieser Readings/Internals werden die Differenzen zur letzten Messung berechnet und können geloggt werden.
    Wenn man DbLog für das Logging benutzt kann man sehr schön über SQL-Abfragen durch Aufsummierung über die Zeiträume entsprechende Auswertungen des
   verbrauchten bzw. eingespeisten Stroms anfertigen.  Vielleicht kann man auch noch ein schönes Auswertungstoll schreiben wenn es das noch nicht geben soltte.
 * das Internal "LASTUPDATE" zeigt die lesbare Zeit des letzten Updates

Durch dieses Änderungen gehen die Meßwerte auch nicht verloren wenn der Meter mal zurückgesetzt wird (z.B. durch Stromausfall wie bei mir geschehen).  Ich habe das nun schon recht lange gestet und es läuft prima bei mir.
Vielleicht gefällt es dir/euch in dieser Form ebenfalls und es könnte bald eingcheckt werden da die anderen SMA-Geräte wahrscheinlich nicht mit integriert werden können und eher in einem separaten Modul (Waldmensch) einfließen.

viele Grüße
Heiko

Cool. Kannst Du mir die Änderungen als patch gegen den git-head schicken? (git diff)
Ich werde schauen, dass ich 77_SMAEM ins offizielle Repository bekomme, denn ich denke auch, dass der SMA-STP wohl ein eigenes Modul bekommen wird.

[DS_Starter]

So, hab das jetzt mal mit git versucht  und hoffe es richtig gemacht zu haben.
Habe das diff-File angehängt. Schau mal Volker ob du damit klar kommst.

Gruß
Heiko

[DS_Starter]

Hallo Volker und Mitstreiter,

ich habe das Modul noch erweitert um die Readings: Bezug_WirkP_Kosten_Diff, Einspeisung_WirkP_Verguet_Diff und die Attribute feedinPrice, powerCost.

Über die Attribute setzt man den individuellen Strompreis seines Tarifs (powerCost) bzw. den Vergütungssatz für die kWh (feedinPrice) ein.

Darüber werden dann wieder die Differenzwerte bei jeder Messung geloggt.

Für die DB-Auswertung (setzt allerdings den Einsatz des Moduls 93_DbLog voraus) habe ich ein Modul 93_DbRep.pm geschrieben was man natürlich auch für allgemeine Auswertungen unabhängig vom SMAEM nutzen kann. Das Modul und die Beschreibung gibt es hier:
https://forum.fhem.de/index.php/topic,53079.msg450475.html#msg450475

Das geänderte 77_SMAEM.pm und Screenshots für die Auswertungen mit 93_DbRep habe ich angehängt.

schönes Pfingsten,
Heiko

[Volker Kettenbach]

Hi Heiko,

ich bin gerade eben dabei, Deinen letzten Patch einzuarbeiten und zugleich das Modul SVN-fähig zu machen, d.h. ich strebe an, dass Modul in den nächsten Tagen ins offizielle SVN hoch zu laden.
Zu Deinen Verbesserungen noch folgende Anmerkungen:

Aus dem Patch kann ich alles übernehmen, bis auf die Entfernung der Serialnummer aus der Bezeichnung des Readings (sowie die dann nicht nötige Anzeige der Serial)
1. ist das Modul dafür gemacht mehrere SMAEM zu unterstützten und das würde sonst nicht mehr gehen
2. würde die bisherige Historie dadurch zerstört werden (=> Logs etc.)
Da müsstest Du also ggf. mit leben, wenn das Modul ins offizielle SVN wandert.

Zur heutigen Änderung: ich übernehme gerne auch die Kostenberechnung und deren Attribute.

Was das 93_DBRep.pm angeht: super Idee, aber ich würde das nicht mit in meinem Repository aufnehmen wollen und auch nicht ins SVN hoch laden, da ich es nicht verwende und somit auch nicht testen kann.

Werde jetzt mal Deine letzten Änderungen testen und das ganze SVN-Ready machen! Melde mich, wenn der Commit in github gelaufen ist.

Gruß
Volker

[DS_Starter]

Hallo Volker,

das 93_DbRep war nur als Information für alle Interessenten gedacht, sollte nicht in dein Modul mit eingehen.
 Ggf. checke ich es irgendwann mit ein wenn es genügend getestet ist.

Wegen der Seriennummer würde ich dich bitten evtl. noch ein Attribut für einen Multmetersupport o.ä. vorzusehen um in diesem Fall die Seriennummer bei Bedarf mit einzublenden.

Hintergrund ist u.a. dass das Readingsfeld im DbLog-Modul nur 32 Zeichen lang ist und die Readingsbezeichnungen nicht so endlos sein dürfen. Wenn du die Seriennummer zwangsweise mit davor setzt, dürften alle Nutzer die Logs in eine Datenbank schreiben Probleme haben.

M. Meinung nach sollte die SN auf jeden Fall abschaltbar sein um auf bestimmte Erfordernisse reagieren zu können.

Gruß
Heiko

[Volker Kettenbach]

Hintergrund ist u.a. dass das Readingsfeld im DbLog-Modul nur 32 Zeichen lang ist und die Readingsbezeichnungen nicht so endlos sein dürfen. Wenn du die Seriennummer zwangsweise mit davor setzt, dürften alle Nutzer die Logs in eine Datenbank schreiben Probleme haben.

Das lässt sich leicht lösen: einfach in der SQL-Datenbank die Definition der Felder DEVICE und READING verändern, z.B. auf varchar(64).

[DS_Starter]

Hi Volker,

Ja sicher, aber ich bin nicht der Maintainer von DbLog. Insofern wäre es sicherlich angebracht sich zunächst einmal den Gegebenheiten anzupassen. Dort müßten dann die Scripte für die DB-Erstellung angepasst werden usw.  Nicht jeder FHEM-Nutzer ist ja mit dem DB-Handling vertraut und die SN nur bei Notwendigkeit einzublenden ist ja eine Kleinigkeit und würde sicherlich vielen Nutzern dienlich sein.

[Volker Kettenbach]

Hi Heiko,

ich verstehe, dass Du die Seriennummern nicht in den Readings-Bezeichnungen haben willst.
Ich denke aber, dass sie für das ganze Modul notwendig sind, wenn man Speedwire korrekt implementieren will. Es handelt sich um ein Protokoll, über das mehrere Geräte gleichzeitig Ihre Daten übermitteln. Daher muss die Software in der Lage sein, damit auch um zu gehen. Wir würden sonst die Software "verschlimmbessern".

Ich würde durchaus einen Patch akzeptieren, der ein Attribut "disable_serno_in_reading" = (true|false) implementiert.
Wer das dann so haben will, kann das Attribut setzen.
Default sollte es aber an sein.

Gruß
Volker

[DS_Starter]

Hi Volker,

genau das meinte ich, per Attr abschaltbar würde es doch treffen, wäre super 
Danke dir !

[Volker Kettenbach]

Hi Volker,

genau das meinte ich, per Attr abschaltbar würde es doch treffen, wäre super 
Danke dir !

Bitte einen (Unified) Patch gegen https://github.com/kettenbach-it/FHEM-SMA-Speedwire/blob/master/77_SMAEM.pm schicken!
Der letzte Patch war gut, den konnte ich verwenden.

Gruß
Volker

[DS_Starter]

Du meinst damit sicher ein Diff bzgl. meiner letzten Version aus #93 ?

EDIT: nehme alles zurück .... sehe du hast diese Änderungen bereits drin ..   Ich lade mir diese Version mal runter und schlage dir einen Patch bzgl dem besprochenen Attr vor.

[DS_Starter]

Hi Volker,

noch eine kurze Frage. Wozu hast du denn beim ReadingsUpdate überall vor der Seriennummer "SMAEM" davor ?

Beispiel:   readingsBulkUpdate($hash, "SMAEM".$smaserial."_L3_Einspeisung_Wirkleistung_Zaehler", sprintf("%.1f",$l3_einspeisung_wirk_count));

Das habe ich bisher nicht ergründen können.

Grüße
Heiko

[Volker Kettenbach]

noch eine kurze Frage. Wozu hast du denn beim ReadingsUpdate überall vor der Seriennummer "SMAEM" davor ?

Weil das die eineindeutige Bezeichnung eines Speedwiregerätes im Netzwerk ergibt.
Die Seriennummer an sich ist nicht eindeutig, sondern nur SuSy-ID+Serial.
Man könnte auch also auch die Susy-ID verwenden, ich habe diese aber in SMAEM "übersetzt", da die Susy-ID dem Anwender nicht viel sagen wird.

[DS_Starter]

Ok ... verstehe.  Was hältst du davon statt des fixen "SMAEM" den Device-Namen zu verwenden den der Nutzer beim Anlegen des SMAEM-Devices vergibt ?  Wäre m.M. nach irgendwie einleuchtender.