Multiplus 2 GX, Victron Gridmeter und openDTU - geht immer wieder in passthrough (durchleiten) modus

[zac_mckracken]

moinsen,
folgendes System:

• Pylontech US3000C (2*) via Typ A Kabel an VE.CAN angeschlossen
• Muliplus 2 GX, neuestes VenusOS 3.54, via LAN angeschlossen
• Victron-VM-3P75CT Gridmeter via LAN angeschlossen
• Hoymiles 1500 an L1
• opendtu (henne49_dbus-opendtu)
  AC-seitig an L1 angeschlossen
  ESS konfiguriert

Akkus und Gridmeter werden erkannt und zeigen korrekte Werte.
Das System funktioniert soweit einwandfrei, 2 Tage lang.
Jetzt ist es schon zum 2. mal passiert, dass es vormittags ordnungsgemäss anfängt, bei PV Überschuss die Akkus zu laden, und plötzlich schaltet es um auf "durchleiten".
Hab es weder durch softwareseitigen Neustart noch durch temporäres ausschalten aller Komponenten wieder zum laufen bekommen.
Das Sytem dann resetted (mit USB-Stick und venus-data-90-reset-all.tgz) - läuft nach Neueinrichtung wieder.
Dann die openDTU installiert, weil ich gerne auch die PV Daten im VRM Portal haben möchte - PV Daten werden sofort (ohne Neustart) angezeigt.

So läuft das dann 2 Tage, dann schaltet's auf durchleiten.
Versuchsweise die opendtu mit uninstall.sh "deinstalliert" - scheinbar wird da jedoch nur ein log-Ordner gelöscht - jedenfalls geht es direkt danach wieder !?!
Dann war nach 2 Tagen ! der PV Inverter aus der Anzeige verschwunden, System funktionierte aber noch.
openDTU wieder aktiviert mit install.sh und restart.sh.
2 Tage später wieder das selbe Spiel, Anlage hat vormittags auf "durchleiten" umgeschaltet und nach ausführen der uninstall.sh gings sofort wieder.

Ist das jedes mal nur ein Zufall (ist schliesslich nur "rumprobieren" meinerseits) oder kann da ein Zusammenhang bestehen ???

Hab mir sämtliche Videos von "SchattenPV", "meine Energiewende" und "mein techblog" zu dem Thema Victron ESS nochmal reingezogen und denke, dass ich alles korrekt eingestellt habe (ist ja auch ein ziemlich simples setup was ich hier habe)
Komme aber an dieser Stelle nicht mehr weiter ....

[zac_mckracken]

niemand eine Idee ?
würde dann die Frage mal im PV Forum stellen....

[pippo72]

Ich habe das gleiche Problem seit ca. 5 Tagen. Ich hatte OpenDTU vor ca. 2 Wochen installiert.
Zudem wird das Victron-Dashboard nicht richtig angezeigt bzw. bleiben die Werte "eingefroren".
In der Geräteliste auf dem Cerbo GX wird seitdem der Eintrag "Tasmota" angezeigt. Das war vorher nicht der Fall. Ich habe gesehen, dass das bei Dir ebenso der Fall ist.

Bin auch ratlos.....

[jojo182]

Hi,
so wie ich das gelesen habe scheint es ja an dem opendtu plugin zu liegen.
Ich selber habe auch die opendtu am laufen, hole mir aber die Daten über dbus-mqtt-pv ins venus os (GitHub - mr-manuel/venus-os_dbus-mqtt-pv: This Venus OS driver gets the data from MQTT and displays it as pv inverter.). Ist vielleicht erstmal etwas mehr Aufwand, aber es funktioniert ohne Probleme.
Wenn du node-red in venus os aktiviert hast, könntest du da direkt die mqtt Nachricht generieren (direkt über mqtt von opendtu oder über webapi).
Zuerst würde ich aber wahrscheinlich dein Cerbo nochmals resetten, schauen ob es mehrere Tage sauber läuft und dann dbus-mqtt-pv installieren.

[zac_mckracken]

moin,
danke, das werde ich mal versuchen !
Bin gespannt, ob mein system morgen früh wieder „aussteigt“ - dann sind die 2 Tage wieder rum.
Dass das Dashboard nicht aktualisiert, hatte ich auch ein mal.
Das neue GUI bekommt manchmal nicht mit, wenn keine Daten mehr kommen. (warum auch immer, schlechte/keine Verbindung, what ever)

Was ich absolut nicht verstehe: die Daten der openDTU sind doch nur „informativ“, der MP 2 GX arbeitet auch ohne diese Daten einwandfrei - er braucht ja nur einen Gridmeter, um zu entscheiden, ob der Akku be- oder entladen wird.
Was zum Henker kann das script da überhaupt dazwischen funken ?
Und warum tritt das Phänomen nur alle 2 Tage auf ?

[cmock]

ohne daß ich das phänomen schon gehabt hätte -- da könnt sich am system was aufschaukeln, bis es entweder nach diesen 2 tagen CPU oder RAM dichtmacht oder den dbus.
du könntest mal im VRM bei den graphen unter advanced danach schauen, ob da was auffällt, da gibt's für den dbus auch einen "dbus round trip time"-wert.

[zac_mckracken]

moin,
jetzt hat das System um 4:00 morgens die Arbeit eingestellt, Akku wurde ab da nicht mehr entladen.
Hab mich per ssh eingelogged und nur mal mit df -h den freien Speicher angesehen - ab da ging es wieder !?

Wo genau finde ich im VRM den dbus wert ?
Ich sehe diverse graphen vom gridmeter und VE.Bus, zum dbus finde ich dort nichts.
Ich habe nur rudimentäre Linuxkenntnisse (Kommandozeile ist mir nicht fremd, hatte schon vor Windows eine PC)
Wie kann ich checken, ob der Speicher voll läuft oder dbus aussteigt ?
Und, wenn es wirklich das openDTU script ist, wie bekomme ich das wieder runter vom GX ?
(notfalls setze ich das ganze system zurück, aber es sollt ja auch anders möglich sein...)

P.S.
zum deinstallieren habe ich was bei github gefunden:
/data/dbus-opendtu/uninstall.sh stops the service and prevents it from being restarted (e.g. after a reboot).

If you want to remove the service completely, you can do so by running rm -rf /data/dbus-opendtu.

was mir nur unverständlich ist; nach dem ausführen von uninstall.sh (ohne anschliessenden Neustart des GX) wird der PV Inverter noch für ca 2 Tage angezeigt.

[zac_mckracken]

ich habe mir jetzt mal das Paket von mr-manuel installiert.
auf dem venusOS 3.54 läuft ja scheinbar schon dbus-flashmq (Nachfolger von dbus-mqtt)

In der config vom dbus-mqtt-pv habe ich bei Broker die Adresse vom Venus eingegeben. (Der mqtt-explorer spuckt auch Werte aus unter der Adresse und dem Port)

Wo ich allerdings noch auf der Leitung stehe: Was/wo muss ich noch einstellen, damit der die Daten von der openDTU bekommt ?

In der Geräteliste taucht das auch noch nicht auf.

[jojo182]

Ich hab hier mal ein einfaches Beispiel für dich gemacht über node-red, das kannst du dann im venus os node-red importieren.
Über die webapi von open-dtu wird alle 5s Daten abgeholt und in ein json gepackt, das wird dann an den internen mqtt broker von venus os gesendet.
In der config von dbus-mqtt-pv gibst du dann ip und topic an.
Natürlich könntest du auch statt die webapi mqtt benutzen:

[
    {
        "id": "84c0181e46789d44",
        "type": "tab",
        "label": "opendtu_to_dbus_mqtt_pv",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "c8104602d6eed4eb",
        "type": "inject",
        "z": "84c0181e46789d44",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "5",
        "crontab": "",
        "once": true,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "x": 190,
        "y": 340,
        "wires": [
            [
                "569263f41b06cf80"
            ]
        ]
    },
    {
        "id": "569263f41b06cf80",
        "type": "http request",
        "z": "84c0181e46789d44",
        "name": "",
        "method": "GET",
        "ret": "obj",
        "paytoqs": "ignore",
        "url": "http://192.168.2.120/api/livedata/status",
        "tls": "",
        "persist": true,
        "proxy": "",
        "insecureHTTPParser": false,
        "authType": "",
        "senderr": false,
        "headers": [],
        "x": 390,
        "y": 340,
        "wires": [
            [
                "a957fed997f2318a"
            ]
        ]
    },
    {
        "id": "a957fed997f2318a",
        "type": "template",
        "z": "84c0181e46789d44",
        "name": "",
        "field": "template",
        "fieldType": "msg",
        "format": "json",
        "syntax": "mustache",
        "template": "{\n    \"pv\": {\n        \"power\": 0.0,\n        \"energy_forward\": 0.0\n    }\n}",
        "output": "json",
        "x": 580,
        "y": 340,
        "wires": [
            [
                "56199d94167612bf"
            ]
        ]
    },
    {
        "id": "56199d94167612bf",
        "type": "function",
        "z": "84c0181e46789d44",
        "name": "dbus mqtt pv",
        "func": "let json = msg.template;\n\njson[\"pv\"][\"power\"] = msg.payload[\"total\"][\"Power\"][\"v\"];\njson[\"pv\"][\"energy_forward\"] = msg.payload[\"total\"][\"YieldTotal\"][\"v\"];\n\nmsg.payload = JSON.stringify(json);\n\nreturn msg;",
        "outputs": 1,
        "timeout": "",
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 770,
        "y": 340,
        "wires": [
            [
                "151f95b6c9f02aee"
            ]
        ]
    },
    {
        "id": "151f95b6c9f02aee",
        "type": "mqtt out",
        "z": "84c0181e46789d44",
        "name": "",
        "topic": "pv/dbus-mqtt-pv",
        "qos": "",
        "retain": "",
        "respTopic": "",
        "contentType": "",
        "userProps": "",
        "correl": "",
        "expiry": "",
        "broker": "b3c3d4a4790113f9",
        "x": 1020,
        "y": 340,
        "wires": []
    },
    {
        "id": "b3c3d4a4790113f9",
        "type": "mqtt-broker",
        "name": "",
        "broker": "localhost",
        "port": "1883",
        "clientid": "",
        "autoConnect": true,
        "usetls": false,
        "protocolVersion": "4",
        "keepalive": "60",
        "cleansession": true,
        "autoUnsubscribe": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "birthMsg": {},
        "closeTopic": "",
        "closeQos": "0",
        "closePayload": "",
        "closeMsg": {},
        "willTopic": "",
        "willQos": "0",
        "willPayload": "",
        "willMsg": {},
        "userProps": "",
        "sessionExpiry": ""
    }
]

[cmock]

den dbus-wert findest, wenn du das entsprechende widget hinzufügst unter advanced.
systemauslastung unter linux: "free", da müßt ziemlich viel unter free stehen, bei mir aktuell auf einem raspi, der schon 3 monate läuft:

              total        used        free      shared  buff/cache   available
Mem:        3929296      401364     3128332        2088      399600     3504008
Swap:             0           0           0

CPU über "top", da hast dann eine spalte "idle", die sollte dauerhaft irgendwo jenseits der 50% sein. aussteigen mit Ctrl-C.

[zac_mckracken]

prima - danke, hab's hinbekommen !!

der topic "name": "dbus mqtt pv" war falsch bzw korrespondierte nicht mit meinem,
der heisst in der Beispielconfig im mr-manuel script enphase/envoy-s/meters

sonst nur die IP der opendtu angepasst und es läuft

zu dem dbus-wert im VRM:
beim dritten mal suchen hab ich den d-bus Wert bei den benutzerdefinierten unter "Gateway" gefunden !

Danke euch - bin gespannt, ob das System jetzt die magische 2-Tagesgrenze überschreitet...

[jojo182]

Super!
Ich kann dir nur sagen das bei mir 2 Anlagen zuverlässig damit laufen. Falls es bei dir wieder Probleme gibt, muss es andere Ursachen haben.
Übrigens ist es ab der Venus OS Version 3.60 beta möglich, direkt in node-red "virtual devices" anzulegen, also Grid Meter, PV Inverter, Battery usw und dann mit Daten zu füttern.
Sprich, die ganzen plugins wie hier könnten überflüssig werden.
Ich habs aber noch nicht getestet, möchte mein System nicht durcheinander bringen.

[zac_mckracken]

na das wäre ja super !
aber ich hab eh schon zu viel auf einmal geändert (ein update der opendtu firmware wurde auch noch gemacht)
Ich lasse es jetzt mal so laufen, und wenn das neue Venus 3.6 als release raus kommt, sehe ich es mir mal auf meinem Bastel-Raspi an.

Das ganze System ist (für mich) eh noch neu, und da habe ich erstmal keine Lust auf beta's
(mit möglichen Fehlern in der firmware wird's dann für mich noch schwieriger, mich in das System einzuarbeiten)

Wenn es jetzt mal ohne Fehler arbeitet und nicht alle 2 Tage ein Eingriff erforderlich ist, ist das schon mal ein riesen Erfolg.
Das "Grundrauschen" vom Haus deckt die Anlage (sonnige Tage vorausgesetzt, nicht sowas wie heute) perfekt ab, der Akku hat die letzten Tage immer bis morgens um 7-8:00 gehalten.

Ich hatte anfangs das Problem, dass der Akku auch tagsüber bei Lastspitzen (Heizung, Herd, Kaffeemaschine usw) schon entladen wurde, dadurch wurde er an manchen Tagen nicht mal 1/2 voll.
Habe dann im GX ESS das geplante Laden von 9-19:00 eingestellt, nun wird der Akku in diesem Zeitraum nur aufgeladen (bei PV Überschuss, nicht aus dem Netz)
Hintergrund ist, dass ich die Akkukapazität auch voll ausnutzen will (soll sich ja irgendwann amortisieren)
Das würde ich gerne bei Gelegenheit mit node red umsetzen, dann könnte man es so steuern, dass, sobald der Akku voll ist (90% z.b), er auch wieder entladen werden kann, und nicht stumpf nach Uhrzeit.

Hintergrund des ganzen ist, dass ich noch eine PV-Anlage habe, die aber nicht vom Gridmeter erfasst wird (Einspeiseanlage mit Eigenverbrauch) und die Leistung dieser Anlage somit für das ESS unsichtbar ist bzw als Bezug aus dem Netz untergeht.
Daran will (und kann) ich derzeit auch nichts ändern, da ich (alte Anlage) im mom noch mehr Einspeisevergütung bekomme, als der Strom aktuell kostet.

Aber die PV Produktion der Hoymiles Anlage soll komplett "intern" verbraten werden, die soll nichts einspeisen (darf sie genaugenommen auch nicht ) aber den Akku füllen und Nachts wieder abgeben.

[zac_mckracken]

so, noch zur Systemauslastung,
scheint alles im grünen Bereich, oder ist die Speicherauslastung grenzwertig ?

[zac_mckracken]

update:
System läuft seit 5 Tagen ohne Probleme,
scheint also wirklich am openDTU plugin gelegen zu haben...

[cmock]

sorry, war im urlaub. das schaut an sich gut aus.