Folgender Sensor benötigt das hier!
Ladung +
Entladung -
1 „Gefällt mir“
Ja das ist mir schon alles klar was du schreibst. Und ich bin mir auch des Fehlers bewusst.
Aber es gibt die Integration PowerHelper, die jemand entwickelt hat um die Sensoren für SFML Stats bereit zu stellen. Diese wird auch von vielen genutzt (so wie ich das hier im Forum verfolgt habe).
Dort kann ich entweder einen Sensor (+ / - ) angeben und diesen nötigenfalls auch invertieren.
ODER:
Ich gebe 2 Einzelsensoren an … 1x Ladung und 1x Entladung. Die Powerhelper machen daraus macht daraus einen Sensor Akkupower. Dieser ist bei Ladung negativ und bei Entladung positiv. Das ist aus meiner Sicht auch korrekt so.
Gibt ein Stromversorgungsgerät Leistung ab ist diese positiv.
Solarpanel arbeitet … positive Leistung
Netz liefert … positive Leistung
Einspeisung ins Netz … negative Leistung
Akku liefert (entlädt) … positive Leistung
Akku lädt … negative Leistung
SFML Stats … wie du ja geschrieben hast
genau umgekehrt … Das widerum bedeutet, dass alle die die PowerHelper nutzen und dort die 2 Einzelsensoren für die Akkuleistung einen Helfer bauen müssen, der die Akkuleistung wieder invertiert.
@Schwippser
Ich kann zu der von Dir benannten Integration nichts sagen. Es ist nicht meine Integration und ich kenne den Entwickler auch nicht persönlich, finde es aber großartig das er sich Gedanken gemacht und eine tolle Integration entwickelt hat!
Grundsätzlich ist es aber so, es zählt was SFML / STATS an Sensorik verlangen um korrekt zu funktionieren. Es gibt von mir einen sehr sehr klaren Thread wo alle Sensoren beschrieben, ihre Funktioinen dargelegt und ihre Notwendigkeit erklärt wird.
Es ist kein Argument zu sagen " Ja aber… " Woran ich allerdings aktuell arbeite, und da hast Du und viele andere, einen guten Punkt: Die Beschreibungen / Erklärungen zu erweiteren und einen Picker einzuführen. Bei Stats ist das mit dem Picker schon erledigt, bei SFML noch nicht.. das liegt aber an der Sensor-Plattform die in HA zugrunde liegt und nur sehr eingeschränkt veränderbar ist.
Danke für deine Zeilen. Ich sehe das auch nicht als so problematisch an, denn ein Helfer der invertiert ist ja schnell gebastelt.
Bei diesem Thema prallen scheinbar zwei Sichtweisen aufeinander. Eine Seite sieht es aus Programmtechnischer Sicht und die andere Seite (so wie ich) aus physikalischer Sicht. Und für mich bedeutet die physikalische / elekrische Sichtweise halt - gibt ein Akku/Batterie (Stromversorgungseinrichtung) Leistung ab ist diese Positiv und nimmt ein Akku Leistung auf beim Laden ist diese negativ. Ein Solarpanel hat ja schließlich auch keine negative Leistung, wenn es produziert.
Vielleicht ist es ja möglich in der Konfiguration der SFML-Stats auch eine Auswahlmöglichkeit (z.B. Kontrollkästchen) einzurichten um mittels einfachem Klick zu invertieren.
P.S. konntest du dich schon mit diesem Problem befassen? Verschiebung “Prognose heute” vs. “Prognose nächste Stunde”
Richtig ! Aber ein Akku produziert nicht, sondern er gibt ab (-) .. oder nimmt auf (+) so ist es glaube ich für alle am einfachsten zu verstehen… ich musste einen Weg finden der für alle gut funtioniert
Ich will mich darüber auch nicht mit dir streiten, aber mit deinen umgekehrten Vorzeichen läuft SFML halt genau umgekehrt wie die gängige Praxis in HA ist. Daher denke ich nicht, dass es für die meisten User so am einfachsten zu verstehen ist. Siehe dazu folgenden Screenshot.
Dort steht ganz deutlich … positive Werte zeigen das Entladen der Batterie an, negative Werte das Laden. SFML ist nun einmal eine Integration in HA und ich finde dann sollte sich diese Integration auch an HA-Praxis halten und nicht umgekehrt.
Das ist alles nicht bös gemeint. Ich denke nur im Sinne der HA-User.
1 „Gefällt mir“
kurzer Einwurf: Anker macht es genau wie Tom in Stats, Positiv Laden, negativ entladen.
Wenn ich nicht ganz Falsch liege, hat Tom auch eine Anlage von Anker, von daher ist das darauf ursprünglich mal abgestimmt gewesen.
Davon abgesehen, in HA ist das nicht genormt oder irgendwie vorgeschrieben, wie Laden/Entladen als Sensor zu geschehen hat und daher ist das nunmal eine Designentscheidung des Entwicklers. Im Prinzip kann es jeder so machen, wie er (der Entwickler) es für richtig hält.
Andere Sache: Ich bitte darum, weitere Diskussion dazu in einem eigenen Thread oder den Fragen Thread zu Stats weiter zu diskutieren, um diesen hier wieder dem eigentlichen Thema BUG-REPORTS zurückzuführen!
Mein letztes Post zu diesem Thema.
Natürlich gibt es in HA keine Normung. Du und Tom nutzen Anker. Andere wiederum nicht. Ich verstehe auch, dass man ein System/Software so aufsetzt, wie es die beim Entwickler vorhandene Hardware verlangt. Ich habe auch kein Problem mir einen Helfer zum Invertieren zu bauen.
Wenn aber jede Integration speziell erstellte Sensoren benötigt, obwohl diese eigentlich schon in HA vorhanden sind, dann können sich HA-Nutzer vor lauter Helfern nicht mehr retten.
Beispiel: User hat seit Jahren eine PV und legt sich Template-Sensoren an, damit die PV im Energy-Dashboard von HA abgebildet werden kann. Plötzlich erscheint Integration X welche dann die gleichen Template-Sensoren möchte - nur halt invertiert. Also baut User wieder neue Template-Sensoren nur um die Vorzeichen zu invertieren.
Wenn sich Entwickler also an HA-Praxis halten, erspart es ihnen also durchaus auch Bug-Reports wie diesen hier.
Frage zu den Panelgruppen:
In der Konfig zu SFML Stats habe ich die Anordnung: Osten/Süden/Westen
In der Darstellung sieht es von den Werten so aus: Osten/Westen/Süden
Liegt der Fehler bei mir oder ist er anderweitig vorhanden?
danke für Deine ausführliche Rückmeldung und dafür, dass Du Deine Sicht so sachlich beschrieben hast. Ich verstehe den Punkt durchaus: Wenn man in Home Assistant über Jahre mit einer bestimmten Vorzeichenlogik arbeitet, wirkt es natürlich erst einmal irritierend, wenn eine Integration an dieser Stelle anders arbeitet und dadurch zusätzliche Helfer nötig werden. Ja Du hast auch Recht, ich benutze aktuell eine Anker Solix und zuvor eine EcoFlow.. das sind die Grundlagen gewesen wie auch Hoymiles.
Der Knackpunkt ist hier aber tatsächlich, dass in HA rund um Energie, Batterie, Leistung und Flussrichtungen keine durchgängig einheitliche Praxis existiert - es selbst in HA selbst inkonsequent ist.. Je nach Integration, Hersteller, Datenquelle und technischer Herleitung werden Vorzeichen unterschiedlich verwendet. Genau da prallen dann, wie Du selbst schon geschrieben hast, zwei Sichtweisen aufeinander: die eher physikalische Interpretation und die eher datenlogische bzw. integrationsbezogene Verarbeitung… allerdinge sehe ich das “Template-Thema” nicht so kriegsentscheidens.. x(-1) und das Thema ist erledigt. Man verliert weder Daten noch bricht was. Es optional zu machen, geht nicht! Das scheitert an den massiven Logiken und mathematischen Schritten - das ist kein Energiedashbord das einfach Werte addiert oder ähnliches, sondern hier geht es um solide Daten für eine KI.
Gleichzeitig heißt das aber nicht automatisch, dass die aktuelle Umsetzung ein Bug ist. Im Moment ist das eher eine Designfrage als ein technischer Fehler. Daher.. (nett gemeint) Ich nehme das nicht als BUG auf.
Das ist kein BUG sondern eine Namensgebung.. wenn due Gruppen umbenenst, sollte es as Alphabetisch Ordnern.. wenn nicht muss ich noch mal ran.. behindert aber so oder so nicht funktioinsweise, da intern mit dem Azimut und Tilt gerechnent wird.
1 „Gefällt mir“
Danke dir … mit dieser Erklärung ist es gesagt und sie leuchtet ein. Manchmal gibt es halt programmtechnische Gründe.
Diese Art Gespräch hat doch etwas sehr positives, wie ich finde. Beide Seiten lernen die Sichtweise und “Zwänge” der anderen Seite kennen. Wenn ein Gespräch so ausgeht wie diese hier , hat es letztendlich doch etwas Positives.
Also … 
von mir
P.S. Es wäre trotzdem schön, wenn du das andere von mir angesprochene Thema mal angehen könntest. Dieses ist ziemlich wichtig für mich, da ich mit den Daten/Sensoren arbeiten möchte. Der Versatz von 1 Stunde ist dabei leider im Moment quasi der Verhinderer der weiteren Arbeit.
1 „Gefällt mir“
Bei Huawei ist es auch so.
Danke für den Hinweis. Nach Richtigstellen der Reihenfolge der Panele startet jetzt die Torox App nicht mehr:
toorox_foresight.api.server.RuntimeBootstrapError: TFS startup aborted: no trusted panel groups available from SFML
ERROR: Application startup failed. Exiting.
und die Daten in SFML Stats → Settings → Panelgruppe sind ebenfalls nicht mehr vorhanden:
HA Neustart hat übrigens auch nichts gebracht.
Bitte die Fragen NICHT in den Bugtracker! Schreiben, bitte den Fragen Thread benutzen!
1 „Gefällt mir“
Das ist Grundsätzlich erstmal kein BUG.. sondern das hängt damit zusammen, dass im “Laufenden Betrieb” die Gruppen sich geändert haben.. das bedarf dann eines EOD damit sie wieder korrekt zugeordnet werden.
Das lässt sich leider nicht “on-the-fly” lösen, da die KI auf die neue Situation / Schemata neu trainieren muss..
wenn man also die Gruppen umbaut / umkonfiguriert während die Produktion noch läuft.. passen die Actuals nicht mehr.. das ist aber KEIN PROBLEM.. der EOOD zieht das gerade und macht einen Backfill
Das passt auch zu deinem fehlerprotokoll! prüfe aber trotzdem mal die systems-logs.. auch wichtig: wie jede App / Integration speichern meine Intergrationen ihre konfigurationen an dem von HA vorgesehenen platz und der wird in der regel NUR bei kompletten neustart (roter knopf) geladen und liegt dann im RAM oder Swap von HA.. ein “reload” (gelber knopf) bringt da nicht immer den gewünschten erfolg
1 „Gefällt mir“
In der Energieübersicht, ist bei mir die Anzeige der Verbraucher „etwas“ zu hoch.
In der Flowanzeige stimmt der Wert.
Hatte ich etwas falsch eingestellt, oder ist es wirklich ein bug? Danke!
Ich hatte da mal bei der Wärmepumpe einen Sensor Verbrauch eingetragen der sich nicht täglich zurück setzt,deshalb hatten sich die Werte auch so hoch gezeigt.
1 „Gefällt mir“
Hier ist die Skalierung nicht schön, alles was im oberen rechten Bereich ist wird überlappt dargestellt.
1 „Gefällt mir“
Das wurde schon mehrfach besprochen und auch schon mehrfach darauf hingewiesen und auch erklärt, dass es kein weiterer Pack, den ich jetzt aufnehme. Bitte einfach mal ein bisschen weiter oben lesen. Dazu gibt es einige Erklärungen.