76_SMAPortal - Integration SMA Sunny Portal - Ideen & Modulweiterentwicklung

[Wzut]

dann wären im ersten Schritt zwei Code Zeilen zu ändern und die sub weather_icon komplett zu ersetzen
( alles im Anhang )
Im nächsten Schritt kann dann wieder alles um wwd und $we_txt komplett entfallen.
Die Texte werden jetzt hart in die HTML Ausgabe kopiert , ich schau mal ( oder ein User erbarmt sich ? ) und übersetzt die ganzen deutschen Texte in Englisch, dann könnte man das schön innerhalb der global DE, EN Abfrage abhandeln. Dann wird we_txt natürlich wieder gebraucht, also vllt. doch ersteinmal drin lassen. 

[DS_Starter]

Hallo mein fleißiger Wzut 

habe die Änderungen übernommen mit folgenden Anpassungen:

1. alles auf utf8 umgestellt, sodass die Umlaute genutzt werden können und es sich einfach besser liest (das Modul nutzt utf8)
2. der ID-Hash wird jetzt nur einmalig am Anfang des Moduls erstellt und nicht jedes mal bei Aufruf der Funktion. In der Fn wird nur noch die Elemente gesucht und zurück gegeben.

Liegt im contrib.

LG,
Heiko

[Wzut]

ich arbeite im Editor mit utf-8, bin aber genau wie bei meinen MAX Modulen bei der Ausgabe teilweise gescheitert.
Bzw bei MAX hatte ich den Effekt das bei einem User stimmte und bei anderen nicht und habe das dann irgendwann entnervt zu Seite gelegt.
Wenn das bei deiner Lösung nun immer passt , perfekt.

[DS_Starter]

Jetzt habe ich die automatische Vorhersageanpassung eine Weile im Betrieb beobachtet.
Die Tendenz sieht bei mir schon recht gut aus. Welche Erfahrungen habt ihr bisher gemacht ?

Ich habe auch schon eine Idee dieses Verfahren noch weiter zu verbessern ... aber alles Schritt für Schritt ...

[Wzut]

gefühlt sieht es auch bei mir ganz gut aus .... aaaaber :
a. sind jetzt in der dunklen Jahrezeit die Prognosen und der Ertrag unterirdisch niedrig , ich bin auf März/April gespannt.
b. muß ich mir immer merken wie hoch war denn der Forcast und was habe ich wirklich gemacht,
den Punkt hatten wir ja schon besprochen das da eine History Tabelle im log,csv, etc Format sehr helfen würde.   

[DS_Starter]

Ja, schauen wir mal wie es sich entwickelt. Wie gesagt, Idee zur Verbesserung habe ich noch.
Für einen Vergleich könntest du die Readings doch in eine DB loggen und dann Auswertungen (Grafik o. DbRep) fahren, oder ?

Bei mir werden es mal ausprobieren ...

[Dode]

Wenn ich die Readings Today_HourXX_PVforecast und Today_HourXX_PVreal mit einander vergleiche bin ich derzeit weit auseinander.
Ich habe auch schon eine andere Station genommen, aber die bringt ähnliche Vorhersagewerte.

Ich hoffe die Sonne kommt mal raus.

[ClausL]

Hallo,

nach meinen Beobachtungen waren die Prognosen bisher (auch schon vor Einführung der Korrekturen) mindestens so gut, wie die, die vom Sunny Portal kamen. Gefühlt eher besser. M. E. reicht die Güte voraussichtlich für Prognosebasiertes Laden des Akkus soweit aus, dass im Sommer die Kappung der Einspeisung durch die 70%-Grenze vermieden werden kann.

Für die weitere Entwicklung wäre noch die Erweiterung der Energiebilanz interessant, um hier ähnliche Ergebnisse zu bekommen, wie im Portal. Dabei geht es mehr um die Zahlen, die ich für die Steuer brauche.

Ich bin beeindruckt, wie schnell und dynamisch die bisherige Entwicklung gelaufen ist. Das hätte ich so nicht erwartet.

Viele Grüße, Claus

[assi05]

Guten Morgen,

danke für die Info. Hört sich doch nicht schlecht an. 
Das "Berührungsproblem" wirst du sicherlich auch noch lösen. Evtl. hat schon jemand aus der ESP-Ecke Erfahrung damit und kann raten.

Hallo Heiko,

schau mal das Foto im Anhang: Aktueller Verbrauch, sekundengenau abgegriffen per ESP32-Sniffer am Sensorkabel vom Sunnyhomemanager 1. Damit gibt es endlich eine Möglichkeit, ohne unsere Freunde von SMA auf die eigenen Verbrauchsdaten zuzugreifen und diese in FHEM zu verwenden.

Die Daten stehen per MQTT in FHEM zur Verfügung.

