[Recherche de testeurs] Nouvelle image Gladys Raspberry Pi OS sous Bullseye

Titre assez clickbait ! ^^

Le test a été effectué sur un Raspberry Pi 400 avec 4Go de RAM, donc oui dans ce cas là ça fait un vrai boost car un système 32 bits gère environ 3.5 GB de RAM max, et le passage au 64 bits permet à un seul process de prendre toute la RAM au besoin :slight_smile:

Sur n’importe quel autre Pi, le gain ne sera pas aussi fort, et il peut même être négatif sur certain modèle.

Mais je suis d’accord sur le fait qu’avoir une image 64 bits sera utile, à partir du Pi 4 d’après les benchmark il y a un vrai intérêt

( Et j’ai cru voir des leaks d’un Raspberry Pi 4 + qui aurait jusqu’à 16Go de RAM… Là ce sera clairement nécessaire )

1 « J'aime »

Leur spécialité !

Le prix va piquer !

Tu as raison, si ça ajoute même 2% de perf en plus c’est l’idéal de passer en 64 bit.

Là où ça m’intéresse, c’est que théoriquement un système 64 bits peut avoir des performances améliorées sur les opérations genre chiffrement/compression.

Dans Gladys, ça peut avoir un vrai impact sur toute la partie Gladys Plus :

  • Le chiffrement de bout en bout théoriquement plus rapide?
  • La sauvegarde quotidienne (compression gzip + openssl pour le chiffrement)

Oui y’a juste a faire un fichier de conf dédié, je préfère qu’on fixe d’abord bullseye, si tout roule on fera du 64 bits.

3 « J'aime »

Si besoin de test, j’ai un RPi 4 4Go et SSD Gladys est dessus mais c’est aussi mon Media Center (Kodi) d’où mon intérêt pour des performances améliorées :wink:

Petite update pur bullseye

2 nouveaux build disponibles

Image arm64 ( Raspberry Pi OS 64 Bits ) => 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

A vos tests :slight_smile:

la release github

1 « J'aime »

En cours de test de l’image 32 bits pour l’instant pour ma part…

Tout se passe bien pour l’instant :

Premier retour sur l’image 32bits Bullseye :

:white_check_mark: Installation sans souci, tout fonctionne comme avant
:white_check_mark: Intégration MQTT fonctionnelle, le container est lancé, tourne bien
:white_check_mark: Intégration Zigbee2mqtt fonctionnelle

:white_check_mark: Bluetooth fonctionnelle, le scan marche bien ( Raspberry Pi 3B+ )
:white_check_mark: Intégration caméra fonctionnelle (on sait jamais)

Je n’ai pas testé les autres intégrations (ZWave, Xiaomi notamment), mais à mon avis ça devrait fonctionner aussi.

Beau travail @VonOx !!

Je passe au test du 64bits.

Ouf :sweat_smile:

1 « J'aime »

Retours sur l’image Raspberry Pi OS 64 bits Bullseye :

:white_check_mark: Lancement ok, comme d’hab
:white_check_mark: Intégration MQTT fonctionnelle
:white_check_mark: Intégration Zigbee2mqtt fonctionnelle
:white_check_mark: Intégration Bluetooth fonctionnelle
:white_check_mark: Intégration caméra fonctionnelle

Tout me parait bon aussi !!

Beau boulot @VonOx :smiley:

1 « J'aime »

Hello à tous, je voulais savoir si certains d’entre vous avaient prévu de tester ces images ?

Je suis le seul à l’avoir testé, c’est pas suffisant pour passer en production ça :smiley:

Retours sur l’image Raspberry Pi OS 64 bits Bullseye sur SSD/Pi 4 - 8 Go :

:white_check_mark: Lancement ok,
:white_check_mark: Backend de mise à jour au démarrage,
:white_check_mark: Intégration MQTT fonctionnelle,
:white_check_mark: Intégration Zigbee2mqtt fonctionnelle, une erreur est survenu pendant le démarrage, mais il s’en est dépatouillé tout seul ^^

Logs Zigbee

:white_check_mark: Intégration Bluetooth testée rapidement avec mon tel, il a bien détecté et j’ai pu l’ajouter … pas d’autres appareils bluetooth ^^ mais ça à l’air fonctionnel,
:white_check_mark: Intégration caméra fonctionnelle,
:white_check_mark: Intégration tasmota fonctionnelle,
:white_check_mark: Backup Gladys Plus semble fonctionnel, les fichiers ont bien été créés dans le dossier /var/lib/gladysassistant/backups/ mais pour le moment pas de refresh de l’envoi sur le backend


J’en profite pour proposer d’avoir un retour sur l’exécution en cours et les étapes réalisées lors d’une sauvegarde manuelle (on voit dans le dossier backup qu’il y a une première étape de copie de la base, puis une seconde de compression et enfin je suppose l’envoi vers Gladys Plus. Si une étape bloque, le message pourrait peut-être spécifier à quelle étape pour mieux debug),

