[gelöst] Victron Energy CerboGX

[Beta-User]

Neben der "typischen" Ursache "(zu) viele Events" (samt unsauberem Event-Handling) könnte es hier auch sein, dass sich der TE unbeabsichtigt eine Schleife via MQTT gebaut hat.
Falls es sowas ist (und FHEM selbst nicht mehr zur Anzeige zu gebrauchen ist), sollte das auch mit einem externen Tool wie mosquitto_sub feststellbar sein.

Allerdings ist die Zahl der Events in dem List nicht besonders hoch. "Komsich" finde ich aber diese drei Zeilen:
 

Code Auswählen Erweitern

  event-on-change-reading .*
  event-on-update-reading .*
  subscriptions setByTheProgram
Die ersten beiden machen in dieser Kombination m.E. gar keinen Sinn (=> Löschen!), und die letztere klingt danach, als wäre MQTT_GENERIC_BRIDGE im Spiel (was für die Schleifen-Theorie spräche, aber dann passen wieder andere Dinge nicht so recht, wie die Client-Prio).

[SebastianStorb]

Code Auswählen Erweitern

event-on-change-reading .*
  event-on-update-reading .*
  subscriptions setByTheProgram
-> habe ich gelöscht, was leider nicht zur Beschleunigung beigetragen hat.


Ich habe dann auch mal sämtliches Logging deaktiviert, auch alle Plots in FHEM gelöscht, ohne dass die CPU unter 98% (eher weiterhin dauernd bei 100%) gefallen wäre. Dann habe ich ALLE MQTT2_DEVICE und die MQTT_GENERIC_BRIDGE deaktiviert. Hierdurch ist die CPU dann nur noch bei im Schnitt 50-60%, schwankt jedoch sehr stark und geht auch immer wieder auf kurz 100%.

Wahrscheinlich hat es wirklich damit zu tun, dass auch noch zu viele interne Abhängigkeiten bei meinem FHEM (Thema Notify Loop) bestehen.

Kann es etwas bringen wenn ich den Arbeitsspeicher vergrößere? Neue CPU wird ja wahrscheinlich wenig bringen, weil nur ein Kern genutzt wird.

Ich bin dabei alle MQTT über HomeAssistant umzuschreiben und FHEM nur das nötigste zur Verfügung zu stellen - ich verstehe nicht warum HomeAssistant so viel mehr Informationen verarbeiten, darstellen und weitergeben kann, obwohl nur als CORE bei mir läuft. Der Umweg über HASS ist leider sehr lästig. Oder gibt es eine bessere Lösung, als die ich zur Zeit nutze direkt in FHEM?

Vielen Dank!

[SebastianStorb]

Ich habe einen Rpi neu mit FHEM aufgesetzt. Außer dem CerboGxClient und dem MQTT2_CerboGxClient läuft nur der at-Befehl.

Sobald die Verbindung zum CerbroGX hergestellt ist und FHEM Daten empfängt geht der RPi in die Knie. Von ca 25% CPU Leistung auf 100% Dauerleistung und ist kaum noch zu bedienen.

Ich denke, das schließt den Großteil der für mich behebbaren Überlegungen leider aus.


Vielen Dank an Alle - ich denke das Thema kann damit geschlossen werden.

[Beta-User]

Kann es sein, dass es ein weiteres System gibt, das mit derselben ClientID arbeitet?

Code Auswählen Erweitern

2023.04.25 20:05:02 1: 192.168.1.250:1883 reappeared (CerboGxClient)
Ändere das mal auf dem Pi, im Prinzip kann diese ID beliebig sein, es muss nur anders sein wie alle andere ID's, die auf den mosquitto zugreifen.

Und: Welche Version von mosquitto ist auf dem Hauptserver? Seit 2.0 braucht man eigentlich Zugangsdaten.

Weiter (andere/alte Baustelle): Wenn du auf dem Hauptsystem warst, lief der mosquitto ja auf derselben Maschine. Warum bist du da eigentlich über die externe IP gegangen und nicht über localhost?

[SebastianStorb]

Ja etwas stimmt tatsächlich nicht:

Code Auswählen Erweitern

1684041366: mosquitto version 2.0.12 starting
1684041366: Using default config.
1684041366: Starting in local only mode. Connections will only be possible from clients running on this machine.
1684041366: Create a configuration file which defines a listener to allow remote access.
1684041366: For more details see https://mosquitto.org/documentation/authentication-methods/
1684041366: Opening ipv4 listen socket on port 1883.
1684041366: Error: Address already in use
1684041366: Opening ipv6 listen socket on port 1883.
1684041366: Error: Address already in use

Auch die Änderung in FHEM auf 127.0.0.1 hat da nicht geholfen (ich hatte es zum testen umgestellt, und dann vergessen wieder auf localhost zu setzen).

Wenn ich die Client-Verbindung zu mosquitto deaktiviere, wird das System plötzlich auf deutlich flotter.

Unter der Bezeichnung CerboGxClient wird mit list folgendes angezeigt:

Code Auswählen Erweitern

Internals:
  Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
  ClientsKeepOrder 1
  DEF        192.168.1.250:1883
  DeviceName 192.168.1.250:1883
  FUUID      6457e000-f33f-af37-d2a3-9a2a3f3b8c77ea9c
  FVERSION  00_MQTT2_CLIENT.pm:0.274680/2023-04-20
  NAME      CerboGxClient
  NR        769
  STATE      disconnected
  TYPE      MQTT2_CLIENT
  WBCallback
  clientId  CerboGxClient
  eventCount 68
  lastMsgTime 1684040715.13978
  nextOpenDelay 10
  nrConnects 6
  MatchList:
    1:MQTT2_DEVICE ^.
    2:MQTT_GENERIC_BRIDGE ^.
  READINGS:
    2023-05-14 07:22:49  lastPublish    R/c0619ab1e261/keepalive:
    2023-05-14 07:05:15  state          disconnected
  helper:
    bm:
      MQTT2_CLIENT_Attr:
        cnt        2
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 07:04:16
        max        4.41074371337891e-05
        tot        7.20024108886719e-05
        mAr:
          set
          CerboGxClient
          Internals:
  Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
  ClientsKeepOrder 1
  DEF        192.168.1.250:1883
  DeviceName 192.168.1.250:1883
  FUUID      6457e000-f33f-af37-d2a3-9a2a3f3b8c77ea9c
  FVERSION  00_MQTT2_CLIENT.pm:0.274680/2023-04-20
  NAME      CerboGxClient
  NR        769
  STATE      disconnected
  TYPE      MQTT2_CLIENT
  WBCallback
  clientId  CerboGxClient
  eventCount 68
  lastMsgTime 1684040715.13978
  nextOpenDelay 10
  nrConnects 6
  MatchList:
    1:MQTT2_DEVICE ^.
    2:MQTT_GENERIC_BRIDGE ^.
  READINGS:
    2023-05-14 07:22:49  lastPublish    R/c0619ab1e261/keepalive:
    2023-05-14 07:05:15  state          disconnected
  helper:
    bm:
      MQTT2_CLIENT_Attr:
        cnt        2
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 07:04:16
        max        4.41074371337891e-05
        tot        7.20024108886719e-05
        mAr:
          set
          CerboGxClient
          event-on-change-reading
          .*
      MQTT2_CLIENT_Read:
        cnt        168
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:58:12
        max        0.104403972625732
        tot        3.25332355499268
        mAr:
          HASH(0x56550bbc4c00)
      MQTT2_CLIENT_Set:
        cnt        192
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:58:27
        max        0.0814881324768066
        tot        0.441740989685059
        mAr:
          HASH(0x56550bbc4c00)
          CerboGxClient
          disconnect
      MQTT2_CLIENT_connect:
        cnt        4
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:55:35
        max        0.000626087188720703
        tot        0.00127315521240234
        mAr:
          HASH(CerboGxClient)
Attributes:
  event-on-change-reading .*
  event-on-update-reading .*
  room      MQTT
          .*
      MQTT2_CLIENT_Read:
        cnt        168
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:58:12
        max        0.104403972625732
        tot        3.25332355499268
        mAr:
          HASH(0x56550bbc4c00)
      MQTT2_CLIENT_Set:
        cnt        192
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:58:27
        max        0.0814881324768066
        tot        0.441740989685059
        mAr:
          HASH(0x56550bbc4c00)
          CerboGxClient
          disconnect
      MQTT2_CLIENT_connect:
        cnt        4
        dmx        -1000
        dtot      0
        dtotcnt    0
        mTS        14.05. 06:55:35
        max        0.000626087188720703
        tot        0.00127315521240234
        mAr:
          HASH(CerboGxClient)
Attributes:
  event-on-change-reading .*
  event-on-update-reading .*
  room      MQTT
Ich habe die event Attribute wieder reingenommen, weil ich meine festgestellt zu haben, dass die Performance ein klein wenig besser wurde. Komisch ist, dass ich die MQTT_GENERIC_BRIDGE meines Wissens gar nicht aktiv installiert habe - wahrscheinlich automatisch an Board?

Fhem verliert ständig die Verbindung zu mosquitto und baut diese wieder auf. Das kostet wahrscheinlich sehr viel Performance. Ich hatte mal auf verbose 5 über nach gestellt und parktisch nur noch Einträge dieserseits bekommen:

Code Auswählen Erweitern

023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)1homeassistant/sensor/ecosys_p6130cdn/state_reasonnull
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/state_reason\000null
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)0homeassistant/sensor/ecosys_p6130cdn/command_set"PCLXL,PostScript Emulation,PCL5C,PJL"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/command_set\000"PCLXL,PostScript Emulation,PCL5C,PJL"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)2homeassistant/sensor/ecosys_p6130cdn/uri_supported["ipps://192.168.1.50:443/ipp/print", "ipp://192.168.1.50:631/ipp/print"]
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/uri_supported\000["ipps://192.168.1.50:443/ipp/print", "ipp://192.168.1.50:631/ipp/print"]
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)2homeassistant/sensor/ecosys_p6130cdn/friendly_name"ECOSYS P6130cdn"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/friendly_name\000"ECOSYS P6130cdn"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0))homeassistant/sensor/ecosys_p6130cdn/icon"mdi:printer"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/icon\000"mdi:printer"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0);homeassistant/sensor/ecosys_p6130cdn_magenta_tk_5140m/state87
((Darüber hinaus bin in noch (bisher vergeblich) dabei in Homassistant nur das nötigste an mosquitto zu senden, um dort auch die Last für FHEM zu senken.))

[Beta-User]

Ernsthaft - dein Beitrag liest sich wie ein "Honigtopf"... Da ist gefühlt einfach alles schräg, was schräg sein kann, und man hat auch das Gefühl, dass du selbst überhaupt keine Mühe darauf verwendest, zu recherchieren, was im Einzelnen hinter Problemen aus dem Log und Empfehlungen steckt!

Vor dem Hintergrund ein letzter Versuch:

a) Es läuft auf dieser Maschine offenkunding noch was auf Port 1883! Das KANN so nicht klappen mit Mosquitto...
Vermutlich bekommst du raus, was das ist, wenn du "list mosquitto" über das FHEM-Kommandofeld ausführst - das sieht mir nach einer MQTT2_SERVER-Instanz mit diesem Namen aus, oder du versuchst irgendwie krampfhaft, eine zweite mosquitto-Instanz aufzumachen?... Oder du hast zwischenzeitlich die ClientID von deiner MQTT2_CLIENT-Instanz geändert, aber ein "veraltetes" log gezeigt - alles diffus, vermutlich, weil du zu viel auf einmal änderst und dabei den Überblick verlierst? (Die IP ist nämlich auch wieder eine externe, was vermutlich nicht so zu sein braucht).

b) Die "event"-Attribute KÖNNEN in dieser Zusammenstellung NIE zu einer Verbesserung führen! Ganz egal, was du "fühlst", es ist unlogisch. Es werden dadurch nämlich einfach MEHR Prüfungen OHNE Änderung des Endergebnisses...

c) Dass ausgerechnet die "homeassistant"-Zweige dispatcht werden, zeigt mir, dass du das Wiki zu MQTT2_CLIENT/ignoreRegexp nicht gelesen hast.

Kurzfassung:
Finde raus, was das für ein anderer MQTT-Server ist, der schon gestartet ist. Mehr wie einen MQTT-Server brauchst du vermutlich nicht, und wenn, muss der (und alle seine Clients!) einen anderen Port nutzen!
Lösche den event-Attribut-Unfug!

PS: Für einen schnellen Überblick über das, was in FHEM im MQTT-Bereich vorhanden ist, gibts du ins Kommandofeld ein:

Code Auswählen Erweitern

list TYPE=MQTT.*Evtl. etwas weniger Geräte, aber mehr Infos gibt es mit

Code Auswählen Erweitern

list TYPE=MQTT.* DEF

[sukram]

Hallo zusammen,

in einem benachbarten Thread kam das Thema mit der massiven Datenflut aus dem Cerbo/Venus auch schon mal auf. Ganz wichtig ist, dass man seine Subscriptions auf das nötigste eingrenzt, weil sonst der Venus jedesmal seinen kompletten DBus Speicher auf MQTT einkippt, teilweise im Sekundentakt!

Beispiel, hier verbindet sich FHEM direkt als Client an den Cerbo und abonniert nur wenige Datenpunkte:

Code Auswählen Erweitern

