TFS HA Solar Forecat ML 8 Head Transformer KI (App-Version)

Da mich einige Mails erreicht haben, muss ich hier noch einmal sehr klar sagen:

TFS HA ist eine APP für Home Assisiatnt die SFML erweitert und keine Standalone App! → sie ist leichtgewichtigt und lauffähig auf den benannten HW-Konfigurationen. Sie ist aber extrem abhängig von der HW → Bessere HW schenlleres Fine Tuning (einmal notwendig nach der Installation) .. danach sehr RAM und Prozessorschonend.

Was ist das Fine-Tuning warum braucht es Zeit und Leistung?

TFS HA kommt mit einen Vortrainierten Transformer und sog. Backfill. Sie ließt die Konfiguration von SFML und die Datenbank von SFML und füllt Lücken mit dem HA Recorder. Die Daten werden normalisiert und in das richtige Format gebracht das die KI das lesen kann.
Im Anschluss wird die KI auf eure Anlage, euren Standort angepasst. Dieser ganze Prozess ist das Fine-Tuning und muss nur einmal gemacht werden. Je nach Rechenleistung dauert es nicht nervös werden und laufen lassen.
Überwachbar im Protokoll der App hier eine kurze Erklärung:

1: Die maximal Anzahl der zu Verarbeiteten Epochen - > von mir festgelegt auf 30
2: Die aktuell beste Epoche (die letzte die eine Verbesserung gebracht hat)
3: Die Anzahl der Epochen die keine Verbesserung mehr gebracht haben. Steigt der Wert auf 5, wird das Training beendet man spricht dann vom sog Plateau
4: Dauer der Verabreitung einer Epoche und die zu letzt verarbeitete Epoche und ob sie eine Verbesserung gebracht hat

Also 2 Dinge beenden das Trainig auf die Anlage:

a) 30 Epochen wurden erreicht (unwahrscheinlich)
b) Early Stopping da das Plateau erreicht wurde und keine weitere Verbesserung zu erwarten ist.

