SMA Sunny Home Manager abfragen.

Begonnen von Brun, 07 Oktober 2014, 10:40:34

Vorheriges Thema - Nächstes Thema

Xguide

Zitat von: Wzut am 07 Mai 2019, 14:19:42
oh ha ... hat da jemand den Smiley übersehen ?
Hallo Wzut, ja habe ich übersehen, war aber auf den Henker und Richter bezogen, am Ende entscheide ich was bei mir läuft  ;) Müsste dann aber auf Updates verzichten :(

Zitat
Marcel ich habe gerade noch ein kleines geistiges Problem mit deiner Zeitkorrektur unterhalb
#correct the hour for accurate display
Zeitkorrektur insofern, dass die Schleife nicht die echten Stunden hochiteriert (1-24), sondern von der Startstunde bspw. 21Uhr 0=21, 1=22, 2=23, 3=0, 4=1....23=20Uhr Damit ich nun die Einschaltzeit richtig einblenden konnte, habe ich genau diese Ermittlung gemacht. Frei formuliert, in x Stunden finden das Ereignis statt und nicht um 10 Uhr.
Weiss gerade nicht wie ich es besser formulieren kann.

Zitatweisst du wann genau die Readings für Start und Ende wieder auf undefined zurück fallen ?
Bzw. bleiben beide mit ihren Werten erhalten solange Ende nicht erreicht ist ?
Ich habe versäumt es loggen. Habe aber die Vermutung, das nach dem Einschalten das planned auf no gesetzt wird und die Infos futsch sind.

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 -

Wzut

Zitat von: Xguide am 07 Mai 2019, 16:17:42
Habe aber die Vermutung, das nach dem Einschalten das planned auf no gesetzt wird
gut, no wäre so schlecht nicht da dann Start und Ende eh egal sind.
Ich denke ich kann heute Abend mal wieder eine Version raushauen, bei der Consumers Sache mußt du dann aber dranbleiben und schauen ob alles stimmt, da es vermutlich nicht so viele User gibt die das eingerichtet haben ( ich kann es ja auch nur simulieren )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Xguide

Kannst mir ja Deine Version mal zur Verfügung stellen, beim letzten Mal hast Du nur einen Screenshot geteilt. Probiere ich gerne aus.
Meinst Du ich bin so ein Exot mit den Steckdosen? Habe die seinerzeit zur Eigenverbrauchsoptimierung als recht praktikabel erachtet. Gut, ich habe dafür auch nichts bezahlt, da ich sie ausgehandelt habe. Das ich dafür extra den Trockner modden musste, war mir auch nicht klar, aber es macht bei mir schon Sinn. So kann ich die Abriegelung etwas abfangen, bin allerdings vom Wetterbericht, PV-Prognose und der Einplanung der Geräte vom SMA-Algorithmus abhängig. Dafür funktionieren die Dinger out of the box.
Neben den SMA Steckdosen gibt es doch inzwischen einen ganzen Haufen EEBUS Komponenten, die müssten sich doch ähnlich verhalten. Dabei stellt sich mir wieder die Frage ob die Neuentwicklungen auch SHM I kompatibel sind, vielleicht kann das j amla jemand am Rande kommentieren. In der Doku steht meist SHM II, wobei das auch der aktuelle ist.

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 -

Wzut

#423
So wie versprochen hier meine aktuelle Version. Ich denke das ist ein Stand mit dem (fast) keine Wünsche mehr offen bleiben und sich auch mit den etwas schwierigern Styles gute Ausgaben erzeugen lassen. Das war die gute Nachricht, die Schlechte : Ihr müsst eure bisherigen Weblinks löschen und mit dieser Version neu anlegen.
Was mich bisher am meisten gestört hat war die Tatsache, das ich zwar mehr als einen Weblink anlegen konnte, aber diese nicht verschieden parametrieren, da die Parameter ja alle direkt aus dem SMAPortal Device kamen. Das ist nun anderes, alle Parameter bzw. Attribute stehen direkt im Weblink Device.
Eine mögliche Anwendung für verschiedene Ausgaben ist z.B. eine Grafik mit 24 Stunden auf der FHEM Webseite aber eine andere z.B. kleinere auf einem zentralen Tablet. Der set <name> createPortalGrafik Befehl kann bis zu 3x wiederholt werden und erzeugt jedesmal einen neuen Weblink.

Die verwendeten Attribute mit ihren neuen Namen als userattr direkt im Weblink Device :
color  -> Farbauswahl der Balken (unverändert)

hours -> (4-24) Anzahl der Balken/Stunden , default 24 (unverändert)

icon  -> Hier kann jetzt das Icon mit Hilfe der normalen Funktion Select Icon (links unten) ein beliebiges Icon direkt ausgewählt werden.
Weblink Devices haben dieses Attribut als default, allerdings wird bei Weblinks nie eines angezeigt. Kann wie üblich durch Zusatz von @farbe noch verändert werden falls es vom Typ svg ist.

show_header -> (1,0) default 1 , Anzeige der Kopfzeile

show_link -> (1,0) default 1 , Anzeige des Device Links links über der Weblink Ausgabe

height  -> default 200 , Höhe der Balken in px und damit Bestimmung der gesammten Höhe, in Verbindung mit hour lassen sich so auch recht kleine Ausgaben erzeugen

font_size -> default 24, legt fest wieviel Platz über den Balken zur Anzeige der Werte freigehalten wird. Bei Styles die große Fonts benutzen kann dieser Wert mit 24 zu klein sein, bzw. u.U. rutscht ein großer Balken unten über die Grundlinie, in diesen Fällen den Wert bitte erhöhen   

html_start & html_end -> default leer, hier können beliebige HTML Strings eingetragen werden die vor und nach dem Weblink ausgegeben werden.
Auf diese Art kann z.B. beim hausautomatiesierung_com Style die Ausgabe nach unten oder oben gerückt werden um einen Zwischenraum zu schaffen,
Bsp <br/>&nbsp;<br /> oder auch einkapselung in eine extra Table, div usw. Damit sollte sich eigentlich nahezu jedes Ausgabeproblem lösen lassen.

Last but not least noch drei Attribute für User wie Xguide die SMA unterstützte Zusatz Schaltgeräte haben
consumers , Komma getrennte Liste der Geräte ( Name = Reading ) in der Form name:icon@farbe, usw. Beispiel :
Trockner:scene_clothes_dryer@yellow,Waschmaschine:scene_washing_machine@lightgreen

legend_pos (top,bottom) -> wo soll die Legende Angezeigt werden

legend_style (icon, text,none) , default icon , bzw. farbiger Text oder keine Legende

Die Attribute legend_pos & legend_style werden nur berücksichtigt wenn auch consumers gesetzt ist.

Edit : letzte Version in Antwort #439

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Xguide

#424
Hi Wzut,

das sieht richtig gut aus! Danke für die Berücksichtigung der Vorschläge und für die gute Integration.
Vorschlag für eine mini Änderung, als Linktitel für show_link könnte der Alias des Weblinks genutzt werden, dann könnte dieser konfiguriert werden. Was meinst du, kommt man da via ReadingsVal ran, der WL Name ist ja bekannt?

Du ignorierst nun die Stunden bei denen kein PV-Ertrag vorhergesagt wird und erstellst keinen Balken, oder? Dadurch ist der WL in der Breite sichtlich schlanker geworden - nett!

Ich habe testweise mal meine Consumer aktiviert und vom Portal planen lassen. Nach dem get data, waren dann die Glühbirnen weg und auch wurden keine consumer angezeigt. Also alles leer!
Es war ein kleiner Fehler drin. Und zwar fehlte ein split beim Abfragen der Readings. Die waren aus dem vorherigen Prozessing noch mit icon@farbe aufbereitet.
Die Symbole werden noch nicht dem richten Balken/Stunde zugeordnet, das schaue ich mir aber gerne morgen noch mal an.

Update mit neuer Erkenntnis: Die im Reading angezeigten Consumptionwerte / h beinhalten schon den geplanten Verbraucher. Also wäre es eigentlich korrekt die Differenz aus PV und Consumption anzuzeigen, das ist dann wirklich die Energie die zur Verfügung stehen sollte!?
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 -

Xguide

Hallo Wzut,

hier noch mal kurz die geänderte Version.
Darin ist auch der L2_Forecast-Today-PV Bug behoben, den ich mit deiner Version plötzlich wieder hatte :)

