Solarweb Nachbau

  • Hallo,


    habe angefangen, mir Funktionen von Solarweb von Fronius teilweise nachzubauen. Bisher habe ich mich auf die Charts beschränkt, außerdem berücksichtige ich keinen Batteriespeicher, weil ich keinen solchen habe. Echtzeitdaten stehen auch noch auf der Liste. Bei Interesse stelle ich es gerne zum Testen zur Verfügung. Wenn es mir danach sinnvoll erscheint, stelle ich es OpenSource auf Github zur Verfügung. Funktioniert für mich ganz gut, woanders habe ich es noch nie getestet, wäre gespannt, wie sich das so macht und worauf ich alles noch vergessen habe :)


    - Liest alle Verfügbaren historischen Daten aus dem Speicher

    - Sichert diese in eigener Datenbank

    - WebUI mit Charts für Tag/Monat/Jahr/Gesamt

    - Keine Einschränkung bezüglich der Datennutzung und Anzeige

    - Optionale Installationsmöglichkeit auf eigenem Webspace, ohne Notwendigkeit, von außen ins eigenen Netz zu müssen (Voraussetzungen php + sqlite Modul)


    Eine Einschränkung gibt es an Tagen mit Zeitzonenwechsel (Sommer/Winter), hier macht Fronius irgendwas ganz merkwürdig.


    Voraussetzungen: Gerät mit SolarApi v1, Java8. Läuft bei mir als self contained jar auf dem RaspberryPi


  • Habe jetzt noch Livedaten dazu eingebaut. Dazu frage ich den Inverter alle 10s um die aktuellen Daten und weiter geht es dann per MQTT, im Browser läuft ein JS MQTT-Client. Für diese Funktion ist dann natürlich ein Broker erforderlich.


  • Wie machst Du die grafische Darstellung?

    26 Aleo S25 240 Wp
    Fronius Symo 6.0-3-m mit Smart Meter 63A-3


    Wir neigen dazu, die kurzfristigen Auswirkungen einer Technologie zu überschätzen und die langfristigen Auswirkungen zu unterschätzen (Amaras Gesetz)

  • Also muss der Pi nur die Daten liefern, Grafik macht der darstellende Browser. Bei mir sind die Ladezeiten nicht mehr so toll, wenn ich auf große Datenmengen zugreifen will, aber das liegt eher an der vielen Spielerei, die möglich wird, wenn man nur genug Daten hat.

    Ich hab mich auch an Solarweb orientiert, benutze aber nicht die historischen Daten sondern schreibe jede Minute die aktuellen Daten in meine Datenbank. Zur Darstellung nutze ich Highcharts, weil mir damals die Möglichkeit gefallen hat, zoombare Charts zu erstellen.

    26 Aleo S25 240 Wp
    Fronius Symo 6.0-3-m mit Smart Meter 63A-3


    Wir neigen dazu, die kurzfristigen Auswirkungen einer Technologie zu überschätzen und die langfristigen Auswirkungen zu unterschätzen (Amaras Gesetz)

  • Also von der Architektur ist das so:


    Auf dem RaspberryPi lauft ein Service, welches alle 5 Minuten über die SolarAPI die historischen Daten aus dem Speicher des Inverters holt. Das ist jenes Intervall, dass dieser von sich aus speichert. Normalerweise ist das genau ein Wert, nämlich der gerade neueste Wert. War das Service aber länger nicht am Laufen, so werden alle fehlenden Werte geholt, begrenzt nur durch den Speicher des Inverters, weiß jetzt nicht genau, wie groß der ist, mehr als ein paar Monate nicht. Die Livedaten selbst in einem geringeren Intervall zu speichern wäre natürlich möglich, mir selbst ist noch kein sinnvoller Anwendungsfall in den Sinn gekommen. Diese Daten dann lückenlos und konsistent zu halten, stelle ich mir auch sehr aufwändig vor.


    Das Service bedient sich nicht nur der REST Schnittstelle des Inverters, es stellt auch selbst eine REST Schnittstelle zur Verfügung, dass die Daten für einen Tag, ein Monat, ein Jahr oder die gesamte, verfügbare Datenmenge zur Verfügung stellt. Die Daten werden dabei vom Service pro Request aufbereitet. Das heißt:


    • Für einen einzelnen Tag ein Query für den Zeitraum
    • Für ein Monat die Summen der einzelnen Tage
    • Für ein Jahr die Summen der einzelnen Monate
    • Für den Gesamtzeitraum, die Summe der einzelnen Jahre

    Von der Performance her ist das mit SQLite überhaupt keine Aufgabe, auch nicht über Jahrzehnte gesammelter Daten


    Die Darstellung im Browser bedient sich nun des REST-Services, der die so aufbereiteten Daten an den Client (JS im Browser) liefert. Die Darstellung mit den animierten Charts ist dabei durchgehend flüssig, obwohl der Firefox auf Android schon ein wenig ruckelt, ist das noch akzeptabel.


    Optional kann man das UI auch noch auf einen php-fähigen Webspace laden. Im PHP-Teil ist dieselbe REST-API wie im Java Service implementiert, zusätzlich noch eine Schnittstelle zum Upload der Daten. Das Java Service synchronisiert auf diesem Weg eine SQLite Datenbank am Webspace, der rest funktioniert genauso, wie wenn man das Java-Service lokal laufen hat, das heißt, HTML und JS sind am Webspace oder daheim am Server 1:1 dasselbe, nur die Engine für die REST-API ist eine andere. So gibt es keine Notwendigkeit, von außen auf den Inverter, den Server daheim oder sonst wie zugreifen zu müssen.


    Für die Livedaten habe ich einen Mosquitto MQTT Broker am RaspberryPi, damit das im Web funktioniert, muss man halt über einen Broker draußen publishen, da ist man aber frei und muss nur entsprechend konfigurieren.


    Wenns dich interessiert, kann ich dir ja mal eine Version schicken. Läuft auch auf dem Windows Desktop, ist ja Java. Und konfiguriert ist es auch relativ schnell.

  • Ich hab ja meine Lösung, die ist weit umfangreicher, weil da noch Wetterdaten, Verbrauchsdaten für Strom, Gas und Wasser und jede Menge Messdaten aus dem Haus reingehen. Die macht mir auch die EÜR und Umsatzsteuererklärung. Viel zu individuell.

    Die spuckt mir bei Bedarf halt auch sowas aus:

    26 Aleo S25 240 Wp
    Fronius Symo 6.0-3-m mit Smart Meter 63A-3


    Wir neigen dazu, die kurzfristigen Auswirkungen einer Technologie zu überschätzen und die langfristigen Auswirkungen zu unterschätzen (Amaras Gesetz)

  • Ja, jeder wie er es am besten für sich nutzen kann. Bei mir verfolge ich eher den generischen Ansatz, für die anderen Dinge habe ich noch eine zweite Entwicklung, wo man solche Sachen einfach reinhängen kann, auch die Daten von der Wetterstation, Messfühlern im ganzen Haus etc.

    Anstatt eines Fronius Endgerätes die Ding, das ich hier vorgestellt habe, könnte ich bei mir auch jede andere Datenquelle reinhängen. Mangels einer solchen gibts halt nur die eine Implementierung :)


    Ich würde mich jedenfalls freuen, wenn das mal jemand bei sich ausprobieren würde.

  • Stellt man den Symo auf UTC, tritt der Fronius-Bug mit dem Wechsel von Sommer- auf Winterzeit nicht auf. Irgendwie klar, weil ja keine (inkorrekte) Zeitumstellung erfolgt. Nur so als Info für alle, die sich der Solar-API bedienen und mit diesem Bug ihre Schwierigkeiten haben.