Wird nächste Woche die Kompatibilität mit Debian 11 + Verbesserungen für Unraid/Synology gestartet?

Hier ist, was ich in den Logs hatte, mit einem Fehler, der sich mehrmals wiederholt hat und am Ende funktioniert es dann doch:

gandalf@hal9000:~ $ docker container logs --follow 26e90d537c66
Using '/app/data' as data directory
Zigbee2MQTT:info  2022-03-19 09:35:10: Logging to console and directory: '/app/data/log/2022-03-19.09-35-08' filename: log.txt
Zigbee2MQTT:info  2022-03-19 09:35:10: Starting Zigbee2MQTT version 1.24.0 (commit #7a2ddf2)
Zigbee2MQTT:info  2022-03-19 09:35:10: Starting zigbee-herdsman (0.14.20)
Zigbee2MQTT:error 2022-03-19 09:36:15: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-03-19 09:36:15: Failed to start zigbee
Zigbee2MQTT:error 2022-03-19 09:36:15: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2022-03-19 09:36:15: Exiting...
Zigbee2MQTT:error 2022-03-19 09:36:15: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby
    at ZnpAdapterManager.beginCommissioning (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:347:23)
    at ZnpAdapterManager.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:92:17)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:123:29)
    at Zigbee.start (/app/lib/zigbee.ts:58:27)
    at Controller.start (/app/lib/controller.ts:100:27)
    at start (/app/index.js:101:5)
[...]
Zigbee2MQTT:info  2022-03-19 10:30:41: Logging to console and directory: '/app/data/log/2022-03-19.10-30-39' filename: log.txt
Zigbee2MQTT:info  2022-03-19 10:30:41: Starting Zigbee2MQTT version 1.24.0 (commit #7a2ddf2)
Zigbee2MQTT:info  2022-03-19 10:30:41: Starting zigbee-herdsman (0.14.20)
Zigbee2MQTT:error 2022-03-19 10:31:47: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-03-19 10:31:47: Failed to start zigbee
Zigbee2MQTT:error 2022-03-19 10:31:47: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2022-03-19 10:31:47: Exiting...
Zigbee2MQTT:error 2022-03-19 10:31:47: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby
    at ZnpAdapterManager.beginCommissioning (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:347:23)
    at ZnpAdapterManager.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:92:17)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:123:29)
    at Zigbee.start (/app/lib/zigbee.ts:58:27)
    at Controller.start (/app/lib/controller.ts:100:27)
    at start (/app/index.js:101:5)
Using '/app/data' as data directory
Zigbee2MQTT:info  2022-03-19 13:01:45: Logging to console and directory: '/app/data/log/2022-03-19.13-01-43' filename: log.txt
Zigbee2MQTT:info  2022-03-19 13:01:45: Starting Zigbee2MQTT version 1.24.0 (commit #7a2ddf2)
Zigbee2MQTT:info  2022-03-19 13:01:45: Starting zigbee-herdsman (0.14.20)
Zigbee2MQTT:info  2022-03-19 13:01:58: zigbee-herdsman started (resumed)
Zigbee2MQTT:info  2022-03-19 13:01:58: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"zStack3x0"}'
Zigbee2MQTT:info  2022-03-19 13:01:58: Currently 0 devices are joined:
Zigbee2MQTT:info  2022-03-19 13:01:58: Zigbee: disabling joining new devices.
Zigbee2MQTT:info  2022-03-19 13:01:58: Connecting to MQTT server at mqtt://localhost:1884
Zigbee2MQTT:info  2022-03-19 13:01:58: Connected to MQTT server
Zigbee2MQTT:info  2022-03-19 13:01:58: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
Zigbee2MQTT:info  2022-03-19 13:01:58: Started frontend on port 0.0.0.0:8080
Zigbee2MQTT:info  2022-03-19 13:01:58: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"commit":"7a2ddf2","coordinator":{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"zStack3x0"},"log_level":"info","network":{"channel":11,"extendedPanID":"0x00124b00258de31f","panID":6754},"permit_join":false,"version":"1.24.0"}'
^C

Aber es ist unmöglich, die Geräte zu verbinden, der Temperatursensor wird überhaupt nicht gefunden :frowning:

Habt ihr auf euren RPIs sowohl das SSD als auch den Schlüssel? Die Dokumentation schlägt möglicherweise die Verwendung eines USB-Hubs mit eigener Stromversorgung vor. Ich habe jedoch ein offizielles Netzteil, das 3A liefert, und bei mir zu Hause gibt es keinen USB-Hub LOL

Okay, ich beende die Tests für heute.

Auf dem RPI mit 32 Bit läuft alles perfekt. Ich konnte die Erkennung der Geräte ohne Probleme neu starten und alles wurde leicht erkannt.

Auf meinem stationären Rechner mit Debian Bullseye 64 Bit (Intel-Prozessor, x86_64-Architektur „klassisch“) läuft ebenfalls alles perfekt (die Installation ist super schnell)

Screenshot from 2022-03-19 15-54-38

Die MQTT-Geräte wurden sofort erkannt (Temperatur- und Bewegungssensor), ich musste nicht einmal eine erneute Erkennung durchführen, alles erschien einwandfrei.

Auf dem RPI mit Bullseye 64 Bit scheint die Erkennung nicht richtig zu funktionieren. Der Temperatursensor erscheint schließlich als nicht erkannt (und ich glaube, dass Zigbee2mqtt nicht richtig mit dem Sensor kommunizieren kann) und ich kann nichts damit anfangen.

Was ich testen sollte, ist möglicherweise der Kauf eines USB-Hubs, da die FAQ von Zigbee dies für die Fehler erwähnt, die ich in den Logs hatte. Der RPI versorgt bereits das SSD, daher könnte es sein, dass das SSD plus der Zigbee-Sonoff-Schlüssel zu viel ist und der Schlüssel daher nicht richtig funktioniert. Ich habe keine andere Spur zur Untersuchung.

Ach ja, ich könnte auf die SD-Karte zurückkehren und sehen, ob es ohne das SSD funktioniert, falls es an unzureichender Stromversorgung liegt …

BINGO (Update) !!

Ich hatte gesagt, dass ich aufhöre, aber ich wollte Gewissheit haben. Ich habe von der SD-Karte neu gestartet (immer noch Bullseye 64 Bit). Update, Installation von Gladys und los geht’s. Daher scheint es, dass auf meinem RPI 4 (8GB) das SSD plus der Zigbee-Sonoff-Schlüssel zu viel für ein „offizielles“ Netzteil mit 3A und 5,1V (also 15,3W) ist (der RPI 4 mit 32 Bit lief auf SD-Karte).

Also, bei mir ist alles in Ordnung. Übrigens weiß ich nicht, wie oft ich Gladys heute bereitgestellt habe, aber es ist dennoch von außergewöhnlicher Einfachheit. Ein Docker-Befehl, 2 Minuten Konfiguration und los geht’s. Also entschuldige, dass ich Alarm geschlagen habe, ich habe keine Probleme mit Gladys, aber es ist gut zu wissen, dass, wenn Sie ein SSD verwenden, Sie möglicherweise einen USB-Hub in Betracht ziehen sollten, der unabhängig vom RPI mit Strom versorgt wird.

Die Fortsetzung der Fortsetzung :slight_smile:

Ich habe es geschafft, mit einer cidfile zu starten, indem ich geschummelt habe (der Besitzer der cidfile ist der Benutzer pi)

docker run -d \
    --cidfile ~/GladysContainerId \
    --restart=always \
    --privileged \
    --network=host \
    --log-opt max-size=5m \
    --name gladys \
    --cap-add SYS_RAWIO \
    -e NODE_ENV=production \
    -e SERVER_PORT=80 \
    -e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
	-v ~/GladysContainerId:/var/lib/gladysassistant/containerId:ro \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /var/lib/gladysassistant/:/var/lib/gladysassistant/ \
    -v /dev:/dev \
    -v /run/udev:/run/udev:ro \
    -v /sys/class/gpio:/sys/class/gpio \
    -v /etc/localtime:/etc/localtime:ro \
    -v /etc/timezone:/etc/timezone:ro \
    gladysassistant/gladys:dev

Aber jetzt passieren seltsame Dinge (zu beachten, dass ich jedes Mal die Datenbank, die Ordner usw. lösche…)

Beim ersten Start von Gladys macht die MQTT-Integration ihr eigenes Ding ^^, ich habe noch nicht einmal einen Benutzer erstellt.

2022-03-21T09:25:35+0100 <info> 20210129155044-multi-user.js:23 (Object.up) Multi-User-Migration: 0 Benutzer gefunden
2022-03-21T09:25:35+0100 <info> job.purge.js:17 (Job.purge) Löschen aller Hintergrundjobs, die vor = Mon Mar 14 2022 09:25:35 GMT+0100 (Mitteleuropäische Normalzeit) erstellt wurden
Initialisierung des OpenZWave 1.6.0 Binary Add-Ons für Node.JS.
        OpenZWave Security API ist AKTIVIERT
        ZWave-Geräte-Datenbank: /usr/local/etc/openzwave
        Benutzereinstellungen-Pfad: /src/server/services/zwave/node_modules/openzwave-shared/build/Release/../../
        Optionen-Überschreibungen: --Logging false --ConsoleOutput false --SaveConfiguration true
2022-03-21T09:25:40+0100 <info> index.js:19 (Object.start) Starten des Beispiel-Dienstes
2022-03-21T09:25:40+0100 <info> index.js:64 (Object.start) Starten des CalDAV-Dienstes
2022-03-21T09:25:40+0100 <info> index.js:16 (Object.start) Starten des MQTT-Dienstes
2022-03-21T09:25:40+0100 <info> updateContainer.js:13 (MqttHandler.updateContainer) MQTT: Überprüfung auf erforderliche Änderungen...
2022-03-21T09:25:40+0100 <info> updateContainer.js:18 (MqttHandler.updateContainer) MQTT: Update auf mosquitto v2 erforderlich...
2022-03-21T09:25:40+0100 <info> installContainer.js:19 (MqttHandler.installContainer) MQTT-Broker wird als Docker-Container installiert...
2022-03-21T09:25:40+0100 <info> installContainer.js:23 (MqttHandler.installContainer) Gladys-Netzwerk überprüfen...
2022-03-21T09:25:40+0100 <info> installContainer.js:29 (MqttHandler.installContainer) eclipse-mosquitto:2-Image wird heruntergeladen...
2022-03-21T09:25:42+0100 <info> installContainer.js:33 (MqttHandler.installContainer) Vorbereitung der Broker-Umgebung...
2022-03-21T09:25:42+0100 <info> installContainer.js:37 (MqttHandler.installContainer) Container wird erstellt...
2022-03-21T09:25:43+0100 <info> installContainer.js:45 (MqttHandler.installContainer) MQTT-Broker wurde erfolgreich als Docker-Container installiert
2022-03-21T09:25:44+0100 <info> updateContainer.js:39 (MqttHandler.updateContainer) MQTT: Update auf mosquitto v2 abgeschlossen
2022-03-21T09:25:44+0100 <info> service.start.js:40 (Service.start) Der Dienst mqtt ist nicht konfiguriert, daher wurde er nicht gestartet.
2022-03-21T09:25:44+0100 <info> index.js:14 (Object.start) Starten des GoogleActions-Dienstes
2022-03-21T09:25:44+0100 <info> init.js:36 (Zigbee2mqttManager.init) Zigbee2mqtt-USB-Dongle nicht angeschlossen
2022-03-21T09:25:44+0100 <info> index.js:18 (Object.start) Starten des TP-Link-Dienstes

Ich befinde mich also in einem instabilen Zustand, aus dem ich nicht herauskomme.

Ah okay, ich verstehe, aber dann ist der Docker Run speziell für den Raspberry Pi, und außerdem ist es nicht verkehrt, alle Daten in /home/pi zu legen.

Ich bevorzuge die Version, die ich weiter oben gepostet habe!

Super!! :smiley: Schön, dass es am Ende doch funktioniert hat :slight_smile:

Und ich die dritte :slight_smile:

aha, du hast deine Nachricht geschickt, während ich meine getippt habe, habe ich nicht gesehen!

Es ist schon besser, aber ist der Home-Ordner des Benutzers wirklich ein Ort, an dem man kritische Informationen zur Ausführung von Gladys speichern sollte? Es ist, als ob eine App eine super wichtige Datei auf deinem Desktop speichert, eine Datei, die, wenn du sie löschst, die App nicht mehr richtig funktioniert…

