Multiplus II 24/3000 nicht mehr steuerbar/sichtbar

Hallo,
mir ist vorgestern mitten im Betrieb und ohne Änderungen am Gesamtsystem mein MP2 abhanden gekommen. Damit meine ich, dass das Gerät als device nicht mehr vom VenusOS “gesehen” wird, also aus der Liste der dbus devices verschwunden ist und im VRM Portal als “aus” bezeichnet wird.

Meine Konfiguration ist ein kleines ESS mit einem MP II 24/3000, einem “Balkonkraftwerk” über AC-out, zwei MPPT Ladereglern, einem 2s Bleiakku und einem SmartShunt. Alles (bis auf den Akku) von Victron. VenusOS 3.54 auf einem Raspi kommuniziert mit den Ladereglern und dem Shunt jeweils über einen VE-direct US-Adapter (ebenfalls original VE) und mit dem MP II über ein MK3-USB Interface.
Das System lief jetzt seit einigen Wochen/Monaten stabil, und ich habe nur hin und wieder die Parameter in der Remote Console etwas angepasst. Letzten Freitag habe ich dann mitbekommen, dass die VRM-Anzeige plötzlich etwas wirr wurde und der Akku nicht mehr eingespeist hat. Ich kann gerne noch Details meiner Konfiguration nachreichen, aber akut frage ich mich, wie ich feststellen kann, an welcher Komponente es liegt. MP2, MK3-Interface oder Raspi/VenusOS. Ein paar Dinge habe ich probiert.

MP2: an/aus, komplett vom Strom und Akku trennen. Nach dem Anschalten zeigt es zunächst eine grüne Inverter LED oben rechts, und nachdem die Relais Tests durch sind, erlischt die Inverter LED und auf der linken Seite geht die Mains-LED auf grün. Sonst keine Anzeigen am Gerät.

MK3 Interface: Über Notebook mit entweder Windows oder Linux VEConfigure und VictronConnect probiert. VEConfigure erkennt das Interface und den MP2. Augenscheinlich lässt sich alles konfigurieren und sichern. VictronConnect erkennt weder unter Windows, noch unter Linux den MP2, sprich er wird nicht gelistet. Unter Linux werden aber alle anderen Victron Geräte via Bluetooth angezeigt. Unter Windows wird nur der Raspi angezeigt (weil Bluetooth Kommunikation über VictronConnect mit Windows nicht funktioniert, habe ich irgendwo gelesen). Patchkabel zwischen MK3 und MP2 ausgetauscht.

VenusOS: natürlich mehrere Neustarts, USB Port vom MK3-Interface gewechselt. Von der 3.54 auf ein 3.42 Backup gewechselt. Mit dbus-spy und dbus -y die devices gelistet. Mit lsusb nach dem MK3 gesucht (ist zumindest auf der device Ebene da, als ttyUSB0, bzw. ttyUSB3 nach Portwechsel).

Was kann ich weiter probieren? Gibt es weitere Checks, die ich auf der VenusOS/Raspi Seite machen kann? Ich habe versucht, auf dem Port zu lauschen, der vom MK3-Interface belegt wird. Da kommen auch regelmässig ein paar Bytes rein (hex 80 00 80 00 00…), aber ich habe keine Ahnung, ob die seriellen Einstellungen für den Port stimmen.
Hat jemand Vorschläge für mich, wie ich das Problem eingrenzen kann?
Danke euch für Vorschläge

hallo,
also das problem kenne ich noch nicht. allerdings hatte ich mal einen mp2, der sich nicht mehr einschalten liess und auch unter venusos nicht erkannt wurde. auch veconfig konnte nicht darauf zugreifen.

ich habe mit veflash einen firmware-update gemacht, danach ging alles wieder. dabei wird aber die komplette konfiguration geloescht, es macht also sinn, sie vorher zu sichern, wenn das noch geht!

manchmal spinnt die technik einfach und keiner weiss warum! manchmal steht ihr aber auch nur ein bit im weg, von dem sie selbst nicht weiss, welches!

und es stimmt bluetooth, windows und victronconnect vertragen sich leider nicht!