Was ist eine Epoche
Stellt es auch wie in Bücherregal vor mit vielen Büchern und in schaut jedes einzelne Buch an ob da was drin steht das euer Wissen erweitert. So ungefähr funktioniert das. Eine Epoche ist also ein riesen Haufen von Datenpunkten (Büchern) von dem jeder einzelne Datenpunkt angeschaut wird ob er was spannendes enthält. → So werden KI`s traininert.
Bsp: Das Pretraining wurde auf 160 Epochen durchgeführt mit jeweils rund 50.000 Datenpunkten.

2 „Gefällt mir“

Jupp, für den Gen 24 10.0 Zum Beispiel:

Zwei Strings hängen an dem.

HA Integration - nix von HACS oder Sunspec.

1 „Gefällt mir“

Hallo Joachim,

Gen 24 bitte nicht nur als Beispiel nennen, sondern eher als Voraussetzung.

Bei den älteren Symo-Geräten ohne Gen liefert die originale Fronius-Integration keine getrennten MPPT-DC-Werte, sondern nur einen Gesamtwert, zum Beispiel für zwei MPPTs. Separierte Werte sind dort nur über die SunSpec-Integration verfügbar. Bei der SunSpec-Integration mit mehreren Wechselrichtern, wie in meinem Fall, muss man diese unter Home Assistant gegebenenfalls per Automationen überwachen und bei Bedarf neu starten, da die SunSpec-Integration bei Fronius mit mehr als einem WR instabil ist (gelegentlich hängen bleibt). Ich habe das in meinem „Symo-Universum“ entsprechend angepasst und seit Monaten stabil für SFML im Einsatz.

Automation als yaml:

 alias: Sunspec Fronius Symo 20 neu laden
 description: “”
 triggers:

 - trigger: state
   entity_id:
   - sensor.mppt_module_0_dc_power
   - sensor.mppt_module_1_dc_power
     to:
   - unavailable
   - unknown
     for: “00:02:00”
 - trigger: sun
   event: sunrise
   offset: “00:30:00”
 - trigger: time_pattern
   minutes: /1
   conditions:
 - condition: or
   conditions:
   - condition: trigger
     id: “0”
   - condition: trigger
     id: “1”
   - condition: and
     conditions:
     - condition: trigger
       id: “2”
     - condition: or
       conditions:
       - condition: state
         entity_id: sensor.mppt_module_0_dc_power
         state: unavailable
       - condition: state
         entity_id: sensor.mppt_module_0_dc_power
         state: unknown
       - condition: state
         entity_id: sensor.mppt_module_1_dc_power
         state: unavailable
       - condition: state
         entity_id: sensor.mppt_module_1_dc_power
         state: unknown
         actions:
 - action: homeassistant.reload_config_entry
   data:
   entry_id: 01KJ0V6HKAK9VB5JDAQYMZSETM
   mode: single

P.S. Nicht schön, aber es läuft…

entry_id natürlich mit der Eigenen ersetzen…

Viele Grüße

P.S. @Schreynex Da das hier OT ist, bei Bedarf gerne ggf. PN an mich, oder nochmal einen gesonderten Post an passender Stelle. Ggf. mit Link hierher zu diesem Post.

Fixed, weil ich die original Integration für >1 WR schon optimiert hatte - die Automation für die Überwachung und ggf. den automatisierten Neustart sollte aber auch bei der original Sunspec-Integration ausreichen.

Generelles Problem bei den Symo Modbus Abfrage ist wahrscheinlich die gemeinsame IP, aber zwei getrennte IDs, was sich dann gegenseitig bei (gleichzeitiger) Abfrage der Daten stört, die Integaration sich dann aufhängt…

Nochmal P.S.

Fronius Smartmeter unter Sunspec Integration - mit ID 240:

:crayon:by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
s.a.: ( Neues Update & Features - Hier in der Community 🫶 )

@harryp Danke für den Hinweis! - das mache ich eigentlich auch immer. Keine Ahnung was diesmal bei (mir) schiefgelaufen ist. Vielen Dank aber für die Korrektur!

1 „Gefällt mir“

Die Installation hat schonmal funktioniert, hab es aber noch nicht gestartet, weil ja sfml und stats noch die Updates brauchen.
in der supervisor Log steht nur eine kleine Warnung:

WARNING (MainThread) [supervisor.addons.build] App 2dcb6753_toorox_foresight_ha uses build.yaml which is deprecated. Move build parameters into the Dockerfile directly.

Das Dinge ist, es hat schon einen Grund, warum ich ein Release-Datum angebe.. warum ich klar und Deutliche sage:

Bitte nur Hw: XY
Bitte NUR installatieren wenn SFML und STATS in der Version xy vorliegen

@seebaer1976 Du MUSST es zwingend wieder deinstallieren und zwar grünldich inclusive cash leeren!

  1. Die Tabellen stimmen nicht in SFML
  2. Die Schnittstellen stimmen nicht
  3. Die DB ist nicht vorbereitet
  4. SFML wird mit hoher Wahrscheindlichkeit (Vermutung) TSF NICHT erkennen

Am Besten spielst Du ein Backup ein bevor Du es installiert hast, das ist der sichererste Weg

Das ist wieder " Wo ein Knopf ist" da wird draufgedrückt egal wie groß die Warnung ist und wenn es crahed waren es wieder die anderen..

Ich bitte darum, Warnungen, Hinweise, Installationsanweisungen, Abhängigkeiten wirklich ernst zu nehmen, ich schreibe diese nicht aus Spaß oder Langeweile!

aber natürlich muss ich Releases eher hochladen um zu testen ob die Installation funktioniert, alles ist wie es soll. Das ist besonders kritisch wenn es etwas Neues ist. Besonders in diesem Fall musste ich gestern noch nachsteuern, da die erste Version das System gecrashed hat..

Pythonwarnung / Info, hat nichts mit HA zu schaffen!!

1 „Gefällt mir“

Hatte es nur installiert aber danach noch nicht gestartet. Um zu schauen ob es einen Fehler gibt.
Danach auch wieder gelöscht.
Hatte ich doch auch geschrieben.

Das Problem ist… Wenn Du eine App (HA) installierst, lädt und installiert es schon die ganzen Bibliotheken (auch wenn Du nicht startets) auch werden die Tabellen erstellt. daher kommt auch deine Fehlermeldung (die eigentlich keine ist sondern nur eine info)
DIe Meldung bedeutet: Docker ist gebaut mit Python 3.14 ab Python 3.16 ändert sich die build-routine. .. da ich nicht glaube das HA sein verhalten ändert und regelmäßig updates von Python macht, sondern immer hinterherhinkt wird mit man diesem Hinweis leben müssen.

Was Du aber getan hast (durch die Installation) ist folgende Pakete installiert:

  1. packaging>=24.0
  2. fastapi>=0.115.0
  3. uvicorn[standard]>=0.32.0
  4. pydantic>=2.9.0
  5. PyYAML>=6.0
  6. httpx>=0.28.0
  7. safetensors>=0.4.0
  8. einops>=0.8.0
  9. sqlalchemy>=2.0.36
  10. aiosqlite>=0.20.0
  11. pvlib>=0.11.0
  12. pandas>=2.2.0
  13. structlog>=24.4.0
  14. prometheus-client>=0.21.0

und Du hast die DB von SFML verändert, die ist nun schon auf der Version V20.0.x ohne das SFML damit etwas anfangen kann (den zusätzlichen Feldern) ich kann Dir nicht 100% sagen, ob das nicht heute Abend beim EOD crashed.. kann gut gehen, muss aber nicht.

Du hast also 2 Oprionen

a) = Dauemen drücken das es gut geht und EOD nicht crashed
b) = Backup einspielen so das Du die alte DB zurück hast → es feheln dir dann aber die Daten von heute und der Tag ist verloren.

Ist also eine reine Risikoabwägung.. ich habe dazu eine Meinung, aber wenn ich die nun sage und es crahed bin ich schuld :slight_smile:

Alles passend zu der aktuellen Python-Version die aktueller ist als das Python in HA..

Allgemeine Info:

Wenn ihr eine App (egal welche) installiert werden immer die bnörigten Bibiotheken installiert und / oder Änderungen durchgeführt → egal ob ihr sie startet oder nicht… das ist ja der Sinn eines Installationsprozesses → alles installieren und vorbereiten das die App starten kann.

Ein wichtiger Unterschied zwischen App und Integration ist, dass Apps Bibliotheken nachziehen können die Home Assistant nativ nicht hat oder unterstüzt.

Darum benutz ich für sowas einem ha-testsystem :innocent:

Ich glaube ich schreib das besser nächste mal mit dabei :face_with_peeking_eye:

1 „Gefällt mir“

Wichtiger Hinweis: App vs. Integration (Sicherheitsanalyse)

Die technische Architektur: Flexibilität vs. Kontrolle

Ein entscheidender Unterschied zwischen einer App und einer nativen Integration liegt in der Abhängigkeitsverwaltung. Apps können eigenständig Bibliotheken nachziehen, die Home Assistant nativ weder unterstützt noch verifiziert hat.

Zudem können Apps keine direkten Sensor-Plattformen innerhalb des HA-Kerns registrieren; sie müssen stattdessen Umwege über Brücken (wie MQTT) nutzen. Aus Gründen der Systemstabilität und Sicherheit habe ich mich explizit gegen das aktive „Publishen“ von Entitäten entschieden.

Das SFML-Sicherheitsnetz

Stattdessen fungiert SFML als kontrollierte Schnittstelle, welche Werte übergibt, abholt und verarbeitet.

  • Schutz vor Instabilität: Dieses Design verhindert Fehlkonfigurationen, Daten-Spam und unkontrollierte Zustandsänderungen.
  • Native Validierung: SFML unterliegt zu 100 % der Kontrolle des Supervisors und basiert ausschließlich auf nativem, von Home Assistant freigegebenem Code.

Das Risiko der „Black-Box“

Apps agieren prinzipiell als Black-Box: Ohne tiefgehende Code-Analyse bleibt unklar, ob sie Fehler, versteckte Telemetrie, Trojaner oder Schadsoftware enthalten.

Meine Konsequenz: Totale Isolation.

Meine App ist strikt vom System getrennt. Sie kann weder in den Home Assistant Recorder schreiben noch daraus lesen. Alle benötigten Daten werden über das überwachte SFML-Modul bezogen. Damit ist ein direkter Zugriff auf eure historische Datenbank technisch ausgeschlossen.


Grundsatz: Safety First statt Bequemlichkeit

Integrationen sind hochkomplex und erfordern native, geprüfte Lösungen. Apps hingegen unterliegen keinerlei zentralen Kontrolle. Es gibt keinen technisch logischen Grund, Werkzeuge für Energiestatistiken (STATS), komplexe Energieberechnungen (GPM) oder Datenvergleiche nicht auf einer sauberen, offiziellen Repository-Basis zu bauen.

“Ich investiere lieber deutlich mehr Hirnschmalz in eine robuste Architektur, als eine unberechenbare Gefahr für das Gesamtsystem in Kauf zu nehmen.”

Wir hatten diese Diskussion bereits im Beta-Thread: Warum sind SFML, STATS und GPM keine Apps? Weil Sicherheit Vorrang vor dem vermeintlich einfacheren Weg hat.


Warnung vor KI-Code und unbekannten Quellen

Die Gefahr unerkannter oder gefährlicher Routinen in fremdem Code ist immens. Ich rate zur massiven Vorsicht bei Apps unbekannter Entwickler oder KI-generierten Lösungen – insbesondere wenn diese:

  1. Weitreichenden Zugriff auf den Recorder verlangen.
  2. Sensorik-Daten manipulieren, um Berechnungen oder Statistiken zu erstellen (wie es etwa bei TFS für Tagesprognosen und Erträge praktiziert wird).

Solche tiefgreifenden Zugriffe stellen ein unnötiges Sicherheitsrisiko dar, das durch mein Design konsequent ausgeschlossen wird.

Appell an alle (KI-)Entwickler

Wenn ihr via KI Apps baut: Lasst zwingend einen erfahrenen Entwickler über den Code schauen. Nur ein Mensch, der Code wirklich versteht, kann verifizieren, ob eine App „nach Hause telefoniert“ oder ein Risiko für das Smart Home darstellt.


Fazit & Side-Kick

Wer maximale Sicherheit für Prognosen sucht: Die TFS Docker-Version (Standalone Linux) bietet das höchste Sicherheitsniveau. Sie ist komplett isoliert, und dem Container können strenge Regeln auferlegt werden – ein Sicherheitslevel, das bei HA-Apps konstruktionsbedingt nicht möglich ist.

Kurzgefasst: Äußerste Vorsicht bei der Nutzung von Apps innerhalb von Home Assistant!

@Spatz: Du kannst dazu bestimmt noch einiges mehr sagen.

2 „Gefällt mir“

Ich finde die Technik, dein Wissen um sie und dein Engagement der Umsetzung faszinierend und auch eine irre Bereicherung für Home Assistant. Ich möchte dennoch die Sinnfrage stellen: ein derartiger Aufwand inkl. erhöhte Hardware-Anforderungen für eine Solarprognose? Wir sprechen bei Home Assistant von einem use case, der sich von Gartenhäuschen bis max Mehrfamilienhäusern erstreckt, nicht von Solarfarmen. Der Aufwand ist immens, damit man vielleicht ein paar kWh in der Heizung durch Vorhersehung sparen kann.

Versteh mich nicht falsch - ich sehe den Weg von HA durchaus in der Integration adaptiver KI irgendeiner Form. Spracheingabe, Mustererkennung, Verhaltensvorhersage, aktives Feedback vom System. Und hier bin ich absolut heiss auf Neuerungen und werde auch die benötigten Ressourcen bereitstellen. Und ja: deine Solarprognose ist ein absolut hippes Ding, um KI kennenzulernen / zu beobachten. Deshalb, Resumee: ich bin echt gespannt, was nach der Solarprognose noch kommt. Wir brauchen Fachleute wie dich, die mehr in HA reinbringen als neue Farben für Buttons.
(Obwohl die auch mal sehr nett wären ohne CSS-Verrenkungen :-))

2 „Gefällt mir“

@jubbi

Vielen Dank für deinen Post! Ich verstehe genau, was du meinst – das ist eine Frage, die ich hier zu Hause auch immer wieder gestellt bekomme. Bei 1.200 Stunden Entwicklungsarbeit habe ich aufgehört zu zählen. :slight_smile:

Das, was du beschreibst, war genau der Startpunkt: Ich hatte es satt, in einem System zu arbeiten, das an vielen Stellen alt und umständlich ist und vor allem eine für mich zentrale Frage nicht beantwortet hat: „Lohnt sich die Investition in Speicher oder Solar überhaupt?“ oder „Wie sieht es in der Realität aus?“. Die bunten Apps im App Store und die Berechnungstools diverser Anbieter konnten diese Fragen nicht beantworten.

So ist das Ganze hier entstanden und gewachsen. Mein Hauptberuf hat zwar nichts mit IT zu tun, aber sehr wohl mit Datenschutz und Persönlichkeitsrechten. Deshalb begann ich, etwas Lokales zu bauen, das meiner persönlichen Kontrolle unterliegt (oder der des Nutzers).

Deine Frage zu „ein paar kWh hier und ein paar Kilowatt dort“ trifft genau das größte Problem in der grundsätzlichen Logik von Prognosen. 100 % gibt es nicht – dann wäre es keine Prognose mehr.

Wissenschaftlich gesehen triffst du den Nagel auf den Kopf: Eine Solarprognose mit einer durchschnittlichen Abweichung von weniger als 20 % gilt bereits als zuverlässig. Alles unter 10 % ist unglaublich genau und fast unmöglich. Die Erwartungshaltung an eine zuverlässige Prognose sollte also wissenschaftlich gesehen zwischen 10 und 20 % liegen; alles darunter ist außergewöhnlich. Es gibt jedoch eine wichtige Einschränkung – man muss zwischen folgenden Arten unterscheiden:

  • Rollende Prognosen (Forecast Solar, Meteo, Solcast, …)
  • Feste Prognosen (SFML, TFS, …)
  • Schwellenwertprognosen (Forecast Solar, Meteo, Solcast, …)

Hier liegt genau der Unterschied zu SFML / TFS: Es sind feste Prognosen ohne Schwellenwert-Cap. Daher muss ich auch immer etwas mit den Augen rollen, wenn jemand schreibt, „Forecast Solar“ sei bei ihm genauer. Das ist wie mit VW und der Diesel-Software – ein Vergleich von Äpfeln mit Birnen.

SFML ist „nackt“ und ehrlich: Es regelt nicht nach, kappt keine Schwellenwerte und justiert nicht künstlich nach. Genau da liegt der Kern deines Punkts zu den „kWh“: Ich wollte eine Prognose, die nichts schönrechnet oder fingierte Werte produziert. Ich wollte ein Werkzeug, das die Realität abbildet, Ecken und Kanten hat und auch mal einen Fehler macht – solange es über das Jahr gesehen einen bestimmten Prozentsatz nicht überschreitet, um finanziell beurteilen zu können, ob es sich gelohnt hat. Besonders negativ ist mir hier die Bezahl-App von Fronius aufgefallen, die extrem schönrechnet. Klar, für die ist das Marketing: Je besser es „stimmt“, desto besser verkauft sich das System.

Die Frage ist aber eine andere: Wann ist das Maximum dessen erreicht, was kostenlos möglich ist? Ich denke, dieser Punkt ist erreicht. Es geht nun primär um UI, Alternativen und Hilfestellungen für Nutzer mit dem von dir beschriebenen „kleinen Gartenhäuschen“, um die Materie besser zu verstehen. Ziel ist es, sich nicht blenden zu lassen, sondern klare Entscheidungen auf Basis von Daten statt Emotionen zu treffen.

Zur Genauigkeit: Ich freue mich sogar über Abweichungen, da sie beweisen, dass das System arbeitet und lernt. Noch einmal: Eine durchschnittliche Abweichung von unter 20 % für eine starre Prognose ohne Schwellenwert-Kappung ist wissenschaftlich gesehen mit so wenigen Ressourcen unfassbar – wir reden hier eben nicht von Schönrechnen oder dem Kappen von Ausreißern.

Hardware:
Auch hier triffst Du voll ins Schwarze. Home Assitant ist darin nicht wiklich gut, die vorhandene HW zu nutzen.. eher im Gegenteil es verschwendet Resoucen ohne Ende. Das limitiert massiv was möglich wäre und tatsächlich möglich ist. Ich denke nicht, dass Home Assistant jemals eine lokale KI (so wie sie von den meisten verstanden wird) bekommen wird. - Dazu ist HA einfach zu schlecht um Umgang mit vorhandener HW. Es wird vermutlich ein " Add-On" sein das die Daten an z.B. ChatGpt überträgt. Aus diesem Grund verfechte ich so vehement meine Meinung darüber - auch in anderen Threads.
Die großen Amerikanischen KI`s sind kein Heilmittel sie sind die Pest, wenn sie nciht in ein sehr enges Kostüm gepresst werden. - Ich vermute mal das der US-Amerikanische Mutterkonzern von Home Assistant das auch sehr genau weiß und sie es in der EU so niemals durchbekommen würden.. aus diesem Grund an dieser Stelle nicht viel passiert. -