Zu riskant so, ich bevorzuge immer noch die erste Version ohne die cid-Datei.

Man geht davon aus, dass der Benutzer keine SSH etc. ausführen muss und dass Gladys sicher ist, aber man ist viel mehr gefährdet.

Man könnte dasselbe über den Ordner /var/lib/gladysassistant sagen, wenn der Benutzer ihn löscht, ist alles im Eimer :slight_smile:


Trotzdem gibt es einen Fehler in der Verwaltung der Container, ich verstehe nicht, warum Gladys mir beim ersten Start eine Mosquitto-Konfiguration erstellt

Das gilt nur, wenn der Benutzer das von uns vorgefertigte Image verwendet, aber es gibt immer noch eine nicht unerhebliche Anzahl von Leuten, die Gladys auf einer Maschine installieren, die andere Container hat (Pi-Hole, etc.), und die Gladys mit docker run starten. Diese Erfahrung ist auch wichtig :slight_smile:

Diese Leute, ich bin mir nicht sicher, ob sie sich nach 6 Monaten erinnern, wenn sie zurückkommen und es eine Datei in /home/pi gibt, ob sie sie behalten müssen.

Es gibt trotzdem einen Unterschied zwischen dem Ordner, in dem du landest (das Äquivalent zum Desktop), und dem Ordner /var/lib, der einen Ordner pro Anwendung enthält.

Bist du dir zu 100% sicher, dass du die Container vor dem Neustart von Gladys richtig gestoppt und gelöscht hast?

Der Code ist da ziemlich klar:

Er macht ein getContainers und sieht, was zurückkommt

Ja, da wird man kleinlich, ich habe es dort zum Testen hingelegt, aber ~/.config/gladys geht auch sehr gut

Ich hatte bereits mosquitto (das könnte sehr gut schon existieren), wenn das der Fall ist, sollte der Fehler behandelt werden (Container existiert, aber der Dienst ist nicht konfiguriert/ohne Konfiguration).

Dann nehmen wir das Problem mal von der anderen Seite her. Was ist deiner Meinung nach falsch an der Option --cgroupns=host?

War das nicht bisher das Standardverhalten unter Docker?

Ich bin einverstanden, erstellst du ein GitHub-Issue?

Das ist eine zusätzliche exponierte Schicht (die uns bisher egal war, das gebe ich zu).

Ja, der Standard-Namespace war der des Hosts. (Das hat uns Probleme mit cgroupsv2 + systemd bereitet.)

Was jetzt dringend empfohlen wird, ist der Benutzer-Namespace aus Sicherheitsgründen.


Zum Abschluss: Keine cidfile auf dem rpi-Image, aber wir lassen die Möglichkeit trotzdem offen für diejenigen, die --cgroupns=host nicht verwenden möchten?

Ok, ich verstehe.

Erneut verstehe ich diese Sicherheitsmaßnahmen im Cloud-Kontext (für einen Hosting-Anbieter, der Kundencontainer startet, die gut isoliert sein müssen), in unserem Fall etwas weniger.

Wenn die cidfile einfach und problemlos funktionieren würde, wäre ich motiviert, über die cidfile zu gehen, aber angesichts unserer gemeinsamen Erfahrung mit (und ich denke nicht, dass wir Docker-Nullen sind! :p), sehe ich schon die Nachrichten auf dem Forum für alle, die docker run für ihre Installation anpassen wollen.

Dort, wo cgroup gut funktioniert und universell ist.

Ich denke, wir werden uns dafür entscheiden.

Der --cgroupns=host überall: im Rpi-Bild, auf der Website, für Synology/Unraid.

Ich lasse den cidfile-Code-Snippet in der Codebase, das gibt uns eine Option, falls sich die cgroup-Seite wieder ändert, und falls jemand Gladys in einem besonderen Kontext ohne cgroupns=host starten möchte, haben wir die Option :slight_smile: Aber ich kommuniziere nicht darüber auf der Website.

:pray: das ist okay für mich :smiley:

Perfekt! :slight_smile:

Da das Feedback zu diesem Build positiv ist und dieses Release viele Fälle freischaltet (Synology/Unraid/Raspberry Pi OS 64-Bit), beginne ich mit der Vorbereitung für ein baldiges Release!

Ich halte euch auf dem Laufenden.