tschuess

Hallo Dieter,
danke für’s Antworten. Ich habe auch schon überlegt, ob ich dem MP2 ein reset auf Werkseinstellungen gönnen soll. Das Auslesen der Konfiguration über VEConfig funktioniert ja noch, aber es wäre auch kein Drama nochmal frisch anzufangen. Einige Sachen würde ich sowieso ändern wollen. Beispielsweise ist die Batterieüberwachung auf dem MP2 noch aktiviert. Da ich später einen SmartShunt nachgerüstet habe, könnte ich das z.B. auch deaktivieren.
Schlimmer kann es auch nicht werden, weil der MP2 in diesem Zustand auch keine Funktion mehr für mein System hat. Ohne ESS wird weder vom Akku eingespeist, noch der Akku zusätzlich vom PV-Wechselrichter an AC-Out geladen.
Da ich den MP2 erst letztes Jahr im November gekauft habe, möchte ich nur wissen, ob ich da einen Garantiefall draus machen kann/muss, oder ob der MP2 eigentlich ok ist und nur das MK3 Interface spinnt. Von der Firmware müsste er eigentlich auf dem letzten Stand sein. Vor einigen Wochen wollte Victron Connect bei der Verbindung ein Update aufspielen. Ich erinnere mich aber nicht, welche Version das war. Vielleicht steht das ja auch irgendwo bei den ausgelesenen Parametern von VEConfig drin. Ich schau morgen mal…

hallo,
das kannst du mit veconfig abfragen. du kannst natuerlich einen garantiefall daraus machen, aber einen firmware-update einzuspielen, selbst wenn es die gleiche version ist, kann sich trotzdem lohnen. denn bei einem firmware-update wird er auf werkseinstellungen zurueckgesetzt, also alle einstellungen geloescht, auch die bits, die ihm im hals stecken.

das dauert zwar ein paar minuten, geht aber immer noch schneller, als einpacken und wegschicken und warten, bis er wieder kommt oder du ersatz bekommst.

am mk3 duerfte es wohl eher nicht liegen, sonst wuerde es auch mit veconfig nicht funktionieren. normalerweise muesste er auch automatisch eingeschaltet werden, wenn du veconfig startest. da er aber nicht angeht, kann es eben nur noch ein firmware-problem sein oder der inverter selbst muesste defekt sein.

tschuess

Hi,
ich habe den MP2 heute morgen resettet (noch bevor ich deine Antwort gesehen habe), leider ohne Erfolg. Ich war etwas irritiert, weil das Passwort zum Zugriff auf die geschützten Einstellungen nicht funktioniert hat. Wahrscheinlich soll man das hier nicht reinschreiben, aber es ist ja im Netz nicht so schwer zu finden.
Als Firmware Version habe ich mit VEConfig die 2611552 (13.06.24) ausgelesen. Das ist laut der Victron Downloadseite nicht letzte Version. Dort gibt es noch eine 2611556.vff Datei mit Datum 18.03.25. Aber natürlich habe ich keine Ahnung, wie Victron die firmware Dateien für die verschiedenen Geräte benennt.
Über VEFlash habe ich immer nur die Info gelesen, dass man es nicht mehr benutzen soll, sondern stattdessen VictronConnect. In meinem Fall bringt das natürlich nichts, weil ich damit den MP nicht reinbekomme. Also werde ich das gleich mal angehen und später berichten.
Eine Sache hat mich heute morgen beim Blick auf den VE-Bus Monitor in VEConfig noch irritiert. Dort gibt es die Frequenzanzeige für In und Out, was sich vermutlich auf AC-In und AC-Out bezieht. Jedenfalls blieb Freq.In stabil auf 50.1 Hz, während Freq.Out immer zwischen 49.9 und 50.1 Hz hin und her wechselte. Ist das normal? Ich habe ja keine wirkliche Ahnung von der Sache. Mir ist klar, dass der MP2 auf AC-out Seite sein eigenes Grid aufbauen kann, um im Falle eines Stromausfalls auf AC-In Seite den netztparallelen PV-Inverter auf AC-Out bei Laune zu halten. Aber sind es tatsächlich zwei unabhängige Grids, die permanent aufrechterhalten werden? Frage jetzt nur aus Neugierde.

