[23_BYDBox] - Modul für BYD Box Battery

[Prof. Dr. Peter Henning]

Die Angabe der Nennkapaziät eines BYD-Speichers unmittelbar aus dem BYD-Modul heraus fände ich schon sehr sinnvoll

Ich halte das nicht für sinnvoll, das steht nämlich auf Deiner Rechnung bei Kauf des Produktes...

Du fragst ja mit FHEM auch nicht Deine Hausnummer ab. Oder doch?

LG

pah

P.S.: Und wenn du die Daten wirklich haben willst: Hole sie aus dem Wechselrichter. Denn der muss sie kennen um ggf. das Entladen zu stoppen
http://192.168.0.181/solar_api/v1/GetStorageRealtimeData.cgi 300
enthält Body_Data_0_Controller_DesignedCapacity 10240

Über Modbus kennt man sie auch.

P.P.S.: Im Übrigen kann ich nur empfehlen, für Deinen Speicher 3 Devices anzulegen:
1x BYDBox
1x HTTPMOD aus dem WR
1x ModBus

Liefern allesamt leicht komplementäre Daten

[Parallix]

Die Angabe der Nennkapaziät eines BYD-Speichers unmittelbar aus dem BYD-Modul heraus fände ich schon sehr sinnvoll

Ich halte das nicht für sinnvoll, das steht nämlich auf Deiner Rechnung bei Kauf des Produktes...

Auf der Rechnung steht auch die Seriennummer, die Anzahl der Module und vieles mehr.

Für das Führen einer schlichen Diskussion wäre es hilfreich, auf die Argumente des jeweils anderen einzugehen. Da ich ich mir nicht sicher bin, ob Du (pah) sie vielleicht nicht aus meines vorherigen Postings herauslesen konntest, hier nochmal (m)ein Hauptargument:

Ein Modul sollte - nach meiner Auffassung - alle für dessen Nutzung relevanten Readings zur Verfügung stellen, sofern diese nicht auf Basis bereits vorhandener Readings ohne weiteres abgeleitet werden können. Da die Nennkapazität nicht ohne spezielles Wissen (hier die Nennkapazität eines Moduls) aus dem Modulreadings ermittelt werden kann, schlage ich vor, entweder die Nennkapazität eines Moduls oder aber die Nennkapazität des ges. BAT-Systems in die Modulreadings aufzunehmen.

[Prof. Dr. Peter Henning]

Ich denke nicht, dass du meine Antwort richtig gelesen hast.

Es gibt Daten, die man häufig braucht: SOC, Lade- bzw. Entladeleistung und weitere.

Daten wie die Anzahl der Module oder die Nennkapazität braucht man einmal pro laufendes FHEM. Oder z.B. den Wirkungsgrad nur 1x pro Tag. Natürlich kann man das alles in ein Modul reinpacken - mit unterschiedlichen Zeitabläufen. Das würde aber das Modul in der Komplexität (und Wartbarkeit) dramatisch verschlechtern.

Bau statische Daten lieber in ein userAttr.

LG

pah

[Parallix]

Ich denke nicht, dass du meine Antwort richtig gelesen hast.

Es gibt Daten, die man häufig braucht: SOC, Lade- bzw. Entladeleistung und weitere.

Daten wie die Anzahl der Module oder die Nennkapazität braucht man einmal pro laufendes FHEM. Oder z.B. den Wirkungsgrad nur 1x pro Tag. Natürlich kann man das alles in ein Modul reinpacken - mit unterschiedlichen Zeitabläufen. Das würde aber das Modul in der Komplexität (und Wartbarkeit) dramatisch verschlechtern.

Bau statische Daten lieber in ein userAttr.

LG

pah

Hat jemand nur einen Speicher, so kann das Modul niemals eine falsche Datenbasis haben, zumindest dann nicht, wenn dieser nicht verändert wird. Bei zwei (oder mehr) unterschiedlichen Speichern, die unterschiedliche IP-Adressen haben, sieht das anders aus: Erhält ein Speicher - aus welchen Gründen auch immer - eine andere IP-Adresse, dann führt Dein Ansatz zu einem Problem. Letzteres taucht bei Verfolgung des von mir vorgeschlagenen Ansatzes erst gar nicht auf und somit führt dieser letztlich auch zu einem verlässlicheren FHEM-System zur Heimautomatisierung.