Danke und 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 -

Wzut

Zitat von: Xguide am 07 Mai 2019, 23:45:31
als Linktitel für show_link könnte der Alias des Weblinks genutzt werden
<--snipp -->
Du ignorierst nun die Stunden bei denen kein PV-Ertrag vorhergesagt wird und erstellst keinen Balken, oder? D
<--snipp -->
Die Symbole werden noch nicht dem richten Balken/Stunde zugeordnet, das schaue ich mir aber gerne morgen noch mal an.
<--snipp -->
Differenz aus PV und Consumption anzuzeigen, das ist dann wirklich die Energie die zur Verfügung stehen sollte!?
Klar den Alias kann man nutzen und editieren (bzw. muß man editieren wenn man mehr als ein WL nutzt) , den hatte Heiko ja schon eingeführt

Ja , keine Balken wenn kein Ertrag zu ewarten ist, da schafft Raum nach rechts bei den Monster Styles. Und genau hier liegt auch noch ein Bug, da es zu einer Divison by Zero kommen kann.

D.h. die Diskussion Icon anzeigen ja oder nein ist hinfällig , da SMA die Werte dann eh soweit runterrechnet ?

ja, bitte du hast ja echte Werte

Zitat von: Xguide am 07 Mai 2019, 23:52:59
auch der L2_Forecast-Today-PV Bug behoben, den ich mit deiner Version plötzlich wieder hatte :)
schau ich mir an , das liegt aber weiter oben im Code und hat nichts mit der HTML Grafik zu tun ?