hallo,
der multi baut nur dann sein eigenes grid auf, wenn das netz fehlt, ansonsten hast du das netz als grid.

dass die frequenzanzeige abweicht, kann passieren, vor allem auch, weil die messungen nicht gleichzeitig, sondern nacheinander erfolgen und manchmal habe ich auch das gefuehl, dass die messung im multi wesentlich stoeranfaelliger ist als die messung eines zaehlers oder eines anderen frequenzmessers.

was veflash angeht, da muss man sich selbst die firmware-datei besorgen oder vom haendler besorgen lassen, bei victronconnect oder dem vrm wird automatisch die richtige firmware gesucht. allerdings kann man die alten multis auch nicht ueber das vrm und das gx updaten.

aber im notfall geht leider nur noch veflash!

tschuess

Die firmware files habe ich im download bei Victron gefunden. Ich habe einmal die Version probiert, die schon auf dem MP2 drauf war, und dann noch die neue Version. Die neue Version scheint irgendwelche Voraussetzung für §14a Energiewirtschaftsgesetz mitzubringen - für mich momentan nicht relevant.
image
Das Flashen hat funktioniert, wobei ich mir nicht sicher war, was mit “Multi Compact” Geräten gemeint ist, bei denen man vorher vom Netz trennen soll. Ist das eine alte Bezeichnung?
Tja, danach habe ich es sowohl mit Aufspielen der letzten gesicherten Einstellung probiert, als auch mit völlig neu eingestellten Parametern nach Reset. Es hat nichts verändert. Der Raspi sieht den MP2 einfach nicht. Und auch in VictronConnect (Windows) zeigt er mir nur den Raspi/VenusOS an. Nur zur Sicherheit, dass ich nicht was völlig blödes mache: VictronConnect sollte den MP2 anzeigen, wenn der über das MK3 am Notebook hängt, oder? Unter Windows zeigt er die Laderegler und den Shunt ja erst an, wenn man sich mit dem Raspi verbindet. Allerdings habe ich auch in der Variante mit MK3 am Raspi nichts gesehen.

hallo,
wenn du den mk3 an einen windows-pc haengst, sollte victronconnect den multi auch anzeigen.

schau mal noch, ob dieser dienst laeuft:
root@einstein:~# ps |grep -i vebus
980 root 1608 S supervise dbus-vebus-to-pvinverter
994 root 22792 S {dbus_vebus_to_p} /usr/bin/python3 -u /opt/victronenergy/dbus-vebus-to-pvinverter/dbus_vebus_to_pvinverter.py
999 root 1620 S multilog t s25000 n4 /var/log/dbus-vebus-to-pvinverter

der ist wohl fuer die kommunikation mit dem multi zustaendig. jedenfalls benutzt der bei mir die schnittstelle, an der der multi haengt.

so kannst du ins logfile reinsehen:
less /var/log/dbus-vebus-to-pvinverter/current

was mich wundert, ist dass das geraet wohl funktioniert, aber trotzdem nicht erkannt wird. ich kann dir auch gerne noch ein script geben, das mir die daten des systems anzeigt.

tschuess

Der Dienst läuft wohl

root@raspberrypi2:~# ps | grep -i vebus
 1051 root      1608 S    supervise dbus-vebus-to-pvinverter
 1080 root     22792 S    {dbus_vebus_to_p} /usr/bin/python3 -u /opt/victronenergy/dbus-vebus-to-pvinverter/dbus_vebus_to_pvinverter.py
 1102 root      1620 S    multilog t s25000 n4 /var/log/dbus-vebus-to-pvinverter
31935 root      2692 R    grep -i vebus

Das logfile geht erfreulicherweise bis zum 10.03.25 zurück, wo noch alles lief. Weiss nicht mehr, warum ich da ein paar mal neu gebootet habe (VenusOS update?). Letzten Freitag, 28.03.25 kommen dann die neuen boots, nachdem der MP2 plötzlich verschwunden ist. Da findet er dann einfach nix mehr, wenn ich das richtig interpretiere. Habe Leerzeilen zwischen die Neustarts zur Übersichtlichkeit reingesetzt.