Daher erneuere ich meine Bitte zur Aufnahme eines Readings mit der Nettokapazität, entweder eines Moduls oder des ges. jeweiligen Speichersystems.

PS: Möglicherweise scheint Dir die Tragweite Deiner Vorschläge nicht bewusst zu sein, denn nach Deinem Ansatz (den ich nicht teile !) müsste MadMax einige  Readings sogar herausnehmen.

[MadMax]

Also mir tut es nicht weh dieses Reading mit einzubauen wer es braucht nutzt es, wer nicht, der eben nicht.

[Prof. Dr. Peter Henning]

Möglicherweise scheint Dir die Tragweite Deiner Vorschläge nicht bewusst zu sein, denn nach Deinem Ansatz müsste MadMax einige  Readings sogar herausnehmen.

Aber doch. Und ja: Das Prinzip der Datensparsamkeit gilt auch hier.

Das ist (noch) ein freies Land, jeder kann machen was er will. Aber

somit führt dieser letztlich auch zu einem verlässlicheren FHEM-System zur Heimautomatisierung.

ist natürlich absoluter Käse.

LG

pah

[MadMax]

Hier mal zum Testen, da habe ich drei Werte eingebaut.

BatteryNominalCapacity also die Nennkapazität der Batterie
BatteryCurrentCapacity also laut SOC und SOH aktuelle Energie in der Batterie
BatteryCapacity wäre die Nennkapazität mit dem SOH Korrigiert

Bin mit der Namensgebung noch nicht zufrieden.

Gruß
Max

[Prof. Dr. Peter Henning]

Nicht ganz zu Unrecht.

Denn hier wird keine "Kapazität" gemessen, sondern die Energie. Auch wenn umgangssprachlich die "Nominalkapazität" mit der maximal verfügbaren Energie gleichgesetzt werden kann, sollte man das spätestens für die derzeit verfügbare Energie nicht mehr verwenden. Und dass man "Current" als englische Bezeichnung für den Strom auch nicht verwenden sollte, ist auch klar.

Und dass es sich um die Batterie handelt, ist bei dem Device auch klar.

Ich schlage vor:
energy_nominal
energy_max
energy_actual

Dann stehen die readings auch untereinander.

LG

pah

Edit: Und noch ein Nachtrag: SOH ist nicht der richtige Begriff. Zwar verändert sich der "Gesundheitszustand" eines Speichers im Laufe der Zeit - aber auch bei dem allerneuesten Speicher gibt es einen prinzipiellen Ladeverlust, der um so größer ist, je stärker die Ladeleistung.

[Parallix]

Hier mal zum Testen, da habe ich drei Werte eingebaut.

BatteryNominalCapacity also die Nennkapazität der Batterie
BatteryCurrentCapacity also laut SOC und SOH aktuelle Energie in der Batterie
BatteryCapacity wäre die Nennkapazität mit dem SOH Korrigiert

Bin mit der Namensgebung noch nicht zufrieden.
...

Ganz lieben Dank!

Im Grunde reicht der erste Wert völlig aus, da die anderen daraus und dem SOC ableitbar sind.

Da im englischen der Begriff capacity auch Aufnahmefähigkeit bedeuten kann, wäre er hier durchaus nutzbar und mit dem Postfix _Wh auch inhaltlich hinreichend klar beschrieben.

[Prof. Dr. Peter Henning]

Da im englischen der Begriff capacity auch Aufnahmefähigkeit bedeuten kann, wäre er hier durchaus nutzbar und mit dem Postfix _Wh auch inhaltlich hinreichend klar beschrieben.

Kopfschüttel.

pah

[Parallix]

Da im englischen der Begriff capacity auch Aufnahmefähigkeit bedeuten kann, wäre er hier durchaus nutzbar und mit dem Postfix _Wh auch inhaltlich hinreichend klar beschrieben.

Kopfschüttel.

pah

Du meinst Kopfnicken, da der Hersteller (BYD) in seinen Datenblättern auch den Begriff Kapazität verwendet oder weil der Begriff "Capacity" auch in der Fachliteratur durchaus unterschiedlich verwendet wird und daher die Angabe der Einheit erforderlich ist? Oder meinst Du vielleicht doch Kopfschütteln, weil Du zeigen willst, dass Du als Prof. eben unglaublich schlau bist, als Physiker eine Richtlinienkompetenz in Sachen Einheiten besitzt und ein einziges Wort (hier Kopfschüttel) von Dir reicht, damit andere voller Erfurcht vor Dir jegliche weitere Diskussion beenden? 

