Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Samson71]

@Sefina sagte:
Gib gerne kurz Bescheid ob's tut.

Leider nein. Verhalten identisch wie zuvor. Ohne Bestätigt die schon bekannte Meldung. Bestätigt kein Log-Eintrag und keine Funktion. Bei Änderung im VRM oder lokal über die GUI bekommt auch der Adapter es sofort mit. Die Datenpunkte laufen auch immer noch als "schreibgeschützt".

[Sefina]

Bitte auf die Version achten : 0.9.2 und dann die Objekte löschen -> am einfachsten den ganzen victron-gx.0 Ordner löschen das die Objekte neu angelegt werden

[Samson71]

@Sefina
Habe die ganze Instanz erst deinstalliert, alles gelöscht und dann nochmal komplett neu die 0.9.2 installiert.

Keine Änderung. Die Datenpunkte werden immer noch als schreibgeschützt angezeigt und eine Änderung verursacht die bekannten Auswirkungen (bzw. hat keine).

Dafür bekomme ich im Log jetzt regelmäßig:

2026-07-28 16:06:07.090 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.AcFeedInEnabled" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.092 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.DcFeedInEnabled" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.106 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.BatteryLifeSocLimit" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.106 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.EssMode" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.106 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.GridSetpoint" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.106 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.BatteryLifeState" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.106 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.MinimumSoc" has no existing object, this might lead to an error in future versions
2026-07-28 16:06:07.107 - warn: victron-gx.0 (181133) State "victron-gx.0.control.system.MaxFeedInPower" has no existing object, this might lead to an error in future versions

[Sefina]

Kurzer zeitlicher Einordnung: du hast den Adapter neu installiert dann konfiguriert -> Schalter zum Steuern gesetzt -> dann das erste Mal den Adapter gestartet zum Objekte anlegen?
Oder hast du den Schalter, nachdem die Objekte angelegt waren geschaltet ?

Rest schaue ich mir direkt an

[Samson71]

@Sefina
Der Adapter startet nach der Installation ja direkt in die Konfigurationsübersicht (zu dem Zeitpunkt gibt es im Protokoll erstmal nur den Warnhinweis, dass noch keine IP-Adresse konfiguriert ist.), dort dann direkt die Einstellungen für IP etc. gemacht und auch den Haken für die MQTT-Steuerung gesetzt und dann dann gespeichert.

[Sefina]

0.9.3 ist raus -> in der Prüfung wird aber nur 1 Problem beheben das steuern wohl nicht -> bitte trotzdem prüfen -> setze mich Abend nochmal rann, wenn du mir keine positive Nachricht gibst.

[Samson71]

@Sefina
0.9.3 im gestoppten Zustand aktualisiert. Objektbaum gelöscht. Adapter startet ohne Fehler im Log und ist grün. Steuern ist wie schon erwartet noch nicht behoben. Reaktion auf Änderungen in der Victron GUI oder im VRM erfolgt sofort.

[Sefina]

@Samson71 Ich habe den kompletten EV-Charger jetzt bei mir lokal simuliert (eigener MQTT-Broker, ioBroker-Testinstanz, exakt derselbe Adapter-Code den du auch hast) und den Weg genau nachgezogen den du gegangen bist: frisch installiert, Config mit MQTT-Steuerung-Haken gespeichert, Charger meldet sich. Ergebnis bei mir: control.evcharger.46.SetCurrent / StartStop / Mode sind beschreibbar, Änderung in Admin UI löst korrekt einen MQTT-Write aus. Der Code funktioniert also.

Damit muss die Ursache bei dir woanders liegen. Drei realistische Kandidaten, könntest du mir bitte kurz zu jedem was schreiben:

1. Kannst du in Admin UI unter Objekte den Datenpunkt victron-gx.0.control.evcharger.283534.SetCurrent aufklappen und rechts unten die Objektdefinition anzeigen (das kleine JSON-/Details-Icon)? Da muss "common": {"write": true, ...} stehen. Screenshot davon wäre Gold wert.

2. Zeigt der Adapter in der Übersicht (Instanzen-Seite) die 0.9.3-Version an und ist grün? Nur zur Sicherheit — falls beim Update was hängengeblieben ist.

