Victron SmartShunt 300A/50mV

[ingbrunner]

Hallo,

könnte bitte der Victron SmartShunt 300A/50mV ergänzt werden?

Der Eintrag müsste meines Dafürhaltens nach in folgender Datei vorgenommen werden:
/lib/VeDirectFrameHandler/VeDirectData.cpp

Zu ändern wäre Zeile 29:
(29) static constexpr frozen::map<uint16_t, frozen::string, 106> values = {

Zu ergänzen wäre folgende Zeile:
(131) { 0xC038, "SmartShunt 300A/50mV" },

Ich besitze neuerdings einen SmartShunt 300A/50mV und habe diese Änderungen getestet. Negative Auswirkungen dieser Änderungen habe ich (noch) nicht bemerkt. Aber um das wirklich beurteilen zu können, fehlt mit der Überblick über den Code. Zum Testen bin ich gern bereit.

Viele Grüße
Ingolf

[SW-Niko]

Hallo @ingbrunner ,
Danke für die Meldung. Den SmurtShunt 300A/50mV kann ich aufnehmen.

[ingbrunner]

Hallo @SW-Niko ,
ich habe den SmartShunt 300A/50mV mit dem aktuellen Stand des development branches getestet. Alles funktioniert soweit.
Vielen Dank für die Aufnahme in den Code!

[RealNBB]

Hallo,

ich besitze auch einen SmartShunt, allerdings 500A/50mV.

In der Konsole ist mir nun aufgefallen, dass ich kaputte Frames habe:

checksum 0xfe != 0x00, invalid frame
checksum 0x09 != 0x00, invalid frame
checksum 0x01 != 0x00, invalid frame
checksum 0x18 != 0x00, invalid frame

Als Ergebnis kommt dann in der Konsole „Frame kaputt“.

Ist das bei dir auch so oder läuft da alles sauber bei durch? Und woher könnte das denn kommen in meinem Fall? 😃

Danke und Grüße!

Log_Batterie.txt

[SW-Niko]

Ist das bei dir auch so oder läuft da alles sauber bei durch? Und woher könnte das denn kommen in meinem Fall?

Ich habe auch einen 500A/50mV, läuft ohne Probleme. Bis jetzt ist mir noch kein Übertragungsfehler aufgefallen.

Übertragungsfehler fängst du dir durch eine ungünstige Kabelverbindung ein.

• Nicht galvanisch getrennt
• Masse nicht mitgeführt
• Kabel zu lang
• Kabel zu dicht an anderen Kabeln mit hohen Strömen

[ingbrunner]

Ich habe keine Übertragungsfehler und ein ca. 4 m langes VE.Direct Kabel.

Aber ich würde auch zuerst auf von @SW-Niko genannten Ursachen tippen.

Bei mir liegen Kabel mit hohen Strömen parallel, aber es sind Gleichströme. Die führen nur bei Lastwechseln zu Störungen. Bei mir hat nicht einmal die OpenDTU eine wirkliche Masse. Ich habe ein mit Power-over-Ethernet versorgtes Fusion Board, da muss man aufgrund des Boarddesigns den Shield des Ethernetkabels unterbrechen bzw. man muss mit einem Patchkabel ohne Shield arbeiten. Aber ich habe den Laderegler und den Wechselrichter geerdet (an der Erdungsschraube, nicht am + oder - der Gleichspannung).

Wenn Du die VE.Direct Schnittstelle wie vorgeschlagen mit einem ADUM1201 isoliert hast, fällt mir fast nichts mehr ein. Falls der ADUM1201 aus einer "billigen" Quelle stammt (eBay, Amazon, AliExpress ...) könnte man versuchen, den ADUM zu tauschen. Die Chinesen drucken alles auf einen Schaltkreis, was der Kunde gern haben will. Beispiel: ich hatte mit Pegelwandler von 3,3 V auf 5 V und 1 m Kabellänge Probleme mit DS18B20 Temperatursensoren. Ohne Pegelwandler (der Sensor funktioniert auch mit 3,3 V) direkt am GPIO-Pin des Raspberry Pi waren dann 12 m Kabel kein Problem. Das läuft so seit einem Jahr ohne Probleme. Übrigens: der Pegelwandler war angeblich von TI (und die DS18B20 waren auch gefälscht).

Viel Erfolg bei der Fehlersuche!

[RealNBB]

Hallo,

Danke ihr Zwei!

Ja, mit den ADUM1201 stehe ich ganz offensichtlich etwas auf Kriegsfuss:

Ich habe jetzt schon vier von den Dingern bestellt, zusammengelötet und auch entsprechend angeschlossen - zum laufen habe ich sie aber nie gebracht.
Ich bin allerdings zu 99,9% sicher, dass die Lötstellen i.O. sind und auch richtig verkabelt wurde (TX vom Victron auf VIA und auf der anderen Seite dann den VOA abgreifen und als RX auf einen GPIO mappen).
Bei meinen originalen Victron-Kabel (jedes 1,5m) ist/war aber eigentlich nur auffällig, dass rot Masse ist und schwarz Plus. So zumindest habe ich das rausgemessen.

Lange Rede, kurzer Sinn: Letzter Versuch sind nun diese hier:

https://www.amazon.de/Kayfg-Digitalisolatormodul-Magnetische-CAN-Bus-Transceiver-Signalisolierung-Blau-Wei%C3%9F/dp/B0F12ZVRTT/ref=sr_1_18?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=LM6ID6DQLAHZ&dib=eyJ2IjoiMSJ9.iHiUI2Vi3rGPKpEfXYCfCEVTzzT4duNeelS2FqmYKBb-mv0RYe1l8NR2E35GryUFfAAAS14kWQqDPfPeZIBAbGcZsWnAgQBTIrZUXEMfcTa5A-QjLr5-xur4tFvi9Dgd_msPCAlqESSRUmCkm8Tl_FVgxh76o_5W5MuDstTsk6XOOgeWZe2f9HjQJt0sT2N3LgyUH-1QOBGv5TgASZ7pWcQfnVaRfBtzuWTpZLRJpShpP7rCAHjsxNKykiZg7i-u2PBuOxGz_JlSuGMYF2CfzsLaICbu1agU38oMrvzbJF4.AF7Cb1dL75Gl0GFJAUJysu9mgVV_PGBsdlXVTOWSs68&dib_tag=se&keywords=adum1201&qid=1744626592&sprefix=adum1201%2Caps%2C88&sr=8-18

ohne Löten, einfach nur Kabel ancrimpen und einstecken. Wenn es damit nicht geht, gebe ich es auf! :D

[SW-Niko]

Bei meinen originalen Victron-Kabel (jedes 1,5m) ist/war aber eigentlich nur auffällig, dass rot Masse ist und schwarz Plus. So zumindest habe ich das rausgemessen.

Dazu kann ich nichts sagen. Ich verwende keine originalen Victron-Kabel. Ich vermute nur das pin 2 und 3 gekreuzt sind und pin 1 und 4 nicht. 🤔
Ich verwende ein Fusion-Board und habe mir einem Adapter für 3 ADuM gebaut. Im Prinzip schaut das dann folgendermaßen aus.

[ingbrunner]

Meistens ist es allerdings nicht der ADUM1201 an sich, sondern die Verkabelung. Meine Bemerkung zur "billigen" Hardware war nur ein Hinweis, dass es dieser liegen könnte.
Auch ich hatte ein original VE-Direct Kabel, in dem "rot" GND und "schwarz" Plus war. Den Elektronen im Kabel macht das nichts aus, aber es ist hässlich. Das originale Kabel war bei mir Crossover: Rx und Tx waren gekreuzt (grün bzw. weiß). Ich habe das Kabel geteilt und musste die beiden Enden bezüglich der Farben der Datenleitungen jeweils andersherum anschließen. An einem Stecker war weiß TX und an anderen grün Tx.
Die Steckerbelegung der Victron SmartShunt und Ladereglern ist (Draufsicht auf die Buchse am Gerät):

Im Zweifelsfalle Tx und Rx einmal tauschen und schauen, was passiert.

Die zweite Idee wäre: Worauf hast du GPIO-Pin gemappt? Beim OpenDTU Fusion Board mit CAN/Iso Shield kommen für das CAN/Iso Shield z.B. folgende Schnittstellen in Frage (Auszug aus meinem für SmartShunt und Victron Laderegler angepasstem Mapping):
"battery": {
"rx": 11,
"tx": 12
},
"victron": {
"rx": 10,
"tx": 9,
"rx2": -1,
"tx2": -1
}
Dabei wird der SmartShunt unter "battery" (!) angeführt, das Gerät mit der Bezeichnung "victron" ist der Laderegler. Bei einem Laderegler wäre es auch wichtig, Daten senden zu können (Rx und Tx).

[RealNBB]

@SW-Niko

Ja…so habe ich es im Endeffekt auch angeschlossen gehabt: Vom Victron das Kabel, „das spricht“ (also TX), auf Pin 7 (bei mir heißt der „VIA“) und auf der anderen Seite raus (Pin 2 = VOA) und auf das ESP32, gemapped als „RX“.

Warum gehst du eigentlich rechts im Schaubild mit dem Kabel einmal über Kreuz, damit du gleich wieder über kreuz gehen kannst? Du könntest doch auch direkt drauf gehen oder nicht?

@ingbrunner

Also wie gesagt…mein Victron SmartSolar 150/45 und der SmartShunt kommunizieren ja schon mit dem ESP32. Heißt, ich bekomme Daten rein, nur eben mit dem Frame-Error. Sonst lüppt alles. Das heißt für mich, Kabel habe ich schon mal richtig herausgefunden.

Ansonsten – mit angeschlossenem ADUM1202- hatte ich auch schon alles ausprobiert: 5V statt 3,3V, RX und TX vertauscht, verschiedene GPIOs ausprobiert – nichts ging. Aktuell läuft der Laderegler auf GPIO12 und der SmartShunt auf GPIO14. Die TX sind gar nicht angeschlossen im Moment.

Ein OpenDTU Fusion Board besitze ich nicht. Ich mache das über ein gewöhnliches Breakout-Board, von daher völlig frei im Mapping. :p

[SW-Niko]

Warum gehst du eigentlich rechts im Schaubild mit dem Kabel einmal über Kreuz, damit du gleich wieder über kreuz gehen kannst?

Ich mag es einfach. Ich verwende den gleichen Steckertyp wie Victron und auch die gleiche Steckerbelegung. Jetzt bin ich kompatibel, kann hin und her tauschen wie ich will und muss keine Kabel ändern.

Du könntest doch auch direkt drauf gehen oder nicht?

Klar, könnte man. Aber letztendlich macht es mehr Arbeit und man wird inkompatibel.

[ingbrunner]

Bei den verschiedenen ESP32 Board gibt es Pins, die man nicht benutzen sollte. Du könntest nachschauen, welche Pins das bei deinem Board betrifft. Aber ich glaube nicht, dass es daran liegt.
Oder Du probierst einfach mal einen andern Pin aus.
Ich glaube mich dunkel daran zu erinnern, dass es bei verkehrt angeschlossenem Kabel auch irgendwelchen "Datenmüll" auf der Konsole gab. Aber das will ich nicht noch einmal nachstellen...

[ingbrunner]

Hallo @SW-Niko,
ich habe den SmartShunt 300A/50mV jetzt auch mit dem aktuellen Release 2025.04.17 getestet. Alles funktioniert bisher bestens, das habe ich nicht anders erwartet. Die Firmware habe ich selbst kompiliert, auch dabei gab es keine Probleme (es wurden nur zwei nicht verwendete Variablen gemeldet).
Viele Grüße
Ingolf

[SW-Niko]

Sehr schön. 👍

es wurden nur zwei nicht verwendete Variablen gemeldet.

Das kannst du ignorieren. Ich habe das Gefühl das Victron mit jedem Update mehr Daten sendet die wir aktuell noch nicht benötigen oder verarbeiten.

[schlimmchen]

Ich glaube nicht, dass das hier gemeint war... Gemeint war, dass der CPP compiler auf seinem Rechner eine Warnung über zwei unbenutzte Variablen gemacht hat?

Meinst du das?

.pio/libdeps/generic_esp32s3_usb/U8g2/src/clib/mui.c:591:16: warning: 'mui_task_read_nth_selectable_field' defined but not used [-Wunused-function]
 static uint8_t mui_task_read_nth_selectable_field(mui_t *ui)
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.pio/libdeps/generic_esp32s3_usb/U8g2/src/clib/mui_u8g2.c: In function 'mui_u8g2_s8_vmm_draw_wm_pf':
.pio/libdeps/generic_esp32s3_usb/U8g2/src/clib/mui_u8g2.c:1256:9: warning: unused variable 's' [-Wunused-variable]
   char *s = buf;
         ^

[ingbrunner]

Hallo @schlimmchen,
genau das meinte ich. Ich hielt das für unkritisch, also habe ich meine Anmerkung in Klammern gesetzt. Es schien mir eine Warnung von der Sorte zu sein, die man getrost ignorieren darf.
Viele Grüße und frohe Ostern!