Supervisor-Fehlermeldungen

harryp · 2. Dezember 2024 um 08:29

Hallo zusammen,

in der Supervisor-Protokolldatei taucht regelmäßig folgende Fehlermeldung auf:

2024-12-01 18:16:09.719 WARNING (MainThread) [supervisor.addons.options] Option 'mpm_packages' does not exist in the schema for Node-RED (a0d7b954_nodered)
2024-12-01 18:16:09.962 WARNING (MainThread) [supervisor.addons.options] Unknown option 'mqtt' for Zigbee2MQTT (486e6e9b_zigbee2mqtt)
2024-12-01 18:16:09.962 WARNING (MainThread) [supervisor.addons.options] Unknown option 'serial' for Zigbee2MQTT (486e6e9b_zigbee2mqtt)

Hat dazu jemand eine Vermutung/Lösung?

Ergänzend dazu kommt noch, dass mein Node-Red jeden Tag gegen 18:30 Uhr plötzlich über 40%-CPU-Leistung zieht und sich erst nach einem Neustart von Node-Red (passiert meistens automatisch oder auch von mir händisch) wieder für 24h normalisiert.

Jim_OS · 2. Dezember 2024 um 08:45

Moin,

zu Node-Red kann ich gar nichts sagen. Was die beiden Warnungen zu Z2M betrifft scheint es in Deiner Z2M Konfiguration bei dem mqtt und dem serial Eintrag irgendetwas, bzw. irgendeine Formatierung zu geben die HA nicht (mehr) “mag”. Poste hier mal Deine Z2M configuration.yaml, vielleicht fällt irgendjemanden dazu dann etwas ein.

VG Jim

harryp · 2. Dezember 2024 um 08:51

Die Konfiguration im Add-On:

data_path: /config/zigbee2mqtt
socat:
  enabled: false
  master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
  slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
  options: "-d -d"
  log: false
mqtt:
  mqtt:
    server: mqtt://core-mosquitto:1883
    user: Mein_User
    password: Mein Passwort
serial:
  port: >-
    /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696359-if00
  serial:
    adapter: deconz

und hier die Z2M.yaml

homeassistant: true
advanced:
  network_key:
    - 75
    - 160
    - 168
    - 180
    - 9
    - 29
    - 231
    - 115
    - 191
    - 10
    - 118
    - 67
    - 116
    - 176
    - 123
    - 156
  pan_id: 20841
  ext_pan_id:
    - 72
    - 85
    - 45
    - 120
    - 217
    - 23
    - 215
    - 85
  channel: 20
  last_seen: ISO_8601
mqtt:
  server: mqtt://core-mosquitto:1883
  user: addons
  password: ***************************************
  include_device_information: true
  keepalive: 60
  reject_unauthorized: true
  version: 4
serial:
  adapter: deconz
  port: >-
    /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696359-if00

Jim_OS · 2. Dezember 2024 um 09:25

OK auf den ersten Blick sehe ich da nicht wirklich etwas das diese Warnmeldung auslösen könnte. Wäre ja auch zu einfach.

Ich vermute das Problem kommt daher das es ja bekanntlich Probleme mit der Übernahme von irgendwelchen Einträgen die man im Z2M Addon GUI für die Konfiguration vornimmt und den Einträgen die dann in der Z2M configuration.yaml stehen. Auch wenn - wie ja auch in Deinem Fall - an beiden Stellen eigentlich das gleiche eintragen wurde.

Ich würde an Deiner Stelle als ersten Test erst einmal folgendes probieren. Lösch bei dem Z2M Addon GUI bei Konfiguration mal den MQTT-Part so das da unter MQTT gar nichts mehr steht.
Z2M_GUI_MQTT

Dann abspeichern und dann schauen ob der MQTT-Eintrag in der Z2M configuration.yaml noch vorhanden ist. Dort sollte und muss er weiterhin vorhanden sein! Dann das Z2M Addon mal neu starten und schauen ob Z2M noch normal funktioniert. Wenn ja den HA Host neu booten und schauen ob a) Z2M noch normal funktioniert und b) die Supervisor Warnung zu MQTT ggf. weg ist, bzw. nicht regelmäßig wieder auftaucht.

Warum dieser Test: Weil das m.M.n. eigentlich der einzige Ansatz ist dem Problem auf die Spur zu kommen, ohne das man Z2M kompl. löschen und neu einrichten müsste.

Anm. 1: Solche Supervisor Warnungen bzgl. Z2M gibt es schon seit Jahren (Beispiel) immer mal wieder und das liegt halt an der o.g. Problematik mit der nicht richtig funktionierenden Übernahme von Daten aus der Z2M GUI Konfiguration in die Z2M configuration.yaml. Warum das so ist dafür gab es irgendwie noch nie eine echte Erklärung. Auch nicht von Koenkk.

Anm. 2: Zu der serial Warnung kommen wir dann später.

VG Jim

maxe · 2. Dezember 2024 um 09:50

Ich soll ja eigentlich nicht helfen aber der serial unterm serial sieht mir falsch aus

Das selbe beim mqtt

