Proxmox -> Zigbee2MQTT -> Ausfälle

Allgemein
, ,
1

Moin zusammen,

vor einigen Monaten bin ich vom Raspi auf Proxmox umgestiegen - auch dank Simons Videos.
Einiges habe ich anders gemacht, das läuft aber (frigate mit coral auf einem anderen, leistungsstärkeren Knoten z.B.).
Aber eben auch mein Problemkind: Zigbee2MQTT. Von drei Instanzen laufen zwei und eine zuckt herum.

Proxmox läuft in einem Cluster aus drei Rechnern, nicht schwach auf der Brust. An der Leistung kann es nicht liegen, weder Prozessoren i5-9500T, 2x10Gb Netzwerk, RAM 32 oder 64GB oder ZFS-Speicher mit knapp 100TB.

Mittels onbord-Backup von HA mache ich täglich ein Backup auf eine Synology. = keine Probleme
Jeweils ein weiteres Backup bei der Installation neuer Software oder Addons bzw. deren Update. = keine Probleme
Das dritte Backup (jetzt fängt mein Problem an) mache ich über Proxmox und Proxmox Backup Server als Snapshot. Einer von drei LXC für Zigbee2MQTT starten “komisch”. Sie laufen, ziehen Speicher und CPU, aber die Webseite von Zigbee2MQTT wird nicht angezeigt. Diesen LXC-Container kann ich über Proxmox oder die Android App zu Proxmox einfach rebooten. Danach läuft es wieder stabil bis zum nächsten Tag.

Aufgrund der Größe meines Hauses und der Anzahl der Zigbee-Devices laufen 3 (ja, drei) unterschiedliche SLZB-06 (Firmware Version: 20240710 Zigbee v2.5.8 ESP) und drei Zigbee2MQTT LXC Container. Bei zwei von denen tritt überhaupt kein Problem auf. Nur bei einem von denen. Die SLZB-06 laufen übrigens problemlos. Migration auf andere Knoten brachten keine Änderung.

