Feature: Mehrere „Virtual Batteries“ (VBat) als Komposit-Data-Devices – feldweise Quellenwahl (BMS + Shunt kombinieren)

[D3R-ST3FAN]

Aus einer früheren Diskussion mit @shining-man

Motivation / Problemstellung

In realen Multi-Pack-Setups existieren pro Pack oft zwei (oder mehr?) Datenquellen:

BMS: Zellspannungen, Temperaturen, Errors, FET-Status, Balancer-Daten
SmartShunt: deutlich bessere Genauigkeit bei Strom und daraus abgeleitetem SoC (Coulomb Counting), häufig auch Spannung

Aktuell ist ein Data Device typischerweise „ein Pack“ und liefert alle Werte.
Das ist in gemischten Setups unpraktisch, weil man für ein Pack die „besten Sensoren“ aus unterschiedlichen Data Devices beziehen möchte.

Ziel

Ein neues Konzept „Virtual Battery (VBat)“ als Komposit-Device, das nach außen wie ein normales Batterie-/Pack-Device wirkt, dessen Werte aber feldweise aus anderen Data Devices zusammengesetzt werden können.

Wichtig: Es sollen mehrere VBats möglich sein, typischerweise eine VBat pro physischem Pack.

Beispiel (mehrere VBats)

Ich habe 10 Data Devices:

5× BMS (Batterie01..05)

5× SmartShunt (Shunt01..05)
Je Shunt ist elektrisch einem Pack zugeordnet.

VBat01

Basis: Data device 1 (Batterie01/BMS)

Overrides:

soc = Data device 7 (Shunt01)

current = Data device 7 (Shunt01)

voltage = konfigurierbar, z. B. max(BMS.voltage, Shunt.voltage) oder direkte Quelle

Zellwerte/Temps/Errors/FET weiterhin aus Batterie01

VBat02 analog: Batterie02 + Shunt02
…
VBat05 analog: Batterie05 + Shunt05

Ziel ist, dass im System nicht „BMS und Shunt parallel“ als zwei konkurrierende Packs erscheinen, sondern pro Pack eine konsolidierte Sicht.

@shining-man

Du hattest erwähnt, dass du über eine Verknüpfung nachdenkst, bei der man „für jedes Data Device SoC/Gesamtstrom/Spannung aus einem anderen Data Device verknüpfen kann“.
Die VBat-Idee geht in genau diese Richtung.

Wie könnte man das umsetzen?

Statt bestehende Data Devices „umzubiegen“, erzeugt man zusätzliche, virtuelle Devices, die Werte übernehmen/aggregieren.

Pro VBat:

Base source (Standardquelle für alle Werte, typischerweise ein BMS-Device)

Overrides nur für wenige Felder (Start klein):
SoC source: [ein Data Device]
Current source: [ein Data Device]
Voltage source: [ein Data Device] oder Aggregation (min/mean/max) über eine definierte Quellenliste (z. B. Base + Shunt)

Fallback-Regel:
wenn Override-Quelle invalid/offline → Base source verwenden oder „invalid“ (konfigurierbar).

Vielleicht kann man das auch grafisch entspannen indem man ein Attribut einfügt, dass ein DD "nur" Datenquelle oder Pack ist.

Wäre in Verbindung mit #275 einsetzbar

[shining-man]

Das ist ein Punkt über den ich schon viel nachgedacht habe.
Ich möchte ungern das ganze verkomplizieren. Denn es ist nur für die Usergruppe sinnvoll, die für jede Battery einen Smartshunt oder eine andere zweite Quelle hat und das dürften wenige sein.

Ich frage mich, wo der eigentliche Nutzen wäre. Für die meisten Laderegelungen ist die Zellspannung die wichtigste Regelgröße. Der Strom ist noch für den Cut-Off wichtig. Wenn man dafür genauere Werte hat, ist es natürlich schön, wenn man sie auch nutzen kann.
Der größte "Nutzen" dürfte das bereitstellen der Daten über REST oder MQTT sein, da hier dann die Daten schon passend zugeordnet sind und man das nicht am Ziel (im HA, ..) machen muss.

Die Idee der VBat würde eine zusätzliche Ebene einführen, was wieder ein weiterer Schritt der Konfiguration ist und für viele überflüssig, da sie keinen Shunt o.ä. haben. Daher war meine Idee die Data-Devices so zu belassen wie sie sind und man kann zusätzlich für jedes Datadevice eine Quelle für Gesamtspannung, Gesamtstrom, SoC angeben.
Hier wäre dann noch offen ob man ein anderes Data-Device als Quelle für z.B. den Strom angibt, oder ob man direkt die Schnittstelle und das Device daran konfiguriert. Im zweiten Fall hätte man für den Shunt kein eigenes Datadevice, sondern es wäre direkt Teil des Master-Datadevice.

Die Fragen gehen auch weiter zu MQTT/REST. Welche Daten will ich dort. Nur noch die der neuen Struktur? Sende ich bei zwei verknüpften Devices zu einem Neuen, nur die verknüpften Daten?