Meine Hoffnung ist, dass Home Assitant niemals den Schritt geht und offizielle Möglichkeiten bietet LLM auf das System zu lassen denn 99% der User wissen nicht was es bedeutet. - lokale KI`s sind durch die Single-Core Architektur ausgeschlossen.

Aber das wird eine Frage des Geldes sein.. wenn ChatGpt und Claude an die Tür klopfen und Nabu Casa riesige Summen bieten um ihre Live-Daten zu bekommen, werden sie schneller im System sein als wir schauen können.

Jeder Home Assistant User sitzt auf einem Goldschatz, persönliche Echtzeitdaten, Telemetriedaten, … das ist super Interessant und eine ganz andere Größenordnung als FaceBook, Alexa, … Daher bereite ich mich schon jetzt darauf vor, sollte der Tag kommen, um HA aus meinem Heim auszusperren.. das ist die Entwicklung von TFS Docker… und meinem eigenen Linux das Smart-Home kann LOKAL

Fazit:
Das berühmte Ende der Fahenstange ist erreicht, es geht nur noch um Pflege und kleinen Verbesserungen.
Aber was ich super toll finde, wieviele Menschen sich hier begeistern und die ganzen Info rechts und links des Weges.. sei es nun die Gefahr von KI`s, unterschiede zwischen Apps und Integrationen, Prozessoren, RAM, Arbeitsweise von HA, rechtliches, Datenschutz, ..

