DCB Batteries missing

[Treasy79]

Hallo Thomas,

mir ist aufgefallen dass bei den DCB Werten nicht alle Batterien kommen.
Ich habe 5 Stück und bekomme nur die ersten 3 Stück, welche am Batterie String 1 meines E3DC PRO hängt.
Die beiden Module auf dem zweiten Batterie-String werden nicht übertragen.

Gibts dafür auch TAGS mit denen du die Werte lesen kannst?

Danke & Grüße
Philipp

[pvtom]

Hallo Philipp,

bei mir hängen die Batteriemodule alle an einem Strang, es sind auch nur vier. Von daher habe ich das Problem nicht.
Ich gehe aber davon aus, dass man das hinbekommen sollte.

In der Datei RscpMqttMain.cpp Zeile 637
protocol.appendValue(&batteryContainer, TAG_BAT_INDEX, (uint8_t)0);
wird der Batteriestrang, der abgefragt wird, mitgegeben. Hier "0".

Wenn Du möchtest kannst Du die "0" mal durch eine "1" austauschen, dann neu kompilieren und testen, ob Du jetzt die beiden anderen DCB-Module ausgegeben bekommst.
Wenn das geht, kann ich den Code so erweitern, dass beide Batteriestränge und damit alle DCB-Module abgefragt werden.

Gruß
Thomas

[pvtom]

Hallo Philipp,

das neue Release v3.8 steht zur Verfügung.
Mit dem (bisher nicht dokumentierten) Konfigurationsattribut BATTERY_STRING kannst Du den Batteriestring in der .config ändern, z.B. auf 1 (Default ist 0).
Kannst Du damit die anderen DCB-Module auslesen?
Wenn das geht, könnte ich ein richtige Lösung für mehrere Batterie-Strings programmieren.

Gruß Thomas

[Werner1000]

Hallo Thomas,
habe bei mir das gleiche Problem: 3 Batteriemodule am S10E PRO, eins am ersten Strang (DC0), zwei am zweiten Strang (DC1). Ich habe mit der 3.9er Version gerade auf meinem Haus-UBUNTU-Server begonnen, läuft ansonsten sehr gut. Wenn ich dich richtig verstehe, dann muss ich (auch) bei dieser Version in der .config nur zusätzlich eine Zeile BATTERY_STRING=1 einfügen, damit auch der zweite Strang ausgelesen wird. Bei mir ändert sich dadurch aber nichts, es wird nur die erste Batterie ausgelesen, im MQTT taucht weiterhin auf: E3DC/battery/dcb/count 1 und E3DC/battery/dcb/1/manufacture_name LG etc.. Die Batterien des zweiten Strings fehlen.

Was mir auch noch auffällt: der .config Parameter INTERVAL=1 zieht bei mir nicht, ich habe auf 60 umgestellt und trotzdem kommt alle ca. 10s eine MQTT-Meldung. Natürlich nach allen Änderungen rscp2mqtt neu gestartet.

Viele Grüße und Danke
Werner

[pvtom]

Hallo Werner,

bisher gibt es noch keine vollständige Lösung, um zwei Batteriestränge zeitgleich auszulesen.
Der Parameter BATTERY_STRING ist nur zu "Forschungszwecken" eingerichtet.
Wie geschrieben, habe ich 4 Module an einem Batteriestrang. Ich programmiere hier also blind und bin auf Tests und Mithilfe von "Betroffenen" angewiesen.
Mit BATTERY_STRING=1 kann man (wahrscheinlich) auf den anderen String wechseln (Default ist BATTERY_STRING=0). D.h. man bekommt in der vorliegenden Version nur Angaben zu einem String, entweder zu 0 oder zu 1.

Wenn ich bei meiner Anlage BATTERY_STRING=1 setze, bekomme ich nur noch e3dc/battery/power und e3dc/battery/soc und gar keine Angaben zu den DCB-Modulen. Der Parameter wirkt also grundsätzlich.

Du müsstest mal vergleichen, ob es Unterschiede gibt, wenn Du mal BATTERY_STRING=0 und mal BATTERY_STRING=1 setzt. Z.B. bei den Angaben e3dc/battery/dcb/1/soc ../soh ../serial_code ..
Wenn dem so ist, werden unterschiedliche Battery-Strings ausgelesen.

Dann könnte ich die Software so anpassen, dass nicht nur ein Battery-String, sondern beide (oder konfigurierbar noch mehr) ausgelesen werden und dann z.B. als Topics e3dc/battery/1/dcb/1/soc ausgegeben werden (mit Angabe des Strings nach "battery" und Angabe des Moduls nach "dcb").

Zum Interval. Hmm, funktioniert bei mir tadellos.
Wenn ich INTERVAL=1 eintrage oder die INTERVAL-Zeile in .config ganz rausnehme (oder auskommentiere), fragt das Programm sekündlich ab. Das Programm akzeptiert Werte von 1 bis 10. Höhere Werte werden auf 10 Sekunden zurückgesetzt.
Was sagt das Programm denn beim Programmstart? "Fetching data every second" oder "Fetching data every X seconds"