Wenn ich mir dein png so anschaue fehlen jetzt eigentlich nur noch die Wetter Symbole über den Balken ...... :)
(mal schauen , ich habe ja fast unendlich Zeit als Renter in Lauerstellung an meinem Arbeitsplatz)   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Xguide

#427
Hallo Wzut,

vielleich kannst Du kurz erklären wie du das meinst.
Klar den Alias kann man nutzen und editieren (bzw. muß man editieren wenn man mehr als ein WL nutzt) , den hatte Heiko ja schon eingeführt

Aktuell gibt es zwei Links im Weblink. Einmal den der in der Grafik im Header angezeigt wird und zum SMAPortal device führt und dann der zum Weblink führende der mit "showLink" ein/aus geschaltet werden kann. Letzteren meinte ich, der nicht mit dem Alias versorgt wird.

Zitat
D.h. die Diskussion Icon anzeigen ja oder nein ist hinfällig , da SMA die Werte dann eh soweit runterrechnet ?
Nicht so ganz, ich hatte ja gestern noch herausgefunden, dass hier nur die zu erwartende PV-Leistung angezeigt wird. Es gibt aber das korrespondierende Reading Consumption und außerdem ConsumptionRecommended. Wenn ConsumptionRecommended = true, dann Lampe an. Ggf. sollten wir mal über eine Anzeige von Erzeugung und Verbrauch nachdenken.
Und kurz zum Verständnis (bezogen auf SMA rechnet runter). Mal angenommen ich habe eine Südanlage mit 10kWP, die macht in der Mittagszeit dann so ca 10 kWh, da können schon winige Verbraucher hinzugenommen werden und es kann immer noch die Empfehlung anstehen mehr zu verbrauchen.
Kurz um, so wie es jetzt gerade ist, ist es genau wie im Portal. Siehe Screenshot.

Um die zeitliche Korrektur der Consumer Icons kümmere ich mich gleich....


Zitat
schau ich mir an , das liegt aber weiter oben im Code und hat nichts mit der HTML Grafik zu tun ?