ich glaube jeder (mich eingeschlossen) hier (und besonders im Beta-Thread) hatte bestimmt den einen oder anderen AHA-Effekt der nichts mit Solar-Prognosen zu tun hat.. das ist der eigentliche Gewinn!

6 „Gefällt mir“

Diese Meinung teile ich nicht.

Der Energiekosten Assistent kostet nicht nur eine Premium Mitgliedschaft sondern ist auch Premium.

Da ist kein HA drin, der dann mal Verbrauchszähler explodieren lässt.

Das stimmt eindeutig!

Das stelle ich auch nicht in Abrede! Vieleicht habe ich mich da etwas Missverstädnlich ausgedrückt → durch die Entwicklerbrille
Fronius ist eine adaptive KI-Steuerung und keine Prognose!

Lass mich das kurz erklären wo der Unterschied liegt:

  1. Fronius bezieht die Solardaten / PV-Ertragsprognose von dem österreichischen Unternehmen UBIMET (hochaufgelöste Wetter- und PV-Leistungsprognosen für Solar.web Premium) Der gelieferte Prognosezeitraum beträgt in der Regel 48 Stunden.
  2. Die Prognose wird laufend nachgeschärft (durch Nowcasting-Elemente und neue Wetterdaten von UBIMET).
  3. Der Energiekosten-Assistent (ECA) arbeitet daher nicht mit einer starren Tagesprognose, sondern mit einer rollierenden, dynamischen Optimierung
  4. Der ECA berechnet kontinuilirch die Optimierung auf Basis einer Kombination aus Prognose und Ist-Daten
  5. Die eigenen Anlagendaten werden (in der Regel anonymisiert) an Fronius übermittelt und fließen in die zentrale Datenbank
  6. Von dieser Datenbank profitieren Anlagen in der Nähe (Schwarmwissen)
  7. Es ist eine win/win Situtation da UBIMET so auch echtzeitdaten bekommt, diese wiederrum werden dort verarbeitet und fließen in die Korrektur der Daten ein. Es ist quasie ein geschlossener Kreislauf der alle hilft.