root@raspberrypi2:~# cat /var/log/dbus-vebus-to-pvinverter/current | tai64nlocal
2025-03-10 14:56:56.377289500 *** starting dbus-vebus-to-pvinverter ***
2025-03-10 14:57:04.470148500 INFO:root:-------- dbus-pvinverter-vebus, v1.37 is starting up --------
2025-03-10 14:57:04.527034500 INFO:root:Loglevel set to INFO
2025-03-10 14:57:04.543339500 INFO:root:Searching dbus for vebus devices...
2025-03-10 14:57:04.564577500 INFO:root:Finished search for vebus devices
2025-03-10 14:57:04.564583500 INFO:root:Starting mainloop, responding only on events
2025-03-10 14:57:14.525098500 INFO:root:Found: com.victronenergy.vebus.ttyUSB0, checking for valid AC Current Sensors
2025-03-10 14:57:14.570305500 INFO:root:New service added, or sensorcount was changed on an existing service. Count for com.victronenergy.vebus.ttyUSB0 is now None
2025-03-10 15:16:50.438061500 *** starting dbus-vebus-to-pvinverter ***
2025-03-10 15:17:03.359716500 *** CCGX booted (0) ***

2025-03-10 15:28:18.268451500 *** starting dbus-vebus-to-pvinverter ***
2025-03-10 15:28:25.859457500 INFO:root:-------- dbus-pvinverter-vebus, v1.37 is starting up --------
2025-03-10 15:28:25.859466500 INFO:root:Loglevel set to INFO
2025-03-10 15:28:25.992674500 INFO:root:Searching dbus for vebus devices...
2025-03-10 15:28:26.006798500 INFO:root:Finished search for vebus devices
2025-03-10 15:28:26.006805500 INFO:root:Starting mainloop, responding only on events
2025-03-10 15:28:36.012817500 INFO:root:Found: com.victronenergy.vebus.ttyUSB0, checking for valid AC Current Sensors
2025-03-10 15:28:36.050276500 INFO:root:New service added, or sensorcount was changed on an existing service. Count for com.victronenergy.vebus.ttyUSB0 is now None

2025-03-10 17:02:13.048211500 *** CCGX booted (0) ***
2025-03-10 17:02:34.859542500 *** starting dbus-vebus-to-pvinverter ***
2025-03-10 17:02:39.025097500 INFO:root:-------- dbus-pvinverter-vebus, v1.38 is starting up --------
2025-03-10 17:02:39.025788500 INFO:root:Loglevel set to INFO
2025-03-10 17:02:39.032746500 INFO:root:Searching dbus for vebus devices...
2025-03-10 17:02:39.035525500 INFO:root:Finished search for vebus devices
2025-03-10 17:02:39.036141500 INFO:root:Starting mainloop, responding only on events
2025-03-10 17:02:50.751806500 INFO:root:Found: com.victronenergy.vebus.ttyUSB0, checking for valid AC Current Sensors
2025-03-10 17:02:50.774497500 INFO:root:New service added, or sensorcount was changed on an existing service. Count for com.victronenergy.vebus.ttyUSB0 is now None

2025-03-28 13:47:29.112887500 *** CCGX booted (0) ***
2025-03-28 13:47:53.514920500 *** starting dbus-vebus-to-pvinverter ***
2025-03-28 13:48:02.083093500 INFO:root:-------- dbus-pvinverter-vebus, v1.38 is starting up --------
2025-03-28 13:48:02.083713500 INFO:root:Loglevel set to INFO
2025-03-28 13:48:02.132265500 INFO:root:Searching dbus for vebus devices...
2025-03-28 13:48:02.158782500 INFO:root:Finished search for vebus devices
2025-03-28 13:48:02.158788500 INFO:root:Starting mainloop, responding only on events

