SMA Sunny Home Manager abfragen.

[Wzut]

wenn Wzut das nicht schon längst gemacht hat.

Doch hatte er schon gestern Morgen
Ich bin euch noch die letzte Version schuldig, hatte da einen Darstellungsfehler der mich fast zur Verzweiflung gebracht hat ....

Bei den SVG bin ich auch einen Schritt weiter , einfache Icons konnte ich durch editieren des Quelltextes größer machen,
bei anderen tut Inkscape ganz gute Arbeit.

Die zusätzlichen Attribute sind type -> pv,co,pvco & dif für die nun vier möglichen Darstellungen
und das Attribut W/kW zum umschalten der Anzeigewerte

[Wzut]

Und weil es so schön ist , Umbau auf die Standart FHEM Icons die mit weather_ beginnen.
Vorteil : FHEM übernimmt fast perfekt die Skalierung und passt je nach Style sogar die Ausgabefarbe an.
Falls man diese aber nicht möchte kann mit dem neuen Attribut weather_color umgefärbt werden.
(siehe Screenshot)

Kleiner Nachteil : es fehlt FHEM ein Icon für Nacht. Es gibt aber weiter oben in der Auswahl ein Icon mit Namen day_night.
Dieses habe ich mit Inkscape bearbeitet , d.h. die Sonne gelöscht und die Mondsichel vergrößert, es muß also nur dieses eine Icon der Sammlung zugefügt werden.
Ich werde mal im passenden Unterforum nachfragen ( https://forum.fhem.de/index.php/topic,100655.0.html )
und das Ding dann bei postiv Bescheid einchecken, wenn nicht kann es Heiko ja in seinen contrib Ordner packen.
   

[DS_Starter]

Hallo Jungs,

@Wzut, mach mal in Ruhe deine Baustellen fertig.
Wenn ich ab Montag wieder aktiv bin, werde ich mich wohl erstmal um ein kleines Problem mit SMAEM kümmern.
Xguide kennt das.
Wenn ich das erledigt habe, gehe ich unser Modul wieder an.

Btw.... Top Job . Wäre gut wenn das eine Icon eingecheckt werden könnte. Soll ja perspektivisch nicht im contrib bleiben.

Grüße,
Heiko

[Wzut]

Ok, dann hier meine letzte Version.
Das Nacht Icon habe ich als Übergang einfach in den Quelltext gepackt so das erst einmal jeder der testen möchte etwas sieht.

Edit : so langsam kapiere ich auch wie Inkscape bedient wird. Ich habe mal bei den drei weather_cloudy_ Icons die Sonne gelöscht und durch den Mond ersetzt.

[Dersch]

So, heute wurden die Elektroarbeiten (neuer Verteilerschrank) abgeschlossen und meine SMA Gerätschaften in Betrieb genommen. SMAPortal läuft schon mal aber in Betrieb darf die Anlage erst nach dem Zählertausch durch den Netzbetreiber. Nun heißt es Warten bis ich endlich meine Module (seit Mitte April auf dem Dach) auch mal in mein Netz einspeisen dürfen. Bis dahin sehe ich in FHEM nur meinen aktuellen Bedarf aus dem Stromnetz.

Also habe ich ja nun noch etwas Zeit die Entwicklung hier im Thread aufzuarbeiten.

Habt ihr ein paar Tipps und Hinweise? Ist ja einiges passiert hier so wie es scheint

Helfen mir noch weitere Module für SMA außer dem Abgreifen des SunnyPortals?

Grüße
Dirk

[Waldmensch]

Beim Testbetrieb sollte sich der Zähler rückwärts drehen.


Gesendet von iPhone mit Tapatalk

[Wzut]

Helfen mir noch weitere Module für SMA außer dem Abgreifen des SunnyPortals?

Natürlich, das Modul hier ist IMHO gut & schön um die Prognosedaten zu haben, aber für die eigenen Echtzeitdaten solltest du dir Heikos SMAEM anschauen.
Des weiteren gehe ich davon aus das dein Wechslrichter auch von SMA ist. Dann solte noch entweder SMAInverter dazu oder ModbusAttr.

[Xguide]

Beim Testbetrieb sollte sich der Zähler rückwärts drehen.


Gesendet von iPhone mit Tapatalk

Ich glaube das dürfen die heute nicht mehr, früher wurde das in der Tat so gemacht. Meine Anlage durfte auch erst nach dem Zählertausch in Betrieb gehen, das war 2015. Da aber meine Tochter am gleichen Tag geboren wurde, hatte ich ein paar andere Sachen um die Ohren und kenne nicht alle Details. Allerdings war der Netzbetreiber bei mir auch schneller, PV-Generator am Freitag abschliessend installiert, Montag Installation der WR und Kabel ziehen. Dienstag kamen dann die  Stadtwerke mit dem neuen Zähler und ab ans Netz.


Gesendet von iPhone mit Tapatalk

[Waldmensch]

Also mein Solarteur hat mir 2014 nach Fertigstellung der Anlage gesagt: ,,und das hier ist der Hauptschalter des Wechselrichters, sie dürfen den nicht reinstecken, sonst läuft der Zähler rückwärts" und später, im gehen: ,,übertreiben sies nicht"


Gesendet von iPhone mit Tapatalk

[Wzut]

Die Diskussion ist hier aber etwas OT ... Zähler ab Baujahr X haben eine Rücklaufsperre , kommt also auf einen Versuch an.
Auf jeden Fall ist es ein gutes Geschäft, denn später bekommt man nicht mehr 100 % des Kaufpreises für eine kWh ......

[Xguide]

Dann mal wieder zu OnTopic....

Hallo Wzut,

ich habe Deine Version nun mal eingespielt - sorry eher war kein Zeit.
Nachdem ich mal alle attr gesetzt habe, gefällt es mir echt gut. Eine Sache ist etwas unübersichtlich im style pvco, vermutlich aber auch in den Anderen, und zwar wenn co > pv ist. Klar kann man das durch Farben definieren, aber eine weitere Idee wäre es die Werte zu negieren. bei -1.0 kW ist sofort klar, dass es sich um den Bezug handeln muss.

Sehe ich es richtig, dass im style ("type") pvco die consumer nicht mehr berücksichtig werden?
Darüberhinaus musste ich gerade feststellen, dass sie in den anderen Styles auch nicht funktionieren.

Hatte gerade keine Zeit zu vergleichen, habe meine Schleife zur Initialisierung des @pgCDev reinkopiert und es funzt wieder.
Solltest Du mal ersetzen....

Code Auswählen Erweitern


  #+++++++++++++++++++++++++++++++++++++++++++++++++++++++
  # MS: get consumer list and display it in portalGraphics
  #+++++++++++++++++++++++++++++++++++++++++++++++++++++++
  #foreach (@pgCDev)
  #{
  #  my ($itemName, undef) = split(':',$_);
  #  $itemName =~ s/^\s+|\s+$//g;  #trim it, if blanks were used
  #
  #  $_ =~ s/^\s+|\s+$//g;  #trim it, if blanks were used
  #  #check if listed device is planned
  #  if (ReadingsVal($name, "L3_".$_."_Planned", "no") eq "yes")
  #  {
  #    #get start and end hour
  #    my ($start, $end); # werden auf Balken Pos 0 - 23 umgerechnet, nicht auf Stunde !!
  #    # Pos = 24 -> ungültige Pos = keine Anzeige
  #
  #    if(AttrVal("global","language","EN") eq "DE")
  #    {
  #     (undef,undef,undef,$start)  = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeBegin",'00.00.0000 24') =~ m/(\d{2}).(\d{2}).(\d{4})\s(\d{2})/;
  #     (undef,undef,undef,$end)    = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeEnd",'00.00.0000 24')   =~ m/(\d{2}).(\d{2}).(\d{4})\s(\d{2})/;
  #    }
  #     else
  #    {
  #     (undef,undef,undef,$start)  = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeBegin",'0000-00-00 24') =~ m/(\d{4})-(\d{2})-(\d{2})\s(\d{2})/;
  #     (undef,undef,undef,$end)    = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeEnd",'0000-00-00 24')   =~ m/(\d{4})-(\d{2})-(\d{2})\s(\d{2})/;
  #    }
  #
  #    $start = int($start);
  #    $end   = int($end);
  #
  #    #correct the hour for accurate display
  #    if ($start < $t{0})
  #    {  #consumption seems to be tomorrow
  #      $start = 23-$t{0}+$start;
  #    } else { $start -= $t{0}; }
  #
  #    if ($end < $t{0})
  #    { #consumption seems to be tomorrow
  #      $end = 23-$t{0}+$end;
  #    } else { $end -= $t{0}; }
  #
  #    $_ .= ":".$start.":".$end;
  #
  #  } else { $_ .= ":24:24"; }
  #}
  foreach (@pgCDev)
  {
    my ($itemName, undef) = split(':',$_);
    $itemName =~ s/^\s+|\s+$//g;  #trim it, if blanks were used
    #check if listed device is planned
    if (ReadingsVal($name, "L3_".$itemName."_Planned", "no") eq "yes")
    {
      #get start and end hour
      my ($start, $end); # werden auf Balken Pos 0 - 23 umgerechnet, nicht auf Stunde !!
  # Pos = 24 -> ungültige Pos = keine Anzeige
      if(AttrVal("global","language","EN") eq "DE")
      {
        (undef,undef,undef,$start)  = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeBegin",'00.00.0000 24') =~ m/(\d{2}).(\d{2}).(\d{4})\s(\d{2})/;
        (undef,undef,undef,$end)    = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeEnd",'00.00.0000 24')   =~ m/(\d{2}).(\d{2}).(\d{4})\s(\d{2})/;
      }
      else
      {
         (undef,undef,undef,$start)  = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeBegin",'0000-00-00 24') =~ m/(\d{4})-(\d{2})-(\d{2})\s(\d{2})/;
         (undef,undef,undef,$end)    = ReadingsVal($name,"L3_".$itemName."_PlannedOpTimeEnd",'0000-00-00 24')   =~ m/(\d{4})-(\d{2})-(\d{2})\s(\d{2})/;
      }
 
      $start = int($start);
      $end   = int($end);
 
      #correct the hour for accurate display
      if ($start < $t{0})
      {  #consumption seems to be tomorrow
        $start = 23-$t{0}+$start;
      } else { $start -= $t{0}; }

      if ($end < $t{0})
      { #consumption seems to be tomorrow
        $end = 23-$t{0}+$end;
      } else { $end -= $t{0}; }

      $_ .= ":".$start.":".$end;
    } else { $_ .= ":24:24"; }
  }
  #+++++++++++++++++++++++++++++++++++++++++
  #/MS
  #+++++++++++++++++++++++++++++++++++++++++


[Xguide]

Hier noch zwei Screenshots, Consumer gehen nach Modifikation in allen Styles wieder...
PM File anbei....

[Wzut]

Eine Sache ist etwas unübersichtlich im style pvco, vermutlich aber auch in den Anderen, und zwar wenn co > pv ist. Klar kann man das durch Farben definieren, aber eine weitere Idee wäre es die Werte zu negieren. bei -1.0 kW ist sofort klar, dass es sich um den Bezug handeln muss.
<--snipp -->
Sehe ich es richtig, dass im style ("type") pvco die consumer nicht mehr berücksichtig werden?

a. Du meinst das was im Screenshot zu sehen ist ? Wenn man die Werte negiert ist das IMHO von der Logik falsch, denn mein Verbrauch bleibt positiv
Im type diff wird soetwas klar.

b. die consumers sollten nur bei pv & co gehen , ok Fehler war  L3_".$itemName."_Planned"  vs. L3_".$_."_Planned"
Das sie bei pvco und diff nicht gehen ist Absicht !
Hintergrund : zum einen unsere alte Diskussion wegen dem normalen Icon und dann wollte ich ein und die selbe Schleife nicht an drei Stellen verbauen.
IMHO gehört das in eine eigene Funktion und die kann man dann an drei Stellen aufrufen.
Bsp ist z.B. die neue Funktion formatVal6 -  das wurde zuerst auch nur einmal gebraucht, ergo war es ok direkt in die Schleife zu schreiben.
Mit den anderen typen wurde es dann aber an sieben Stellen nötig, also  ist es jetzt eine eigene Funktion.

[Xguide]

a. Du meinst das was im Screenshot zu sehen ist ? Wenn man die Werte negiert ist das IMHO von der Logik falsch, denn mein Verbrauch bleibt positiv
Im type diff wird soetwas klar.

b. die consumers sollten nur bei pv & co gehen , ok Fehler war  L3_".$itemName."_Planned"  vs. L3_".$_."_Planned"
Das sie bei pvco und diff nicht gehen ist Absicht !
Hintergrund : zum einen unsere alte Diskussion wegen dem normalen Icon und dann wollte ich ein und die selbe Schleife nicht an drei Stellen verbauen.
IMHO gehört das in eine eigene Funktion und die kann man dann an drei Stellen aufrufen.
Bsp ist z.B. die neue Funktion formatVal6 -  das wurde zuerst auch nur einmal gebraucht, ergo war es ok direkt in die Schleife zu schreiben.
Mit den anderen typen wurde es dann aber an sieben Stellen nötig, also  ist es jetzt eine eigene Funktion.

a: Formell natürlich komplett richtig, als Stilmittel durchaus üblich, oder?
b: D.h. wir ziehen es in eine extra Funktion, auch das wäre natürlich komplett der richtige Ansatz, und werden es in Zukunft wieder in allen types zur Verfügung haben? Sonst macht die Legende in den Styles die keine consumer unterstützen auch keinen Sinn.

[Wzut]

a. Geschmacksache , frag 5 User und du hast 6 verschiedene Meinungen

b. vollkommen richtig, aber es machen eh nicht alle Attribute bei jedem Typ Sinn. Ich sehe das ganze Ding als Baukasten, der User bekommt mit 4 x klicken auf createPortalGrafik , vier verschiedene Angebote. Welche er davon nutzen möchte und wie im Detail ist ganz alleine ihm selbst überlassen. Das finde ich ist eine der großen Stärken von FHEM, der User kann selbst sehr viel bestimmen wenn der Modulautor mitspielt und nicht nur seine persönlichen Vorlieben im Fokus hat.