Ich habe die neue Version gerade installiert und sehe, dass einige Entitäten nicht mehr verfügbar sind , z.B.”Pattern Count”, “ML Service Status”, “Training Readiness”. Ist das normal? Muss ich die löschen? Wenn nicht, kann mir jemand ein Rezept empfehlen, wie die Integration sauber neu aufgebaut werden kann (inkl. SFML und Grid Price Monitor)?
Verstehe nicht, warum bei den live Daten, z.B. “heute” nach mehrmaligem Klick auf eben “heute” immer leicht unterschiedliche Werte angezeigt werden?
Ist auch bei “gestern” so, da sollten doch die gesammelten Werte fest geschrieben sein ![]()
Können gelöscht werden, das ist korrekt so
Ich habe das ausführlich auf der Website beschrieben.. warum es KEINEN Sinn macht das ich kWh Sensoren berechne. Das ist mathematischer Unsinn und logisch absolut verständlich.
Es ist und wird immer zwingen notwendig sein, dass
1x Gesamtpower
1x Gesamtenergie die sich um Mitternacht zurücksetzt
vorhanden sind. Natürlich kann man X WR und X Strings hinzufügen, die werden auch korrekt behandelt - Allerdings NUR wenn sie der selben Logik folgen 1 Energiesensor pro String / WR der sich um Mitternacht zurücksetzt.
Seit der aktuellen Version von Stats, ist es auch möglich die jeweiligen Gruppen zu benennen um sie besser zu identifizieren.
ABER es macht absolut keinen Sinn X Gruppen zu erstellen, das ist mathematisch Unfug. Besser ist die Gruppen (wenn sie dann notwendig sind) logisch zu bilden.
Grundsatz:
Gleiche Ausrichtung + Gleicher Tilt (+/- 15 Grad) sollten immer zusammengeführt werden. - Auch muss man zwingen die eigene Leistungsfähigkeit des Systems beachten.. Mehr Gruppen = mehr Rechenleistung!!!
(Sonst wird Schattenerkennnung, Schneeerkennung, .. scheitern!!!)
Nein! Das ist eine Live-Berechnung! Sie wird erst beim EOD festgeschrieben.. ist nicht wie bei dem “Stündlichen” Energie-Dashboard bei HA
Wie von @Matt1 korrekt beschrieben: Bitte löschen! Es gibt kein ML (Machine-Learning) und keine Pattern mehr, seit dem auf 3 KI und einer Hybrid-KI als Master Transformer und Grid-Search umgestellt wurde.
Danke!!!
(ist aber auch bei “gestern” genau so, daher die Frage)
Was sagt mir das im Log?
2026-01-02 23:30:09 - custom_components.solar_forecast_ml.ai.ai_tiny_lstm - INFO - Training: 233 samples, 200 epochs, 1 outputs
2026-01-02 23:30:09 - custom_components.solar_forecast_ml.ai.ai_predictor - ERROR - Training failed: shapes (32,52) and (49,1) not aligned: 52 (dim 1) != 49 (dim 0)
2026-01-02 23:30:09 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - WARNING - AI model training incomplete: shapes (32,52) and (49,1) not aligned: 52 (dim 1) != 49 (dim 0)
Meiner leihenmeinung nach, kann sein das noch alte Daten vorhanden waren und das du ohne Reset auf die neue Version gegangen bist? Aber ob der Fehler jetzt schlimm ist kann nur Tom sagen.
Schwierig ! Ich brauche das gesamte LOG! - Bitte schicken..
Es schaut so aus, als ob Du mehrfach die Konfiguration der Panelgruppen geändert hast, oder Sensoren…(Vermutung da ein großer Teil des LOG fehlt) so haben sich insgesamt 11 -12 Panelgruppen / Sensorkonfiguratione in den vorhanden Samples angesammelt.. was natürlich nicht funktionieren kann!
- Panel-Gruppen-Konfiguration prüfen
- Modell neu trainieren (passiert automatisch > auf KEINEN Fall via Service starten!!!)
- Alte Gewichte löschen
- Korrekte Sensor-Konfiguration sicherstellen
Das ist ein klassischer Fall von GiGo.. Garbage in Garbage out... Aber die Integration hat sich selbst geheilt und den Garbage ignoriert / aussortiert und nur 1 Sample akzeptiert.
Das ändert aber nichts daran das Du so eine Ewigkeit brauchen wirst, bis du korrekte Prognosen bekommst. Das hängt damit zusammen das die Gewichtungen alle korrupt sind (Entweder durch mehrfaches ändern der Panelgruppen oder Sensoren) und erst nach und nach korrigiert werden.
Empfehlung:
- Ordner: config/solar_forecast_ml komplett löschen (NICHT config/custom_components/solar_forecast_ml !!!)
- HA Neustarten (roter Knopf) > Neuladen reicht nicht
Effekt:
Es werden frische und korrekte Daten erzeugt > Deutlich schneller als zu warten bis die korrupten Daten nach und nach korrigiert werden. - **
Allgemein:
- Zwingend auf die korrekten Sensoren achten
- keine Unnötigen Panelgruppen
- FINGER weg von den Entwickler-Services!
Hier noch mal die Frage in welchem Werte Bereich sollten der Lux-Sensor und der Sonneneinstrahlungssensor arbeiten um korrekt mit der Solarprognose zusammenzuarbeiten?
Luxsensor, von 0-1000, 0-10000 oder 0-100000?
Sonneneinstrahlungssensor, 0-300, 0-1000?
Moin Südschwede
LUX-Sensoren sind leider nicht standardisiert, daher haben sie auf die Prognose keinen Einfluss. Sie werden benutzt, um durch Wert-Änderungen, zur Wolken-, Dämmerungserkennung beizutragen. Dieses ist wichtig um Schattenerkennung, Bewölkung, Dämmerung für den lokalen Standort zu erkennen. Einfach gesagt sie sagen der KI " Hey die Leistung ist eingebrochen weil…"
Einen aktiven Beitrag zur Berechnung liefern sie nicht.. - das hatte ich bereits seit Version 4.0 komplett entfernt.
Vor diesem Hintergrund ist die Range wirklich zweitranig, es ist nur wichtig das die fein genug ist um Veränderungen zu erkennen. - Üblicherweise ist der Bereich zwischen 0 - 130.0000 besser ist aber 0 - 10.000 um nicht zu sensibel zu sein.
Zara
Hi Zara,
habe nun den Ordner gelöscht und HA neu gestartet. Mal schauen, was passiert …
Zuvor hatte ich die Samples aus V 12.0 behalten. Panelgruppen hatte ich noch nie konfiguriert und auch mit den Services nicht rumgespielt.
Danke für Deine Unterstützung!
Gut, Luxsensor ist nun klar, meiner läuft von 0-12000.
Nun zum Sonneneinstrahlungssensor, wie schaut es da aus?
Sehr gern… kein Problem! Das ist die Beste Lösung .. das empfehle ich auch jedem bei dem Prognose nicht passt. Der Code hat sich mehrfach bewiesen, wenn es Probleme gibt, ist es zu 90% falsche Sensoren oder alte Daten.
Die Logik dahinter ist:
Sensor A = zwei Tage
geändert zu Sensor B = zwei Tage
geändert zu Sensor C = 3 Tage
Geändert zu…
Damit entstehen
Senor A = 48 Prognosen / Daten
Sensor B = 48 Prognosen / Daten
Sensor C) = 72 Prognosen / Daten
usw..
Die KI weiß dann einfach nicht.. Was ist denn nun korrekt? Liegt ein Sensor-Fehler vor, habe ich falsche Prognosen erstellt.. etc.. > Das wird sie dann nach 30 Tagen selber erkennen, aber warum solange warten?
Ich kenne keinen W/m2 Sensor der eine Range hat.. kannst Du mir dein Model mal nennen, dann schaue ich es mir mal an.
Hinweis zum W/m2 - Sensor
Der ist wichtig und ein 100% Gewinn - wer ihn hat! Der Übernimmt (wenn vorhanden) eine immense Menge an Korrektur-Arbeit. - Goldstandard - das hier nun zu erklären würden den Rahmen sprengen!
Ich nutze hier den Ecowitt-Sensor von meinem Nachbarn, hier mal der Verlauf vom heutigen Tag, ist das so ausreichend?
Das ist perfekt!!! Wichtig.. die Sensorflächen müssen verschattungsfrei und sauber sein.. sonst GiGo..
Kennt jemand diese Fehlermeldung Konfigurationswarnungen
Setup of package 'PV_Sensoren' failed: Invalid package definition 'PV_Sensoren': invalid slug PV_Sensoren (try pv_sensoren). Package will not be initialized
Ich bekomme die angezeigt, wenn ich in den Entwicklerwerkzeugen auf “Konfiguration prüfen” drücke, bevor ich neu starte. Kommt seit heute früh hoch. Ich habe die FDML seit 01.01. und neu installiert. Sonst läuft die App super und die ersten Ergebnisse sind relativ genau.