Der Datenfluss ist:

UBIMET → Fronius → Nutzer → Fronius → UBIMET usw..
so korrigiert sich das System fortlaufend und unglaublich effizient und Smart! Gut durchdacht!! So wird es immer genauer und besser und die Korrekturen fallen immer geringer aus!
Wobei Fronius betont, dass die Nutzerdaten an UBIMET aggregiert und ohne Rückschlüsse auf den Nutzer übermittel werden. Nur innerhalb von Fronius selber liegen die “echten” Daten.

Fazit:
Der Energiekosten-Assistent ist eine hybride, adaptive KI-Steuerung (keine klassische Prognose – es ist eine Optimierung .. was super cool funktioinert) Sie kombiniert die laufend aktualisierte 48-Stunden-UBIMET-Prognose mit Echtzeit-Ist-Daten der eigenen Anlage und Anlagen in der Nähe) und passt die Batterie dynamisch an. Das ermöglicht eine selbstkorrigierende Optimierung, die auf Abweichungen zwischen Prognose und Realität reagiert.

Was ich mir angesehen habe und meinte:
Die Rohdaten (Prognose) die Fronius in ihr eigenen System einspeisen und ohne das sie diese nachkorrigieren. Darauf habe ich mich bezogen… sorry für das Missverstädnis.