Wenn ich an das Feature des Wertevergleiches denke, dann brauche ich beide Quellen (BMS und Smarthunt) um z.B. den Gesamtstrom zu Vergleichen. D.h. in dem Fall müssen die einzelnen Datadevices erhalten bleiben.

Ein weiterer Punkt den ich hier mit berücksichtigen möchte wären die Temperatursensoren. Wenn man ein Konzept der Bündelung wählt, egal ob das dann VBat heist oder der Name bei Data-Device bleibt, möchte ich auch die Temperatursensoren zuordnen können. Aktuell gibt es als Zusatz nur die onewire Sensoren (aber das könnte sich ändern). Mein Ziel wäre es sagen zu können, dass ein Datadevice x Sensoren haben kann, die man dann aus den BMS Sensoren und den onewire Sensoren frei zuordnen kann.

Ein weiterer Punkt wäre noch die Zuordnung der seriellen Schnittstelle, denn für mich beginnt das ganz schon weiter vorne, bei der Zuordnung des BMS/Shunt/... zur seriellen Schnittstelle. Aktuell kann an einer seriellen Schnittstelle nur ein Devicetyp (z.B. SmartShunt, Seplos V3, JK Inverter, ...) angeschlossen werden. Aber da immer mehr Hersteller auf Modbus setzen, wäre es denkbar auch unterschiedliche Hersteller an einem Port anzuschließen, solange die Baudrate die Gleiche ist. Auch wenn es stand heute noch kein Device gibt, das man kombinieren könnte, da sie alle unterschiedliche Baudraten nutzen, aber es soll ja für die Zukunft bereit sein. Je nach Umfang der Änderung (Data-Device / VBat) möchte ich dies auch mit berücksichtigen. Zumindest möchte ich betrachten ob es Sinn macht.

Ich habe einmal eine leere Zeichnung erstellt in der jeder, der eine Idee hat und hier etwas grafisch skizzieren will, dies tun kann. Am besten immer den github Namen dazu schreiben und nicht die Zeichnung anderer ändern, sondern daneben selber Zeichnen oder kopieren.
https://docs.google.com/drawings/d/1CMTeZY74I6oWUuiq1ZOETelAtMLhz4zrf9cYGMqDyyY/edit?usp=sharing

In Summe ist wichtig, dass es alles nicht unnötig kompliziert wird und es nachvollziehbar bleibt.

Ich würde mich über rege Diskussion mit weiteren Ideen und Gedanken freuen.
Die Änderung wird unter Umständen keine kleine und sollte daher Zukunftsorientiert sein.

[D3R-ST3FAN]

Deine Bedenken bzgl. zusätzlicher Komplexität sind absolut nachvollziehbar.
Genau deshalb habe ich #280 (UI-Level „Easy / Expert“) vorgeschlagen, damit solche erweiterten Funktionen standardmäßig unsichtbar bleiben und nur im Expert-Modus konfigurierbar sind.

Mir geht es funktional nicht um eine neue „VBat“-Ebene, sondern um eine flexible Zuordnung einzelner Messgrößen innerhalb eines Data-Devices. Wenn das flach im bestehenden Modell lösbar ist (Data-Device bleibt, nur optionale Quellen-Overrides), passt das natürlich auch.

Temperatur würde ich nicht zwingend als „Override“ lösen, sondern als Zuordnung zusätzlicher Sensoren zu einem Data-Device (z. B. OneWire-Temp-Sensor einer Batterie zuweisen).

Ein Data-Device kann dann neben den BMS-Temperaturen auch zugewiesene externe Sensoren enthalten.

Offene Frage zur Umsetzung:
Würde es Sinn machen, das Ganze pro Feld so auszulegen, dass man entweder eine Quelle auswählt (Override) oder optional eine Aggregation über mehrere Quellen definieren kann (z. B. min/max/mean)? Vielleicht auch ein weiterer als Fallback?
Beispiele: Spannung als max(BMS, Shunt), Temperatur als max(zugeordnete Sensoren).

[shining-man]

Nach reichlichem Nachdenken denke ich, dass eine neue "Battery-Pack" Ebene (im weiteren kurz BP) vmtl. das einfachste wird. Du hast deine Data-Device (im weiteren kurz DD) die ganz normal bestehen bleiben. Im Default ist ein BP 1:1 ein DD. Daher sollte das für Neueinsteiger erste einmal nicht Aufwendiger oder komplizierter werden.
In der BP-Settings kann man dann das Mapping festlegen. Bei Gesamtstrom/Spannung und SoC hätte ich auch eine Aggregation von mehreren DD mit eingebaut.

Beim Fallback weis ich noch nicht so recht. Ich sehe es grundsätzlich als bedenklich wenn ein Device ausfällt oder einen Fehler hat. Es ist immer die Frage was einem wichtiger ist. Oft wir die Ausfallsicherheit auf Systemebene betrachtet iSv. das System soll möglichst immer arbeiten. Sehe ich persönlich als den falschen Ansatz, da es mir egal ist ob das System einen Tag steht, ich will Sicherheit für den Battery-Pack isv. "flieg mir nicht um die Ohren". Will ich dann einen automatisierten Fallback?