2025-03-28 15:32:46.007303500 *** CCGX booted (0) ***
2025-03-28 15:33:05.777659500 *** starting dbus-vebus-to-pvinverter ***
2025-03-28 15:33:14.974016500 INFO:root:-------- dbus-pvinverter-vebus, v1.38 is starting up --------
2025-03-28 15:33:15.009143500 INFO:root:Loglevel set to INFO
2025-03-28 15:33:15.019784500 INFO:root:Searching dbus for vebus devices...
2025-03-28 15:33:15.031231500 INFO:root:Finished search for vebus devices
2025-03-28 15:33:15.031779500 INFO:root:Starting mainloop, responding only on events

2025-03-28 16:33:22.064960500 *** CCGX booted (0) ***
2025-03-28 16:33:39.837158500 *** starting dbus-vebus-to-pvinverter ***
2025-03-28 16:33:48.942860500 INFO:root:-------- dbus-pvinverter-vebus, v1.38 is starting up --------
2025-03-28 16:33:48.943611500 INFO:root:Loglevel set to INFO
2025-03-28 16:33:48.969681500 INFO:root:Searching dbus for vebus devices...
2025-03-28 16:33:48.972211500 INFO:root:Finished search for vebus devices
2025-03-28 16:33:48.972930500 INFO:root:Starting mainloop, responding only on events

2025-03-28 19:45:44.043404500 *** CCGX booted (0) ***
2025-03-28 19:46:04.729098500 *** starting dbus-vebus-to-pvinverter ***
2025-03-28 19:46:12.882362500 INFO:root:-------- dbus-pvinverter-vebus, v1.38 is starting up --------
2025-03-28 19:46:12.907582500 INFO:root:Loglevel set to INFO
2025-03-28 19:46:12.952268500 INFO:root:Searching dbus for vebus devices...
2025-03-28 19:46:12.973274500 INFO:root:Finished search for vebus devices
2025-03-28 19:46:12.973281500 INFO:root:Starting mainloop, responding only on events

2025-03-29 12:51:05.584476500 *** starting dbus-vebus-to-pvinverter ***
2025-03-29 12:51:16.109686500 *** CCGX booted (0) ***
...

Der Rest des Logs bis heute mittag bleibt dann gleich wie die letzten Einträge

Danke für dein anhaltendes Interesse, weiss ich sehr zu schätzen :ok_hand: Dein Script lasse ich sehr gerne laufen. Geht das irgendwie über PN oder sowas?

hallo,
dann schau mal, ob das device existiert:
ls /dev/ttyUSB0

das script kann ich dir als zip-datei hochladen. ich nutze es normalerweise unter linux, wenn man die pfade anpasst oder cygwin benutzt, kann man es aber auch unter window mit tcl benutzen.

tschuess

hallo,
hier noch das mehrteilige script:
inverter.zip (23,9 KB)

ein paar dinge must du aber anpassen, da ich inzwischen alles ueber eine mysql-datenbank mache, auch die konfig.

die config-daten braucht das programm, die kannst du auch als array selbst anlegen:
±—±------------±-----±-------+
| id | server | port | anzahl |
±—±------------±-----±-------+
| 1 | /dev/ttyUSB | 0 | 4 |
±—±------------±-----±-------+

bei server kommt die schnittstelle ohne nummer oder die adresse eines netzwerk-portservers hin, port ist dann eben die nummer der ersten schnittstelle oder des tcp-ports und anzahl ist ja wohl selbst erklaerend.

mit diesem einen konfig-datensatz werden die schnittstellen /dev/ttyUSB0-3 abgefragt, ob dort was angeschlossen ist. das mache ich inzwischen bei allen programmen so, was dann wo haengt, stellt das programm selbstaendig fest.

mit dem programm kann man inzwischen auch die eingangsstrombegrenzung einstellen und damit den multi auch auf inverter only umstellen.

es werden zwar nicht alle interprogramm aus /tcl benoetigt, aber bevor ich eines vergesse, habe ich alle eingepackt.

die mysql-teile kommentierst du am besten aus und das config-array, das die sql-abfrage vom server bekommt, kannst du einfach von hand anlegen.