Ist auch nicht wild, hatte das auch schon mal hier kommentiert und im Quelltext ist das markiert. Heiko weiss bescheid.
Wenn Du es auch schon ma glatt ziehen willst, dann nimm meine Version, oder öändere diesen Bereich.


      #MS: Use also old data to integrate daily PV and Consumption
      if ( $current_day == $fc_day ) {
         $PV_sum                            += int($fc_obj->{'PvMeanPower'}->{'Amount'});                          # integrator of daily PV
$consum_sum                    += int($fc_obj->{'ConsumptionForecast'}->{'Amount'}/3600);    # integrator of daily Consumption forecast
      }

      # Don't use old data
      next if $fc_diff_seconds < 0;

      # Sum up for the next few hours (4 hours total, this is current hour plus the next 3 hours)
      if ($obj_nr < 4) {
         $nextFewHoursSum{'PV'}            += $fc_obj->{'PvMeanPower'}->{'Amount'};
         $nextFewHoursSum{'Consumption'}   += $fc_obj->{'ConsumptionForecast'}->{'Amount'} / 3600;
         $nextFewHoursSum{'Total'}         += $fc_obj->{'PvMeanPower'}->{'Amount'} - $fc_obj->{'ConsumptionForecast'}->{'Amount'} / 3600;
         $nextFewHoursSum{'ConsumpRcmd'}   += $fc_obj->{'IsConsumptionRecommended'} ? 1 : 0;
      }

      # If data is for the rest of the current day
      if ( $current_day == $fc_day ) {
         $restOfDaySum{'PV'}            += $fc_obj->{'PvMeanPower'}->{'Amount'};
         $restOfDaySum{'Consumption'}   += $fc_obj->{'ConsumptionForecast'}->{'Amount'} / 3600;
         $restOfDaySum{'Total'}         += $fc_obj->{'PvMeanPower'}->{'Amount'} - $fc_obj->{'ConsumptionForecast'}->{'Amount'} / 3600;
         $restOfDaySum{'ConsumpRcmd'}   += $fc_obj->{'IsConsumptionRecommended'} ? 1 : 0;
         #$PV_sum                        += int($fc_obj->{'PvMeanPower'}->{'Amount'});                 # integrator of daily PV
#$consum_sum                    += int($fc_obj->{'ConsumptionForecast'}->{'Amount'}/3600);    # integrator of daily Consumption forecast
      }


Zitat
Wenn ich mir dein png so anschaue fehlen jetzt eigentlich nur noch die Wetter Symbole über den Balken ...... :)

Genau das habe ich mir gestern auch gedacht :)

Btw: Jetzt wird die Lampe "Verbrauchsanzeige" unterhalb der Consumer angezeigt, das ist dem geschuldet, dass Du $show implementieren wolltest, richtig? Optisch fand ich die Lampen oben besser!
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 -

Wzut

#428
Zitat von: Xguide am 08 Mai 2019, 09:08:16
Aktuell gibt es zwei Links im Weblink.
<--SNIPP-->
Ggf. sollten wir mal über eine Anzeige von Erzeugung und Verbrauch nachdenken.
<--SNIPP-->
Um die zeitliche Korrektur der Consumer Icons kümmere ich mich gleich....
<--SNIPP-->
Genau das habe ich mir gestern auch gedacht
<--SNIPP-->
Optisch fand ich die Lampen oben besser!
a. wir reden vom Gleichen, ich hatte mich zuvor unglücklich ausgedrückt. Ist bereits erledigt und schaut gut aus
b. dann mal los , ich bin zu allem bereit
c. fein
d. SMAPortal gibt das aber als Studendetail nicht her ( nur 1x auf den Tag und next day ) , aber wir haben in FHEM ja diverse Wettermodule  wo man sich bedienen kann.
e. oben/unten, ja/nein IMHO sollten wir das einfach aufschieben bis Heiko aus dem Urlaub zurück ist
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Xguide

Hallo Wzut,

alles gut!

