SOLAX X1 mini G4 mit Victron bzw. VenusOS kommunikativ koppeln

hf_spsler · 26. Mai 2025 um 12:14

Irgendwie bin ich akuell mit dem X1 mini ein bisschen am verzweifeln.

Grundsätzlich macht das ganze System bestehend aus 3x Victron Multiplus2-5000 als Dreiphasenverbund, 12kWp DC gekoppelter PV (über RS450/200) sowie rund 43kWh Speicher was es soll.

Aber der digitale Buchhalter in mir möchte jetzt natürlich auch dass der X1 mit in VenusOS, also auf der Remotekonsole bzw. im VRM Portal datentechnisch angezeigt wird. Und das am besten ohne Umwege über meinen Iobroker oder irgendwelche ESP Gateways.

Ein Auslesen der bereitgestellten Daten im Iobroker über den SOLAX Adapter funktioniert, aber ich hätte den PV Inverter eben gern auch auf der Remotekonsole

Also hab ich nun kurzer Hand mal über die Remotekonsole einen Scan laufen lassen und Dieser findet dann auch beide IP Adressen des sog. WiFi-Dongles. Bei mir war der WiFi/LAN Dongle beim WR mit dabei. WR und Dongle sind auch bereits jeweils mit der aktuellsten Firmware versorgt.

Hier Also den Scan angestoßen:

Es wird sogar was gefunden:

Beide IP-Adressen (WiFi und LAN) werden erkannt:

Und in der Geräteliste taucht der Solax auch auf:

Aaaber: Keine Daten. Es werden keine Daten angezeigt:

Jedoch, unter "Gerät" werden Infos angezeigt, die das VenusOS ja irgendwo her bekommen muss:

Was fehlt hier denn dann noch damit auch die Daten sinnvoll angezeigt werden, ich bin da echt grad ein bisschen am Verzweifeln.

Der Support von Solax glänzt hier auch nicht gerade mit sinnvoller Hilfe. Sie schicken mir Anleitungen wie man die IP des Dongles im Netzwerk ausfindig macht... oder die Doku der ModbusRTU Register, aber auf die Frage ob sie wirklich das "sunspec" Protokoll implementiert haben bekam ich keine Antwort.

Gibt es hier jemanden der die Kommunikation ohne cloud, ohne ESP gedöns schon mal ans Laufen gebracht hat?

wihz · 26. Mai 2025 um 17:58

Ich würde beim Victron-Forum nachfragen: https://community.victronenergy.com/

Deine Frage ist schon sehr speziell. Würde mich persönlich wundern, wenn Victron Geräte von Solax unterstützt. Evtl. simuliert das Solax-Gerät per Modbus/TCP nur Teile der benötigten SunSpec-Register.

Das nur das Gerät, aber keine weiteren Daten angezeigt werden, ist ein Indiz dafür.

Du kannst aber vor den Solax einen von Victron unterstützen Zähler zur Verbrauchsmessung hängen. Dann funktioniert es out of the box. Oder Du nimmst eine Shelly und eines der Skripte, die einen Wechselrichter für VenusOS simulieren. Manche machen das auch per NodeRed.

Hier im Forum gibt es einige, die das per Shelly machen.

nikimann · 27. Mai 2025 um 21:05

Hallo
Der Solax Mini lässt sich ohne zusätzliche Zähler integrieren. Hab das auf Github gefunden.

hf_spsler · 28. Mai 2025 um 08:22

Mit der Cloud möchte ich nichts zu tun haben... Aber trotzdem danke für deinen Tipp

SolaxMonitorSupport · 15. Juni 2026 um 18:41

Wenn Cloud ausdrücklich nicht gewünscht ist, würde ich hier zuerst sauber trennen, was VenusOS beim Scan wirklich erkennt:

Gerät/Host ist erreichbar – das zeigt nur, dass IP/Port grundsätzlich antworten.
Protokoll passt – also ob der Dongle/WR wirklich die Register/Struktur liefert, die VenusOS erwartet.
Semantik passt – ob Leistung, Tagesertrag, Status usw. mit den lokalen SolaX-/iobroker-Werten übereinstimmen.

Der Effekt „Gerät taucht auf, aber keine Daten“ klingt für mich eher nach 2 oder 3 als nach einem reinen Netzwerkproblem. Ich würde deshalb einmal parallel loggen:

lokale SolaX-/iobroker-Werte,
Modbus/TCP-Read auf ein paar bekannte, stabile Register,
VenusOS-Scan/Device-Log zum gleichen Zeitpunkt.

Wenn der Dongle nur einen Teil von SunSpec oder eine SolaX-eigene Registerlogik liefert, muss wahrscheinlich eine Übersetzungsschicht dazwischen. Das kann ein eigenes VenusOS-dbus-Skript, Node-RED, MQTT oder ein kleiner lokaler Collector sein. Wichtig wäre nur: erst read-only und plausibilisieren, bevor man daraus irgendeine Regelung baut.

