Hallo,
endlich Wochenende, und ich habe wieder Zeit ein wenig zu testen
set MK2::DEBUG 0x2
Ich habe das Ergebnis von eben in ein logfile gespoolt, aber bin mir nicht sicher, ob und wie ich das hier hochladen kann…
log_120425.txt (123,6 KB)
Ok, im Nachhinein gefunden 
hallo,
die ursache fuer die stromwerte habe ich gefunden, das sind negative zahlen und das beruecksichtigt mein programm noch nicht, da ich immer nur positive werte habe, ist mir das nicht aufgefallen.
hier der update:
mk2.zip (10,4 KB)
damit sollte die stromanzeige jetzt stimmen.
hier kannst du uebrigends nachlesen, was die ganzen daten im protokoll bedeuten:
die zeilen mit 15 32 am anfang der daten sind die info-frames. bei dir ist es nur das L1 ac info-frame.
leider habe ich in der doku ein paar informationen vermisst, wie die angabe, welches format die 2 byte fuer den strom haben. erst viel weiter hinten steht dann, dass sie vorzeichenbehaftet sind.
ich sollte vieleicht auch noch ein paar dinge im programm aendern, da ich das dc-info-frame noch nicht an der phase info festmache. da habe ich eben ein bisschen ausprobiert, weil es in den anderen frames noch ein code-byte gibt, das hier aber eine andere bedeutung hat.
naja, bisher habe ich es auch nur zum abfragen der daten benutzt, bis ich alle multis an gx-devices hatte. seitdem benutze ich es nur um den mp c1600 und den mp 3000 zu steuern, da das ueber den cerbo nicht funktioniert, warum auch immer!
leider ist damit immer noch nicht klar, warm dein multi vom gx nicht erkannt wird. ich danke aber, einen fehler beim multi koennen wir ausschliessen.
tschuess
Hi,
das mit dem Vorzeichen habe ich tatsächlich auch vermutet. Der Wechselrichter am ACout speist ja ein, insofern war ja anzunehmen, dass dort eigentlich negative Werte auftauchen sollten.
Blockzitatleider ist damit immer noch nicht klar, warm dein multi vom gx nicht erkannt wird. ich danke aber, einen fehler beim multi koennen wir ausschliessen.
Den Satz habe ich mal als Anlass genommen, um wieder am vorderen Ende anzufangen. Ich habe eine andere SD-Karte genommen, ein frisches VenusOS der letzten Version draufgespielt und in den Raspi verfrachtet. Erfolg gleich null. Weder in der Remote Console, noch im VRM-Portal wurde der MP2 unter den devices angezeigt.
Auf der Suche nach anderen Tools, um die Verbindung/Erkennung vom MK3/MP2 zu testen, bin ich auf ein ganz ähnliches Projekt wie dein Programm gestossen. Kennst du wahrscheinlich auch https://github.com/martiby/multiplus2 Im Prinzip wirft es auch kontinuierlich die aktuellen Werte aus, aber in der gui-Version kann man zusätzlich sehr einfach den ESS-Sollwert für den MP2 einstellen, also indirekt den Inverter/Charger anwerfen
2025-04-12 17:56:20.410 vebus INFO mk2_version=1170216
2025-04-12 17:56:20.582 vebus INFO init_address 0 successful
2025-04-12 17:56:20.919 vebus INFO found ess assistant at ramid=130
2025-04-12 17:56:22.155 vebus INFO {'device_state_id': 8, 'device_state_name': 'bypass', 'mains_u': 237.73, 'mains_i': -0.8, 'inv_u': 237.73, 'inv_i': -0.83}
2025-04-12 17:56:22.380 vebus INFO read_snapshot: {'inv_p': -132, 'out_p': -137, 'bat_u': 27.86, 'bat_i': 0.0, 'bat_p': 0, 'soc': 197}
2025-04-12 17:56:22.553 vebus INFO led_light=0x01 led_blink=0x00
2025-04-12 17:56:23.788 vebus INFO {'device_state_id': 8, 'device_state_name': 'bypass', 'mains_u': 238.71, 'mains_i': -0.8, 'inv_u': 238.71, 'inv_i': -0.83}
2025-04-12 17:56:24.033 vebus INFO read_snapshot: {'inv_p': -131, 'out_p': -135, 'bat_u': 27.86, 'bat_i': 0.0, 'bat_p': 0, 'soc': 197}
2025-04-12 17:56:24.225 vebus INFO led_light=0x01 led_blink=0x00
2025-04-12 17:56:25.471 vebus INFO {'device_state_id': 8, 'device_state_name': 'bypass', 'mains_u': 238.71, 'mains_i': -0.8, 'inv_u': 238.71, 'inv_i': -0.83}
2025-04-12 17:56:25.705 vebus INFO read_snapshot: {'inv_p': -130, 'out_p': -135, 'bat_u': 27.86, 'bat_i': 0.0, 'bat_p': 0, 'soc': 197}
2025-04-12 17:56:25.887 vebus INFO led_light=0x01 led_blink=0x00
2025-04-12 17:56:27.164 vebus INFO {'device_state_id': 8, 'device_state_name': 'bypass', 'mains_u': 238.71, 'mains_i': -0.64, 'inv_u': 238.71, 'inv_i': -0.99}
2025-04-12 17:56:27.387 vebus INFO read_snapshot: {'inv_p': -128, 'out_p': -132, 'bat_u': 27.86, 'bat_i': 0.0, 'bat_p': 0, 'soc': 197}
Wenn ich den Sollwert beispielsweise auf -100W setze, springt der Inverter samt LED an, und es werden zusätzlich zum BKK auf ACout 100W eingespeist.
2025-04-12 18:12:14.655 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:14.899 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 236.74, 'mains_i': -0.48, 'inv_u': 236.74, 'inv_i': -0.06}
2025-04-12 18:12:15.133 vebus INFO read_snapshot: {'inv_p': -102, 'out_p': -33, 'bat_u': 27.85, 'bat_i': -3.6, 'bat_p': -100, 'soc': 196}
2025-04-12 18:12:15.316 vebus INFO led_light=0x14 led_blink=0x01
2025-04-12 18:12:16.317 mp2 DEBUG set_power -100
2025-04-12 18:12:16.431 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:16.676 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 236.74, 'mains_i': -0.8, 'inv_u': 236.74, 'inv_i': 0.26}
2025-04-12 18:12:16.920 vebus INFO read_snapshot: {'inv_p': -105, 'out_p': -36, 'bat_u': 27.84, 'bat_i': -3.4, 'bat_p': -95, 'soc': 196}
2025-04-12 18:12:17.103 vebus INFO led_light=0x14 led_blink=0x01
2025-04-12 18:12:18.104 mp2 DEBUG set_power -100
2025-04-12 18:12:18.217 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:18.471 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 236.74, 'mains_i': -0.48, 'inv_u': 236.74, 'inv_i': -0.06}
2025-04-12 18:12:18.705 vebus INFO read_snapshot: {'inv_p': -100, 'out_p': -33, 'bat_u': 27.86, 'bat_i': -3.6, 'bat_p': -100, 'soc': 196}
2025-04-12 18:12:18.888 vebus INFO led_light=0x14 led_blink=0x01
2025-04-12 18:12:19.888 mp2 DEBUG set_power -100
2025-04-12 18:12:20.001 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:20.245 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 236.74, 'mains_i': -0.8, 'inv_u': 236.74, 'inv_i': 0.17}
2025-04-12 18:12:20.470 vebus INFO read_snapshot: {'inv_p': -102, 'out_p': -35, 'bat_u': 27.84, 'bat_i': -3.3, 'bat_p': -92, 'soc': 196}
2025-04-12 18:12:20.642 vebus INFO led_light=0x14 led_blink=0x01
2025-04-12 18:12:21.643 mp2 DEBUG set_power -100
2025-04-12 18:12:21.768 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:22.002 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 237.73, 'mains_i': -0.8, 'inv_u': 237.73, 'inv_i': 0.17}
2025-04-12 18:12:22.226 vebus INFO read_snapshot: {'inv_p': -98, 'out_p': -36, 'bat_u': 27.83, 'bat_i': -3.3, 'bat_p': -92, 'soc': 196}
2025-04-12 18:12:22.408 vebus INFO led_light=0x14 led_blink=0x01
2025-04-12 18:12:23.410 mp2 DEBUG set_power -100
2025-04-12 18:12:23.524 vebus INFO set_ess_power to -100W done
2025-04-12 18:12:23.769 vebus INFO {'device_state_id': 9, 'device_state_name': 'charge', 'mains_u': 237.73, 'mains_i': -0.8, 'inv_u': 237.73, 'inv_i': 0.17}
2025-04-12 18:12:23.992 vebus INFO read_snapshot: {'inv_p': -95, 'out_p': -34, 'bat_u': 27.84, 'bat_i': -3.3, 'bat_p': -92, 'soc': 196}
2025-04-12 18:12:24.164 vebus INFO led_light=0x14 led_blink=0x01
Was mir allerdings ins Auge fiel, war die fehlenden Ausgabe der MK2 (eigentlich MK3) Versionsnummer
Im Quelltext wird der Port für das MK3 Interface hardcodiert und nicht wie bei dir durch Scannen der USB-Ports gesucht. Im Original steht dort:
# port = '/dev/ttyUSB0'
port = '/dev/serial/by-id/usb-VictronEnergy_MK3-USB_Interface_HQ2132VK4JK-if00-port0'
Zuerst habe ich stumpf das /dev/ttyUSB0 wieder aktiviert und die /dev/serial/by-id Variante auskommentiert, was sofort funktionierte. Dann fiel mir ein, dass ich in einem anderen Zusammenhang (Festplattentausch bei einem RAID) schon einmal über die verschiedenen Möglichkeiten der Referenzierung von devices über symbolische Links bei Linux gestolpert bin. Im Prinzip ist es egal welches Alias man nimmt, aber by-id, by-name etc. gibt einem zusätzliche Info über den device, der eingebunden wurde. Jedenfalls fiel mir auf, dass das MK3 Interface im Beispielcode als ID-String sowohl seine Funktion (VictronEnergy_MK3-USB_Interface) als auch seine Serien/Gerätenummer übermittelt hat. Also habe ich sofort überprüft, was mein MK3-Interface am Laptop so sagt
Und siehe da, dieser Teil fehlt bei meinem MK3.
> ls -alp /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 12. Apr 17:53 ./
drwxr-xr-x 4 root root 80 12. Apr 17:53 ../
lrwxrwxrwx 1 root root 13 12. Apr 17:53 usb-FTDI_FT232EX-if00-port0 -> ../../ttyUSB0
Als Gegenprobe habe ich eins der VE.direct USB-Interfaces gescheckt. Dort ist der Hersteller-String enthalten.
usb-VictronEnergy_BV_VE_Direct_cable_VE8BxxxQ-if00-port0 -> ../../ttyUSB0
Dann fiel mir auch wieder ein, dass ich das vor einigen Tagen schon im boot-log seltsam fand
[ 4.471537] hub 1-1.1:1.0: USB hub found
[ 4.475607] hub 1-1.1:1.0: 3 ports detected
[ 4.574678] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 4.737651] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[ 4.746044] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.753361] usb 1-1.2: Product: VE Direct cable
[ 4.757920] usb 1-1.2: Manufacturer: VictronEnergy BV
[ 4.762978] usb 1-1.2: SerialNumber: VExxxAWO
[ 4.804678] usb 1-1.1.2: new full-speed USB device number 5 using dwc_otg
[ 4.967526] usb 1-1.1.2: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[ 4.976092] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4.983582] usb 1-1.1.2: Product: VE Direct cable
[ 4.988312] usb 1-1.1.2: Manufacturer: VictronEnergy BV
[ 4.993544] usb 1-1.1.2: SerialNumber: VExxxPTQ
[ 5.034683] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
[ 5.180027] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[ 5.188426] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5.195775] usb 1-1.3: Product: FT232EX
[ 5.199618] usb 1-1.3: Manufacturer: FTDI
[ 5.264680] usb 1-1.1.3: new full-speed USB device number 7 using dwc_otg
[ 5.427528] usb 1-1.1.3: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[ 5.436095] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5.443585] usb 1-1.1.3: Product: VE Direct cable
[ 5.448315] usb 1-1.1.3: Manufacturer: VictronEnergy BV
[ 5.453547] usb 1-1.1.3: SerialNumber: VExxxIR7
Alle drei VE.direct USB-Adapter melden als Hersteller VictronEnergy BV und liefern anschliessend ihre Seriennummer, nur das MK3 Interface bleibt als FTDI stecken.
Entweder bin ich da jetzt auf einer ganz heissen Spur, oder ich fange aus lauter Verzweiflung an, USB-Adapter-Verschwörungen zu sehen 
Vielleicht gibt es ja noch den ein oder anderen stillen Mitleser, der eine Raspi/VenusOS Installation mit MK3-Interface hat und über ssh auf dem Raspi mal schauen kann, was ein MK3 Interface normalerweise mitteilt. Einfach ein
ls -alp /dev/serial/by-id
absetzen. Danke im voraus
hallo,
das andere projekt kenne ich noch nicht. dass ich die schnittstellen scanne hat einen ganz einfachen grund: ich stecke auch schon mal was um und habe keine lust, dann jedesmal die konfiguration zu aendern. also soll das system sich die geraete selbst suchen und anhand der seriennummer/produktid zuordnen. es macht eben schon einen unterschied, ob die weniger als 5 eintraege in der config brauchst, oder ueber 30 und dann auch noch das richtige geraet der richtigen schnittstelle zuordnen musst.
da war das mit der vorgabe schnittstelle anfang und anzahl wesentlich praktischer!
also auf meinem cerbo sieht das so aus:
lsusb:
Bus 004 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 003 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
ls -lR /dev|grep -i usb|grep -vE “mon|^/”
crw-rw---- 1 root dialout 188, 0 Apr 13 12:22 ttyUSB0
crw-rw---- 1 root dialout 188, 1 Apr 13 12:22 ttyUSB1
drwxr-xr-x 7 root root 140 Feb 29 2024 usb
lrwxrwxrwx 1 root root 10 Feb 29 2024 188:0 → ../ttyUSB0
lrwxrwxrwx 1 root root 10 Feb 29 2024 188:1 → ../ttyUSB1
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:0 → ../bus/usb/001/001
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:128 → ../bus/usb/002/001
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:256 → ../bus/usb/003/001
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:257 → ../bus/usb/003/002
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:384 → ../bus/usb/004/001
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:385 → ../bus/usb/004/002
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:512 → ../bus/usb/005/001
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:513 → ../bus/usb/005/002
lrwxrwxrwx 1 root root 18 Feb 29 2024 189:514 → ../bus/usb/005/003
lrwxrwxrwx 1 root root 13 Feb 29 2024 usb-VictronEnergy_MK3-USB_Interface_HQ20472GV47-if00-port0 → ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Feb 29 2024 usb-VictronEnergy_MK3-USB_Interface_HQ2245HW3FR-if00-port0 → ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Feb 29 2024 platform-1c14400.usb-usb-0:1:1.0-port0 → ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Feb 29 2024 platform-1c1c400.usb-usb-0:1:1.0-port0 → ../../ttyUSB1
ps |grep -i mk2|grep -v grep
1238 root 1608 S supervise mk2-dbus.ttyS4
1359 root 1752 S multilog t s25000 n4 /var/log/mk2_dbus.ttyS4
1389 root 1608 S supervise mk2-dbus.ttyUSB0
1566 root 1608 S supervise mk2-dbus.ttyUSB1
1625 root 1752 S multilog t s25000 n4 /var/log/mk2_dbus.ttyUSB0
1631 root 3044 S {start-mk2-dbus.} /bin/sh /opt/victronenergy/mk2-dbus/start-mk2-dbus.sh ttyUSB0 PRODUCT=MK3-USB_Interface
1708 root 3624 S /opt/victronenergy/mk2-dbus/mk2-dbus --log-before 25 --log-after 25 --banner -w -s /dev/ttyUSB0 -t mk3 --settings /data/var/lib/mk2-dbus/mkxport-ttyUSB0.settings
1744 root 1752 S multilog t s25000 n4 /var/log/mk2_dbus.ttyUSB1
12114 root 3044 S {start-mk2-dbus.} /bin/sh /opt/victronenergy/mk2-dbus/start-mk2-dbus.sh ttyUSB1 PRODUCT=MK3-USB_Interface
12123 root 3628 S /opt/victronenergy/mk2-dbus/mk2-dbus --log-before 25 --log-after 25 --banner -w -s /dev/ttyUSB1 -t mk3 --settings /data/var/lib/mk2-dbus/mkxport-ttyUSB1.settings
18345 root 3044 S {start-mk2-dbus.} /bin/sh /opt/victronenergy/mk2-dbus/start-mk2-dbus.sh ttyS4 PRODUCT=builtin-mkx
18355 root 3644 S /opt/victronenergy/mk2-dbus/mk2-dbus --log-before 25 --log-after 25 --banner -w -s /dev/ttyS4 -i -t mk3 --settings /data/var/lib/mk2-dbus/mkxport-ttyS4.settings
laeuft bei dir denn das mk2-dbus-programm? wenn nicht, probier es doch mal von hand zu starten.
tschuess
hallo,
ich habe mir das programm mal angesehen. die programmierung in python ist wohl nicht so aufwendig, wie in tcl, aber ob das programm auch direkt unter windows ohne nennenswerte aenderungen laeuft und ich weiss auch nicht, ob python auch eine grafische oberflaeche hat, wie tcl in form von tk.
allerdings gibt es noch einen grossen unterschied zwischen diesem programm und meinem programm. mein programm ist ereignisgesteuert und hat deshalb auch keine probleme, mehrere multis parallel anzusprechen, das geht mit dem python-programm nicht.
aber sobald ich zeit habe, werde ich mir wohl mal python naeher ansehen und als alternative wohl noch rust oder pascal unter linux begutachten.
tschuess
Hi,
Das sollte gar keine Kritik an deinem Programm sein. Natürlich sind hardcodierte Parameter weder flexibel noch komfortabel. Mich hat es einfach auf die (hoffentlich) richtige Spur gebracht, dass ich im Umfeld vom MK3-Adapetr weitersuchen sollte
Phython ist für mich ein Moloch, den ich mit seinen vielen Versionen und Modulen einfach nicht unter Kontrolle bekomme. Ich mag es auch nicht, weil ich eine Syntax brauche, die mir klare Strukturen liefert. Allein der Verzicht auf geschweifte Klammern oder ähnliches bei der Gruppierung von funktionellen Blöcken führt bei mir zu verheerenden debugging-Problemen. Aber das liegt wohl eher an mir. Wenn man sich anschaut, was es mittlerweile an Lösungen in Python gibt…
Übrigens greift das grafische Demo-Programm von martiby auf tkinter zurück, was tatsächlich ein Python-Interface zu tcl/tk ist 
Dann nimm lieber Rust. Ich glaube, da gibt es nichts schnelleres und besser debugbares zur Zeit. Hab es auch mal probiert, aber hab es wieder frustriert aufgegeben, weil ich das Konzept nicht so richtig verinnerlichen konnte.
Pascal ist natürlich auch toll, aber gibt es da überhaupt noch eine Community? Als ich vor 40 Jahren meine ersten Programmierversuche auf dem Mac gemacht habe, war es auf jeden Fall die 1. Wahl. Die strenge Typisierung von Pascal habe ich später in allen Sprachen vermisst.
Aber genug der Schwärmerei von alten Zeiten…
Mein Verdacht ist jetzt einfach, dass sich der MK3 beim Einstöpseln in den USB-Port nicht richtig beim Device-Manager meldet. Ich habe zwar keine Ahnung, was genau wann passiert, aber der Manufacturer-String und auf jeden Fall die VE Seriennummer müssen ja bei der Registrierung am Raspi/Laptop vom MK3 selber kommen. Wie man bei dir schön sehen kann, funktioniert das ja auch normalerweise. Ohne die Seriennummer wird in VictronConnect auch kein Gerät angezeigt. Ich denke also, irgendwas stimmt mit dem MK3-Interface nicht (mehr).
Mein MK3 hat ja durchaus eine Seriennummer, die aber nicht im VenusOS landet
Auf meinem Raspi gibt es auch keinen Prozess, der irgendwas mit mk2 im Namen hat. Wenn ich mir das Bash-Script start-mk2-dbus.sh anschaue, wird dort der Produktname benutzt (das ist wohl der Parameter ‘PRODUCT=MK3-USB_Interface’), um überhaupt weiterzumachen.
Der andere Prozess in deiner Liste, mk2-dbus, will als Parameter ausserdem noch eine settings-Datei, die in /data/var/lib/mk2-dbus/ liegt, haben. Obwohl ich langsam an meine Linux-Grenzen komme, werde ich da mal weiter Forensik betreiben…
ok, der mk2-dbus Service wird wohl vom start-mk2-dbus.sh Shellscript gestartet. Ich habe es also mal mit dem momentanen Port meines MK3 am Raspi (ttyUSB2) und dem Paramater ‘PRODUCT=MK3-USB_Interface’ interaktiv aufgerufen:
root@raspberrypi2:~# /opt/victronenergy/mk2-dbus/start-mk2-dbus.sh ttyUSB2 PRODUCT=MK3-USB_Interface
update: 1
UTC-2025.04.13-16:04:48 Starting mk2-dbus on ttyUSB2
mk2-dbus 3.77
-------- dumping backlog -------
132.245 INF.: < 07 FF 'V 28 DB 11 00 00 90
132.245 INF.mk2fh: rx msg queued
132.947 INF.vebus: mark panel frame
133.548 INF.mk2: ---- get mk2 version ----
133.549 INF.: > 02 FF 'V A9
133.574 INF.fh: new frame
133.606 INF.: < 07 FF 'V 28 DB 11 00 00 90
133.606 INF.mk2fh: rx msg queued
133.606 INF.mk2: reset?
133.606 INF.mk2: ---- get mk3 bootblock revision ----
133.606 INF.: > 03 FF 'B 03 B9
133.638 INF.fh: new frame
133.670 INF.: < 07 FF 'B 03 76 74 03 01 C7
133.670 INF.mk2fh: rx msg queued
133.670 INF.mk2: MK3 boot block revision 3 detected
133.670 INF.mk3: ---- Set panel detect and standby line levels ----
133.700 INF.: > 03 FF 'H 00 B6
133.734 INF.fh: new frame
133.750 INF.: < 03 FF 'H 00 B6
133.750 INF.mk2fh: rx msg queued
133.750 INF.mk3: --- Set panel detect and standby line levels 0x0
133.750 INF.mk2: ---- get MK2 settings ----
133.750 INF.: > 02 FF 'D BB
133.782 INF.fh: new frame
133.942 INF.vebus: mark panel frame
134.094 ERR.mk2fh: rx timeout
134.745 WRN.mk2_fh: mk2 no reply
134.745 INF.: > 02 FF 'D BB
134.946 INF.vebus: mark panel frame
135.748 WRN.mk2_fh: mk2 no reply
135.748 INF.: > 02 FF 'D BB
135.949 INF.vebus: mark panel frame
136.751 WRN.mk2_fh: mk2 no reply
136.751 INF.: > 02 FF 'D BB
136.951 INF.vebus: mark panel frame
137.743 WRN.mk2_fh: mk2 no reply
137.744 INF.: > 02 FF 'D BB
137.944 INF.vebus: mark panel frame
138.746 WRN.mk2_fh: mk2 no reply
138.746 INF.mk2: timeout
138.746 WRN.vebus_items: no device associated with item, refusing to update!
138.746 INF.control: resuming panel frames
138.746 WRN.vebus_items: no device associated with item, refusing to update!
138.796 INF.control: resuming panel frames
138.847 INF.vebus: mark panel frame
139.849 INF.vebus: mark panel frame
140.451 INF.mk2: ---- get mk2 version ----
140.451 INF.: > 02 FF 'V A9
140.843 INF.vebus: mark panel frame
141.445 WRN.mk2_fh: mk2 no reply
141.445 INF.: > 02 FF 'V A9
In dem PDF, was du mir oben verlinkt hast, heisst es
Im Log kann man die get mk2 version Versionsabfragen (V) schön sehen, und der MK3 antwortet auch darauf. Wenn ich die ersten 4 byte als INT32 interpretiere, kommt da dezimal 1170216 raus, was wohl stimmen dürfte. Danach macht er weitere Anfragen, aber irgendwann scheitert er, weil er keine Antwort bekommt. Ab da geht das in einer Endlosschleife immer wieder von vorne los. Ich hänge mal einen etwas längeren Auszug an. Du kannst da bestimmt mehr draus ablesen als ich.
start-mk2-dbus.txt (23,5 KB)
Was ich nicht verstehe sind diese ‘panel’ Abfragen. Wovon ist da die Rede? Von einem Bedien-Panel oder Display? Beides habe ich nicht
hallo,
da geht es um das digitalcontrol 200 mit dem der multi gesteuert werden kann. die abfrage kann man aber abschalten, wenn man beim mk2/3 einen jumper umsetzt.
an dem symlink musst du dich nicht stoeren, ich habe einen cerbo gx im einsatz.
probier doch einmal, das programm so zu starten, wie es vom system gestartet wird:
supervise mk2-dbus.ttyO5
vieleicht funktioniert es ja dann. wenn veconfig den mk3 findet, sollte das venus-os ihn ja auch finden.
ich habe zwar einen pi3 mit venus-os, aber mit dem kann ich es jetzt auch nicht testen, da mit kein multi dafuer zur verfuegung steht, die muessen aktuell alle arbeiten.
allerdings ist noch ein multi mit cerbo in planung.
haeng den mk3 mal an einen windows-pc und starte veconfig. ich habe den verdacht, dass das commando D etwas mit einem update zu tun hat und da gibt es wohl probleme. mir ist es auch nie gelungen, einen mk2 mit veconfig unter linux zu updaten, der update wurde immer abgebrochen. bei mir war der mk2 dann erst wieder ansprechbar, nachdem er aktualisiert wurde. es kann natuerlich sein, dass er durch einen spannungsreset auch wieder benutzbar wird.
leider finde ich zu diesem befehl auch nichts im handbuch. aber D duerfte wohl fuer download stehen!
was die programmiersprache fuer meine programme angeht, da ueberlege ich schon seit einiger zeit, die auf rust umzustellen. aktuell liegt die systemlast jedenfalls bei durchschnittlich fast 50% und das ist dit hitliste der prozesse:
2078593 mysql 20 0 3106236 1.2g 0 S 64.7 16.7 800670:48 mysqld
3773960 root 20 0 36976 18208 7380 R 42.9 0.2 7635:01 vedirec+
3897179 nodered 20 0 10.1g 1.1g 13136 S 30.7 15.3 6157:01 node-red
4150145 root 20 0 33056 14276 7244 R 16.5 0.2 3525:11 inverte+
3773656 root 20 0 32484 13432 7492 S 10.9 0.2 2103:43 mqtt.tcl
es ist also noch genug reserve vorhanden, so dass es da mit einer umstellung nicht eilt! aber wenn alles laeuft, wie geplant, kommen dieses jahr noch mehrere bms dazu. und da mir das beim 48V-system inzwischen zuviele kleine portserver sind, werde ich dort wohl einen 16-port-server installieren, das minimiert auch den verkabelungsaufwand. selbst ein 4-port waere jedenfalls schon zu klein und 8-port habe ich nicht.
mal sehen, wo ich eine trennung brauche und wo nicht.
tschuess
Ich habe mich jetzt doch nochmal in die Tiefen von udev vorgearbeitet. Zunächst das, was der Devicemanager von ttyUSB2 (momentan der MK3-Adapter) zu wissen glaubt
root@raspberrypi2:~# udevadm info --name=/dev/ttyUSB2
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB2/tty/ttyUSB2
N: ttyUSB2
S: serial-starter/ttyUSB2
S: serial/by-id/usb-FTDI_FT232EX-if00-port0
S: serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
E: DEVLINKS=/dev/serial-starter/ttyUSB2 /dev/serial/by-id/usb-FTDI_FT232EX-if00-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
E: DEVNAME=/dev/ttyUSB2
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB2/tty/ttyUSB2
E: ID_BUS=usb
E: ID_MODEL=FT232EX
E: ID_MODEL_ENC=FT232EX
E: ID_MODEL_FROM_DATABASE=Bridge(I2C/SPI/UART/FIFO)
E: ID_MODEL_ID=6015
E: ID_PATH=platform-3f980000.usb-usb-0:1.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_3_1_0
E: ID_REVISION=1000
E: ID_SERIAL=FTDI_FT232EX
E: ID_TYPE=generic
E: ID_USB_DRIVER=ftdi_sio
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_VENDOR_ID=0403
E: MAJOR=188
E: MINOR=2
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=11196232550
E: VE_SERVICE=vedirect:default
Wie gehabt listet er als Vendor nicht etwa Victron, sondern den Hersteller des seriellen Wandlerchips FTDI. Und anstatt der Victron-Seriennummer kommt FTDI_FT232EX. Der letzte Punkt ist noch interessant: als VE-Service wird dort verdirect-default angegeben.
Zum Vergleich einer der tatsächlichen VE.direct Dongle auf ttyUSB3
root@raspberrypi2:~# udevadm info --name=/dev/ttyUSB3
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/ttyUSB3/tty/ttyUSB3
N: ttyUSB3
S: serial-starter/ttyUSB3
S: serial/by-id/usb-VictronEnergy_BV_VE_Direct_cable_VE91WIR7-if00-port0
S: serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0
E: DEVLINKS=/dev/serial-starter/ttyUSB3 /dev/serial/by-id/usb-VictronEnergy_BV_VE_Direct_cable_VE91WIR7-if00-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0
E: DEVNAME=/dev/ttyUSB3
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/ttyUSB3/tty/ttyUSB3
E: ID_BUS=usb
E: ID_MODEL=VE_Direct_cable
E: ID_MODEL_ENC=VE\x20Direct\x20cable
E: ID_MODEL_FROM_DATABASE=Bridge(I2C/SPI/UART/FIFO)
E: ID_MODEL_ID=6015
E: ID_PATH=platform-3f980000.usb-usb-0:1.1.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_1_3_1_0
E: ID_REVISION=1000
E: ID_SERIAL=VictronEnergy_BV_VE_Direct_cable_VE91WIR7
E: ID_SERIAL_SHORT=VE91WIR7
E: ID_TYPE=generic
E: ID_USB_DRIVER=ftdi_sio
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=VictronEnergy_BV
E: ID_VENDOR_ENC=VictronEnergy\x20BV
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_VENDOR_ID=0403
E: MAJOR=188
E: MINOR=3
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=10398238
E: VE_SERVICE=vedirect
Beim VE.direct Adapter taucht also als Vendor “VictronEnergy_BV” und als ID_SERIAL der String “VictronEnergy_BV_VE_Direct_cable_VE91WIR7” auf. Die eigentliche Seriennummer gibt es dann nochmal unter ID_SERIAL_SHORT. Und der VE_SERVICE ist hier nur “vedirect” ohne die “:default” Ergänzung. Das bestärkt mich in der Vermutung, dass der MK3-Adapter irgendwo in der Kette der Gerätezuordnungen seine Identität nicht richtig weitergibt. Der udev Dienst verwaltet die Gerätedateien und Symlinks unter /dev ja dynamisch nach Regeln. VenusOS auf dem Raspi hat offenbar die Standardregeln unter /lib/udev/rules.d/ liegen und die spezielleren unter /etc/udev/rules.d/. Also habe ich einfach mal nach Regeln gesucht, die MK3 enthalten
grep -r 'MK3' /etc/udev/rules.d/
/etc/udev/rules.d/serial-starter.rules:ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="MK3-USB_Interface", ENV{VE_SERVICE}="mkx"
Die letzten Zeilen in serial-starter.rules sind hier aufschlussreich:
# VE.Direct cable should have a specific model-id, if not set it is a FT232EX.
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="VE_Direct_cable", ENV{VE_SERVICE}="vedirect"
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="FT232EX", ENV{VE_SERVICE}="vedirect:default"
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="MK3-USB_Interface", ENV{VE_SERVICE}="mkx"
In der zweiten Anweisung sieht man, wieso mein MK3-Adapter in der VE_SERVICE Zuweisung bei verdirect:default landet. Alle usb Geräte, die “FT232EX” als ID_MODEL haben, landen dort.
Voraussetzung, um als VE_SERVICE “mkx” zugewiesen zu bekommen, ist der String “MK3-USB_Interface”, den mein MK3-Dongle aus welchen Gründen auch immer nicht liefert. Deshalb wird die letzte Regel nicht auf meinen MK3-dongle angewendet.
Jetzt ist eine lange Nacht und ein ganzer Vormittag vergangen, und ich habe aus purer Verzweiflung hemmungslos jede Menge Sachen ausprobiert. Irgendwann hat sich der MP2 im VRM und in der Remote Console zurückgemeldet, ohne dass ich es sofort mitbekommen habe. Ich kann jetzt nur meine Schritte zusammenfassen, von denen ich glaube, dass sie möglicherweise dazu geführt haben. Das ist etwas unbefriedigend, und ich kann es auch nicht wirklich als Lösung für andere präsentieren, die mal auf dasselbe Problem stossen. Nun denn…
# VE.Direct cable should have a specific model-id, if not set it is a FT232EX.
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="VE_Direct_cable", ENV{VE_SERVICE}="vedirect"
# ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="FT232EX", ENV{VE_SERVICE}="vedirect:default"
# eigene Definition als MK3 Dongle
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="FT232EX", ENV{ID_MODEL}="MK3-USB_Interface",ENV{ID_SERIAL}="VictronEnergy_BV_MK3-USB_Interface_HQ2311GEEJJ",ENV{ID_VENDOR}="VictronEnergy_BV",ENV{ID_SERIAL_SHORT}="HQ2311GEEJJ",ENV{ID_VENDOR_ENC}="VictronEnergy\x20BV",ENV{ID_MODEL_ENC}="MK3-USB\x20Interface"
ACTION=="add", ENV{ID_BUS}=="usb", ENV{ID_MODEL}=="MK3-USB_Interface", ENV{VE_SERVICE}="mkx"
Also die Zuordnung von “FT232EX” auf den Service “vedirect:default” auskommentiert und stattdessen eine neue Zuordnung als “MK3-USB_Interface” inklusive der ID_VENDOR, ID_SERIAL etc. eingefügt. Das ist jedoch nicht alles auf einmal passiert. Zwischendurch immer mal den Adapter ab- und wieder angestöpselt und mit udevadm test /dev/ttyUSB2 nachgesehen, ob die rules eingelesen werden.
usb-FTDI_FT232EX-if00-port0 -> ../../ttyUSB2 mit usb-VictronEnergy_MK3-USB_Interface_HQ2311GEEJJ-if00-port0 -> /dev/ttyUSB2 Die Bezeichnung habe ich aus deinen Angaben und der aufgeklebten Seriennummer meines MK3 zusammengebastelt.Momentan sieht der ttyUSB2 device also so aus
root@raspberrypi2:~# udevadm info --name=/dev/ttyUSB2
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB2/tty/ttyUSB2
N: ttyUSB2
S: serial-starter/ttyUSB2
S: serial/by-id/usb-FTDI_FT232EX-if00-port0
S: serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
E: DEVLINKS=/dev/serial-starter/ttyUSB2 /dev/serial/by-id/usb-FTDI_FT232EX-if00-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
E: DEVNAME=/dev/ttyUSB2
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB2/tty/ttyUSB2
E: ID_BUS=usb
E: ID_MODEL=MK3-USB_Interface
E: ID_MODEL_ENC=MK3-USB\x20Interface
E: ID_MODEL_FROM_DATABASE=Bridge(I2C/SPI/UART/FIFO)
E: ID_MODEL_ID=6015
E: ID_PATH=platform-3f980000.usb-usb-0:1.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_3_1_0
E: ID_REVISION=1000
E: ID_SERIAL=VictronEnergy_BV_MK3-USB_Interface_HQ2311GEEJJ
E: ID_SERIAL_SHORT=HQ2311GEEJJ
E: ID_TYPE=generic
E: ID_USB_DRIVER=ftdi_sio
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=VictronEnergy_BV
E: ID_VENDOR_ENC=VictronEnergy\x20BV
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_VENDOR_ID=0403
E: MAJOR=188
E: MINOR=2
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=327513660822
E: VE_SERVICE=mkx
Die Symlinks/Pfade wurden zwar wieder überschrieben, aber zumindest die geänderten Attribute hat er bekommen und behalten. Wobei ich noch keinen Neustart riskiert habe
Wie erwähnt, hat der Raspi sich dann irgendwann heimlich entschlossen nach neuen vebus-Geräten zu scannen und dann von selber auch einen mk2-dbus service gestartet.
root@raspberrypi2:~# ps | grep -i mk2
7014 root 1608 S supervise mk2-dbus.ttyUSB2
7029 root 1620 S multilog t s25000 n4 /var/log/mk2_dbus.ttyUSB2
24692 root 2692 S grep -i mk2
32274 root 3044 S {start-mk2-dbus.} /bin/sh /opt/victronenergy/mk2-dbus/start-mk2-dbus.sh ttyUSB2 PRODUCT=MK3-USB_Interface
32283 root 3548 S /opt/victronenergy/mk2-dbus/mk2-dbus --log-before 25 --log-after 25 --banner -w -s /dev/ttyUSB2 -t mk3 --settings /data/var/lib/mk2-dbus/mkxport-ttyUSB2.settings
Die VRM Anzeige ist wieder wie gewohnt 
hallo,
das problem ist nicht udev oder der name des symlinks, das problem liegt daran, dass der mk3 nicht auf das Kommando “D” reagiert. leider wird dieses kommando nicht in der doku erwaehnt, aber ich vermute, dass es fuer download steht und das wuerde bedeuten, dass das system wohl versucht, einen firmware-update durchzufuehren.
wenn du die moeglichkeit hast, den mk3 mal an ein gx anzuschliessen, solltest du das mal probieren!
tschuess
Ein paar Kleinigkeiten sind noch nicht wie vorher, beispielsweise bei den DVCC Einstellungen. Ich habe den mitgelieferten Temperaturfühler am MP2 angeschlossen, und der wurde auch als STS gefunden. Jetzt sieht er ihn nicht mehr.
Ich meine mich auch zu erinnern, dass SCS vorher nicht auf externer Kontrolle war, bin mir aber nicht 100% sicher.
Aber ich bin schonmal hochzufrieden, dass ich den Akku/Inverter überhaupt wieder nutzen kann. @d_ferdi Dir jedenfalls vielen Dank für deine Hilfe. Und für deinen Optimismus, dass man da selber was drehen kann. Sonst hätte ich es viel früher drangegeben.
hallo,
bei mir sieht das log so aus:
@40000000679227d9018aeb9c -------- dumping backlog -------
@40000000679227d9018af36c 002.008 INF.fh: new frame
@40000000679227d9018afb3c 002.008 INF.: < 03 FF 'H 01 B5
@40000000679227d9018b030c 002.008 INF.mk2fh: rx msg queued
@40000000679227d9018b0adc 002.008 INF.mk3: — Set panel detect and standby line levels 0x1
@40000000679227d9018b1694 002.008 INF.mk2: ---- get MK2 settings ----
@40000000679227d9018b1e64 002.008 INF.: > 02 FF 'D BB
@40000000679227d9018b2634 002.090 INF.fh: new frame
@40000000679227d9018d0e7c 002.090 INF.: < 0A FF 'D 03 00 10 01 64 3E 0B 00 F2
@40000000679227d9018d1a34 002.090 INF.mk2fh: rx msg queued
und auf die anweisung:
02 FF 'D BB
kommt bei dir keine antwort, bei mir kommt das:
0A FF 'D 03 00 10 01 64 3E 0B 00 F2
und leider habe ich keine ahnung, was das bedeutet weil diese kommando im protokollhandbuch nicht vorkommt!
aber das ist genau die stelle, bei der bei dir die erkennung fehlschlaegt!
komisch ist nur, dass es mit veconfig keine probleme gibt. wie sieht es da mit victronconnect aus?
im zweifelsfall muss dein mk3 einen zwangsupdate bekommen. ob das ueber veflash geht, weiss ich aber nicht!
ich versuche mal was herrauszufinden.
tschuess
Hi,
welches log ist das? Bei mir sieht /var/log/mk2_dbus.ttyUSB2/current | tai64nlocal so aus:
2025-04-16 08:03:32.572784500 -------- dumping backlog -------
2025-04-16 08:03:32.572790500 017.961 INF.: > 05 FF 'Y 30 85 00 EE
2025-04-16 08:03:32.572797500 017.992 INF.fh: new frame
2025-04-16 08:03:32.572802500 017.992 INF.: < 07 FF 'Y 85 1F 0C 3F 5D 55
2025-04-16 08:03:32.572808500 017.992 INF.mk2fh: rx msg queued
2025-04-16 08:03:32.572814500 017.992 INF.mk2: ++++ got ramvar 133 value 3103 ----
2025-04-16 08:03:32.572817500 017.992 INF.mk2: periodic msg is done 99
2025-04-16 08:03:32.572820500 =========================================================
2025-04-16 08:03:32.573025500 017.992 INF.mk2: next action 33
2025-04-16 08:03:32.573030500 017.992 INF.task: device was done, checking other devices
2025-04-16 08:03:32.573038500 017.992 INF.task: nothing other to do
2025-04-16 08:03:32.573044500 017.992 INF.mk2: do next action 33
2025-04-16 08:03:32.573049500 017.992 INF.Periodic Action: MK2_ACT_GET_IGNORE_AC_INPUT_STATE
2025-04-16 08:03:32.573058500 017.992 INF.Periodic Action: MK2_ACT_GET_BATTERY_CAPACITY
2025-04-16 08:03:32.573102500 017.992 INF.mk2: get setting 64 from 0
2025-04-16 08:03:32.573107500 017.992 INF.: > 05 FF 'Z 31 40 00 31
2025-04-16 08:03:32.573110500 018.041 INF.fh: new frame
2025-04-16 08:03:32.573112500 018.041 INF.: < 05 FF 'Z 86 CC 00 50
2025-04-16 08:03:32.573115500 018.041 INF.mk2fh: rx msg queued
2025-04-16 08:03:32.573118500 018.041 INF.mk2: periodic msg is done 102
2025-04-16 08:03:32.573123500 =========================================================
2025-04-16 08:03:32.573193500 018.041 INF.mk2: next action 100
2025-04-16 08:03:32.573196500 018.041 INF.task: device was done, checking other devices
2025-04-16 08:03:32.573200500 018.041 INF.task: nothing other to do
2025-04-16 08:03:32.573203500 018.041 INF.mk2: do next action 100
2025-04-16 08:03:32.573303500 018.041 INF.Periodic Action: MK2_ACT_SOC
2025-04-16 08:03:32.573307500 018.041 INF.mk2: ---- get ramvar 13 from 0 ----
2025-04-16 08:03:32.573313500 018.084 INF.: > 05 FF 'X 30 0D 00 67
2025-04-16 08:03:32.573318500 018.233 ERR.serial: Ready for reading but read 0 bytes. Device removed?
2025-04-16 08:03:32.573325500 018.233 ERR.serial: serial error -> exiting the application!
2025-04-16 08:03:32.573332500 018.233 INF.task: done in 018.233
2025-04-16 08:03:32.594601500 /opt/victronenergy/serial-starter/run-service.sh: line 15: kill: (7040) - No such process
2025-04-16 10:07:05.386234500 *** starting mk2-dbus ***
2025-04-16 10:07:05.436525500 update: 1
2025-04-16 10:07:05.458970500 mk2-dbus 3.77
Um 10:07 Uhr ist er dann wohl einfach gestartet. Die vorletzte Zeile könnte für deine Vermutung sprechen. Allerdings habe ich den Dongle in den letzten Tagen ja mehrmals an VEConfig hängen gehabt. Da sollte doch gleich zu Anfang die Meldung kommen, dass einen neue Firmware für den MK3 verfügbar ist
hallo,
manchmal ist man wirklich blind: es steht doch als info da, mit dem befehl ruft man die einstellungen des mk2/3-adapters ab und deiner liefert die einfach nicht.
also hat das teil ne macke oder braucht eben den zwangsupdate!
ich konnte leider die firmware fuer den mk3 nicht finden, den update macht wohl nur victronconnect oder veconfig/systemconfig.
wie alt ist denn das teil, probier doch mal, es umzutauschen! dass es an der verbindung zum mk3 liegt, glaube ich nicht, da er ja auf andere befehle reagiert!
tschuess
hallo,
das mit dem update stimmt, veconfig und systemconfig oder auch quickconfig machen einen update sobald eine neue firmware existiert.
funktioniert es denn jetzt wieder? mein programm gibt ja auch die versionsnr der mk2/3 aus, wenn ich das richtig in erinnerung habe.
wenn es der mk3 jetzt aktualisiert wurde, dann war es wohl ein firmware-fehler, der zu dem problem gefuehrt hat.
auf jeden fall scheint er heute ja mal funktioniert zu haben.
aber gegen 8:3 gabs dann wohl ein kommunikationsproblem, hast du ihn da abgezogen?
oder hast du ein problem mit deinem usb-bus?
tschuess
Meine Rede 
Unter updates.victronenergy.com finde ich auch nichts. Die momentane Version ist ja 1170216, und mit 1170xxx gibt es keine .vff files. Die remote console zeigt es jetzt übrigens auch wieder an
Theoretisch gäbe es ein Tool auf VenusOS selber, nennt sich vbdup und liegt in /usr/bin/
root@raspberrypi2:~# vbdup --help
vbdup version 1.14
Vebus device firmware updater.
Supported products:
-MK3
-Multi/Quattro versions 26xxyyy/27xxyyy
where yyy >= 2xx
A BMS and/or DMC should not be connected to the Ve.Bus.
These devices do not support blocking mode in order to stay silent on the VeBus during updates.
WARNING:
Updating will reset any user defined settings to default!
If you want to keep your settings you must use VeConfigure, local or remote, to readout and save the settings.
After updating, you can use VeConfigure again to restore the settings.
Firmware updates currently do not work through the dbus tunnel. Please close the mk2-dbus before using this feature
Aber ohne firmware file geht da nichts. Eine Beschreibung von vbdup findest duch auch in Victrons github unter dem Punkt 3.2
hab ich zusammen mit dem MP2 gekauft, also 11/24. Halt von einem Online-Händler, der vermutlich kein Victron-Vertragshändler ist 
Noch läuft es, aber wer weiss wie lange
ich habe nichts aktiv aktualisiert, automatische Updates sind auch nicht aktiviert. Ich wüsste also nicht, woher der MK3 ein Update herbekommen haben sollte.
unwahrscheinlich, da VictronConnect auf dem Laptop mit Windows oder Linux den MK3/MP2 auch nicht erkennt. Am Raspi habe ich die USB-Ports mehrfach gewechselt, und die VE.direct USB-Adapter funktionieren ja auch einwandfrei.
hallo,
im letzten log, das du hochgeladen hast, steht aber etwas von einem update. vieleicht wurde einfach die aktuelle firmware nochmal installiert. da du ja kein log vom kompletten datenverkehr hast, laesst sich das nachtraeglich nicht mehr feststellen.
ist wie bei dem mp2 24/5000 den ich mal hier hatte. der lies sich weder einschalten noch ansprechen, ausser mit veflash, da konnte ich die aktuelle firmware installieren und danach hat er wieder funktioniert.
na dann beobachte das mal weiter, manchmal verhaellt sich die technik einfach nicht so, wie sie sollte. damit habe ich schon jede menge erfahrung gesammelt!
am schlimmsten ist es, wenn es so aussieht, als wuerde alles funktionieren, es das aber nicht macht!
tschuess