Der neue Monatsrückblick für September 2026 ist online!

[Sefina]

die frage ist -> da victron ja mit dem nächsten update ja Lasten selber schalten kann, kann es sein das -> da du ja es mit einem Script einbindest da noch mehr geht.
Ich gehe mal davon aus das du es mit ein paar anpassungen es wascheinlich voll schalten kannst, dann kann der adapter das auch.

[Samson71]

@Sefina
Das Skript zur Einbindung des Charger in Victron stammt nicht von mir.
https://github.com/gonzo7734/dbus-goecharger
Das ist leider nicht mein Skill.

[Sefina]

also theoretisch muss das script nur angepasst werden, sodass da in virtueler switch mit integriert ist -> Phasenumschaltung -> wenn es über die api erlaubt ist gehe ich mal davon aus das Victron das auch kann -> wenn es Victron kann bekommen wir es auch in den Adapter

Das ist ja mein derzeitiges Vorgehen -> alles was mit Strom und Großverbraucher zu tun hat ins Victron OS einbinden.

Allerdings ohne Hardware ist das ein sehr Aussichtloses Unterfangen um es genau zu testen und zu verifizieren

---

EDIT :

Du brauchst nichts am Script anzupassen da Victron den echarger so nicht vorsieht.
Einfacher ist es über Node Red einen Virtuelen Switch einbinden -> ChatGPT / Claude können dir da entspannt helfen.

Mit diesen Virtuelen Switch einfach das Umschalten und schon ist er auch in dem Adapter drin :

http://<IP>/api/set?psm=1   → Force 1 Phase
http://<IP>/api/set?psm=2   → Force 3 Phasen
http://<IP>/api/set?psm=0   → Auto (nur wenn Firmware das unterstützt)

https://github.com/goecharger/go-eCharger-API-v2/blob/main/API_KEYS_FIRMWARE/apikeys-de.md

Allerdings steht psm dort nicht drin, das wurde wohl durch Reverse-Engineering herrausbekommen.
Aber das sollte man rausbekommen und so hast du da die einfachste möglichkeit.

[Sefina]

0.10.0 ist im Latest — Ankündigung mit ein paar Breaking Changes

Hallo zusammen,

Version 0.10.0 hat es gerade ins Latest geschafft. In der Version steckt ein größerer struktureller Umbau, deswegen bitte kurz reinschauen bevor ihr updated — insbesondere wenn ihr Skripte, Blockly-Regeln, Node-RED-Flows oder VIS-Widgets habt die auf Adapter-Datenpunkte zugreifen.

Was strukturell anders wird

