Diskussion über Stromverteilung und Aggregatoren in parallelen Batteriesystemen

Veröffentlicht von: @ogurgurpv

↑

Nachdem du persistente Namen für deine Geräte erstellt hast, musst du die Konfigurationsdatei für deine Anwendung ändern, um diese Namen zu verwenden:

```json
{
"excludedServices": ["com.victronenergy.battery.battery1"],

"cvlMode": "max_always"

Mit Hilfe von "mytechblog" konnte ich erreichen, dass bei der Eingabe 

ls -l /dev/shunt

ttyUSB4 ausgegeben wurde. Scheinbar ein Erfolg. Wenn ich aber 

```json
{
"excludedServices": ["com.victronenergy.battery.ttyUSB4"],

"cvlMode": "max_always"

}

zu

{
"excludedServices": ["com.victronenergy.battery.shunt"],

"cvlMode": "max_always"

}

mache, funktioniert es nicht mehr. Das ganze Thema ist äußerst verwirrend für mich.

@r-l "excludedServices": ["com.victronenergy.battery.shunt"], wird wahrscheinlich nicht funktionieren, da das ein Alias im Betriebsystem ist und nicht innerhalb vom DBUS, ich glaube, dass wir mit der Ausgabe von "ls -l /dev/shunt" die config.ini automatisch anpassen können, .... ich überlege was hier machbar ist ....

So kann der Script aussehen, was die config.ini Datei anpasst. 

Ich bin mit sicher, aber in der Datei /data/reinstallScriptList könnte man dieses Script vor dem /data/BatteryAggregator/setup reinstall eintragen.

(das habe ich nicht getestet, da ich keine Testumgebung habe) Prüfe bitte kritisch ob das den Sinn macht.

#!/bin/bash

# Pfad zur Konfigurationsdatei
CONFIG_FILE="/data/setupOptions/BatteryAggregator/config.json"

# Ermittle den aktuellen Gerätenamen verlinkt mit /dev/shunt
DEVICE_LINK=$(readlink /dev/shunt)

# Extrahiere den tatsächlichen Gerätenamen aus dem Pfad (z.B. ttyUSB4)
DEVICE_NAME="${DEVICE_LINK##*/}"

# Ersetze die Zeile in der Konfigurationsdatei mit dem neuen Gerätenamen
sed -i "s/com.victronenergy.battery.ttyUSB[0-9]*/com.victronenergy.battery.$DEVICE_NAME/" $CONFIG_FILE

# Feedback geben
echo "Konfigurationsdatei wurde aktualisiert: $CONFIG_FILE"
echo "Aktuelles Gerät: $DEVICE_NAME"

@ogurgurpv Deinen script habe ich ausprobiert. Es funktioniert. Danke! Ich bin mir aber nicht sicher, ob man ihn in die reinstallSciptList einfügen sollte. Die wird ja sicherlich nur ausgeführt, wenn eine reinstall gemacht wird. Es muss aber funktionieren, wenn z.B. ein reboot gemacht wurde. Am besten wäre es wahrscheinlich, wenn man den sript direkt nach der 99-usb-serial.rules ausgeführt wird. Wie kann ich das machen?

Die Option "cvlMode": "max_always" hat sich übrigens bewährt. Die Ströme der Batterien sind jetzt nicht mehr so weit auseinander.

@r-l das klingt schon ganz gut. reinstallScriptList ist in der Tat nicht der beste Platz dafür, hier ist eine Variante beschrieben:

Um sicherzustellen, dass das Skript jedes Mal ausgeführt wird, wenn das System neu gestartet wird oder wenn USB-Geräte erkannt werden, kannst du es in den UDEV-Regeln integrieren. Dies ist besonders effizient, weil UDEV direkt auf Hardwareänderungen reagiert, wie das Einstecken oder Entfernen von USB-Geräten, und somit das Skript genau zum richtigen Zeitpunkt ausführt.

### Schritte, um das Skript mit UDEV zu integrieren:

#### 1. Skript für die Ausführung vorbereiten:
- Stelle sicher, dass dein Skript ausführbar ist, indem du ihm die entsprechenden Berechtigungen gibst:

chmod +x /path/to/your/script.sh

#### 2. UDEV Regel erstellen:
- Erstelle eine neue UDEV Regel, die das Skript ausführt, wenn USB-Geräte, die als `/dev/shunt` gelinkt sind, erkannt werden.
- Erstelle oder bearbeite eine UDEV-Regeldatei im Verzeichnis `/etc/udev/rules.d/`, zum Beispiel `99-shunt-device.rules`.

Hier ist ein Beispiel, wie die Regel aussehen könnte:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="YYYY", RUN+="/path/to/your/script.sh"

Ersetze `XXXX` und `YYYY` mit den tatsächlichen `idVendor` und `idProduct` Werten deines USB-Geräts. Das `ACTION=="add"` sorgt dafür, dass das Skript ausgeführt wird, sobald das Gerät hinzugefügt wird.

#### 3. UDEV-Regeln neu laden:
- Nachdem du die Regel hinzugefügt hast, musst du UDEV anweisen, die Regeln neu zu laden, um die Änderungen zu übernehmen:

udevadm control --reload-rules
udevadm trigger

#### 4. Testen:
- Um zu testen, ob deine Regel korrekt funktioniert, kannst du versuchen, das Gerät physisch zu trennen und erneut zu verbinden. Überprüfe, ob das Skript wie erwartet ausgeführt wird.

#### Warum nicht `reinstallScriptList` verwenden?
Die `reinstallScriptList` wird typischerweise verwendet, um Skripte nach der Neuinstallation von Software oder Updates auszuführen. Dies ist nicht ideal für dein Szenario, da das Skript nach jedem Neustart oder bei Hardwareänderungen ausgeführt werden sollte, nicht nur nach einer Neuinstallation.

Durch die Verwendung von UDEV zur Ausführung deines Skripts stellst du sicher, dass es genau dann ausgeführt wird, wenn es notwendig ist, also direkt nach dem Erkennen des USB-Geräts. Dies ist eine zuverlässige Methode, um Probleme mit dynamisch zugewiesenen Gerätenamen zu handhaben.

So hat "meintechblog" das beschrieben. So hab ich eine 99udev... angelegt:

SUBSYSTEM=="tty", ATTRS{serial}=="VE6WGROY", SYMLINK+="shunt", OWNER="raspberrypi4"

Ich hab schon überlegt, ob man deinen script einfach daranhängen kann. Wenn ja, muss ein Syntyx beachtet werden? Danach muss dann noch der Batteryaggregator neu gestartet werden, falls beim aus und einstecken eine neue ttyUSBx vergeben wird. 

Veröffentlicht von: @r-l

↑

SUBSYSTEM=="tty", ATTRS{serial}=="VE6WGROY", SYMLINK+="shunt", OWNER="raspberrypi4"

hier kann noch ein  RUN+="/path/to/your/script-update-config-ini.sh" drangehängt werden. So dass es so aussieht:

SUBSYSTEM=="tty", ATTRS{serial}=="VE6WGROY", SYMLINK+="shunt", OWNER="raspberrypi4", RUN+="/path/to/your/script-update-config-ini.sh"

ja, wenn sich die ttyUSB ändert, sollte der Batteryaggregator, danach restartet werden. Das kann man am Ende des Scripts hinzufügen. Man könnte auch prüfen ob sich der Name geändert hat und erst dann restarten

# Pfad zur Konfigurationsdatei

CONFIG_FILE="/data/setupOptions/BatteryAggregator/config.json"




# Ermittle den aktuellen Gerätenamen verlinkt mit /dev/shunt

DEVICE_LINK=$(readlink /dev/shunt)




# Extrahiere den tatsächlichen Gerätenamen aus dem Pfad (z.B. ttyUSB4)

DEVICE_NAME="${DEVICE_LINK##*/}"