Der Fehler mit der Anzeige der Consumer ist ein UTC Problem. Das Reading selbst zeigt schon den falschen Wert an. +2h wäre richtig.
Jetzt strauchel ich gerade bei Heikos Implementierung der UTC2Local. Gerne hätte ich gewusst ob da was falsch läuft, kannst du mal einen Blick darauf werfen?


  if(%consumers && $forecast->{'ForecastTimeframes'}) {
      # es sind Vorhersagen zu geplanten Verbraucherschaltzeiten vorhanden
      foreach my $c (@{$forecast->{'ForecastTimeframes'}{'PlannedTimeFrames'}}) {
          my $deviceOid      = $c->{'DeviceOid'};   
         
    my $timeFrameStart = UTC2LocalString($hash,$c->{'TimeFrameStart'}{'DateTime'});  # wandele UTC Time zu lokaler Zeit       
             my $timeFrameEnd   = UTC2LocalString($hash,$c->{'TimeFrameEnd'}{'DateTime'});    # wandele UTC Time zu lokaler Zeit
  my $tz             = $c->{'TimeFrameStart'}{'Kind'};
          foreach my $k (keys(%consumers)) {
               $val = $consumers{$k};
               if($val eq $deviceOid) {
                   $k      =~ /^(\d+)_.*$/;
                   my $lfn = $1;
                   # $consumer = $consumers{"${lfn}_ConsumerName"};
                   $consumers{"${lfn}_PlannedOpTimeStart"} = $timeFrameStart;
                   $consumers{"${lfn}_PlannedOpTimeEnd"}   = $timeFrameEnd;
               }
          }         
      }
  }


Ich habe es mal mit einem Logging versucht und egal ob ich die Funktion nutze oder nicht, der Wert bleibt gleich. Nur die Formatierung ändert sich. Ich nehme an, das reading sollte in localTime angezeigt werden, oder?

2019.05.08 09:48:43 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T12:25:00
2019.05.08 09:48:43 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 12:25:00

2019.05.08 09:48:43 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T11:55:00
2019.05.08 09:48:43 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 11:55:00

2019.05.08 09:53:49 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T12:25:00
2019.05.08 09:53:49 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 12:25:00

2019.05.08 09:53:49 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T11:55:00
2019.05.08 09:53:49 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 11:55:00

2019.05.08 09:58:43 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T12:25:00
2019.05.08 09:58:43 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 12:25:00

2019.05.08 09:58:43 1: sunnyPortal - MS debug - : timeFrameStart2019-05-08T11:55:00
2019.05.08 09:58:43 1: sunnyPortal - MS debug - : timeFrameStart UTC2Local2019-05-08 11:55:00
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 -

Xguide

Wenn ich in der Funktion folgendes auskommentiere, dann bekomme ich das richtige Ergebnis. Aus meiner Sicht macht bei UTC to local ein -3600/-7200 auch kein Sinn, es wäre doch eher ein +3600/+7200.
Das Original-Codesnip sieht sieht auch ein wenig aus...

Kann das bitte jemand bewerten!?


sub UTC2LocalString($$) {
  my ($hash,$t) = @_;
  $t            =~ s/T/ /;
  my ($datehour, $rest) = split(/:/,$t,2);
  my ($year, $month, $day, $hour) = $datehour =~ /(\d+)-(\d\d)-(\d\d)\s+(\d\d)/;
 
  #  proto: $time = timegm($sec,$min,$hour,$mday,$mon,$year);
  my $utcepoch = timegm(0,0,$hour,$day,$month-1,$year);
 
  #  proto: ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
  #my (undef,undef,undef,undef,undef,undef,undef,undef,$isdst) = localtime(time);
 
  #if($isdst) {
  #    $utcepoch = $utcepoch - 7200;
  #} else {
  #    $utcepoch = $utcepoch - 3600;
  #}
 
  #  proto: ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
  my ($lyear,$lmonth,$lday,$lhour) = (localtime($utcepoch))[5,4,3,2];
 
  $lyear += 1900;                  # year is 1900 based
  $lmonth++;                       # month number is zero based
 
  if(AttrVal("global","language","EN") eq "DE") {
  return (sprintf("%02d.%02d.%04d %02d:%s", $lday,$lmonth,$lyear,$lhour,$rest));
  } else {
  return (sprintf("%04d-%02d-%02d %02d:%s", $lyear,$lmonth,$lday,$lhour,$rest));
  }
}


Grüße Marcel

Mit dieser Anpassung sind die Consumer Readings in local time gefüllt und entsprechen den SMA Portal Werten
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 -

Xguide