Transparenz: Ich arbeite an SolaxMonitor, daher schaue ich auf SolaX-Themen stark aus Sicht „lokale Daten sauber einsammeln und plausibilisieren“. Kein Pitch – in diesem konkreten Fall würde ich erst beweisen, welche lokalen Werte der X1 Mini wirklich stabil liefert, und danach entscheiden, ob VenusOS direkt reicht oder ob eine kleine Übersetzungsschicht nötig ist.

hf_spsler · 16. Juni 2026 um 05:48

Moin,

erst mal danke für die Antwort

Genau das scheint mir im Moment ziemlich unklar. Wie hier zu erkennen ist, werden eine Reihe an Geräteinformationen dargestellt die dem Victron-System ja so ohne Weiteres gar nicht bekannt sind, also “irgendwoher” kommen müssen:

Die Information “Produkt” als String kann meiner Meinung nach nur ausgelesen werden. Deshalb wundert es mich, dass zwar der Produktname sozusagen voll ausgeschrieben erkannt wird, alle weiteren Daten aber nicht.

Ein Netzwerkproblem kann ich ausschließen, das zyklische Auslesen von Mittlerweile einem X1 mini Gen4 und einem X3 Mic Gen2 klappt via standard Modbus-TCP über die jeweils verwendeten Dongles relativ gut - bis auf das es hin und wieder zu Timeouts kommt obwohl ich alle in den Datenblättern angegebenen Timings einhalte. Jedoch ist mein primäres Ziel nicht, dass da der Iobroker als Man-In-The-Middle fungiert sondern dass das VenusOS als zentrale Datenanlaufstelle verwendet werden soll. Daher hege ich noch immer den Wunsch, dass die Solax Geräte direkt von VenusOS gelesen werden.

SolaxMonitorSupport · 16. Juni 2026 um 06:32

Moin, ja — wenn der Produktname als String sauber auftaucht, würde ich auch davon ausgehen, dass VenusOS zumindest irgendeinen gültigen Modbus-Block liest. Das schließt aber leider noch nicht aus, dass die eigentlichen Messwerte über einen anderen Block, andere Registeradressen, Unit-ID oder ein anderes Layout erwartet werden.

Ich würde es gedanklich in zwei Ebenen trennen:

Geräteerkennung / Identifikation: Produktname, Hersteller, ggf. Serien-/Modellstring. Das kann aus einem relativ allgemeinen Bereich kommen und reicht oft, damit ein Gerät „erkannt“ aussieht.
Nutzdaten: PV-Leistung, Spannung, Strom, Batterie, Grid, Statusbits usw. Hier sind SolaX-Modelle/Dongles/Firmwarestände deutlich zickiger, weil Registerbereiche, Skalierung, signed/unsigned und teilweise auch die Erwartung an Input- vs. Holding-Register abweichen können.

Wenn ioBroker die Werte per Standard-Modbus-TCP lesen kann, wäre der nächste sinnvolle Vergleich aus meiner Sicht nicht mehr Netzwerk, sondern exakt: Welche Requests schickt ioBroker erfolgreich, und welche Requests schickt VenusOS beim Scan/Lesen?

Praktisch würde ich dafür vergleichen:

Unit-ID/Slave-ID bei beiden Wegen,
Function Code: Holding Register vs. Input Register,
Startadresse und Länge der gelesenen Blöcke,
ob VenusOS vielleicht nur einen generischen SunSpec-/Victron-kompatiblen Block erwartet,
ob die Register bei X1 mini G4 und X3 Mic Gen2 wirklich gleich liegen oder nur der Identifikationsblock ähnlich ist,
Timeouts: ob sie bei bestimmten Blocklängen/Adressbereichen häufiger kommen.

Dass der Produktstring funktioniert, aber danach „nichts Brauchbares“ kommt, passt für mich sehr gut zu: Erkennung klappt, aber der VenusOS-Treiber hat für diese SolaX/Dongle-Kombination noch keine passende Messwert-Mapping-Schicht.

Wenn VenusOS die zentrale Stelle bleiben soll, wäre vermutlich der saubere Weg, die funktionierenden ioBroker-Registerzugriffe als Referenz zu nehmen und daraus entweder das passende VenusOS/Modbus-Mapping zu erweitern oder testweise einen kleinen Bridge-Prozess zu bauen, der die Werte liest und in VenusOS/dbus einspeist. Nicht schön, aber besser als ioBroker dauerhaft als Man-in-the-Middle, wenn das eigentlich nicht dein Ziel ist.

Ich würde also nicht weiter am „ist das Gerät erreichbar?“-Teil suchen, sondern an einem kleinen Request-Vergleich: ioBroker erfolgreich vs. VenusOS erfolglos, gleiche Minute, gleiche Dongle-IP. Daraus sieht man meistens recht schnell, ob es Unit-ID, Registerbereich, Function Code oder Datenformat ist.