Mal ganz platt gesprochen:
Die Fronius “Genauigkeit” basiert auf fortlaufende Korrekturen der eingekauften Prognose. Das ist das selbe Prinzip wie bei der Anke KI, EcoFlow KI, (kostenlos)… Ob es wirklich eine KI oder Machine-Learning ist.. keine Ahnung die Grenzen sind eh fließend.

Hinweis:
Ich hatte ganz zu Anfang über ein ähnlches Konzept nachgedacht.. Prognose einkaufen, korrigeren und fertig.Ich habe viel recherchiert wie es andere machen, was die pro/ cons sind.. Aber mein Ziel ist ein anderes…

Das habe ich gemeint.. :slight_smile:

1 „Gefällt mir“

Genau und kann keine Schatten erkennen!

Muss ja `n Grund geben, warum ich mich mit dem Thema beschäftige :innocent:

2 „Gefällt mir“

Hallo Tom,

sehr gut beschrieben. Ich kann nur bestätigen, dass ich in allen threads mit Dir und den Foristen mehr über KI und Datenschutz gelernt habe, als je zuvor.
Danke an Euch alle und vor allem an Dich persönlich.
Beste Grüße Stefan

2 „Gefällt mir“

Lief zwei mal sauber durch.

I5 7200U: 2264 sec = 37,73 Minuten; early stop bei Epoch 22; improvement_percent = 74.83; samples_train = 1400

RasPi 5: 6703 sec = 111,72 Minuten; early stop bei Epoch 25; improvement_percent = 74.91; samples_train = 1373

Bist Du hier richtig?

Würde sagen ja, da ich ja von TFS HA rede und es ja eigentlich ne Thementrennung gibt :sweat_smile:

Das Finetunig lief in der Test-VM auf meinem J5005 in 58min durch…ja ich weiß die CPU ist nicht supported…aber man wird ja mal testen dürfen :wink: CPU Last der VM war im durchschnitt bei 66% (4 Cores)

So, Fine Tuning zum 2., diesmal hat es nochmal etwas länger gedauert.

I5 7200U: 3126 sec = 52 Minuten; stop bei Epoch 30, beste Epoch = 26; improvement_percent = 74.83; samples_train = 1417

RasPi 5: 7290 sec = 2 h 1 min 30 sec; early stop bei Epoch 26, beste Epoch = 21; improvement_percent = 76,54; samples_train = 1392