Zum Beispiel ist es so, dass es Smart Meter gibt die Akku Einspeiseleistungen rausrechnen. Hier ist zum Beispiel das prominente Beispiel Anker, nutzt man das Smart Mieter von Anker ist im aufsummierten Netzbezug, die Netzladung des Akkus nicht enthalten. Es gibt auch noch andere Hersteller, die es exakt genauso machen. Damit ist zwangsläufig die reine Abfrage des Smart Meters falsch um den Gesamtbezug aus dem Netz zu bestimmen. Genau für diese Fälle ist das zusätzliche Feld.
Ein anderes Beispiel sind Nebengelasse, die nicht am HK hängen..
Mich hat das auch verwirrt. Für mich gibt es nur einen Smart Meter und das ist jener vom Netzbetreiber.
Alles andere definiere ich als Unterzähler oder Zwischenzähler.
Aber jeder Jeck ist anders. Und Anker noch anders
Das ist dann aber nur Deine eigene und persönliche Definition…
Ich habe für unsere PV z.B. ein Fronius Smart Meter:
Vom Netzbetreiber habe ich aktuell nur eine moderne Messeinrichtung mMe.
https://www.sh-netz.com/de/energie-service/zaehler/mme.html
Demnächst rüstet der Netzbetreiber aber unser mMe eventuell auf ein intelligentes Messsystem (iMSys) mit Smart Meter Gateway um…
Den habe ich selber ebenfalls verbaut. Nur zur Abrechnung der tatsächlich anfallenden Kosten wird er halt nicht herangezogen.
Ob der Smart Meter vom Netzbetreiber genauer ist, steht auf einem anderen Blatt. Aber letztendlich zählt was am Ende abgerechnet wird.
Aber ich verstehe natürlich was du an dieser Stelle meinst.
Die Beschreibung der Sensoren sind halt der unterschiedlichen Arten von PV Anlagen geschuldet. Und ich bin mir sehr sicher, wenn Tom nicht Anker geschädigt wäre, würde es in dieser Form auch gar nicht so beschrieben sein.
1 „Gefällt mir“
Moin, herzlichen Dank für deine Erläuterung. Dass es so etwas gibt, hatte ich nicht auf dem Schirm. In ein Messgerät schon Applikations-”Intelligenz” derartig einzubauen, so dass man sich den eigentlichen Messwert durch Rückrechnung wieder ermitteln muss, wenn man ihn benötigt, ist aus meiner Sicht - sorry wg. des Ausdrucks - völlig beknackt. Das ist wohl dem neuen Zeitgeist geschuldet …
Ich habe hier 2 SMA-Wechselrichter. Einen 12,5 Jahre alten STP9000 und eine STP10.0SE. Letzterer hat das Problem, dass er als Hybridwechselrichter eine recht hohen Eigenverbrauch an Leistung hat (~40 W). Da ist es auch nicht so einfach, an den tatsächlichen PV-Ertrag heran zu kommen. Der Eigenbedarf wird, zumindest rechnerisch. dem String B entnommen, wenn PV da ist. So dass String B immer etwas später mit der Produktion anfängt, als String A, zumindest wenn man diese Produktion über Speedwire-IF ausliest. Nachts kommt die Leistung aus dem Speicher. Und wenn ich morgens vor PV-Produktion auf das Webinterface des WR schaue, wird dort für die Nacht ein Ertrag ausgewiesen!? Die Entladung aus der Batterie 
. Kann man so machen, ist aber eindeutig SMA-Folklore, und ist auch in der Applikationsschicht programmiert, nicht im Messgerät.
Anyway, ich denke, nun habe ich die Idee hinter den vielfältigen Sensor-Optionen verstanden .
Moin @Tom-HA ,
als Folge meines temporär demolierten Sensors habe ich anscheinend noch ein Problem mit einem Wert in der Statistik.
Der Anteil Solarenergie am gesamten Hausverbrauch erscheint mir etwas hoch . Gibt es einen Service, um diesen zu rekalibrieren, oder müsste/könnte ich den in der Datenbank per SQL ändern? Falls letzteres, wäre ein Hinweis auf Tabelle/Feld schön, damit ich nicht irgendwas ändere.
Danke!
@Tom-HA ,
ich habe die Werte inzwischen gefunden:
sqlite> select solar_to_house_kwh, home_consumption_kwh from stats_daily_energy;
24.0094236666667|11.367
28.3151541666667|21.868
141.339713583333|18.94
141.6695005|17.133
74.4891905|35.732
20.737|27.193
11.5635|19.79
11.4253333333333|15.201
sqlite> select sum(solar_to_house_kwh), sum(home_consumption_kwh) from stats_daily_energy limit 10;
453.54881575|167.224
Sie passen zu den gerade angezeigten Werten:
Die Benennung der Werte in der GUI scheint mir das Problem zu sein, weil sie irreführend ist.
Hallo zusammen, ich bekomme leider keine vernünftigen Vorhersagen hin.
Setup:
-
6.4 kWp, SolarEdge SE5K mit Modbus
-
4 Panel-Gruppen: 3520Wp/180°/13°, 1600Wp/180°/42°, 640Wp/90°/42°, 640Wp/270°/42°
-
Netatmo Wetterstation (Temp, Feuchte, Druck, Regen)
-
Version: 20.2.0, HAOS auf Intel N100
ich habe Claude mal den Log anschauen lassen, er ist der Meinung es gibt einen Fehler im Grid_search:
ERROR: too many values to unpack (expected 3, got 4)
File service_registry.py, line 275
X_sequences, y_targets, _ = await predictor._prepare_training_data()
Hier mal der Log des gestrigen Tages. Hat jemand eine Idee wie ich ihn sinnvoll wieder in die richtige Richtung leiten kann?
Danke im Voraus!
solar_forecast_ml_anonymized.txt (269,5 KB)
Es werden zwar Updates veröffentlicht, aber es ändert sich nichts. Die Vorhersagegenauigkeit sinkt gegen null. Ich habe Protokolle gesendet, aber es kommt einfach keine Antwort mehr. Tatsächlich werde ich wohl auf eine andere Integration umsteigen müssen, da die Genauigkeit dieser hier gegen null tendiert und sich niemand mehr darum kümmern will.
So schlecht ist es doch gar nicht, es muss halt lokal noch viel eingelernt werden um noch genauer zu werden.
1.: Du hast einen Service manuell getriggert, der ausschließlich zu Entwicklungszwecken gedacht ist. Das hat das ggf. Mapping zerstört (Spekulation da mir dazu das komplette LOG fehlt) !
2.: Dann hast Du eine KI gefragt, die 100% quatsch erzählt hat, da sie nicht den Code lesen kann - die Logiken sind verschlüsselt. Die Antwort von Claude ist so wertvloll / aussagekräftig wie ein Toastbrot im Regen. - genau aus diesem Grund gibt es klare Hinweise die Services NICHT zu nutzen!
Ob und was nun genau dadruch zerstört wurde, oder ob Du vieleicht noch andere Service getriggert hast - gegen die Ausdrüchliche Warnung es nicht zu tun, vermag ich so nicht zu sagen.
Eines ist aber klar: Fast alle Service sind im normalen Betrieb destruktiv!!!
3.: Viel wichtiger ist, dass bei 4 konfigurierten Panel-Gruppen im (laut Log ) nur Gruppe 1 Ist-Werte bekommt, offenbar sogar Werte, die eher nach Gesamtproduktion aussehen.Bitte unbedingt die Panel-Gruppen-Ist-Sensoren prüfen: Jede der 4 Gruppen braucht den passenden eigenen Energie-/Leistungspfad oder die Gruppen dürfen nicht als getrennte lernbare Outputs konfiguriert sein.
Lösung:
Die Sensoren / Panelgruppen fixen und 3 Tage warten, ob das Sytem sich erholt. Wenn das nicht der Fall ist, wurde durch die Services / den Service noch mehr zerstört als gerade anhand des kurzen LOG sichtbar ist und dann muss zwingend von vorn angefangen werden, da die KI-Logiken unwiederbringlich zerstört sind. Hierzu reicht es nicht nur die Integration zu löschen, sondern die DB muss gelöscht werden und auch das Konfigurationsfile in der HA Konfig.
Fazit: Das ist kein BUG von SFML sondern ein Bedienungsfehler und ggf das Handeln gegen klare Warnungen
Du hast immer antworten bekommen, hast aber nicht das gebracht was gefragt wurde, sorry
Entschuldigung, gibt es da vielleicht ein Übersetzungsproblem? Was genau übersehe ich? Ich wurde gebeten, die Protokolle per privater Nachricht zu senden, was ich sofort getan habe, aber ich habe noch keine Ergebnisse erhalten. Was genau übersehe ich?
Hallo Tom,
Danke fürs anschauen. meine Intension war übrigens, dich nicht auch noch zu belangen. Du bist ja extrem aktiv.
Meine PV Anlage hat in der Tat nur einen Sensor. Gibt es eine Regel wie man dann verschiedene Winkel, Ausrichtungen etc. eintragen soll? Gewichtete Mittelwerte zum Beispiel?
Ich denke ich werde einmal alles löschen und komplett von vorne lernen lassen, dafür möchte ich die Config aber diesmal richtig anlegen.
Danke für deine Arbeit!
Viele Grüße
@Johnny_1993 @Kaysen899 @alteMade …
Könnt ihr bitte einspringen und helfen.. VIELEN DANK
Schicke mal ein Screenshot von deinen Stringgruppen und die dazugehörigen DC Leistungsentitäten.
Die Leistungsentitäten am besten aus den Entwicklerwerkzeugen Zustände.
Vielleicht ergibt sich daraus schon etwas.
Entweder arbeitest du immer noch mit falschen Sensoren oder die Datenlage in der Datenbank ist so schlecht, dass du neustarten solltest. Davor sollten allerdings die Sensoren funktionieren.
Ein prinzipielles Problem existiert meines Erachtens nicht.
Vielleicht ist allerdings auch deine Erwartungshaltung zur Genauigkeit der Werte zu hoch angesiedelt.
Eine vergleichbare Integration wirst du allerdings keinesfalls finden können. Speziell wenn du ein Interesse daran hast, dass deine Daten und Werte auch deine bleiben.
1 „Gefällt mir“
Hallo @Vladd1980
bitte erstelle einen neuen Thread in dieser Kategorie.
folgende Infos benötigen wir von dir.
Deine Konfiguration von SFML in Home Assistant.
Welche Panel Gruppe du konfiguriert hast.
Was du auf dem Dach zu liegen hast. (kWp,Azimut,Neigung.)
Und an mich gerne deine komplette Log aus SFML. → coinfig/solar_forecast_ml/logs/
Vielen Dank
Hello
Please create a new thread in this category.
We need the following information from you:
Your SFML configuration in Home Assistant.
Which panel group you have configured.
What you have installed on your roof (kWp, azimuth, tilt).
And please send me your complete SFML log. → coinfig/solar_forecast_ml/logs/
Thank you very much
Wenn du nur einen Sensor für die Panel Gruppe hast, bitte auch nur eine angeben, sonst kann SFML damit nicht umgehen.
Bitte das umsetzten was @Tom-HA geschrieben hat.
ggf. wenn du Fragen zu Konfig hast, gerne in einen Extra Thread oder im “Fragen” Thread fragen.
Hier geht es um das aktuelle release ob es da Probleme gibt und nicht mit SFML im generellen.
Hi Schnabel,
An sicht nein, nicht direkt. Wenn man seine Anlage mit mehreren unterschiedlichen Ausrichtungen und Neigungen hat, würde es meiner Meinung nach am meisten Sinn machen, das zu nehmen, was am Meisten vorherrscht. Mit der Zeit lernt ja SFML auch deine Anlage kennen und passt sich dem an.
Wie hast du deine Anlage aufgebaut? Ich mein, xPanles Süd, x Panels West etc.?
Wird dann mit Sicherheit das beste sein, ja.
Und was @Kaysen899 gesagt hat
