Sieht auch gut aus, leider auf z. B. Handy dann viel zu hell. Auf dem MAC sieht es sehr fein aus!! 
Komm auf die Größe des Bildschirms an.
Zum Thema (Schnee/Frost) - seit vorgestern Abend (Update Zendure HA Integration) hat es bei mir einige Sensoren zerschossen. Sprich, gestern den ganzen Tag keinen Schnee/Frost nur ein defekter Sensor, aber angezeigt wird: Gestern: 7h vom Lernen ausgeschlossen (Schnee/Frost)
Solar 18.4.0
Ich habe immer noch die Anzeige mit “unusually high production”
Und das Thema der falschen Windgeschwindigkeit beim ML Wetter v 8.3
1 „Gefällt mir“
Kannst Du bitte mal bei Dir prüfen, ob Du den korrekten Temperatur-Sensor eingebunden hast (nicht das Du ausversehen den Dewpoint-Sensor genommen hast) → damit ich einschätzen kann ob es ein Zeitfensterproblem ist ..
Danke
Habe ich. Meiner Meinung nach wären Taupunkt- und Außentemperatur für Frost/Schnee zuständig.
Den Fehler kann ich bestätigen. Auch bei mir immer noch das Problem mit V18.4.0. Ich frage mich woran das liegt 
Da hst Du Recht… der Code berechnet den Taupunkt selbster anhand von Temperatur, Sonneneinstrahlung, und Luftfeuchtigkeit. Heraus leitet er Rauhreif auf den Panelen ab.
Daher ist es zwingend notwendig, dass der Code die Temperatur bekommt und nicht einen Sensor der bereits den Taupunkt ausgibt. - der niederiger ist als die Außentemperatur
könnte man nicht auch einen optionalen sensor für den taupunkt einbauen, viele wetterstationen geben ja auch einen taupunktsensor aus, so wie ecowitt.
oder wäre das ehr konterproduktiv?
Ist der am Ende nicht auch berechnet?
1 „Gefällt mir“
Das war tatsächlich eine Überlegung, aber das führt zu Problemen bei Usern die keine Wetterstation haben. → Hintergrund: Der Taupunkt ist maßgeblich für die Frosterkennung und “Wetterdaten” allein sind viel zu ungenau.
2 „Gefällt mir“
wenn jemand keinen hat, dann kann es sfml ja weiterhin selber berechnen
In der Theorie = Ja
In der Praxis = massive Änderungen am Code, die zu unerwarteten Nebeneffekten und Neutraining führen würden
Nutzen = Marginal
Daher, im Prinzip hast du Recht (theoretisch) aber der Nutzen ist für den Aufwand zu gering als das es sich lohnen würde. - Es gibt bereits im Code selber eine interne Prüfung ob der Flag korrekt ist und wird bei negativem Bescheid automatisch aufgehoben (EOD).
Es ist also kein Stress für die AI sondern mehr ein Anzeigethema das verwirren könnte. → Einfacher: Meldung entfernen.. aber das möchte ich nicht machen.
Hallo zusammen! Meine Solarstromprognose ist völlig ungenau geworden. Der Genauigkeitssensor zeigt 61 % an und sinkt ständig. Heute zum Beispiel waren 7 kW prognostiziert, tatsächlich habe ich aber 16 kW gemessen. Das passiert regelmäßig. Ja, ich hatte eine Woche lang Probleme mit dem Wechselrichter und habe vergessen, das Lernverfahren zu deaktivieren. Anfangs (im Winter) hatte ich einen Lichtsensor, den ich dann ausgetauscht habe. Dieser funktionierte auch eine Zeit lang nicht, aber ich habe ihn aus dem System entfernt und dann wieder installiert. Könnten diese Faktoren die Prognosegenauigkeit so stark beeinträchtigt haben? Oder muss ich das Modell neu trainieren?
Hallo @Vladd1980
Dazu habe ich in den Releas-Notes etwas geschrieben.. bitte mal kurz Lesen.
If I understand correctly, you mean that I should wait for version 18.6?
I also wanted to know about the solar radiation sensor. It’s not very cheap, is it worth it? Will it really significantly increase the forecast accuracy?
Hi @Vladd1980
Yes, please wait for the core integration update to version 18.6.0. I am currently testing it and have identified another issue.
Update 04/03/2026
My test series have shown that these changes alone will not be enough. Specifically, the late afternoon hours exhibit too much drift.
This drift stems from the weather data; as production windows grow longer in line with the sun’s position, the forecast accuracy decreases proportionally over the extended time horizon.
There are two competing solutions:
- Implementing a rolling forecast: No—this contradicts my philosophy and the target I have set.
- Expanding the weather mechanics with further factors: This is my chosen method to ensure I don’t compromise the core idea.
I have reset the test and expanded the Weather AI by two core features to incorporate greater stability and an extended production horizon.
This will lead to an error message in the LOG after the update:
2026-04-03 18:11:38 - custom_components.solar_forecast_ml.ai.ai_predictor - DEBUG - LSTM ensemble prediction failed: Features: expected 32, got 33
This is normal and will be automatically fixed at EOD (End of Day) by the sequencer, which will trigger a new training session. The EOD process will take longer than usual this one time, depending on your hardware performance. Put simply, the sequencer integrates the new features into the Weather AI and trains it once.
Regarding the Radiation Sensor:
I recommend the EcoFlow Weather Station. It is more than sufficient for private use and offers a good radiation sensor.
Best regards,
Zara
PS: For future Requests i kindly ask you use a translator to post in German - or write me a PM ..
The full changelog:
Installation: Vorgang lief ohne Fehlermeldungen durch.
HACS: Keine Probleme beim Download via HACS.
Schwierigkeiten: Keine spezifischen Probleme.
Diese Warnung wurde nach dem Update angezeigt
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.ai.ai_predictor
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 21:21:55 (3 Vorkommnisse)
Zuletzt protokolliert: 21:21:55
Ridge architecture mismatch: saved input=35/flat_size=840/outputs=3, needed input=36/flat_size=864/outputs=3
LSTM architecture mismatch: saved input=35/hidden=(48,24)/heads=4/outputs=3, needed input=36/hidden=(48,24)/heads=4/outputs=3. Retraining required.
No compatible weights found. Config has 36 features, 3 outputs. Model needs retraining.
Hier auch …
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.ai.ai_predictor
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 21:26:26 (3 Vorkommnisse)
Zuletzt protokolliert: 21:26:26Ridge architecture mismatch: saved input=35/flat_size=840/outputs=3, needed input=36/flat_size=864/outputs=3
LSTM architecture mismatch: saved input=35/hidden=(48,24)/heads=4/outputs=3, needed input=36/hidden=(48,24)/heads=4/outputs=3. Retraining required.
No compatible weights found. Config has 36 features, 3 outputs. Model needs retraining.
Bitte lest die Update Notes..!! Ich habe sogar extra den Code eingefügt! - erklärt was es bedeutet!
und auch in dem Update Notes direkt noch einmal:
Note: After the update, the following may appear once in the LOG:
LSTM ensemble prediction failed: Features: expected 32, got 33
This is normal and will be automatically resolved by the sequencer at the next EOD (End of Day). A new training session will be triggered; the EOD will take longer than usual once, depending on your hardware.
und ein Drittes Mal noch auf Github zu den Release Notes :
2 „Gefällt mir“