Gruß
Das ist das Problem mit dem Zeithorizont. → Die aktuellen Tests scheinen das problem Final und über alle Jahrezeiten hinweg zu lösen. Für den Zweck habe ich die Wetter-KI erweitert und zwei neue sog.Features zum Lernen hinzugefügt. Aktuell macht aber der Core von HA 2024.4 Probleme… ich versuche das aktuell noch zu fixen bzw zu umgehen und dann kann das Update raus.
Danke! Das ist hilfreich (wie auch von den Anderen) .. es zeigt das Problem. Ich bin mittlerweile an dem Punkt, dass ich meine “alte” eigene Linux Distrubution aus der Mottenkiste hole und ein komplette eigene Distro baue (auf Debian), die HA als supervised Docker und eigener lokaler KI enthält 
das hätte den Vorteil, das die lokale KI HA einrichten und auch auf Probleme überwachen könnte und die SFML KI unterstützen könnte - all in one ohne die ganzen nebenkriegsschauplätze.. ich baue da dann direkt alles ein was man als Start so braucht…
- Paperless
- Immich
- lokale KI (wenn eigene Grafikkarte im System vorhanden)
- SFML
- Zigbee
- VM
- Docker
- gehärtet gegen Werbung, Datenschutz,..
- -VPN (WireGuard)
Mal sehen…
bedeutet was? Solar Forecast ML läuft bei mir nicht mehr?
An so etwas hatte ich auch schonmal in klein gedacht. Also SFML in einer Docker ausserhalb von HA mit einem “eigenen Linux” und die Sensoren werden über die API oder MQTT gepullt.
Mal laienhaft ausgedrückt.
Das ist überhaupt nicht Laienhaft ausgedrück… im Kern ist es genau das Ich spiele da schon eine Weile mit rum, da aktuell das “gegen den Code von HA Testen” mehr Resourcen bindet als die eigentliche Entwicklung.
Ich komme ja aus der Linux-Welt und habe somit schon verschiedene Ansätze überlegt:
- Ein auf Debian 13 (Trixie) basierendes schmales Linux getrimmt auf Datenschutz und Sicherheit das entweder direkt die API zu HA mitbringt oder aber HA im Docker und nur updated wenn HA auch wirklich stabil ist..
- mit einer leichtgewichtigen lokalen und Deutschen LLM das bei den Dingen im Alltag hilft.. als auch die Konfiguration von Ha selbst..
- quasi das Schweizer Taschenmesser, für alle, die maximalen Datenschutz und möglichst wenig Stress mit HA haben wollen..
- die beliebtesten User Integrationen direkt verfügbar und Konfiguriert..
Alternativ: HA forken ist ja eh Open Source und den ganzen Krempel fixen und eine " Pre-Installed" Version mit den wichtigsten Integrationen und automatischer Konfiguration rausbringen… gibt viele denkbare Möglichkeiten!
Nein, das bedeutet es nicht! - Keine Auswirkungen… es ist nur eine Gedankenspielerei.. Im Kern geht es darum, sich von den ständigen Bugs und Problemen zu befreien und HA nur als Lieferant von Sensordaten zu benutzen und sich zu befreien von den Einschränkungen.. und Datenschutz und Privatsphäre als oberste Maßgabe.. als auch echte Unterstützung bei der Konfiguration von HA anstatt dieser altbackenen und manches Mal verwirrenden Konfigurationsschritten.. Im Kern eine All in One Lösung ohne Gefummel.. das ist aber ein völlig anderes Thema!
Also ganz entspannt zurücklehnen… das ist Nerd-Stuff und Brainstormen.. nichts weiter!
Wie macht @supernova1963 das denn mit eedc? SFML als App (Add on) ? Wäre das nicht auch einen Gedanken wert? No offense - nur mal laienhaft dahin gestormt.
Kenn ich nicht… ? Weder den User noch was er macht..aber ich schaue es mir gern mal an…
Fazit
was @supernova1963 hier macht, ist grundsätzlich etwas anders. Für sein Hauptproblem habe ich aber die Lösung " Dynamische Preis".
SFML, Stats, GPM behandeln es komplett anders. Sie berechnen
a) Wann wurde Energie aus dem Grid bezogen / zu welchem Preis
b) Wann wurde die bezogene Energie wieder abgegeben / wie hoch war der Grid-Preis zu dem Zeitpunkt
c) Zu welchem Zeitpunkt wurde Solar-Energie eingespeist und wie hoch ist die Ersparnis im direkten Vergelich zum GRID-Preis
und noch andere Dinge.. ich bin gespannt wie sich sein Projekt weiterentwickelt! Aktuell ist es m.E. noch in einem sehr frühen Stadium. Besonders fehlt mir persönlich das, an dem ich gerade arbeite und was schon bei einigen Nutzern im Test ist: Lokale Ki-geführte Auswetung von WP! Hier geht es nicht nur um Strompreise sondern auch um Dämmwerte des Hauses und die tatsächliche Ersparnis. Einfach nur Strompreise zu berechnen, ist da zu kurz gedacht.
Schon wieder ein Missverständnis.
Mir geht‘s darum, dass er eine App baut. Darauf wollte ich hinweisen. Mach doch Solar Forecast ML zu einer eigenständigen App.
eedc verfolgt ja auch eine anderen Ansatz, wenn ich das alles so richtig verstehe.
achso … Nee SFML ist keine APP es ist eine Integration bringt an der Stelle auch keine Punkte
Aber wenn Du eine daraus machst, hast du dann immer noch den Zirkus mit dem HA core?
Das SFML eine Integration ist, ist mir schon klar. Vielleicht verstehe ich nur nicht den Unterschied.
Das ist im Prinzip egal.. das schwächste Glied in der Kette ist aktuell Home Assisiatnt selbst…
Zu Deiner Frage:
Apps = keine eigene Sensor Plattform
Integrationen = Stellen Sensoren bereit
Ein Umstand der schon lange kritisiert wird, da gerade so schwere Integrationen (wie z.B. SFML) besser als eigenständige App laufen würden → Konsequenz keine Senoren können angeboten werden.
Sensoren, würden dann ggf. Über MQTT laufen?
HA würde ich schon eigenständig lassen, ansonsten hast du das nächste Thema.
An sich würde ich auch ein reines SFML Docker machen, oder es wie dietpi aufbauen, da ich z.B. die anderen Programme ebenso extern von HA als Docker laufen habe.
Genau das währe auch meine Frage .
Wenn SFML eigenständig würde wie SFML dann an den Sensor daten kommt?
Gruss
Ich denke, das ist erstmal Zukunftsmusik, wenn überhaupt, dann werden wir bestimmt sehen.
Denke das könnte über einer API laufen und einer kleinen Integration nur für diese API. Die schickt die benötigten Sensoren dann an sfml und sfml schickt Sensoren an die Integration für ha. 
Wenn es dazu kommen sollte, dann sollte die Kommunikation über MQTT laufen. Ich habe mehrere “große” Geräte hier, die über MQTT mit HA-Discovery sehr gut und stabil laufen. Zum Teil mit über 100 Entitäten.
Aber irgendwie sind wir für diese Diskussion im falschen Thread…
Gruß Ralf