76_SMAPortal - Integration SMA Sunny Portal - Ideen & Modulweiterentwicklung

[Freee84neu]

Gibt es denn eine andere Möglichkeit die Daten Vom Home Manger 2.0 direkt auszulesen. Finde da irgendwie nix bzw. Werde draus nicht wirklich schlau 🙈

[Wzut]

der Hm 2.0 wird nicht "ausgelesen" , da der ständig Multicasts verschickt muß man nur die Hand aufhalten und nachsehen was reinfällt -> 77_SMAEM.pm

[hochholzer]

Hallo Heiko,

zu meinem gestern geschriebenen Problem, das in FTUI mit dem Widget smaportalspg die Grafik nicht angezeigt wird:

Ja, ich habe den BrowserCache gelöscht. Auch mit 2 anderen Browsern und auf dem Tablet wird statt das FTUI-Widgets nur der Schriftzug  smaportalspg angezeigt.

Mein HTML innerhalb einer FTUI-Seite:
     <header><div data-type="label" class="large"><font color="#B28F00" size="+1">Vorhersage</font></div></header>
   <div class="cell">
            <div data-type="smaportalspg" data-device="Solar" data-get="state"></div>
        </div>

Mit dem bisherigen Model SMAPortal hats funktioniert. Mit dem FHEM-Befehlt 'get Solar ftui' wird die Grafik innerhalb von FHEM anzeigt.

Was könnte noch falsch laufen bei mir?

Viele Grüße
Hermann

[DS_Starter]

Hallo Hermann,

ich sehe da keinen prinzipiellen Unterschied zwischen deiner Definition und meinem Test.
Hier nochmal zum Vergleich:

Code Auswählen Erweitern


<li data-row="1" data-col="1" data-sizey="3" data-sizex="5">
  <header>Solar Vorhersage</header>
  <div class="cell">
  <div data-type="smaportalspg" data-device="Solar" data-get="state"></div>
  </div>
</li>


Läuft einwandfrei. Mir fällt da momentan auch nichts ein. Sieht alles richtig bei dir aus.
Lösch es doch einfach nochmal aus deiner index.html und schreibe meine Zeilen hinein. Möglicherweise sind irgendwelche Steuerzeichen in deiner Datei.

Grüße,
Heiko

[hochholzer]

Hallo Heiko,

ich hatte heute mal etwas Zeit und hab' mein Problem mit "smaportalspg" jetzt selbst gelöst:

In der JavaScript-Console stand eine Fehlermeldung, das die Funktion ftui.setfhemcommand nicht bekannt ist.

Ich hatte bisher leider die Version 2.62 von FTUI. Habe jetzt upgedatet auf die Version 2.7.15.

Jetzt funktioniert alles.

Nochmal vielen Dank Heiko.

Servus
Hermann

[Wzut]

So ich habe nun endlich mal angefangen zu testen und bin gleich verwundert das ich Ertragserwartung für heute Nacht habe .....
Das DWD Modul liefert die Rad1h Werte mit diesen Zeitstempeln :

Code Auswählen Erweitern

2020-12-25 18:44:46   fc2_3_Rad1h     40.00
2020-12-25 18:44:46   fc2_3_time      10:00
2020-12-25 18:44:46   fc2_4_Rad1h     240.00
2020-12-25 18:44:46   fc2_4_time      13:00
2020-12-25 18:44:46   fc2_5_Rad1h     50.00
2020-12-25 18:44:46   fc2_5_time      16:00
2020-12-25 18:44:46   fc2_6_Rad1h     0.00
2020-12-25 18:44:46   fc2_6_time      19:00

Edit : peinlich .... man sollte auch bei DWD forecastResolution 1 und nicht 3 nehmen, dann schaut das auch wesentlich besser aus  

[Wzut]

Update : hätte ich gestern Abend die richtige Flächengröße eingetragen hätte ich heute eine Punktlandung von Prognose zu Ertrag

@Heiko, die ganzen Parameter via set einzutragen und sie dann in Readings zu packen finde ich etwas FHEM unüblich.
Warum nicht eine Latte von Attributen ? Das sind doch alles Werte an denen man eh nicht täglich schraubt und so überleben sie alles da sie dann in der fhem.cfg stehen statt nur in fhem.save. Bei den Parametern die andere Devices betreffen (DWD, Inverter, usw) kann ich es noch im Ansatz verstehen, da du so dem Reihenfolge Problem innerhalb der fhem.cfg entgehst, aber auch das lässt sich gut lösen wenn man $init_done vor dem ersten Lauf berücksichtigt.

[DS_Starter]

Nabend,

@Heiko, die ganzen Parameter via set einzutragen und sie dann in Readings zu packen finde ich etwas FHEM unüblich.

Ja ich weiß.
Das ich diese Dinge per Setter eingetragen habe ist einfach der Tatsache geschuldet, dass wir jede Menge Attribute verwendet haben um die Darstellung der Überblicksgrafik zu gestalten.
Ich wollte hier einfach eine logische Trennung herbeiführen. Also alles was Attribute sind, betrifft die grafische Darstellung, Inhalte werden durch die Setter definiert.