• Der control.-Zweig verschwindet komplett. Alle schreibbaren Datenpunkte leben ab jetzt direkt unter devices. — ein Objekt pro logischem Datenpunkt statt Rohdaten und Alias parallel. Ob ein Datenpunkt schreibbar ist, seht ihr sofort am Schloss-Icon in Admin.
• Zwei Config-Schalter statt einem unter Adapter-Einstellungen:
• • Modbus-Steuerung (früher „Steuerung aktivieren", intern umbenannt von controlEnabled zu modbusControlEnabled — der Wert wird beim ersten Start automatisch übernommen, ihr müsst nichts manuell umstellen)
• • MQTT-Steuerung (bisher nur für EV-Charger, jetzt für alle MQTT-basierten schreibbaren Datenpunkte)
• SwitchableOutputs sind jetzt an den MQTT-Steuerung-Schalter gebunden. Vorher waren die immer beschreibbar, unabhängig vom Schalter. Wer Switches per Skript schaltet und MQTT-Steuerung bisher deaktiviert hatte, muss den Haken jetzt setzen.

Was einfach besser wird

• Der EV-Charger ist nicht mehr als „experimentell" gekennzeichnet — er wird wie jeder andere Gerätetyp behandelt. Steuerung über devices.evcharger.<serial>.SetCurrent / .StartStop / .Mode, wenn MQTT-Steuerung aktiv ist.
• Die Temperatursensor-Kalibrierung (Offset, Scale, FilterLength) ist erstmals schreibbar. Auch das über MQTT-Steuerung gated.
• Keine Doppelbäume mehr, keine Verwechslung mehr zwischen Serial-ID und Instance-ID, deutlich weniger Objekt-Overhead.

Migration — was passiert beim Update

Beim ersten Start nach dem Update wird der alte control.*-Zweig automatisch entfernt, der Config-Schlüssel wird umbenannt, und im Log erscheint bei jedem Restart ein Warn-Block mit der vollständigen Alt→Neu-Zuordnung als Erinnerung. Der Warn-Block bleibt bis Version 0.11.x drin und wird ab 0.12.0 entfernt.

Was ihr tun müsst wenn ihr control.*-Referenzen habt

Kurz durch eure Skripte / Blockly / Node-RED / VIS scrollen und control.evcharger., control.system., control.inverter.* durch die entsprechenden devices.*-Pfade ersetzen. Vollständige Mapping-Tabelle im README auf GitHub. Wenn ihr euch bei einem Pfad unsicher seid — gerne fragen.

Danke

Besonderer Dank an @Samson71 der mit seiner detaillierten Fehlermeldung zum EV-Charger die Diskussion angestoßen hat, die letztlich zu diesem Umbau geführt hat. Ohne den Praxis-Feedback wäre die alte Doppelbaum-Struktur wahrscheinlich noch länger geblieben.

Feedback, Bug-Reports und Rückfragen wie immer gerne hier im Thread oder als Issue auf GitHub.

[zottel]

hi,
habe einen tank140 mit 2 sensoren dran. es wird in den objekten aber nur eine sensor angelegt.
im adapter bei den geräten ist auch nur eine instanz zu sehen, bei den topics sind die daten aber vorhanden.
desweiteren fehlen alle meine temp-sensoren (ebenfalls bei den topics vorhanden).

[Samson71]

@zottel
Vielleicht machst Du mal Screenshots der Einstellungen und zeigst mal den Objektbaum. So richtig verstanden wo es klemmt habe ich nämlich nicht. Erst fehlen die Temp-Sensoren (wo?) und dann sind sie aber doch vorhanden?

[Nicedrake]

Hallo Sefina, ich habe deinen Adapter gerade mite einem Cerbo-GX und einem SmartSolar Laderegler ausprobiert. Bisher habe ich die Werte immer via ESP geholt. Jetzt will ich gerne umstellen. Ich habe jedoch nur 5 Werte via MQTT. Gibt es einen Weg, wie ich zusätzliche Werte aus "Alle Topics" in die Whitelist bekomme? Ich finde nirgendwo eine Einstelloption.
Dankeschön erstmal das Du Dir überhaupt die Arbeit machst!

[nettworker]

@sefina

Ich habe seit neuestem alle 2 Minuten Fehlermeldungen im Log, Installierte Version: 0.10.0

[Sefina]

@nicedrake wenn du geräte hast die der Adapter nicht kennt, und du gerne mehr haben willst, oder mehr objekte haben willst, dann benötige ich den white catalog um die MQTT Topics zu bekommen.

@nettworker ist das Problem noch aktuell oder wurde es schon gelösst ?

@zottel das gleiche wie nicedrake -> wenn etwas fehlt dann bitte den catalog und genau beschreiben was fehlt

[zottel]

habs jetzt anders gelöst und benutze den adapter nicht mehr.
fyi: neben den oben genannten prblemen, war mir das insg. zu viel traffic (zumal die daten über eine sim-karte laufen). jetzt pusht mein victron-system die hand voll daten nur bei änderung in meinen iobroker, statt alle paar sek alles zu holen...

[Maximal]

@sefina

Ich benutze den tollen Victron-GX Adaper, es fehlen mir aber 2 Datenpunkte:
Batterie State: (system/0/Dc/Battery/State)
Batterie Temp.: (system/0/Dc/Battery/Temperature)

Nachtrag
Diese fehlen mir auch noch:

solarcharger/XXX/DeviceInstance
solarcharger/XXX/Devices/0/CustomName
solarcharger/XXX/History/Daily/0/Yield
solarcharger/XXX/Yield/User

könntest du die Datenpunkte noch mit einbauen ?

Im Anhang ist der Topic Katalog
victron-gx-catalog.json

Vielen Dank...
Michael (Maximal)

[JB_Sullivan]

Hallo zusammen, bin heute auf den Adapter gestoßen. Was ich so raus lese, scheint der Adapter bei der Geräteerkennung mehr auf Stationäre Anlagen ausgelegt zu sein.

Ich hingegen habe mein Wohnmobil komplett mit Victron Technik umgerüstet und nutze den Victron-Cerbo Adapter mit seinen über 4000 Datenpunkten.

Eine erste Test Installation des GX-Adapter hat leider diverse Geräte nicht gefunden (SmartCharger IP 43, Orion Ladebooster, nur ein Tank Sensor, obwohl 5 Verbaut sind (3 x BLE Mopeka (Ultraschall) Sensoren, keine BLE RUUVI Temperatur Sensoren).

Vielleicht kann ich trotzdem bei dem einen oder anderen Test etwas dazu beisteuern.

Anbei das Dashboard meines Camper. Hinter jeder Kachel befinden sind noch Themen spezifische weitere Seiten. 90% basiert auf Cerbo Daten.

[Wunderlag]

Hi, ich würde auch gerne beisteuern, ich habe bis jetzt alles per Modbus abgegriffen und würde aber viele Vorteile an dem Adapter sehen.

Ich habe auch einige spezielle Geräte am Cerbo installiert, die zB per MQTT gefüttert werden (zB EV-Charger).

Ich glaube, dass niemand die unzähligen Parameter per Hand und für alle perfekt zugeschnitten anlegen kann, meine Frage:

Was spricht dagegen, die Whitelist vom User optional selbst verwalten zu lassen? Ein download button für die aktuelle (bzw voreingestellte) Whitelist und ein upload für eine modifizierte Whitelist, die bis zu einem "reset" verwendet wird, wäre für mich perfekt.

Oder, falls es gewünscht ist die kontrolle über die voreingestellten Parameter zu behalten, könnte man eine zusätzliche Whitelist anbieten, die dann von den "devices" getrennt unter zB victron-gx.0.custom. angezeigt wird.

Alternativ dazu würde ich auch schon mit einer Möglichkeit zufrieden sein, einfach alle (oder ggf in den Adapter-Einstellungen per Häkchen gewählte) Datenpunkte in von Victron bereits vorgegeber Struktur in meinen Objekten zu sehen (also ganz stur zB battery/512/System/MinCellTemperature -> victron-gx.0.raw.battery.512.System.MinCellTemperature).

Ich kann natürlich auch gerne meine .json schicken mit Wünschen und Vorschlägen 🙂