glaube das system braucht nach einem update erstmal eine weile um sich selbst zu finden, alles durchzugehen und so nach und nach sich selbst zu aktualisieren
Update ohne Probehme.
Danke und Gruss
SQL…
Ich denke das sollte kein großes Problem sein
und ehrlich gesagt aktuell auch nicht so wichtig, dass ist Kosmetik die ich dann später mal angehe..
oder ich vernachlässige es bis der Keilriemen reißt ![]()
Wie immer, just 4 info!!!
Der hatte keine 1500 Kilometer….
Wahrscheinlich falsch montiert!!!
Ish abe gar keine Schnee….
Einer noch….
ich habe noch das hier im log:
![]()
Danke, weil da in deinem neuen Abschnitt in Stats eine Zahl steht, kein Typ…war ich etwas verwundert, was das genau ist.
**UPDATE KOSTENBERECHNUNG in STATS **
Ich werde es nicht mehr schaffen (zeitlich) die Kostenberechnung für alle erdenklichen Systeme fertig zu machen - ist einfach zu viel. - Wird aber nachgereicht. Aktuell geht mit ANKER und Systeme die ähnliche Sensoren haben (man kann sie sich die natürlich auch bauen) folgendes:
Dynamischer Stromtarif incl Netzladung Akku (muss über GPM laufen)
Stundengenaue Preisberechnung mittels meiner Integration Grid Price Monitor. Es wird exakt der Preis genommen, der zum Zeitpunkt des Netzbezuges gültig gewesen ist.
Beim Einspeisen wird der “Gewinn” exakt berechnet an dem zu dem Zeitpunkt gültigen Preis dabei wird unterschieden zwischen:
- Netzbezogenen Strom zum Akkuladen (da ist der Gewinn die Differenz zwischen Einkaufspreis und Preis zum Zeitpunkt des Einspeisens) und
- Eingespeisten Solarstrom (da ist der Gewinn der zu dem Zeitpunkt gültige Preis.
Festpreis (direkt in STATS)
Ist glaube ich selbsterklärend.
![]()
Jaap… ist doch okay! Kein BUG sondern nur ein Hinweis das Du keine Default-Gruppe hast und alles in Ordnung ist!
Da haben wir es wieder… Du machst einfach immer alles kaputt ![]()
Das ist ein einmaliges Vorkommnis (“1 Vorkommnis”) und bedeutet, dass die SQLite-Datenbank in dem Moment kurz nicht erreichbar war - z.B. weil ein anderer Prozess sie gerade gelockt hatte oder das Dateisystem kurz beschäftigt war. Zum Beispiel durch die Migrations-Skripte die im Hintergrund noch laufen und aufräumen..
Solange der Fehler nicht dauerhaft auftritt, kannst du das ignorieren. Falls er regelmäßig kommt, dann schick mir bitte dein LOG
1500km uhhh das ist echt nicht viel!!!
Guten Tag allerseits,
auch auf meiner Proxmox-VM lief der 16.4.0-Update problemlos durch und sieht − bis auf die üblichen kosmetischen Fehler™ − aus der STATS-Perspektive plausibel aus.
Allerdings bin ich ja mittlerweile vier Wochen mit Solar Forecast ML zugange, habe aber immer noch nicht kapiert, wie die einzelnen Integrationen aus diesem Kontext zusammenwirken:
-
STATS: Okay, das ist klar. Das zeigt die Datenbankinhalte, die SFML produziert, grafisch hübsch aufbereitet an.
-
ML Weather: Liefert meinen Wetter-Cards ähnlichen Input, wie auch andere Wetter-Quellen. Wird der Output von ML Weather für SFML benötigt? Sind die beiden irgendwie innerlich miteinander verdrahtet? Keine Ahnung…
-
Weather Fusion AI: Trägt aus öffentlich zugänglichen Quellen und aus Daten meiner lokalen Sensoren Parameter für eine lokale Wetterprognose zusammen und liefert mit − ähnlich wie ML Weather − Input vor meine Wetter-Cards. Aber: Wird der Output von Weather Fusion AI für SFML benötigt? Sind die beiden irgendwie innerlich miteinander verdrahtet? Auch hier habe ich keine Ahnung…
Kann bitte mal einer der Erleuchteten unter Euch mir auf die Sprünge helfen? Ich könnte mir gut vorstellen, dass das auch für das eine oder andere Greenhorn unter uns von Interesse sein könnte.
Beste Grüße, Burkard
Der Fehler „Error reading forecast comparison from DB: unable to open database file“ tritt bei mir dauerhaft auf. Auch nach einem weiteren Neustart. Dadurch ist in den Stats im Prognose Vergleich Solcast verschwunden. Man sieht da nur noch SFML. Ich schick dir mal das Logfile.
Ich werde die Entwicklung weiter beobachten. Da das System ansonsten einwandfrei läuft, ist dies kein kritisches Hindernis. Die fehlende Gegenüberstellung der Prognosedienste ist zwar ein Manko, für den aktuellen Betrieb aber nicht ausschlaggebend.
Reden wir hier aneinander vorbei? In der Standardberechnung (kein dynamischer Strompreis) sollte er doch nicht die Netzladung zur Batterie als autarke Energie nehmen. Das hat nichts mit verschiedenen Systemen etc. zu tun, sondern ist ne allgemeine Formel, die hier noch nicht korrekt ist.
In meinem Beispiel:
18,2 Gesamt , davon 9,1 vom Netz = 50%
ABER: Akkuladung vom Netz= 100% - also nix vom Dach - und da er auch die Werte hat, wäre es natürlich sinnvoll, wenn er das dann nicht als autark sieht, sondern subtrahiert.
Aber wollte es nur “melden” - für mich ist das jetzt nicht so wichtig - ist halt nur so nicht korrekt.
Da nervt mich die fehlende Wattanzeige bei der Batterie schon mehr - da die Visualisierung so nicht stimmt ![]()
korrekt, rechnet nicht selber mit Ausnahme der Energie und Kosten. Das ist aber aktuell nur für Anker Systeme voll implementiert da mein Fokus auf SFML lag bei dem letzten Update
Das ist nicht ganz korrekt, es ist das Wetter / die Bedingungen vor Ort wie die KI sie am Abend zuvor für die Prognoseerstellung berechnet hat. Es ist also keine klassische Wetter-App sondern eher eine Kontrolle
Das Teil ist echt erstaunlich gut und unterschätzt: Es verwandelt deine eigene Wetterstation vor Ort (z.B, Eco-Witt) in eine echte, lokale Vorhersage-Zentrale! Mit SFML oder bloßen Statistiken hat das nichts zu tun (außer das unter Haube die Wetter-KI von SFML werkelt). Das Prinzip ist simpel, aber smart: Eine KI nutzt die Rohdaten von Wetterdiensten (keine fertigen Prognosen) und die Daten deiner eigenen Station, um eine maßgeschneiderte Prognose direkt für deinen Standort zu erstellen. Dabei lernt sie wie genau sie war und korrigiert sich. Eine sehr einfache Form von dem was SFML macht.
Ich wollte schon ewig eine eigene, präzise Vorhersage für meinen Garten haben – und das Ding liefert verdammt gut ab! Es lernt extrem schnell und in 8 von 10 Fällen deckt sich die Prognose exakt mit den später gemessenen Werten. Das haut mich selbst immer wieder um!
Ich hoffe es ist etwas klarer ![]()
Ok, alles klar. Fehler tritt übrigens auch bei jedem Neuladen von Stats reproduzierbar auf.
Nein, wir reden nicht aneinander vorbei. Das funktioniert aktuell NUR mit Anker-Systemen da dort die entsprechenden Sensoren vorhanden sind und miteinander und gegeneinander gerechnet werden. Wie der Hinweis auch schon sagte, man kann das natürlich mit eigenen Sensoren / Templates die so funktionieren wie die originalen Anker Sensoren nachbauen.
Was deine Watt-Anzeige angeht, das muss bei Dir im System liegen. Mehrere User haben Dir nun schon ihre Screen-Shots gezeigt das es grundsätzlich funktioniert. Fazit irgendwas stimmt da bei Dir nicht - der Code funktioniert (zumal die Sensoren eh nur durchgereicht werden und an der Stelle nichts berechnet wird)
Ich probiere mal mein Glück:
Gibt die von SFML gelernten und von den Wetter-Rohdaten abgeleiteten Prognosen für deinen Standort aus. Dies wird für die Prognose genutzt und sollte, wenn ich nicht komplett falsch liege, auch in Stats der Reiter “KI” beim Wetter-Teil die Anzeige sein für den aktuellen Moment.
Ist an sich die aus SFML herausgelöste Vorhersage-Logik, welche hier auch aus den Wetter-Rohdaten eine Prognose baut für deinen Standort. Hier lernt die KI auch die Gegebenheiten an deinem Standort. Weather Fusion AI ist allerdings eine komplett eigenständige App und ist nicht von SFML abhängig.
Danke @Johnny_1993 das ist 100% korrekt!!!
nur ein kleiner Hinweis: Weather Fusion ist für eigen Wetterstationen gedacht wie z.B. Eco-Witt Davis Netamo und Co.. ohne diese geht es zwar auch aber sehr bescheiden da die Stellgröße fehlt
Ich probiere es die ganze Zeit mit Temperatur und Luftfeuchtigkeit Sensor.
Hmm und? Prinzipiell sollte es “einigermaßen” funktionieren .. aber gedacht ist es für etwas anders… daher ist es auch nicht Teil der “Extras” von SFML
Ich denke 0,3 Grad sind ein akzeptabler Differenzwert.. besondern wenn man sich mal anschaut wo OpenWeather Map liegt:
Also die KI von SFML kann schon was.. wenn man sie in Ruhe lässt ![]()