Müssen wir mal schauen ob das so bleibt. Sehe da momentan keinen Nachteil, im Gegenteil. Wenn ich die Grafik ändern will greife ich zu den Attributen, alles andere über die Setter. Aber das soll natürlich kein Dogma sein. 

[Wzut]

ok, anderes Thema :

pvCorrectionFactor_Auto <on | off>
Schaltet die automatische Vorhersagekorrektur ein / aus.
Ist die Automatik eingeschaltet, wird nach einer Mindestlaufzeit von FHEM bzw. des Moduls von 24 Stunden für jede Stunde ein Korrekturfaktor der Solarvorhersage berechnet und auf die Erwartung des kommenden Tages angewendet. Dazu wird die tatsächliche Energierzeugung mit dem vorhergesagten Wert des aktuellen Tages und Stunde vergleichen und daraus eine Korrektur abgeleitet.

Kommt der User irgend wie an diese Daten ?
Ich finde es super das du in der Richtung schon Berechnungen machst, aber ich habe die ganze Zeit im Hinterkopf "irgendwie müsste man Vorhersage und Ertrag gegeneinander auswerten" Wie und und welcher Form ist mir noch unklar, (Tabelle, Grafik) aber es wäre schon toll eine Übersicht zu bekommen (Woche , Monat Jahr) wo man sieht wie "gut" die Vorhersage wirklich war.  Kann man natürlich dann auch negativ sehen, frei nach dem Motto "die Werte stimmen hinten und vorne nicht, also brauch ich auch das Modul nicht"

[DS_Starter]

Kommt der User irgend wie an diese Daten ?

Ja, die Vergleichsdaten werden/sind in den Readings:

Code Auswählen Erweitern


Today_Hour09_PVforecast
Today_Hour09_PVreal
....


enthalten. Zur Zeit wird die Vorhersage und Realität des heutigen Tages für jede Stunde des Tages verglichen, daraus ein Quotient gebildet und dieser auf die Vorhersage morgen angewendet. Aber damit bin ich noch nicht so zufrieden. Dieses Verfahren führt u.U. zu großen Ausschlägen in die eine oder andere Richtung. Bin jetzt gerade dabei etwas zu verändern und schauen wie es wirkt.

[Wzut]

ToDo : Icon 63 & 163 suchen / neu erstellen ( ich schau später mal )

Code Auswählen Erweitern

fc0_23_ww 63
fc0_23_wwd durchgehend mäßiger Regen

[DS_Starter]

Moin mein lieber Wzut,

wenn du dann schonmal dabei bist ... das Icon 'weather_night_cloudy_heavy' färbt sich nur zum Teil ein. Der Mond in dem Icon bleibt immer Standard. Vllt. kannst du das mit korrigieren.

LG,
Heiko

[DS_Starter]

Probehalber habe ich mir gestern einen Account bei solcast.com angelegt. Für die private Nutzung kann man 20 x am Tag kostenfrei eine Forecast über eine schöne API abrufen.

Es werden auch Perzentile ausgegeben, z.B.:

Code Auswählen Erweitern


pv_estimate 0.4194
pv_estimate10 0.1561
pv_estimate90 2.4519
period_end "2020-12-27T11:00:00.0000000Z"
period "PT30M"


Ich vergleiche das mal mit den Werten aus DWD die wir berechnen bzw. real erzeugen. Wenn es sich anbietet, integriere ich SolCast als eine alternative Quelle für Vorhersagen. Mal schauen.

[Wzut]

Ich habe jetzt nach den Icons geschaut , IMHO lohnt es nicht für die fehlende 63 ein eigens Icon zu machen.
Hier könnte man auch die 61 nutzen (ist in meinem Forcast eh direkt davor und dahinter)
Aber ich bin mit den Texten von DWD und unserer Zuordnung nicht ganz zufrieden

Code Auswählen Erweitern

'60' => 'weather_rain_light', # Sonne, Wolke mit Regen (1 Tropfen)                   
'61' => 'weather_rain',       # Sonne, Wolke mit Regen (2 Tropfen)                   
'62' => 'weather_rain_heavy', # Sonne, Wolke mit Regen (3 Tropfen)

DWD nennt 61 "durchgehend leichter Regen" das wäre jetzt aber Icon 60

Das Thema Mond lässt sich nicht färben kann man leicht mit einem Texeditor fixen, es fehlt das berühmte fill="#000000" für das Element wodurch FHEM die Füllfarbe nicht ersetzen kann. Ist dir der Fehler nur bei dem einen Icon aufgefallen ? Ich habe jetzt mal alle weather_night durchsehen und bin mir unsicher ob das nicht doch auch noch andere betrifft die ich damals aus zwei zusammenkopiert habe.

[DS_Starter]

Ok, dann nehme ich 'weather_rain' auch für die 63.

Ja, die fehlende Einfärbung ist mir bisher nur bei dem einen Icon aufgefallen.