Danke für die Antworten. Ich habe keine Alternative was den Installationsort angeht, überall im Garten und Vorgarten wird bewässert. Das stört auch sonst nicht, Automationen für Markisen greifen beispielsweise nicht um 6 Uhr morgens. Ich hatte die Vermutung, dass die KI evtl. nach einiger Zeit erkennt, dass ein Regen jeden Tag zur genau gleichen Uhrzeit für den genau gleichen Zeitraum kein natürliches Phänomen ist und das Egebnis der Prognose dann immer noch besser ist, als wenn ich keinen Regensensor aufnehme.
Dann setz den Sensor doch einfach auf eine 2m Stange, so hoch wirst ja nicht bewässern.
Du bewässerst nicht zufällig automatisch? Dann könntest du doch ganz einfach den Sensor in der Zeit ausblenden.
Das Problem ist:
Eine KI braucht qualifizierte Datenströme. Nur so kann sie lokal lernen, daher ist das Temporäre “abschalten” keine Option.
Die Grundfrage bleibt also: Warum stellt man sich eine Wetterstation an eine Stelle von der man weiß das sie niemals korrekte Daten liefern wird, wenn ein Rasensprenger " Regen simuliert" oder wenn die entscheidenden Sensoren nur Unsinn liefern, der mit der Realität nichts zu tun hat. Das gilt im Übrigen auch für W/m2 und LUX Sensoren.. liegen die regelmäßig im Schatten sind die Werte absolut nutzlos. - nicht nur für SFML!
Mein Tipp daher: Entweder eine länger Stange wo die Wetterstation den ganzen Tag in der Sonne ist und nicht Unsinn misst oder ganz umhängen.
Da hast du vollkommen recht. Der Standort sollte überdacht werden (also von denken, nicht mit Dach drüber 
).
Mit Ausblenden meinte ich auch eher, auf 0 setzen. Oder was auch immer der Wert ist wenn kein Regen fällt. Nur als absolute Notlösung.
Zu diesem Zeck kannst Du Dir ja ein Template Sensor erstellen. Wenn Bewässerung aktiv und Bewässerungszeit dann 0 sonst den Wert des Regen Sensors.
Gruß Osorkon
Ist aber auch das falsche, weil wenn es tatsächlich regnet, dann ists ärgerlich.
Lieber richtige Daten, als gebaute.
Wenn es tatsächlich regnet, wird seine Bewässerung hoffentlich nicht aktiv sein, diese Bedingung fragst Du mit ab.
Gruß Osorkon
Danke, in die Richtung werde ich mal überlegen, das sollte klappen. Sonst nehme ich den Sensor raus. Bislang kommt die KI auch recht gut klar damit, evtl. weil um die Zeit sowieso kein relevanter Solarertrag zu verzeichnen ist. Und nein, ich werde keine hohe Stange in den Garten setzen - aus „was ist das für ein hässliches Gerät, kommt nur in den Garten wenn es zwischen dem Schilf nicht so auffällt“ wird dann nämlich eine Entsorgung der Station.
Hi,
ich weiß dass das eher nen Stats-Thema ist, aber da in dem allgemeinen Thread nicht viel Aktivität herrscht und ich seit knapp ner Woche keine Antwort bekommen habe, ziehe ich meine Frage bzw. mein Problem mal hier rüber.
Ich hab vor ein paar Tagen mal wieder im SFML Stats reingeguckt und mir mal genauer angeschaut warum die angezeigten Werte für € gespart von meinen manuell errechneten abweichen und hab den Fehler gefunden: Ich hatte als Sensor “Energy to Grid Daily” dummerweise “Akkudischarge to Grid” ausgewählt, somit fehlt die Komponente Einspeisevergütung quasi komplett.
Den Sensor hab ich mittlerweile korrigiert, allerdings sind natürlich alle historischen Werte seit meine Anlage Ende Jan ans Netz gegangen ist nicht berücksichtig. Kann ich das irgendwie korrigieren (z.b. den Wert für Energy to Grid YTD überschreiben)?
Edit: Kurze Klarstellung hierzu. Ich habe die korrekten “eingespeist” Werte pro Stunde im HA Sensor. Sie fehlen lediglich in der SFML DB, ich weiß nur nicht wo genau ich die da updaten müsste und bevor ich mir alles zerschieße wollte ich mir das feedback einholen. Ein ganz unverschämtes @Tom-HA für Sichtbarkeit des Edits
Hier liegt ein grundlegendes Missverständnis bezüglich der Funktionsweise meines KI-Stacks vor.
Das System arbeitet mit mehreren, hochgradig miteinander verzahnten KI-Layern – einer davon ist die Solar- und Wettersensorik-Verarbeitung. Wenn du deine Wetterstation so positionierst, dass sie morgens vom Rasensprenger getroffen wird, fütterst du das System mit systematischen Falschmeldungen.
Ein solcher Sensorfehler korrumpiert die Lernmodelle in beide Richtungen:
- Falsch-Positiv-Fehler: Das System prognostiziert trockenes Wetter, registriert aber durch den Rasensprenger „Regen“. Die KI geht von einem eigenen Vorhersagefehler aus und versucht, sich mathematisch selbst zu korrigieren, um den vermeintlichen Drift auszugleichen.
- Falsch-Negativ-Fehler: Umgekehrt wird der reale Zustand verzerrt, wenn das System versucht “Regen prognostiziert” und es kommt aber kein Regensignal
Warnung vor manuellen „Workarounds“ (Templates):
Ich kann nur dringend davor warnen, hier mit Behelfstemplates oder manuellen Filtern zu arbeiten, um deinen Installationsfehler zu kaschieren. Damit gehst du an der physikalischen Realität vorbei und bringst das komplette, hochsensibles System ins Wanken.
- Der KI-Stack verarbeitet Daten holistisch: In meinem System arbeiten mehrere KIs parallel, die diese Wetterdaten für völlig unterschiedliche Zwecke (z. B. Ertragsprognose, Speicherbeladung, thermische Dynamik) nutzen.
- Der Domino-Effekt: Ein systematischer Messfehler an der Quelle pflanzt sich durch alle nachgelagerten Layer fort. Die Fehler summieren sich rasant und führen zu massiven Performance-Einbußen des Gesamtsystems.
Fazit: Wenn es dir nicht möglich ist, die Wetterstation normgerecht und frei von künstlichen Störeinflüssen (wie dem Rasensprenger) zu positionieren, deaktiviere und entferne die Sensoren bitte komplett aus dem System. Keine Daten zu haben ist für KIs um Welten besser, als mit systematisch korrupten Daten trainiert und gesteuert zu werden.
Ich kann aus eigener Erfahrung nur bestätigen, dass das Verwenden schlechter Sensoren zu schlechten Ergebnissen führt.
Mehrere Monate Anfang des Jahres habe ich eine Wetterstation genutzt, die nur 400 m Luftlinie von uns entfernt liegt, hat zunächst funktioniert. Im Frühling habe ich festgestellt, dass diese Station bis 11.30 uhr im Schatten liegt und dann abrupt Sonnenstrahlung bekommt. Ist im Winter kaum aufgefallen, aber mit zunehmender Sonne wurde es sehr deutlich.
Eigene Wetterstation gekauft und die Prognosen wurden langsam deutlich besser.
Danke für die Erklärung, ist umgesetzt
Moin zusammen,
ich habe SFML nun schon ein paar Wochen laufen und nachdem es stetig bergauf ging mit der Prognosequalität (> 75%) erfahre ich jetzt über die letzten Tage ziemlich schlechte Prognosen (Abweichungen >100 Prozent teilweise) und einen Drop der Gesamtgenauigkeit auf unter 68 Prozent.
An meinem Setup hat sich auch was geändert. Seit zwei Wochen betreibe ich einen AC Speicher, welcher aber NICHT zwischen Modulen und WR hängt (oder einen eigenen WR hat) sondern einfach an der Steckdose hängt. Das Setup ist so konzipiert, dass es eine Nulleinspeisung fährt (Shelly Pro 3em vorhanden). Dabei wird aber der WR der Module kein bisschen angesteuert. Der liefert immer genau das ins Netz, was auch über Solar ankommt. Das regeln übernimmt dann der AC Speicher mit Lade-/Entladesteuerung.
Nun ist es so, dass SFML bei den schlechten Prognosetagen regelmäßig Daten rausschmeißt mit dem Grund “Nullexport/Basislast”. Während ich ja einen Nullexport am Zähler anstrebe, steuere ich das aber eben explizit nicht am WR (also dem Eingangssensor für SFML).
Meine Befürchtung ist nun, dass SFML die Daten nicht zum Training nutzt aus der falschen Annahme heraus, dass der WR in den Stunden, die nicht zur Prognose passen würde der WR auf Nulleinspeisung geregelt worden sein. Somit tritt kein Lerneffekt und dadurch auch keine Verbesserung des Gesamtsystems ein.
Im Setup von SFML ist Nullexport eines Akkus explizit nicht ausgewählt. Den Hausverbrauch - Sensor habe ich wieder rausgeschmissen, weil ich den Verdacht habe, dass über diesen ein Nullexport ermittelt wird.
Deswegen meine Frage: Kann SFML mein Setup so berücksichtigen oder liegt die rapide Abnahme meiner Vorhersagequalität an etwas anderem?
Ich rate dringend davon ab, in der SFML-DB irgendwelche Werte einzutragen - so habe ich deinen Post verstanden. - Bitte korrigieren, sollte es ein Missverständnis sein!
Grundsätzlich gibt es zwei sicherer Möglichkeiten, wenn falsche Sensoren eingetragen wurden:
a) Laufen lassen bist es sich selbst heilt
b) DB löschen und neu anfangen
Alles andere ist ein Spiel mit dem Feuer
Es geht um die Berechnung der Einspeisevergütung. Ich hatte von Feb - 10 Juli quasi Null-Einspeisung. Damit sind die Werte für € gespart, Armotisations und eingespeiste kWh falsch. Das würde ich mit den richtigen Werten korrigieren wollen.
Ich hab leider keine Ahnung von Frau Holle und den anderen Kameraden hier.
Ich kriege aber bei jedem Neustart diese Benachrichtigung.
Das wirkt bisher wie eine “Konstante”, weil es eine ist oder aber alles läuft.
Ich hab das ja erst 3 Tage am Laufen und auch nur bedingt weil sozusagen 1 Wechselichter mit 4,6 kW aktuell ausgefallen ist und nächster Woche erst wieder dazu geschaltet werden kann.
Ich will da jetzt auch nicht pfuschen oder verpfuschen, sondenr das könnte ggf. auch die Ursache der Driftwarnungen sein bzw. “kritisch” Hinweis. An sich hab ich verstanden, dass es gut sei, weil System laufen würde.
Jetzt war aber meine Frage zur Benachrichtigung, ob diese Grafiken sich und Text dahinter auch ändern können oder immer gleich sind.
Der letzte Punkt schien aber irgendwie eine Art Status Report zu sein.
All system operational sieht aus wie ein Prüfungsergebnis.
Und da war dann meine Frage, welche Sensoren man mal anschauen kann zum Stand der Dinge bzw. Status, also kWh oder kW etc. denn die kann ich mir selber herleite.
Und wozu ist der Stromverbrauch Sensor gut, der ja der Strom Energieverbrauch sein dürfte und nicht nur ein Bezug.
Bisher ermittel ich den immer indirekt über Bezug + Erzeugung - Einspeisung (und dann noch der Akkusaldo). Soll ich den mit aufnehmen ?
Danke - spannendes Thema, auch wenn ich von Miss Ridge und all den Dingen keine Ahnung habe und nur Bahnhof versehe, aber doch ab und an was dazu lerne.
Hier findest Du weiterführende Informationen …