Gruß
Thomas

[Werner1000]

Hallo Thomas,
danke für Deine Erläuterungen, damit konnte ich BATTERY_STRING sinnvoll ausprobieren. Der Forschungs-Parameter wirkt und liefert nach Änderung alle 3 bei mir installierte Batterien:
BATTERY_STRING=0:
...
E3DC/battery/dcb/1/device_name EM048126P3S
E3DC/battery/dcb/1/serial_code xxx
...
E3DC/battery/dcb/2/device_name EM048126P3S
E3DC/battery/dcb/2/serial_code xxx
...
BATTERY_STRING=1:
...
E3DC/battery/dcb/1/device_name EM048126P3S
E3DC/battery/dcb/1/serial_code xxx
...

Anders als ich bisher annahm sind also bei mir am ersten Strang zwei Batterien und am zweiten eine. So wird es auch von E3DC empfohlen, um die damit maximal mögliche Lade/Entladeleistung von 7,5kW (3 Batterien) zu ermöglichen. Die meisten der installierten Geräte mit mehreren Batterien werden also beide Stränge nutzen. Deshalb wäre es toll, wenn Du das Programm entsprechend erweitern könntest. Der Batterie-Bezeichner "dcb" wäre dann aber bei beiden Strängen der gleiche von 1 beginnend hochzählend, was eine Unterscheidung erschwert. Bei RSCPGui (Win) wird dazu eine Auswahl BAT#0 oder BAT#1 angeboten, vielleicht lässt sich etwas ähnliches einbauen.

Vielleicht hilft das auch anderen Nutzern: ich möchte einfach alle überhaupt vorhandenen Messwerte über MQTT publishen, um dann selektiv die nötigen in meinem Nodered auszuwerten. Dazu habe ich in der .config folgenden Eintrag hinterlegt:
#-Forced Topics
#--will be published with every cycle
FORCE_PUB=E3DC/./.
und die bereits vorhandenen mit # stillgelegt.

Der Parameter INTERVAL funktioniert schon wie Du schreibst. Da mir eine Meldung alle 60s ausreicht und ich das so eingetragen hatte, werden daraus die beschriebene 10s. Gibt's einen Grund, dass Du das auf diese 10s limitierst oder ließe sich das auch auf längere Zeiten aufweiten? Die Möglichkeit, die Server-/Netzlast zu reduzieren wäre m.M. nach sinnvoll.

Viele Grüße und Danke
Werner

[pvtom]

Hallo Werner,

vielen Dank für Deine Forschungsarbeit. Ich habe die Unterstützung mehrerer Batterie-String bereits umgesetzt, kommt bald mit dem nächsten Release. Die DCB-Module werden einfach durchnummeriert, wie Du vorgeschlagen hast.
Der Parameter FORCE_PUB bewirkt, dass damit konfigurierte Topics in jedem Intervall zum MQTT-Broker gesendet werden. Default ist, dass Topics nur gesendet werden, wenn sich der Wert (Payload) ändert.
Zur Frage, warum das Intervall nur auf max. 10 Sekunden gesetzt werden kann (bzw. konnte). Bisher war auch die Reaktion auf "e3dc/set/..."-Steuerungskommandos abhängig vom Intervall. Damit sich das dann noch einigermaßen "flüssig" anfüllt, die Grenze von 10 Sekunden... Ich habe das jetzt angepasst und eine Lösung für die Steuerungskommandos gefunden. Mit dem nächsten Release sind auch höhere Werte möglich.

Gruß
Thomas

[Werner1000]

Hallo Thomas,
vielen Dank für Deine Mühe und die schnelle Umsetzung. Beide Funktionen laufen jetzt sehr schön.
In der .config eingetragen:
#--Number of Battery Strings, default is 1
BATTERY_STRINGS=2
liefert:
...
E3DC/battery/dcb/1/device_name EM048126P3S
E3DC/battery/dcb/1/serial_code xxx
...
E3DC/battery/dcb/2/device_name EM048126P3S
E3DC/battery/dcb/2/serial_code xxx
...
E3DC/battery/dcb/3/device_name EM048126P3S
E3DC/battery/dcb/3/serial_code xxx
...

Weiter oben hatte ich meine Settings für die Anzeige aller möglichen Topics gezeigt, da sind die Sternchen verloren gegangen. Bevor ich da lang experimentiere, das 'Stern' durch ein Sternchen ersetzen:
#-Forced Topics
#--will be published with every cycle
FORCE_PUB=E3DC/.Stern/.Stern

Jetzt werde ich mich um die Integration in meine Nodered-Umgebung kümmern.

Tolle Arbeit, viele Grüße
Werner