[DS_Starter]

Gratulation  Dann konntest du das "Berührungsproblem" lösen ?

Ich selbst habe ja einen SMA Energy Meter und bin somit versorgt. Aber ich könnte mir vorstellen  dass viele User an deiner Lösung Interresse haben. Vllt. ein Thema für einen Wiki-Beitrag ?

Dein MQTT Device kannst du nun auch in SolarForecast einbinden weil die Device / Reading Kombination  des Meterdevices abstrahiert ist.

LG,Heiko

[assi05]

Guten Morgen Heiko,

ich hab jetzt SolarForecast auch mal so weit aktiviert, stehe aber mit zwei Dingen auf dem Schlauch:

- Erzeugung --> kommt von SMAInverter, diverse Readings verfügbar, z.B. "State" steht in "kW" zur Verfügung
- Verbrauch --> kommt von Tasmota via MQTT2, div. Readings verfügbar, z.B. "Haus___Power_curr" in "W" (nicht Verbrauch, sondern aktueller Kauf. Verbrauch wäre Erzeugung - Verkauf, bzw. Kauf)

Beide Devices (Inverter+Meter) sind definiert, aber wo sage ich dem Forecast-Modul, welches Reading das Richtige ist? (In SolarForecast sind beide Werte aktuell "0". --> Grid Consumption ist der Verbrauch, korrekt? Den müsste ich tatsächlich erst mal berechnen?!

In dem Zusammenhang kapiere ich nicht, wie ich ein beliebiges Reading eines Devices als "State" definieren kann, damit es in der Übersichtsseite angezeigt wird. Meine Überlegung geht dahin, später mal Werte wie FeedIn, etc. per Alexa/Google Home abfragen zu können, da brauche ich vermutlich auch einen beliebigen Wert als "State".

Screenshot anbei, wie es aktuell aussieht.

Code Auswählen Erweitern

Haus___Power_curr            -170.00         2021-01-10 10:07:11

[DS_Starter]

Guten Morgen,

das sagst dem Modul mit den set ... Kommandos.
Wichtig ist zu erkennen was das Modul an den Stellen verlangt.

Beispiel SMAInverter:

man muß die Reading:Unit Kombinationen angeben die die aktuelle Leistung und die Tageserzeugung liefern.
Mein set <> currentInverterDev   sieht an der Stelle so aus:

     STP_5000 pv=total_pac:kW etoday=etoday_fc:kWh

total_pac ist klar -> aktuelle Leistung. Für die Tageserzeugung habe ich mir im Inverdev noch ein Userreading erstellt (etoday_fc) was ich aus etoday ableite. etoday im Original ist leider nicht ganz brauchbar. Das Userreading wird so definiert:

Code Auswählen Erweitern


etoday_fc:modulstate.* { # Extra-Reading für Solarforecast
                         my $hour = (localtime(time))[2];
                         if (ReadingsVal($name, "gridrelay_status", "") eq "geschlossen" || $hour > 12) {
                           ReadingsVal($name, "etoday", 0);
                         }
                         else {
                           0;
                         }
                       }


Damit wird der Tageswert sauber geliefert.

Beispiel Meterdevice:

Hier gibt man nur das Reading mit dem aktuellen Bezug mit an. Bei dir dürfte es dann so zu bestimmen sein mit set <> currentMeterDev :

     <dein MQTT Device> gcon=Haus___Power_curr:W

[kaminkehrer]

Hallo,

bei der Suche im Netz bin ich auf folgendes gestossen:
https://forum.iobroker.net/topic/26068/forecast-solar-mit-dem-systeminfo-adapter/13
Vieleicht geht das ja in die gleiche Richtung?!?!

Grüße
kaminkehrer

[Wzut]

Sieht auch nicht schlecht aus, Schnelltest sah ganz gut aus wobei man sich da nicht erst müham eine Rad1h Station suchen muss die dann 50 km entfernt ist.

https://api.forecast.solar/estimate/lat/lon/dec/az/kwp

lat - latitude of location, -90 (south) ... 90 (north)
lon - longitude of location, -180 (west) ... 180 (east)
dec - plane declination, 0 (horizontal) ... 90 (vertical)
az - plane azimuth, -180 ... 180 (-180 = north, -90 = east, 0 = south, 90 = west, 180 = north)
kwp - installed modules power in kilo watt

[DS_Starter]

Ja die SolCast API will ich ja in das Modul auch noch einbauen. ALs "Hobbyist" hat man 20 Calls per Day frei.
Ansonsten kostet der Dienst.

Ihr könnt euch hier schon bisschen informieren:

https://toolkit.solcast.com.au/register/hobbyist

Ich mache grad nur etwas Pause ... nicht wundern wenn es hier so ruhig ist und keine Weiterentwicklung zu erkennen ist.