ich kann dir aber auch gerne die tabellen aus meiner datenbank exportieren, da darueber auch festgestellt wird, was es fuer ein multi ist. die dafuer noetigen funktionen sind allerdings immer noch im programm vorhanden, so dass du sie auch nutzen kannst, wenn du ein wenig programmieren kannst.

oder ich muesste dir eine aeltere version aus dem cvs-system schicken.

tschuess

Hi,
bin noch auf der Arbeit, aber werde mich nachher mal darauf stürzen. Normal arbeite ich auch mit Linux, cygwin ist nicht nötig. Eine MySQL Bank kann ich auch problemlos erstellen, wenn du mir einen sql-dump für die Tabellenstruktur gibst.

Die Ports hatte ich auch schon mit lsusb abgefragt, alle vier USB Anschlüsse werden als devices gelistet. Wo der MP noch sichtbar war, hing das MK3 noch an ttyUSB0. Zur Fehlersuche habe ich den Port am Raspi gewechselt, und jetzt ist es ttyUSB3. Ich kann nachher auch noch einen dmesg Auszug reinstellen.
Ein bisschen programmieren kann ich, kommt darauf an, was du benutzt. Werde ich nachher ja sehen :sweat_smile:
Danke!

hallo,
hier noch die tabellen:
vebus-mysql.zip (2,4 KB)

meine datenbank heisst einfach strom.

tschuess

Zunächst noch ein kleiner Check auf dem Raspi. Ich habe mal alle 4 USB Stecker rausgezogen und dann schrittweise wieder angesteckt.

Im Gerätebaum ist erstaunlicherweise schon ein device drin. Scheint als ob der LAN-Anschluss, den ich zusätzlich zum WLAN nutze, über den USB-Hub läuft.

root@raspberrypi2:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M

Als erstes habe ich einen der ve.direct USB Adapter angesteckt (MPPT 100/20). Der wird als device 15 reingehängt und liegt logisch am selben Port wie der LAN-device

root@raspberrypi2:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
            |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

Noch ein ve.direct mit dem zweiten MPPT, der an Port 2 als device 16 kommt

root@raspberrypi2:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
            |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        |__ Port 2: Dev 16, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

Jetzt der SmartShunt, der mit seinem ve.direct wieder parallel an Port 1 zu liegen kommt.

root@raspberrypi2:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
            |__ Port 2: Dev 17, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        |__ Port 2: Dev 16, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

Schliesslich das MK3 Interface, was als device 18 an Port 3 liegt

root@raspberrypi2:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 2: Dev 17, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
        |__ Port 2: Dev 16, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        |__ Port 3: Dev 18, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

Ich finde den Aufbau etwas merkwürdig, aber ich habe davon auch keine Ahnung. Jetzt schau ich mir mal dein TCL Skript an. Das soll aber auf dem VenusOS laufen, oder auf dem Laptop mit MK3-Interface?

Die letzte Frage war wohl Quatsch. Wenn die ttyUSBx getestet werden sollen, muss es auf dem Raspi laufen. War nur kurz unsicher, weil du den MySQL Server als localhost definiert hast.

hallo,
du kannst es ueberall laufen lassen, wo ein tcl-interpreter zur verfuegung steht. auch die datenbank kann auf einem beliebigen system im netz laufen. du musst dann nur die ip und die zugangsdaten eintragen.

unter linux brauchst du im prinzip auch nicht anzupassen, wenn die unterprogramme in /tcl liegen wie bei mir. das gilt auch fuer cygwin unter windows. wenn du activetcl fuer windows benutzt, muessen die pfade zu den unterprogrammen angepasst werden.

die struktur kommt daher, dass mehrere hubs im system hast, wobei es sich bei dem einen wohl um einen 6-port hub oder um einen 4 + einen 3-port hab handelt. jeder hub verursacht eine verzweigung.

auf einem meiner pis sieht das so aus:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 002: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 001: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 002: Dev 005, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 003: Dev 006, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 004: Dev 007, If 0, Class=Hub, Driver=hub/4p, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 001: Dev 006, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 002: Dev 008, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 003: Dev 018, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 004: Dev 019, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 002: Dev 004, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 003: Dev 005, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 004: Dev 012, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 003: Dev 016, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 004: Dev 017, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