# Ermittle den aktuellen in der Konfiguration verwendeten Gerätenamen

CURRENT_DEVICE=$(grep "com.victronenergy.battery.ttyUSB" $CONFIG_FILE | grep -o 'ttyUSB[0-9]*')




# Ersetze die Zeile in der Konfigurationsdatei mit dem neuen Gerätenamen, falls sich dieser geändert hat

if [ "$DEVICE_NAME" != "$CURRENT_DEVICE" ]; then

    sed -i "s/com.victronenergy.battery.$CURRENT_DEVICE/com.victronenergy.battery.$DEVICE_NAME/" $CONFIG_FILE




    # Feedback geben

    echo "Konfigurationsdatei wurde aktualisiert: $CONFIG_FILE"

    echo "Aktuelles Gerät: $DEVICE_NAME"




    # Führe das Reinstall-Kommando aus, da sich der Gerätename geändert hat

    /data/BatteryAggregator/setup reinstall

else

    echo "Keine Änderung im Gerätenamen. Keine Aktion erforderlich."

fi

Hi

ich benötige mal etwas Hilfe.

Es ist mir einfach nicht möglich den SmartShunt aus den Berechnungen des Aggregators aus zu schließen.

Im Cerbo zeigt er mir an das er drei Batterien erkennt, Berechnet aber den Shunt mit 

der Shunt wird bei mir so erkannt

und eingegeben habe ich folgende Zeile

{
"excludedServices": ["com.victronenergy.battery.ttyS5"]
}

mittlerweile in x Variationen.

Da bald ein vierter Akku dazu kommt würde ich das System gerne über den Aggregator Steuern, in Moment Steuert es nur der Shunt.

Bin sehr dankbar über Tips zu einer Lösung.

mfg Carlo

Ich habe vier serial seplos batts und bei mir steht:

# cat ./data/setupOptions/BatteryAggregator/config.json
{
"auxiliaryServices": ["com.victronenergy.battery.socketcan_can0_vi0_uc288664"],
"logLevel": "INFO"
}

Aus dem Bauch raus hätte ich auch exclude genommen, war jetzt selber verweundert als ich nachgeschaut habe.

mittlerweile sollte auch mittels name statt "pfad" gehen

https://github.com/pulquero/BatteryAggregator?tab=readme-ov-file#service-names

Hi, Danke für deine Antwort.

Wie ich sehe hast du keinen SmartShunt verbaut oder ist das (socketcan_can0_vi0_uc288664) dein Shunt?

Meine Batterien erkennt er ja, nur leider auch den SmartShunt und der wird immer mit berechnet.

Man soll den Shunt aus der Messung ausschließen können aber das ist nicht so einfach wie  beschrieben. Bei mir wird der immer als Batterie mit Berechnet wenn ich den Stecker vom Shunt abziehe dann ist es Ok aber ich würde den Shunt gerne mit laufen lassen. 

Hi, habe es geschafft der Shunt ist endlich raus aus der Berechnung nun kann ich mich ans fein Tuning machen. 

Veröffentlicht von: @carlo2

↑

Wie ich sehe hast du keinen SmartShunt verbaut oder ist das (socketcan_can0_vi0_uc288664) dein Shunt?

Kein smart aber ein victron Lynx shunt

Veröffentlicht von: @carlo2

↑

habe es geschafft der Shunt ist endlich raus aus der Berechnung

und wat war nu die Lösung?

Ich Dummerchen habe immer in der Datei /data/dbus-aggregator-batteries/settings.py rum gefummelt statt in nano /data/setupOptions/BatteryAggregator/config.json und das Tage lang.  

Welchen Battery Aggregator habt ihr denn, bzw. welcher ist empfehlenswert? Können die auch mehr als 2 Schnittstellen bzw. Batterien aggregieren?

https://github.com/pulquero/BatteryAggregator

https://github.com/Dr-Gigavolt/dbus-aggregate-batteries

https://github.com/pulquero/BatteryAggregator

nutze ich - bisher guter support und mittlerweile stabil.