Edit : Après 5 minutes, c’est tout bon ^^

:white_check_mark: Agrégations fonctionnelles,

Tout me parait bon pour le moment également, plus qu’à voir dans le temps si ok pour les backup !!
Pour infos, l’interface m’a l’air beaucoup plus rapide, notamment les pages avec de nombreux graphiques … Est-ce lié au 64 bits ??

Beau boulot à tous :smiley:

Merci du retour @Terdious ça fait plaisir de lire ça !! :smiley:

@lmilcent m’avait fait le même retour en décembre, j’ai créé une issue github:

Oui c’est lié au 64 bits, et à mon avis c’est plus lié à l’image Docker buildée en ARMv8 64 bits que le passage de l’OS en lui même !

En gros, jusque-là, pour avoir une image unique qui marche sur tous les Raspberry Pi, on buildait l’image Docker en ARMv6 (car les Pi 1, 2 et Zero sont ARMv6)

Ce qui était dommage, c’est que ton Pi 4 a un CPU ARMv8, qui lui a beaucoup plus d’instructions. Par retro-compatibilité, les images ARMv6 fonctionnaient quand même, mais sans prendre parti de toutes les possibilités du CPU.

En passant en 64 bits, tu télécharge maintenant l’image Docker linux/arm64/v8, qui elle est compilée pour cette architecture.

Tout ce qui est code compilé, ou qui fait appel à des fonctions systèmes compilés devrait voir ses performances grandement améliorée :

  • Accès à la DB (Car le binaire de SQlite3 est compilée ARMv8 64 bits désormais)
  • Chiffrement de bout en bout pour Gladys Plus, compression et chiffrement des backups
  • Tout ce qui est lié à de la compression, du chiffrement, des calculs

Ce serait chouette de quantifier ces améliorations pour faire un petit blog post :smiley: (avec un petit titre putaclic)

2 « J'aime »

Suite à ton retour, comme le retour est vraiment positif et correspond à ce que je voyais aussi, j’ai publié l’image sur le site et sur Rpi-Imager !

Je ne vais pas faire de communication pour l’instant en revanche, on va laisser l’image être progressivement téléchargé et voir ce que ça donne :slight_smile: Je ferais de la com semaine prochaine je pense.

Le site en FR :

Le site en EN :

Rpi Imager :

En revanche, pour vous qui connaissez Gladys, je ne recommande pas de passer par l’image affichée dans Rpi-Imager (mais par un téléchargement manuel + Rpi Imager), car j’ai remarqué que le menu “avancés” qui permet de rentrer les informations de connexion au Wi-Fi n’apparaissaient pas sur les images non-custom, mais il apparait bien quand on télécharge l’image en local :

Je crois que le bug a déjà été remonté à la fondation.

1 « J'aime »

Je viens d’aller faire une petit tour sur RPi imager et je constate que pour HA, il y a un petit (i) renvoyant vers leur site…
image

Au boulot :wink:
Et de fait, pas de roue dentée mais le menu apparait avec le raccourci clavier d’origine : ctrl+shift+x

Top ^^

Oki !! Donc c’est compréhensible ^^

Bon après presque 2 jours de retour, une remarque toutefois, j’ai à nouveau des « blocages » moins récurrents (j’ai l’impression que cela se produit seulement sur des requetes de création / suppression de devices) et pas de plantage de Gladys, la page reste toujours affichée mais reste en recherche 2 min environ, je n’ai aucune idée d’où cela peut venir, contrairement à avant, aucun log docker. Tout est freeze. Sur l’inspecteur idem, aucune requête ne passe, la seule chose que je peux voir c’est ça :




Soit jusqu’à 2 minutes pour charger la page.

Je sais ce qu’il se passe, tu as du effectivement supprimer un appareil.

Sauf qu’actuellement dans Gladys, quand tu supprime un appareil, ça va supprimer en cascade toutes les device_features ainsi que les états de ces features :smiley:

Tu l’as compris, si derrière cet appareil a des milliers d’états, ça peut prendre 2 minutes et pendant ce temps là, la DB est bloquée car c’est une énorme transaction qui prend toute la bande passante du disque.

On a pensé à une solution si ce problème devient trop récurrent, ce serait de supprimer de manière plus soft les états, en étalant dans leur temps leur suppression (200 par 200 par exemple), pour laisser l’instance Gladys respirer entre ces suppressions.

Après c’est un développement à part entière :slight_smile: Tu peux créer une issue github pour qu’on garde une trace de ça ? Je te garantie pas que je vais travailler dessus dans les jours qui viennent, mais tu as raison c’est un point important :slight_smile:

1 « J'aime »

Merci pour ton retour,

Aucun soucis, je te crée ça. Bien sûr qu’il n’y a aucune urgence là dessus, on ne supprime pas de device tout les jours. Et tant qu’on sait que c’est normal, on peut être patient ^^