dabei ist nur ein 16-port hub angeschlossen, aber der besteht aus 5 4-port-hubs.

anscheinend gibt es keine hubs mit mehr als 4-ports. die bestehen dann immer aus mindestens 2 hubs im gehaeuse.

ich weiss ja nicht, welchen pi du benutzt, aber bei den ersten pis war der lan-port ueber usb-angebunden. erst ab einer bestimmten version wurden dann ein ethernet-port direkt angeschlossen.

tschuess

Müsste ein 3B+ sein

root@raspberrypi2:~# dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.110-rpi-venus-4 (oe-user@oe-host) (arm-ve-linux-gnueabi-gcc (GCC) 9.5.0, GNU ld (GNU Binutils) 2.34.0.20200910) #1 SMP Tue Jan 28 14:18:38 UTC 2025
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[    0.000000] random: fast init done

Mit deinem Script kämpfe ich noch ein wenig. Bei den include Anweisung steht der tcl Unterordner teilweise als absoluter Pfad drin. Das konnte ich korrigieren, aber jetzt verlangt er ein Modul/library namens mysqltcl

xxx@Mint8Core:~/Dokumente/Photovoltaik/Multiplus-II/tcl_script$ tclsh inverter.tcl 
can't find package mysqltcl
    while executing
"package require mysqltcl"
    (file "tcl/mysql-src.inc" line 1)
    invoked from within
"source tcl/mysql-src.inc"
    (in namespace eval "::MYSQL" script line 3)
    invoked from within
"namespace eval MYSQL {

  source tcl/mysql-src.inc

}"
    (file "tcl/mysql.inc" line 3)
    invoked from within
"source "tcl/mysql.inc""
    (file "inverter.tcl" line 9)

Die Syntax ist zwar verständlich, aber habe bisher nie tclsh gearbeitet. Naja, werde mich schon durchwühlen…

Hm, habe es jetzt auf dem Raspi, aber der scheint kein tclsh binary zu haben. Ist das nur auf dem large image, oder kann man da was mit opkg nachinstallieren?

Auf meinem Desktop würde es jetzt weiter laufen, aber da gibt’s kein MK3 Interface :sweat_smile:

2025-04-01 22:01:58 init
2025-04-01 22:01:58 Init Device /dev/ttyUSB 0 4
2025-04-01 22:01:58 init -1
can't read "MK2(PIPE_SIZE_-1)": no such element in array
    while executing
"set ID $MK2(PIPE_SIZE_$DEV)"
    (procedure "cmd" line 28)
    invoked from within
"cmd "W 05 00 00" $DEV"
    (procedure "get_version" line 35)
    invoked from within
"get_version $DEV"
    (procedure "init" line 24)
    invoked from within
"init"
    (file "inverter.tcl" line 228)

hallo,
liegt das verzeichnis tcl im gleichen ordner?

normalerweise muesste im programm /tcl/ stehen. wenn der ordner im gleichen verzeichnis liegt, wie das programm, musst du den ersten schraegstrich im code entfernen oder das verzeichnis tcl nach / verschieben.

ich sagte ja, dass ebentuell ein paar pfade angepasst werden muessen.

alternativ kannst du aber auch einen sym-link anlegen. so habe ich das auf einem system gemacht.

installier das modul einfach, unter den meisten system funktioniert das mit apt install mysqltcl. das ist bei allen systemen auf debian-basis der fall. wenn dein system yum benutzt, sollte es mit yum install mysqltcl funktionieren. frueher musste man das selbst kompilen, aber inzwischen ist das mysql-modul fuer tcl wohl ueberall verfuegbar.

tschuess

Ja, alles schon passiert, slashes am Anfang entfernt, mysql ist auch eingerichtet. Läuft auch auf meinem Desktop Linux bis zu dem Punkt, wo das MK3 Interface erkannt werden soll (s.o.)
Mein Problem ist jetzt, dass VenusOS auf dem Pi in der „kleinen“ Installation (ohne node-red) offenbar keinen tcl-Interpreter hat. Weisst du, ob der auf dem large image enthalten ist?