define CerboClient MQTT2_CLIENT 10.102.1.201:8883
attr CerboClient SSL 1
attr CerboClient clientId FHEMServer
attr CerboClient keepaliveTimeout 10
attr CerboClient room Technik->PV
attr CerboClient subscriptions N/vrm-id/battery/+/Dc/# N/vrm-id/battery/512/Info/# N/vrm-id/battery/512/Soc N/vrm-id/solarcharger/# N/vrm-id/dcsystem/278/History/EnergyIn N/vrm-id/dcsystem/278/Dc/#

im oben verlinkten Thread habe ich auch schon weitere Informationen zu Keepalive und zum zerlegen der Datenblöcke geschrieben.

MfG

[SebastianStorb]

keine Mühe darauf verwendest

naja - 4-5 h jeden Abend, ob das nicht genug ist kann ich nicht beurteilen. Ich habe leider wirklich keine Ahnung und bin immer noch Anfänger.

Es läuft auf dieser Maschine offenkunding noch was auf Port 1883

Fast korrekt. Weil ich es selber nicht geschafft habe die Lösung zu finden, habe ich einen Experten und Programmierer `engagiert` sich mein Problem anzuschauen.
Ursache ist die Art und Weise wie FHEM mit der clientId (in diesem Fall mosquitto) umgeht. Es gibt in meinem Netzwerk noch ein weiteres FHEM (192.168.1.20) und über VPN weitere FHEM, welche sich auch am mosquitto Server (192.168.1.100) angemeldet haben. Dies hat dazu geführt, dass mosquitto wegen der identischen clientId nicht unterscheiden konnte, dass es sich um ein anderes System handelt (obwohl jeweils eine andere IP, was aber nicht von mosquitto überprüft wird).
Nachdem die clientId im lokalen FHEM geändert wurde (von mosquitto in mosquitto22) war der "disconnect/reconnect" Fehler schlagartig beseitigt und die CPU läuft nur noch auf 20-50%.

"event"-Attribute KÖNNEN in dieser Zusammenstellung NIE zu einer Verbesserung führen

Habe ich gelöscht. Meine Vermutung war, dass weniger Logging zu weniger CPU Last bzw. Auslastung der SSD führt, was richtiger Weise sich nicht bestätigt hat.

dass du das Wiki zu MQTT2_CLIENT/ignoreRegexp nicht gelesen hast

Ich habe den Wiki Text mehrfach gelesen und mehrfach nicht verstanden. Jetzt wurde mir der Text an Beispielen erklärt.


Hiermit möchte ich mich herzlich für die Große Mühe und Unterstützung hier im Forum bedanken! Ich werde das System noch ein paar Tage beobachten und dann als "gelöst" einstellen.

Nochmals VIELEN HERZLICHEN DANK!!!

[rudolfkoenig]

Ursache ist die Art und Weise wie FHEM mit der clientId (in diesem Fall mosquitto) umgeht. Es gibt in meinem Netzwerk noch ein weiteres FHEM (192.168.1.20) und über VPN weitere FHEM, welche sich auch am mosquitto Server (192.168.1.100) angemeldet haben.

Anders formuliert, die Ursache ist nicht, dass man FHEM mit dem CerboGX mosquitto Server verbunden hat, sondern dass man das mehrfach, mit jeweils identischen MQTT2_CLIENT Definitionen gemacht hat.
Die Loesung war unterschiedliche ClientIDs zu verwenden, entweder durch unterschiedliche MQTT2_CLIENT Namen, oder unterschiedliche clientID Attribute.

[SebastianStorb]

Letztlich gelöst wurde das Problem durch die Ermittlung dieser einen Ursache (s. Zusammenfassung von rudolfkoenig im Beitrag über diesem) leider nicht. FHEM war weiterhin noch immer extrem langsam und kaum bedienbar, die CPU ständig bei 75% und oft bei 100%, (jedoch nicht mehr dauerhaft bei 100%).

"Gelöst" habe ich das Problem mit einem weiteren FHEM auf einem RPi, der flott und problemlos alle Daten vom CerboGX empfängt. Auf diesem RPi läuft nur der CerboClient, das AT und die Verbindung zum mosquitto. Zusätzlich habe ich FHEM2FHEM installiert, wodurch die vom RPi generierten Daten an den debian-server mit der Hauptinstanz von FHEM weitergeleitet werden. Die CPU Auslastung dieses Hauptservers liegt jetzt wieder im Bereich 3-25%.

[satprofi]

hallo.
hat schon jemand mqtt mit klartext verwendet? gibts in den settings.
freund will fhem jetzt für steuerung seines cerbo einsetzen .