[Tester gesucht] Neues Gladys Raspberry Pi OS-Bild unter Bullseye

Etwas reißerischer Titel! ^^

Der Test wurde auf einem Raspberry Pi 400 mit 4 GB RAM durchgeführt, also ja, in diesem Fall gibt es einen echten Boost, da ein 32-Bit-System maximal etwa 3,5 GB RAM verwaltet, und der Wechsel zu 64 Bit ermöglicht es einem einzelnen Prozess, bei Bedarf den gesamten RAM zu nutzen :slight_smile:

Auf jedem anderen Pi wird der Gewinn nicht so groß sein, und er kann sogar auf bestimmten Modellen negativ sein.

Aber ich stimme zu, dass ein 64-Bit-Image nützlich sein wird, ab dem Pi 4 gibt es laut Benchmarks ein echtes Interesse

(Und ich habe Gerüchte über einen Raspberry Pi 4 + mit bis zu 16 GB RAM gehört… Dann wird es eindeutig notwendig sein)

Ihre Spezialität!

Der Preis wird beißen!

Du hast recht, wenn es sogar 2% mehr Leistung bringt, ist es ideal, auf 64-Bit umzusteigen.

Was mich interessiert, ist, dass ein 64-Bit-System theoretisch bessere Leistung bei Operationen wie Verschlüsselung/Komprimierung bieten kann.

In Gladys kann das einen echten Einfluss auf den gesamten Gladys-Plus-Bereich haben:

  • Theoretisch schnellere Ende-zu-Ende-Verschlüsselung?
  • Die tägliche Sicherung (Gzip-Komprimierung + OpenSSL-Verschlüsselung)

Ja, man muss einfach eine dedizierte Konfigurationsdatei erstellen. Ich möchte, dass wir zuerst Bullseye fixieren, wenn alles läuft, machen wir 64-Bit.

Falls Test nötig sind, habe ich einen RPi 4 mit 4 GB und eine SSD. Gladys ist darauf installiert, aber es ist auch mein Media Center (Kodi), daher mein Interesse an verbesserten Leistungen :wink:

Kleines Update für Bullseye

2 neue Builds verfügbar

Image arm64 (Raspberry Pi OS 64-Bit) => https://github.com/GladysAssistant/gladys-pi-gen/releases/download/v0.3.0/gladys-os-rpi64-v0.3.0.zip
Image arm => https://github.com/GladysAssistant/gladys-pi-gen/releases/download/v0.3.0/gladys-os-rpi-v0.3.0.zip

Viel Spaß beim Testen :blush:

Die GitHub-Release
https://github.com/GladysAssistant/gladys-pi-gen/releases/tag/v0.3.0

Ich teste gerade das 32-Bit-Bild für meinen Teil…

Bisher läuft alles gut:

Erste Rückmeldung zum 32-Bit-Bullseye-Bild:

:white_check_mark: Problemlose Installation, alles funktioniert wie zuvor
:white_check_mark: MQTT-Integration funktioniert, der Container wird gestartet und läuft gut
:white_check_mark: Zigbee2mqtt-Integration funktioniert

:white_check_mark: Bluetooth funktioniert, der Scan läuft gut (Raspberry Pi 3B+)
:white_check_mark: Kamera-Integration funktioniert (man weiß ja nie)

Ich habe die anderen Integrationen (ZWave, Xiaomi usw.) nicht getestet, aber meiner Meinung nach sollte das auch funktionieren.

Tolle Arbeit @VonOx!!

Ich wechsle jetzt zum 64-Bit-Test.

Puh :sweat_smile:

Rückmeldungen zum Raspberry Pi OS 64-Bit Bullseye-Image:

:white_check_mark: Start ok, wie gewohnt
:white_check_mark: MQTT-Integration funktioniert
:white_check_mark: Zigbee2mqtt-Integration funktioniert
:white_check_mark: Bluetooth-Integration funktioniert
:white_check_mark: Kamera-Integration funktioniert