In der yaml sieht es allerdings gut aus, kA ob das oben trotzdem stört.

Jim_OS · 2. Dezember 2024 um 09:58

OK ich brauche offensichtlich noch mehr Kaffee heute morgen damit ich Dinge besser erkennen kann. Jepp Du hast vollkommen Recht. Die Wiederholung von serial: und mqtt: ist dort in der Z2M GUI Konfiguration falsch.

@harryp Das bitte korrigieren und sorry das mir das nicht auch aufgefallen ist.

VG Jim

harryp · 2. Dezember 2024 um 10:30

Trotzdem Danke, genau Deine Vermutung war richtig => Fehler ist weg.
Blöd ist nur, dass man die “doppelten” Einträge nur sieht, wenn man die Konfiguration im yaml bearbeitet.

Kein Problem, wir sind ja alle nur Menschen, was auch gut so ist!

Jetzt wäre nur noch das Node-Red-Problem übrig.

dp20eic · 2. Dezember 2024 um 10:50

Moin,

wenn ich mir, die Meldung anschaue, ich befinde mich gerade noch ganz am Anfang mit NR, dann würde ich sagen, dass das Paket mpm in der Installation fehlt

Option 'mpm_packages' does not exist in the schema for Node-RED (a0d7b954_nodered)

Aber ein Paket mpm gibt es nicht, also denke ich, Du hast Dich irgendwo verschrieben und statt npm halt mpm geschrieben, schau mal alle Flows durch.

VG
Bernd

harryp · 2. Dezember 2024 um 11:41

Ich habe gar keine “npm”-node in meinem NR.

Ich werde jetzt mal im addons_Ordner nach Installationsleichen suchen und diese löschen.

crypton · 2. Dezember 2024 um 11:44

Schau dir mal die AddOn-Konfiguration als YAML an, da gibt es eine Sektion npm-packages, eventuell hast du da den Fehler.

harryp · 2. Dezember 2024 um 11:55

Ja, da war der Fehler drin!

Ich habe in der Konfiguration alle installierten Nodes unter “npm_packages” aufgelistet, damit die Nodes beim Backup auch mit gesichert werden (hierzu gab es beim letzten Release eine Änderung) und da hatte ich wirklich “mpm” geschrieben.

Damit sind jetzt die Warnmeldungen im Supervisor alle weg!

Update:

Leider kommt das CPU-Last und der NR-Neustart um 18:30 Uhr immer noch:

2024-12-02 18:27:39.321 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Cannot proxy websocket message of unsupported type: 258
2024-12-02 18:27:39.321 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API for a0d7b954_nodered closed
2024-12-02 18:28:20.658 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request initialize
2024-12-02 18:28:20.867 INFO (MainThread) [supervisor.api.proxy] WebSocket access from a0d7b954_nodered
2024-12-02 18:28:20.869 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request running
2024-12-02 18:29:41.322 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Cannot proxy websocket message of unsupported type: 258
2024-12-02 18:29:41.322 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API for a0d7b954_nodered closed
2024-12-02 18:30:09.207 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request initialize
2024-12-02 18:30:09.349 INFO (MainThread) [supervisor.api.proxy] WebSocket access from a0d7b954_nodered

Wenn ich die Fehlermeldung richtig interpretiere, dann kommt der Fehler vom Node-Red-„websocket“, das erklärt auch, warum der Fehler erst seit dem letzten Update von NR bzw. dem Websocket auftritt.

dp20eic · 2. Dezember 2024 um 17:54

Moin,

keine Fehler, das sind Info-Meldungen, also eigentlich zum Ignorieren.
Auf GitHub, gab/gibt es dazu schon einige Issues im home-assistant / supervisor dazu.

Es kann auch sein, dass Du mehrere Add-ons am Laufen hast, die den websocket nutzen und sich gegenseitig beeinflussen.

VG
Bernd

harryp · 2. Dezember 2024 um 17:59

Ja, auf GitHub habe ich auch schon mal geschaut.

Merkwürdig ist, warum es immer um 18:30 Uhr passiert und nur NR betrifft.
Eine Automatisierung, die um 18:30 Uhr triggert habe ich nicht.
Wie gesagt, passiert erst seit dem letzten Update von NR.

harryp · 3. Dezember 2024 um 17:51

So, habe heute mal den Supervisor-Log um 18:30 Uhr „überwacht“.

Mein Verdacht, dass meine Probleme mit dem „websocket“ zusammenhängen hat sich m.M.n. bestätigt:

2024-12-03 18:32:24.321 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Cannot proxy websocket message of unsupported type: 258
2024-12-03 18:32:24.322 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API for a0d7b954_nodered closed
2024-12-03 18:33:29.845 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request initialize
2024-12-03 18:33:29.996 INFO (MainThread) [supervisor.api.proxy] WebSocket access from a0d7b954_nodered
2024-12-03 18:33:29.998 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request running
2024-12-03 18:34:32.818 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
2024-12-03 18:38:28.320 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Cannot proxy websocket message of unsupported type: 258
2024-12-03 18:38:28.320 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API for a0d7b954_nodered closed

Werde morgen mal auf GitHub einen Issue aufmachen.