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

Hallo zusammen!

Die nächste Version von Gladys ist fast fertig und bringt eine Reihe neuer Kompatibilitäten und Fehlerbehebungen :slight_smile:

Dieses Mal gibt es keine neuen Funktionen, sondern langfristige Arbeiten an der Kompatibilität mit den neuen Hauptversionen der Linux-Betriebssysteme: Debian 11 und Ubuntu > 20.04, sowie Änderungen, um eine erleichterte Installation auf NAS-Unraid und Synology zu ermöglichen.

Es gab insbesondere Probleme beim Starten der MQTT- und Zigbee2mqtt-Container auf diesen Plattformen.

Die Fehlerbehebungen

  • Behebung eines ziemlich wichtigen Bugs, bei dem die Aktualisierungsfrequenz von Geräten wie Kameras nach einer Änderung nicht immer berücksichtigt wurde, oder schlimmer noch, die Aktualisierungsfrequenz wurde mehrmals berücksichtigt, was dazu führte, dass eine Kamera, deren Frequenz geändert wurde, mehrmals pro Zyklus aktualisiert wurde

  • Behebung eines Bugs in den Szenen, bei dem der „Testen“-Button der Aktion „HTTP-Anfrage“ die angegebenen Header nicht berücksichtigte

  • Behebung eines Bugs, bei dem der Name eines Dashboards in der Liste nicht aktualisiert wurde, wenn der Name des aktuellen Dashboards umbenannt wurde

  • Hinzufügen von Übersetzungen zu den Vibrationssensoren

Ich brauche euch

Ich brauche euch, um diese Version im Voraus zu testen. Ich wende mich an ein BESTÄTIGTES Publikum!! Wenn du diesen Beitrag liest und dir nicht sicher bist, warte nächste Woche auf die Veröffentlichung des Produktionsimages :wink:

Ich weiß, dass viele von euch die Kompatibilität mit Debian 11 / Ubuntu 21 gefordert haben, ich brauche euch, um zu überprüfen, dass alles funktioniert, insbesondere in Bezug auf die Integration von Zigbee2mqtt und MQTT.

Wenn du weißt, was du tust, kannst du das Docker-Image « Gladys DEV » mit folgendem Befehl starten:

(Nicht auf einer echten Gladys-Produktionsinstanz ausführen…)

docker run -d \
--log-driver json-file \
--log-opt max-size=10m \
--cgroupns=host \
--restart=always \
--privileged \
--network=host \
--name gladys \
-e NODE_ENV=production \
-e SERVER_PORT=80 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
-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 \
gladysassistant/gladys:dev

Wie ihr sehen könnt, handelt es sich hier um ein Docker-Dev-Image (gladysassistant/gladys:dev), dieser Tag entspricht unseren Pre-Release-Deployment-Tests, dieser Tag sollte nicht für eine echte Installation verwendet werden :slight_smile:

Etwas, das interessant ist, mit dieser Version zu testen, ist die Änderung des Docker-Volume-Pfads, z. B. durch Ändern dieser Zeile: -v /var/lib/gladysassistant:/var/lib/gladysassistant \ durch Festlegen eines anderen Host-Ordners (links) und anschließendes Starten eines MQTT- und Zigbee2mqtt-Containers, um zu überprüfen, ob die Container mit dem gleichen Volume auf dem Host gestartet wurden.

Ich nutze die Gelegenheit, um einen zweiten Aufruf an Tester für @bertrandda zu machen, der an der Integration von Caldav gearbeitet hat, um wirklich alle Kalender zu unterstützen.

Er sucht Tester für dieses Thema:

Verlässt du die cidfile?

Das cgroupns ist wirklich zu permissiv und nicht jeder läuft Gladys auf einem Raspberry Pi :neutral_face:

Ich habe es nicht geschafft, Gladys ohne cgroups zum Laufen zu bringen. Funktioniert es bei dir?

Falls du ein funktionierendes docker run hast, bin ich dankbar :slight_smile:

Edit: Ich spreche von Debian 11

Ich habe es gerade bei mir zu Hause getestet, es läuft perfekt bisher.

Der gleiche Befehl, aber mit der cidfile und ohne cgroupns (rpi Debian 11).

Bist du sicher @VonOx? Ich hatte bei meinen Tests DNS-Fehler.

Ja, basierend auf dem letzten Produktionsbild, auf das ich den PR angewendet habe.

Ich versuche es morgen mit dem Entwicklungsbild, um es zu verstehen.

Wenn du einen genauen Docker-Befehl hast, der bei dir funktioniert, kann ich den gerne haben. Ich werde nächste Woche weitere Tests durchführen.

Ich halte dich auf dem Laufenden

Ich werde diesen neuen Container ab morgen testen. Ich habe meinen Zigbee-Schlüssel, der nur darauf wartet, und Komponenten zum Testen (Präsenzsensor und Temperatursensor). Ich laufe auf bullseye 64-Bit auf einem RPi4. Ich halte euch morgen auf dem Laufenden. Danke für dieses Release, das ist super!