Alles scheint gut zu sein!!

Tolle Arbeit @VonOx :smiley:

Hallo zusammen, ich wollte wissen, ob einige von euch vorhaben, diese Bilder zu testen?

Ich bin der Einzige, der es getestet hat, das reicht nicht für den Produktivbetrieb :smiley:

Rückmeldungen zum Raspberry Pi OS 64-Bit-Bullseye-Bild auf SSD/Pi 4 - 8 GB:

:white_check_mark: Start ok,
:white_check_mark: Backend-Update beim Starten,
:white_check_mark: MQTT-Integration funktioniert,
:white_check_mark: Zigbee2mqtt-Integration funktioniert, ein Fehler ist beim Starten aufgetreten, aber er hat sich selbst darum gekümmert ^^

Zigbee-Logs

:white_check_mark: Bluetooth-Integration wurde schnell mit meinem Telefon getestet, es hat es gut erkannt und ich konnte es hinzufügen … keine anderen Bluetooth-Geräte ^^ aber es scheint funktionell zu sein,
:white_check_mark: Kamera-Integration funktioniert,
:white_check_mark: Tasmota-Integration funktioniert,
:white_check_mark: Gladys Plus-Backup scheint funktionell, die Dateien wurden im Ordner /var/lib/gladysassistant/backups/ erstellt, aber bisher kein Refresh des Versands an das Backend


Ich nutze die Gelegenheit, um eine Rückmeldung zur laufenden Ausführung und den Schritten zu geben, die bei einem manuellen Backup durchgeführt wurden (im Backup-Ordner sieht man, dass es einen ersten Schritt der Datenbankkopie gibt, dann einen zweiten der Komprimierung und schließlich, wie ich vermute, den Versand an Gladys Plus. Wenn ein Schritt blockiert, könnte die Nachricht möglicherweise angeben, in welchem Schritt, um besser debuggen zu können),

Edit : Nach 5 Minuten ist alles in Ordnung ^^
image

:white_check_mark: Aggregationen funktionieren,

Alles scheint bisher auch in Ordnung zu sein, jetzt müssen wir nur noch sehen, ob es mit der Zeit für die Backups in Ordnung ist!!
Zur Information scheint mir die Oberfläche viel schneller zu sein, insbesondere die Seiten mit vielen Diagrammen … Ist das mit den 64 Bit verbunden??

Tolle Arbeit aller :smiley:

Danke für das Feedback @Terdious, das freut mich sehr zu lesen!! :smiley:

@lmilcent hat mir im Dezember das gleiche Feedback gegeben, ich habe ein GitHub-Issue erstellt:

Ja, das liegt an den 64 Bit, und meiner Meinung nach liegt es mehr am Docker-Image, das in ARMv8 64 Bit gebaut wurde, als am Betriebssystem selbst!

Also, bisher, um ein einziges Image zu haben, das auf allen Raspberry Pi läuft, haben wir das Docker-Image in ARMv6 gebaut (weil die Pi 1, 2 und Zero ARMv6 sind)

Das Schlimme daran war, dass dein Pi 4 einen ARMv8-CPU hat, der viel mehr Befehle hat. Durch Rückwärtskompatibilität funktionierten die ARMv6-Images trotzdem, aber ohne alle Möglichkeiten des CPUs zu nutzen.

Durch den Wechsel zu 64 Bit lädst du jetzt das Docker-Image linux/arm64/v8, das für diese Architektur kompiliert ist.

Alles, was kompilierter Code ist oder auf kompilierte Systemfunktionen zurückgreift, sollte seine Leistung deutlich verbessern:

  • Zugriff auf die DB (da die SQLite3-Binärdatei nun in ARMv8 64 Bit kompiliert ist)
  • Ende-zu-Ende-Verschlüsselung für Gladys Plus, Komprimierung und Verschlüsselung der Backups
  • Alles, was mit Komprimierung, Verschlüsselung, Berechnungen zu tun hat