#431
Hallo Wzut,

anbei ein Update!

Das mit UTC2Local ist mir nicht ganz klar, die Änderungen haben sich aber auf das Verhalten der Darstellung ausgewirkt, somit habe ich das raus genommen.
Deswegen habe ich eine UTC2LocalMS angelegt, die nur für die ConsumerZeiten benutzt wird. So sieht es deutlich besser aus.

Zitatd. SMAPortal gibt das aber als Studendetail nicht her ( nur 1x auf den Tag und next day ) , aber wir haben in FHEM ja diverse Wettermodule  wo man sich bedienen kann.
Das stimmt jetzt nicht mehr....
Ferner habe ich bim Logging herausgefunden, dass es vom Portal einen stündlichen Wert "WeatherId" gibt, den habe ich jetzt mit ausgegeben. Abhängig von der WeatherId kann nun ein Wetter-Icon gesetzt werden. Habe mich noch nicht an die Interpretation der IDs gemacht, könnte aber der Weather-Standard sein.

Generell:

Die readings:
L4_NextHourXX : zeigen PvMeanPower - Consumption
L4_NextHourXX_Consumption : geplanter Verbrauch
L4_NextHourXX_IsConsumptionRecommended : yes/no
L4_NextHourXX_PvMeanPower  : Vorhersage PV Leistung
L4_NextHourXX_Time : entsprechender Stundenwert
L4_NextHourXX_WeatherId : Index für den Wetterzustand

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 -

Wzut

OK, ich nehme das jetzt mal für mich als Arbeitsbasis. Diese ganzen Readings Anpassungen und Bugfixes solltest du am besten direkt mit Heiko abklären,
ich möchte eigentlich an so wenig wie möglich Stellen in seinem Code rumschreiben.
BTW: Schau dir mal deinen verwendeten Editor an, der zerstört die bestehenden Umlaute in den Kommentaren.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Xguide

#433
Zitat von: Wzut am 08 Mai 2019, 12:49:15
1: OK, ich nehme das jetzt mal für mich als Arbeitsbasis.
2:Diese ganzen Readings Anpassungen und Bugfixes solltest du am besten direkt mit Heiko abklären, ich möchte eigentlich an so wenig wie möglich Stellen in seinem Code rumschreiben.
3: BTW: Schau dir mal deinen verwendeten Editor an, der zerstört die bestehenden Umlaute in den Kommentaren.

1: Ich habe schon mal ein bisschen nach den WeatherID COdes gesucht, aber so richtig fündig bin ich nicht geworden. Also mal manuell angefangen, vielleicht hilft das ja beim Finden nach der von SMA verwendeten Nummerierung.

#   103 - starke Wolken (3 von 3)
#   130 - Regen abnehmend?
#    30 - leichter Regen
#     1 - Sonne mit Wolken
#   101 - Mond mit Wolken
#    60 - Sonne, Wolke mit leichtem Regen
#     2 - mittlere Wolken (2 von 3)


2: Kann ich verstehen, aber das mit der Tagesvorhersage war ein Fehler. Er wird es sicherlich fixen. Das mit der WeatherId ist die Erweiterung die wir für die Icons benötigen. Um nichts an Heikos UTC2Local zu ändern, habe ich diese eben dubliziert. Das muss auf jeden Fall mit Heiko abgesprochen werden. Irgendwas wird er sich dabei gedacht haben, komme nur nicht dahinter.

3:  Kann ich nicht bestätigen, die sind bei mir da. Ich hatte 76_SMAPortal mit Notepad++ unter einem anderen Namen gespeichert. Kann das original auch noch mal anhängen. Ich hatte schon die Vermutung das Dein Editor die Tabs, bzw. Einrückungen zerschossen hat :)

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 -

Wzut

Zitat von: Xguide am 08 Mai 2019, 13:56:10
Ich habe schon mal ein bisschen nach den WeatherID COdes gesucht,
Lass uns beide mal jeweils die SMA Weather ID mit der Vorhersage des 59_Weather.pm unter OpenWeatherMap (oder gleich direkt) vergleichen,
denn de Icons sind ja schon da unter images/default/weather
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher