hallo,

ich bin endlich einmal dazu gekommen, mein 2. cerbo-gx einzurichten, so dass ich es endlich installieren kann, nachdem es jetzt ca. 1 jahr im schrank lag.

leider ist das ganze aber mit einigen problemen verbunden:

1. ich kann das gx nicht zur steuerung meiner ladeleistung verwenden, das muss eine selbst erstellte software uebernehmen.

2. ich habe mehrere bms in betrieb und das gx nutzt immer nur eines davon was zu falschen werten bei der anzeige fuehrt.

3. ich kann die laderegler weder mit einem ve.direct-kabel noch mit einem ve.direct-usb-adpater anschliessen!

4. es muessen aktuell 22 ve.direct-geraete verbunden werden und es kommen wohl noch welche dazu.

fuer das 1. problem gibt es aktuell leider keine loesung, wenn die laderegler direkt am cerbo haengen, das 2. problem kann ich ueber node-red loesen, indem ich ein dashboard erstelle, das mir die richtigen werte anzeigt.

da ich meine ganzen laderegler an portservern fuer serielle ports haengen habe, ist es aber moeglich, dass die daten der laderegler an bis zu 4 systeme gesendet werden koennen. dadurch habe ich die moeglicheit, die ganzen daten mit einer eigenen software zu verarbeiten und sie zur auswertung und steuerung der wechselrichter ueber node-red dem cerbo zur verfuegung zu stellen.

allerdinge waere ich hier sehr gluecklich darueber, wenn das venus-os so etwas von sich aus unterstuetzen wuerde und ich nicht auf einige tricks zurueckgreifen muesste.

ich habe mir also das programm socat von einem raspberry pi auf das gx kopiert und ein script erstellt, das virtuelle serielle ports damit anlegt und anschliessend das programm vedirect-dbus fuer die schnittstelle startet. es sieht jedenfalls einmal so aus, als wuerde das problemlos funktionieren. das kann ich aber erst morgen sehen, wenn meine laderegler alle wieder daten senden.

falls hier jemand einen besseren vorschlag hat, waere ich sehr interessiert.

meine aktuelle loesung hat auf jeden fall mehrere vorteile, vor allem kann ich die regelung auf mindestens 2 systemen laufen lassen, so dass ich eine backup-regelung habe und das gx bekommt alle daten und kann sie an das vrm-portal senden.

auch eine beschraenkung auf 15 ve.direct-geraete gibt es damit nicht mehr.

urspruenglich hatte ich vor, mit einer software die beiden bms als ein einziges zu emulieren und eventuell die laderegler auch gleich zu einem zusammen zu fassen. aber die aktuelle loesung ist einfacher und liefert mehr informationen.

aber jetzt muss ich das teil erst einmal richtig im system anschliessen, da der akku, den ich zum testen angeschlossen habe, inzwischen leer ist. das hat man davon, wenn man keine lust hat, das teil provisorisch mit einem netzteil zu verbinden.

tschuess

Hi,

I have been using the node red (node-red-contrib-victron) package in node red using the large image v5. I am noticing that after a few days the BMV node will disconnect and won't auto connect again. On the node red screen (port 1880) the Battery monitor widget shows disconnected, however all my MQTT connections are fine. Once this happens and I go into the Battery monitor node, it now shows two instances of the BMV. One is the disconnected BMV and the other shows the BMV that it thinks is new. If I then select the new instance and change the measurement back to what it should be then everything is fine. I'm assuming that this is a bug and possibly needs rectification. In the mean time my workaround is to use the exec command with dbus-spy, convert values to CSV format and then save into variables. By doing this I can force the dashboard to load these values on startup and then subscribe to MQTT topics to refresh the data as it changes.

Just wondering if anyone else faced this issue?

Regards,

Damon