[Prof. Dr. Peter Henning]

1. Die Verwendung des Begriffes "Kapazität" für die bei Herstellung maximale Entladeenergie eines Batteriespeichers ist durchaus üblich.
Allerdings ist es _nicht_ die "Aufnahmefähigkeit", denn bei der "Aufnahme" durch das Laden treten Verluste auf, die auch bei einem neuen und modernen Speicher durchaus 10% erreichen können. Sondern vielmehr die maximale Abgabeenergie zum Zeitpunkt der Herstellung. Also eine rein theoretische Größe, die man fest einem Gerät zuordnen und deren Abfrage zu einem späteren Zeitpunkt eher sinnlos ist.

2. Es ist unergonomisch und in bestimmten Anwendungen sogar hochgefährlich, zur Unterscheidung technisch-physikalischer Größen die Einheit der Größe heranzuziehen. Aus diesem Grund wird das in der Regel vermieden, und sollte auch in FHEM vermieden werden. In FHEM ist es sogar eine seit mehr als 10 Jahren andauernde Diskussion, ob man überhaupt Einheiten in der Detailansicht anzeigen soll.

3. In der Detailansicht eines FHEM-Devices werden die Readings alphabetisch geordnet. Es ist, und das um so mehr, je mehr Daten angezeigt werden, in höchstem Maße unergonomisch, wenn dabei begrifflich zusammengehörende Größen (wie etwa die maximale Abgabeenergie, die gegenwärtig verfügbare Abgabeenergie, die am heutigen Tag hineingeladene Energie und die am heutigen Tage herausgeholte Energie) an ganz unterschiedlichen Stellen stehen.

4. Bei elektrischen Systemen werden oft Ströme ("current") gemessen. Es ist deshalb ebenfalls mit erheblicher Verwechselungsgefahr verbunden und somit erneut unergonomisch, den englischen Begriff "current" auch noch zu verwenden, um den deutschen Begriff "gegenwärtig" zu ersetzen. Auch wenn es sich in FHEM eingebürgert hat, englische Fachbegriffe zu verwenden, sollte man die intrinsische Mehrdeutigkeit der englischen Sprache im Auge behalten und möglichst vermeiden. Vollkommen sinnfreie Kombinationen wie "current energy", oder um es auf die Spitze zu treiben "current capacity", sind einfach semantisch falsch.

5. Es mag ja sein, dass mancher seine Energiedaten gerne in Wattstunden (Wh) anzeigt. Dann werden die Zahlen so schön gruselig groß, etwa, wenn der Speicher heute schon 6395 Wh abgeliefert hat. Das suggeriert allerdings eine Präzision, die bei den hier verwendeten Systemen niemals erreicht wird. Die Angabe von 6,4 kWh wäre hier vollkommen ausreichend und weit sinnvoller.

pah

P.S.: Um beim Thema "Kapazität" zu bleiben: Persönliche Angriffe bezeugen nur die intellektuelle Kapazität des Angreifers.

[Parallix]

Nach einer Nacht "drüber schlafen" ist mir folgende Idee zur Benennung gekommen:


• Energy_Storage_Capacity (falls Angabe in Wh)
• Energy_Storage_Capacity_kWh (falls Angabe in kWh)

Was haltet Ihr denn davon?

PS: Auf die anderen Readings können wir gerne verzichten.

[Prof. Dr. Peter Henning]

Was haltet Ihr denn davon?

Gemischt, aber man nähert sich an.

(E|e)nergy, prima.

Storage? Das ganze Device ist doch ein Speicher. Es wäre eher lustig, in einem DOIF zu lesen [EnergyStorage:EnergyStorageCapacity]

Capacity? Dazu habe ich mich bereits geäußert. EnergyCapacity (oder so) wäre im Hinblick auf die Herstellerangaben als Kompromiss akzeptierbar, ist aber eben nicht ganz zutreffend, weil die tatsächliche maximal entnehmbare Energie im Laufe der Zeit geringer wird. Eher "EnergyNominal".

Abzulehnen wäre aber ein Readingname, bei dem die Einheit per "_" angehängt wird. Das gibt es aus gutem Grund in FHEM nicht.

LG

pah

[MadMax]

Also EnergyCapacity als Kapazität die der Hersteller angibt?
Die anderen Werte brauchen wir nicht bzw kann sich jeder berechnen?
In Wh oder kWh?

Gruß Max