Proxmox läuft seit heute 8.3.0
Instanz 1:
Status running
HA-Status keine
Knoten pve
unprivilegiert Nein
CPU-Auslastung 0.00% von 2 CPU(s)
Speicherverbrauch 0.70% (14.36 MiB von 2.00 GiB)
SWAP-Auslastung 0.00% (0 B von 512.00 MiB)
Bootdisk-Größe 25.93% (1.04 GiB von 4.00 GiB
Zigbee:

Instanz 2:
Status running
HA-Status keine
Knoten pve
unprivilegiert Nein
CPU-Auslastung 0.00% von 4 CPU(s)
Speicherverbrauch 5.90% (120.90 MiB von 2.00 GiB)
Zigbee:
Zigbee2MQTT-Version
1.39.1 commit: 9027c41
Coordinator-Typ zStack3x0
Coordinator-Version 20240710
Coordinator IEEE Adresse 0x00124b00xxxxx
Frontend-Version 0.7.4
Zigbee Herdsman Konverter Version 19.72.0
Zigbee Herdsman Version 0.55.3

Instanz 3:
Status running
HA-Status keine
Knoten pve
unprivilegiert Ja
CPU-Auslastung 0.00% von 2 CPU(s)
Speicherverbrauch 5.73% (117.43 MiB von 2.00 GiB)
SWAP-Auslastung 0.00% (16.00 KiB von 1.00 GiB)
Bootdisk-Größe 32.67% (1.31 GiB von 4.00 GiB)
SWAP-Auslastung 0.00% (16.00 KiB von 1.00 GiB)
Bootdisk-Größe 42.03% (1.68 GiB von 4.00 GiB
Zigbee:
Zigbee2MQTT-Version
1.39.1 commit: ed9de74
Coordinator-Typ zStack3x0
Coordinator-Version 20240710
Coordinator IEEE Adresse 0x00124b00xxxxx
Frontend-Version 0.7.4
Zigbee Herdsman Konverter Version 19.72.0
Zigbee Herdsman Version 0.55.3

Ich habe an den Einstellungen des LXC schon herumgespielt. Ohne Erfolg.
Meist bringt ein reboot etwas. Manchmal erst der Einsatz folgender Befehle:
systemctl stop zigbee2mqtt
systemctl daemon-reload
systemctl start zigbee2mqtt
reboot

Einen Umbau auf 1 (ein) Zigbee-Netzwerk mache ich nicht mehr. Der Versuch endete grausam bei einer hohen dreistelligen Anzahl devices im Netzwerk.
Übrigens hat jedes Zigbee-Netzwerk eine eigene PAN und Frequenz, Zigbee Channel sowie base topic.
Die Daten werden an den auf HA laufenden MQTT broker übergeben (Mosquito).

Viel Blabla um eine Frage: gibt es nicht einen Watchdog, wie unter HA, der die Instanzen einfach wieder selbst startet, wenn mal eine hängt?

Dickes Danke für jede Idee und ein Bier für den, der das Problem löst.
Gruß
Knut

2

ZFS ist sehr RAM hungrig, es wird Empfohlen je 1 TB Speicher 1 GB RAM zur verfügung zu stellen.

Aktuell wäre die v1.41.0

Das wäre der einzige unterschied bei der 3ten Instanz im Vergleich zur ersten und zweiten.

Wobei Du die LXC ruhig unprivilegiert betreiben kannst, die Hardware Ressourcen kannst Du ja individuell mittlerweile in der GUI zuweisen.

Im Klartext, wie viele Geräte?
Bin bei kanpp 100 Geräten und kann noch keine Limitierung feststellen. Mit ausreichend Router Geräten sollten 200 bis 300 Geräte kein Problem sein.

  • Irgendwelche Fehler im Log von ZigBee2MQTT?
  • Läuft die dritte Instanz problemlos, wenn Du die erste und oder zweite oder beide Instanzen deaktivieren tust?
  • Sind an der Dritten Instanz im Unterschied zu den anderen, irgendwelche Geräte die das Netzwerk voll spamen?

Gruß
Osorkon

4

Hallo Osorkon,

ich bin gerade aufgewacht. Der letzte Akt war meine Anfrage und nach dem Aufwachen schon eine so geniale Antwort und Hilfe.

Der Speicher ist aufgeteilt:
Synology 218 20 TB
Synology 923+ 64 TB
TrueNAS 60 TB
Daher nur 60 TB als ZFS. Hätte ich besser notieren können.

Ich werde mal Zigbee2MQTT updaten auf 1.41.0. Das hätte ich schon vorher machen können.

Mit dem Thema “Privilegierung” hadere ich noch im Verständnis. Bei den ersten Versuchen mit frigate bin ich schon darüber gestolpert. Ich muss mich damit beschäftigen und auseinandersetzen.

Wie viele Z2M devices?
Hintergrund: das Haus hat vier Geschosse und ist in der Mitte mit einer stabilen Brandmauer senkrecht geteilt.
In jeder Etage Fenster, Türen, Radar, Schalter, Temperatursensoren und vor allem GU10 Leuchten.
In Summe über 210 devices.
Problematisch waren hier die Sensoren von Aquara, die immer am jeweiligen Router kleben blieben und dann öfter ausfielen. Zuerst habe ich von Conbee auf Sonoff USB als coordinator gewechselt. Danach auf die SLZB-06. Gestartet mit einem Ethernet-Coordinator. Ab und zu fielen Instanzen von Deckenleuchten aus, die als Router fungierten und zuemlich viel Unruhe ins Netzt brachten. Dann kam der zweite SLZB-06 in Spiel. In dem Fall als Repeater eingesetzt. War schon besser, aber nicht perfekt. Mit dem dritten klappt die Abdeckung nun perfekt.

Dank Deiner Antwort habe ich heute noch was vor:

  • Irgendwelche Fehler im Log von ZigBee2MQTT?
  • Läuft die dritte Instanz problemlos, wenn Du die erste und oder zweite oder beide Instanzen deaktivieren tust?
  • Sind an der Dritten Instanz im Unterschied zu den anderen, irgendwelche Geräte die das Netzwerk voll spamen?

Wenn ich damit durch bin, melde ich mich nochmal.
Erst einmal ein dickes Danke und hab ein schönes Wochenende!

Gruß
Knut

Für die, die noch danach suchen:
Updaten des Zigbee2MQTT LXC unter Proxmox

Das System updaten
apt update && apt upgrade -y

Run the update script from the Zigbee2MQTT directory
cd /opt/zigbee2mqtt
./update.sh

Etwas Zeit braucht es schon, aber es läuft. Der Versuch, das Update aus HA heraus anzustoßen funktionierte bei mir nicht.

Ich lerne täglich dazu. Bei dieser Art des Updates lief alles problemlos und es wurden vorher sogar Backups erstellt.

:pencil2: by tarag: Beiträge zusammengeführt

5

Der SLZB-06 ist ja per LAN angeschlossen, da brauchen die Container nicht privilegiert zu sein. Wenn immer der nicht-privilegierte Probleme macht, könnte man das aber mal umstellen.
Generell habe ich irgendwo mal gelesen, dass die Proxmox-Backups im Snapshot-Modus Probleme machen können. Das sicherste ist der Stop-Modus.
Das würde ich beides mal ausprobieren.

6

Moin,

das hängt aber davon ab, wie man es installiert hat, viele nutzen das Skript, vom leider vor kurzem Verstorbenen ttek,

Ich nutze Arch Linux, da wird das auch über deren Paketmanager erledigt, usw.

Ja, wie auch, du kannst von HA VM nicht auf eine LXC zugreifen, auf jeden Fall nicht ohne Klimmzüge, Skripting usw.

Das ist jetzt etwas, das ich nicht verstehe, wenn Du die SLBZs als Router einsetzt, dann brauchen die doch keine eigene Zigbee2MQTT Instanz, oder verstehe ich da etwas nicht, dann bitte einmal meinen Gordischenknoten im Kopf durchtrennen.

VG
Bernd

P.S.:

ich nutze Proxmox, seit ca. zweieinhalb Jahren, und PBS seit ca. 2 Jahren, erst lokal auf einem Synology NAS, aktuell nur noch extern bei einem Dienstleister, ich hatte noch nie Schwierigkeiten und ich nutze nur Snapshot :thinking:
Kannst Du da mal etwas Content zu beisteuern?

7

In der Proxmox-Doku selbst steht, dass der Snapshot-Mode ein kleines Risiko von Inkonsistenten hat. Das betrifft nun eigentlich nur das Restore und kann vor allem bei Datenbanken problematisch werden.
Irgendwo habe ich aber auch gelesen oder auf YT gesehen, dass es selten auch vorkommen kann, das der Container (oder VM?) beim Backup im laufenden Betrieb (Snapshot) abschmiert bzw. Probleme macht. Leider habe ich da keine Quelle mehr. Vielleicht hats mir auch ein Kollege erzählt…

Definitiv Hörensagen und daher nicht als verbrieft nehmen, aber ist zumindest ein Versuch wert wenn da Probleme sind. Kost ja nix. :slight_smile:

9

Genau die habe ich genutzt. Ich habe das auch mitbekommen mit ttek. Schon traurig. er hat sogar vom Bett aus weiter programiert.

Den Knoten habe ich noch immer im Kopf. Aber ich habe schon zu oft alle devices neu angelernt - jetzt werde ich da langsam faul.

:pencil2: by tarag: Beiträge zusammengeführt. Bitte bearbeiten Funktion nutzen.

11

Danke, ein sehr guter Hinweis.
Habe gerade einen weiteren aus der Logdatei erhalten:
“zh:zstack:znp: Socket error Error: read ETIMEDOUT” und darauf folgend
“Adapter disconnected, stopping”

Jetzt ist das Problem wieder da, aber ich sehe auch, woran es liegen könnte.
ich werde den betroffenen SLZB-06 mal neu aufsetzen und an einen anderen Switch hängen. Nacheinander. Vielleicht kann ich da den Fehler einkreisen.
Wie es scheint, kann Zigbee plötzlich nicht mehr mit dem SLZB-06 kommunizieren und gibt es dann auf.
In der Konsole “reboot” und es geht wieder.

Update:
ich versuche es mal mit “Stop”. Läuft gerade…

:crayon:by HarryP: Zusammenführung Doppelpost (bitte “bearbeiten” Funktion nutzen)

12

Moin,

ja, das ist sehr traurig, wenn Menschen, die der Community soviel gegeben haben, plötzlich nicht mehr da sind, wiederum schön, dass sich andere User darum bemühen, das Erbe der Helferskripte zu übernehmen und sie weiterzuführen.

Dann machst Du aber etwas falsch :wink:
Aus der Beschreibung vom Helferskript:

grafik
grafik1123×1012 128 KB

Beim LX Container, also der Basis, dem Debian, hast Du recht, da muss man manuelle ab und an ein update, upgrade machen

apt update && apt upgrade -y

VG
Bernd

P.S.: Korrektur, man kann doch auch nur update nutzen, habe ich auf die schnelle überlesen, Asche auf mein Haupt :frowning:

13

Die Lösung war so simpel und doch schwer zu finden.
Es waren zwei Probleme:

  1. Backup mittels “Stop” genutzt anstelle “Snapshot”
  2. Anstelle PoE aus dem Cisco-Router mal direkt mit USB-Strom versorgt. Das beseitigte den ETIMEDOUT Fehler mit disconnect.

Danke nochmals für euren Support - das war sehrt hilfreich.