Es wäre toll, diese Verbesserungen zu quantifizieren, um einen kleinen Blog-Post zu machen :smiley: (mit einem kleinen Clickbait-Titel)

Aufgrund deiner Rückmeldung, da diese wirklich positiv ist und dem entspricht, was ich auch gesehen habe, habe ich das Bild auf der Website und im Rpi-Imager veröffentlicht!

Ich werde vorerst keine Kommunikation dazu starten, sondern das Bild erstmal langsam herunterladen lassen und sehen, was passiert :slight_smile: Ich denke, ich werde nächste Woche damit beginnen.

Die Website auf FR:

Die Website auf EN:

Rpi Imager:

Für euch, die Gladys kennt, empfehle ich nicht, das im Rpi-Imager angezeigte Bild zu verwenden (sondern einen manuellen Download + Rpi Imager), da ich festgestellt habe, dass das „Erweitert“-Menü, mit dem die Wi-Fi-Anmeldedaten eingegeben werden können, auf den nicht-kustomisierten Bildern nicht angezeigt wird, aber es erscheint, wenn man das Bild lokal herunterlädt:

Ich glaube, der Fehler wurde bereits an die Stiftung gemeldet.

Ich war gerade kurz auf RPi Imager und habe festgestellt, dass es für HA ein kleines (i) gibt, das zu ihrer Website verlinkt…

Bei der Arbeit :wink:
Und tatsächlich, kein Zahnrad, aber das Menü erscheint mit der ursprünglichen Tastenkombination: Strg+Umschalt+X

Top ^^

Oki !! Also ist das verständlich ^^

Nach fast zwei Tagen Feedback habe ich jedoch eine Bemerkung: Ich habe wieder „Einfrierungen“, die weniger häufig auftreten (ich habe den Eindruck, dass dies nur bei Anfragen zur Erstellung/Löschung von Geräten auftritt) und kein Absturz von Gladys, die Seite bleibt angezeigt, bleibt aber etwa 2 Minuten lang in der Suche. Ich habe keine Ahnung, woher das kommen könnte, im Gegensatz zu früher gibt es keine Docker-Logs. Alles ist eingefroren. Im Inspektor ist es dasselbe, keine Anfrage wird gesendet, das Einzige, was ich sehen kann, ist das:


image

Bis zu 2 Minuten zum Laden der Seite.

Ich weiß, was passiert, du hast tatsächlich ein Gerät gelöscht.

Allerdings löscht Gladys derzeit, wenn du ein Gerät löschst, alle damit verbundenen device_features sowie die Zustände dieser Features :smiley:

Du hast es verstanden, wenn hinter diesem Gerät tausende von Zuständen stehen, kann das 2 Minuten dauern und in dieser Zeit ist die Datenbank blockiert, da es eine riesige Transaktion ist, die die gesamte Bandbreite der Festplatte beansprucht.

Wir haben eine Lösung in Betracht gezogen, falls dieses Problem zu häufig auftritt, nämlich die Zustände auf sanftere Weise zu löschen, indem ihre Löschung über die Zeit gestreckt wird (z. B. 200 pro 200), um der Gladys-Instanz zwischen den Löschvorgängen etwas Luft zu verschaffen.

Danach ist es eine eigenständige Entwicklung :slight_smile: Du kannst ein GitHub-Issue erstellen, damit wir eine Spur davon behalten? Ich kann nicht garantieren, dass ich in den kommenden Tagen daran arbeiten werde, aber du hast recht, es ist ein wichtiger Punkt :slight_smile:

Danke für dein Feedback,

Kein Problem, ich erledige das für dich. Natürlich gibt es da keine Eile, man löscht nicht jeden Tag ein Gerät. Und solange wir wissen, dass es normal ist, können wir geduldig sein ^^