@pierre-gilles meine ersten Versuche waren nicht erfolgreich.

Erstens, ich habe zunächst das lokale Verzeichnis der Volumes geändert (/var/lib/gladysassitanttest statt /var/lib/gladysassistant standardmäßig). Die Installation der Container hat dann Probleme verursacht und ich habe festgestellt, dass zigbee2mqtt sich trotzdem im Standardverzeichnis und nicht in dem von mir angegebenen installiert hat. Zum Glück hatte ich mein Verzeichnis /var/lib/gladysassistant gesichert, um meine Produktionskonfiguration nicht zu zerstören :slight_smile:

Kurz gesagt, ich lösche die Container und fange von vorne an, diesmal ohne die Docker-Befehle zu ändern, die du angibst. Diesmal läuft es ein bisschen besser, aber ich stoße etwas weiter vorne auf ein Problem:

Ich habe festgestellt, dass der Container gladys-z2m-zigbee2mqtt nicht stabil zu sein scheint. Er scheint ständig neu zu starten.

Außerdem habe ich nie Zugriff auf die zigbee2mqtt-Schnittstelle auf Port 8080 (was logisch erscheint).

Natürlich, da ich ein Anfänger bin, verwende ich eine 64-Bit-Version von RaspiOS. Ich habe einen anderen Raspi mit 32-Bit auf Bullseye mit Docker und Gladys, ich werde es dort ausprobieren, um zu sehen, ob es besser funktioniert.

@p6ril Hast du zufällig schon das Docker-Dev-Image auf dieser Instanz installiert? Es wundert mich, dass der häufigste Anwendungsfall bei dir einfach nicht funktioniert.

Als du docker run ausgeführt hast, wurde da ein Download des Images durchgeführt oder war das Image bereits lokal vorhanden?

Du kannst docker pull gladysassistant/gladys:dev ausführen, um das zu überprüfen.

@pierre-gilles ich bestätige, dass ich anfangs das Docker-Dev-Image nicht hatte. Beim zweiten Versuch bin ich auch wieder von vorne angefangen (ich habe die Container „gepruned“ und alle zugehörigen Images gelöscht, also gladys dev, und die mqtt- und zigbee2mqtt-Container). Beide Male wurden die Container heruntergeladen.

Debugging für cidFile gestartet

Berechtigungsproblem in /var/lib/gladysassistant (seltsam, da es selbst mit sudo nicht funktioniert) und ich habe dieses Problem nicht auf Ubuntu

Daher habe ich versucht, den Host-Mount zu ändern (das Verzeichnis muss vor der Ausführung des Befehls erstellt werden)

docker run -d \
    --cidfile /home/pi/gladysassistant/containerId \
    --restart=always \
    --privileged \
    --network=host \
    --log-opt max-size=10m \
    --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 /var/run/docker.sock:/var/run/docker.sock \
    -v /home/pi/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

Ergebnis:+1:

Ich suche weiter auf der Berechtigungsseite

@pierre-gilles in 32-Bit lief alles super, ich habe dein YouTube-Video gefolgt, es war super glatt :

hier sind einige Infos über die Maschine, auf der alles funktioniert:

Screenshot from 2022-03-19 11-46-19

und in 64-Bit startet zigbee2mqtt nicht richtig:

Screenshot from 2022-03-19 11-47-16

Ich kann helfen, wenn Logs oder zusätzliche Infos zu Bullseye in 64-Bit benötigt werden.

Ist udev auf deinem Debian 64 installiert?

hal9000 :smirking_face:

ja, udev ist installiert:

Screenshot from 2022-03-19 12-47-40

Der Sonoff-Schlüssel wird korrekt erkannt, das Problem scheint vom Zibgee2MQTT-Container auszugehen, der nicht startet. Vielleicht ein Problem mit dem Image für die Zielarchitektur?

Man muss die Logs des zigbee2mqtt-Containers anschauen.

Ich war kurz davor, das zu tun, aber dann ist es schiefgegangen …

Ich habe gesehen, dass der Zigbee2MQTT-Container nicht mehr in der Liste war, die von docker container ls zurückgegeben wurde.
Die Zigbee-Konfiguration war deaktiviert (da ich den Zigbee-Sonoff-Schlüssel entfernt hatte). Ich habe den Schlüssel wieder eingesetzt, die USB-Dongle-Konfiguration aktualisiert, zigbee2mqtt wieder aktiviert und jetzt scheint alles in Ordnung zu sein.

Alle Container sind up und die Verbindung zwischen Gladys, MQTT und Zigbee2MQTT ist hergestellt. Seltsam.

Falls Sie möchten, kann ich alles löschen, um die Installation von vorne zu beginnen?