An die UDEV Datei habe ich auch schon gedacht. Deine Erklärung wird mir dabei sehr helfen. Die nächsten Tage werde ich daran arbeiten...
Heute wurden die Batterien trotz durchziehender Wolken voll. Die Gesamtspannungen der Batterien wichen noch einige weige mV voneinander ab. Dafür hab ich mir extra noch ein genaues Multimeter gekauft, dass bei 40V noch einstellige mV anzeigen kann. Damit hab ich die BMSen kalibriert. Alle Ströme haben sich am Ende angeglichen und die Spannung wurde langsam reduziert, nachdem der Zielwert erreicht wurde. Es hat sich noch mal bestätigt, dass die Zellenspannungen unterhalb 3,45V praktisch überhaupt nicht auseinanderlaufen. Oberhalb 3,46 wurden dann 10mV Differenz überschritten. Ab 3,47V wurde der Balancer aktiv während nur noch zwischen 0,7A und 4A flossen. Es sieht erst mal perfekt aus. Zum testen habe ich die erhöhte Spannung (3,46V) für alle zwei Tage eingestellt. Das werde ich erst mal beobachten und dann zum Beispiel auf 10Tage setzen. Die Max_Cell_Voltage reduziere ich auf 3,33V und die Float_Cell_Voltage auf 3,31V.
1 „Gefällt mir“
das verhalten ist absolut normal deswegen macht es auch keinen sinn die kabel exakt gleich zu halten
ein akku kann einen anderen innenwiderstand haben durch produktionsschwankungen und schon hast du einen unterschied.
das kabel ist dabei erstmal egal wenn es nicht gerade 3m länger ist
Das ist bei mir der Fall. Zuerst hatte ich zwei 12V Bbatterien mit 320Ah 2p4s. Dann wollte ich die umbauen auf 24V, weil ich günstig einen 24V Wechselrichter bekam. Um den zu testen habe ich eine dritte Batterie nach gleichem Muster gebaut, aber mit 304Ah 1p8s. Als der Test erfolgreich verlief habe ich die anderen Batterien auch auf 1p8s verdrahtet. Die Batterie mit den 304Ah ist eindeutig niederohmiger. Sowohl Ladestrom als auch Entladestrom sind höher. An den Batterien sind etwa 1.2m Zuleitungen mit 35mm², deren ein einpoliger Sicherungsautomat 63A folgt bevor sie parallel geschaltet sind. Der relativ hohe Schleifenwiderstand hält den Stromunterschied in Grenzen.
@voltmeter ja, die Batterien sind eigentlich nie gleich, auch der Verlauf der chemischen Prozesse in den Zellen ist von vielen Faktoren abhängig. Z.B. im Frühjahr, nach der Winder- Dunkelphase sehen die Grafiken unterschiedlich aus, als z.B. jetzt wo die Batterien im guten Rhythmus voll geladen werden. Die Akkus sind kein starres predefiniertes Ding, das sind ehe so weiche Substanz :)))
Mit Hilfe von "mytechblog" konnte ich erreichen, dass bei der Eingabe
ls -l /dev/shunt
ttyUSB4 ausgegeben wurde. Scheinbar ein Erfolg. Wenn ich aber
<span style="color: #339966">{</span>
<span style="color: #339966">"excludedServices": ["com.victronenergy.battery.ttyUSB4"],</span>
<span style="color: #339966">"cvlMode": "max_always"</span>
<span style="color: #339966">}</span>
zu
<span style="color: #339966">{</span>
<span style="color: #339966">"excludedServices": ["com.victronenergy.battery.shunt"],</span>
<span style="color: #339966">"cvlMode": "max_always"</span>
<span style="color: #339966">}</span>
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 ....
1 „Gefällt mir“
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.
1 „Gefällt mir“
@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/shuntgelinkt sind, erkannt werden. - Erstelle oder bearbeite eine UDEV-Regeldatei im Verzeichnis
/etc/udev/rules.d/, zum Beispiel99-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.
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
1 „Gefällt mir“
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
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.
Kein smart aber ein victron Lynx shunt
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. {green}:nonoise:
1 „Gefällt mir“
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
nutze ich - bisher guter support und mittlerweile stabil.