3. Wenn du in ioBroker über die Konsole "iobroker state set victron-gx.0.control.evcharger.283534.SetCurrent 10" absetzt: kommt im Log entweder "MQTT write: W/..." (dann funktioniert der Adapter-Pfad und die Admin-UI-Anzeige spinnt) oder ein Warn "control disabled" (dann ist der Schalter doch nicht wirksam gesetzt) oder gar nichts (dann ist der Datenpunkt tatsächlich nicht beschreibbar aus DB-Sicht)?

Mit diesen drei Antworten lässt sich der Grund bei dir eindeutig einkreisen. Danke dir für die Geduld.

[Samson71]

@Sefina

1. und 2. geht auf die Schnelle mobil

1. Kannst du in Admin UI unter Objekte den Datenpunkt victron-gx.0.control.evcharger.283534.SetCurrent aufklappen und rechts unten die Objektdefinition anzeigen (das kleine JSON-/Details-Icon)? Da muss "common": {"write": true, ...} stehen. Screenshot davon wäre Gold wert.

In der Hoffnung dass es das ist, bin in den Objekten nicht so zu Hause

2. Zeigt der Adapter in der Übersicht (Instanzen-Seite) die 0.9.3-Version an und ist grün? Nur zur Sicherheit — falls beim Update was hängengeblieben ist.

EDIT

Ich habe heute am frühen Abend nochmal einiges probiert. Ich zweifel langsam auch an mir. Der Charger ist ja per Skript dem Victron System untergeschoben.

Ich habe in der parallel laufenden HA-Installation mal die Victron Integration installiert und eingerichtet. Dort wird der Charger auch sofort als Victron Gerät mit 13 zugeordneten Entitäten erkannt und ist darüber auch out of the box steuerbar, d.h. eine Änderung dort kommt sofort im Cerbo an und damit auch in den Objekten in ioBroker vom Victron Adapter.

[Sefina]

@samson71

Mit dem neuen Update (0.9.4) hast du den Ordner control nur dann wenn du das Steuern aktivierst.
Nur in diesem Ordner sind die Objekte schreibbar und so auch Steuerbar (Außer die Switche, da lasse ich mir noch was einfallen)

Wenn du die Schreibrechte entfernst, verschwindet auch der Ordner wieder.

Bitte ausprobieren und wenn du die Dateils mir schickst -> Wichtig : victron-gx.0.control.xxxx

[Samson71]

@Sefina
Auf die Schnelle ausprobiert. Vorher einmal komplett deinstalliert und Neuinstallation ohne weitere Auffälligkeiten.

-> Jetzt geht's

Änderungen werden lt. Log sauber angenommen und kommen auch auf dem Cerbo und damit auf den anderen abnehmenden Systemen an.

[Sefina]

na perfekt -> hoffe das auch alles da ist was man braucht zum steuern.
wenn irgendetwas fehlt (deine Temperaturfühler sollten ja auch da sein), bitte melden

[Samson71]

@Sefina sagte:
na perfekt -> hoffe das auch alles da ist was man braucht zum steuern.

Modus (Auto/Manu) und Start/Stop reicht mir sogar aus. Im Modus PV-Überschuss regeln sich die Ampere automatisch.

deine Temperaturfühler sollten ja auch da sein

Sind sie. Da muss aber nichts gesteuert werden.

EDIT

Was nicht schlecht wäre ist eine Steuerbarkeit der Phasenumschaltung. Also automatische Umschaltung 1/3 Phasen oder fixe Einstellung auf 1 Phase.

[Sefina]

@Samson71 sagte:

chlecht wäre ist eine Steuerbarkeit der Phasenumschaltung. Also automatische Umschaltung 1/3 Phasen od

kann das den das gx gerät von sich aus ? oder kannst du es nur über den charger machen ?
ich bräuchte dazu mehr informationen -> im Elektri KFZ Game bin ich noch nicht drin

[Samson71]

@Sefina
Asche auf mein Haupt. Das kann der GX wohl nicht direkt. Scheint über das Skript nicht implementiert zu sein. Geht nur über den Charger (App) oder den nativen Go-e-Adapter. Genau den suche ich derzeit vollständig zu ersetzen, weil die ganze PV-Überschussteuerung beim Laden das Victron-System macht. Das läuft darüber nämlich out of the box ohne ioBroker mit Rechenperformance zu belasten.

[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).