Gladys v4.0.7 est disponible!

Salut à tous !

C’est lundi, c’est le jour d’une nouvelle release Gladys Assistant 4: La v4.0.7 :partying_face:

Cette mise à jour apporte une nouvelle fonctionnalité très attendue, ainsi que de nombreuses améliorations de performances, notamment pour les instances avec beaucoup de périphériques (hein @Terdious :p), et les utilisateurs de Gladys Plus ! :slight_smile: (que je remercie encore une fois de soutenir le projet!)

1) La possibilité d’injecter des variables dans les scènes.

J’ai mis à jour la documentation, il est désormais possible d’injecter une variable dans un message dans les scènes.

Lire la documentation: Envoyer un message | Gladys Assistant

Démo :

2) Amélioration des performances et de la stabilité des écritures de données de capteurs

Pour ceux qui ont des grosses installations, j’avais remarqué un goulot d’étranglement lors de l’insertion de nouvelles valeurs de capteurs.

Une transaction dans le backend de Gladys ralentissait toute l’insertion, et n’avait pas grand intérêt car au final vu le rythme d’écriture, elle causait plus de tord qu’elle apportait de bénéfice.

Après avoir retravaillé la route d’API, on arrive à des performances vraiment solide, et consistente dans la durée. Votre instance Gladys peut manger des centaines d’écritures par seconde sans difficultés désormais :rocket:

3) Amélioration des performances de Gladys Plus

Vous êtes une cinquantaine à utiliser Gladys Plus, l’offre payante que je propose, qui propose l’accès à distance de Gladys Assistant, chiffré de bout en bout, ainsi que les sauvegardes automatique.

Récemment, on s’est rendu compte avec quelques membres que le service d’accès à distance de Gladys Plus était moins rapide que d’habitude, avec des requêtes qui prenait autour de 500-600ms alors qu’on voyait auparavant des chiffres plus autour des 50-60ms.

J’ai passé une journée complète à investiguer, et j’ai découvert que certains appels de fonctions interne de Gladys (locale) prenaient beaucoup de temps à cause de LOCK au niveau de la DB.

Afin d’améliorer ces performances, j’ai décidé de retirer certains appels à la base de donnée, et à la place, d’interroger le cache en RAM (bien plus rapide!) où nous stockons certaines données accédée fréquemment dans Gladys.

Depuis ce changement, nous sommes repassés à des requêtes ultra-rapide, et performante :zap:

Le changelog complet est disponible sur GitHub .

Comment mettre à jour ?

Si vous avez installé Gladys avec l’image Raspbian officielle, vos instances se mettront à jour automatiquement dans les heures à venir. Cela peut prendre jusqu’à 24h, pas de panique.

Si vous avez installé Gladys avec Docker, vérifiez que vous utilisez bien Watchtower (Voir la documentation )

Bravo à tous ceux qui ont participé à cette release !

1 Like

Pour information, un petit bug affecte Gladys v4.0.7 sur les actions HTTP dans les scènes (Scène avec action requête HTTP ne fonctionne plus)

Je viens de déployer Gladys v4.0.8 qui fixe cette issue !

2 Likes

Il n’y a pas de Test sur ça ? C’est dommage sinon cela aurait été détecté en amont.
En tout cas bravo :slight_smile:

Il y avait des tests, mais c’était un cas très particulier qui est passé dans les mailles du filet :slight_smile:

J’ai ajouté des tests supplémentaires suite à l’incident pour ne pas que la régression puisse revenir !

Bonsoir !

J’ai fait une réinstallation sur un autre SSD hier soir(j’ai eu besoin de l’ancien pour faire autre chose) mais depuis, Gladys est restée en version 4.0.4. D’ailleurs il ne faudrait pas mettre à jour l’image a disposition pour commencer ?

Il y a quelque chose à faire pour que ça passe en 4.0.8 ? Je sais que ça doit se faire de manière automatique mais là ça n’a pas l’air de réagir

Builder l’image Raspbian est un process manuel et très chronophage, je le fais que de temps en temps. Etant donné que la mise à jour se fait automatiquement, c’est moins un problème.

Après là où tu as raison, c’est que depuis les récents changements sur l’API Docker qui rate-limit les appels API, on a changé la fréquence de mise à jour à toutes les 24h. Donc si tu installe Gladys à un instant t, Gladys sera à jour 24h plus tard, ce qui fait un peu tard effectivement.

C’est un peu un sujet débat qu’on a depuis longtemps, mais on n’a pas trouvé de solution parfaite ^^ On a une solution pour builder automatiquement l’image Raspbian, mais cette solution fait que l’image doit s’initialiser au démarrage, soit depuis internet (et du coup si tu as une connexion en bois ou pire pas de connexion, ça marche pas), soit depuis une archive locale qui faudrait dézipper, ce qui fait que ton Pi mettrait pas mal de temps à démarrer au premier boot.

@VonOx cc :slight_smile: l’éternel débat

Oui le poc était réussi, mais l’expérience au premier démarrage pas top car les rpi ont du mal pour dézipper, de souvenir il fallait attendre 15 minutes facilement pour que Gladys soit up. En + de ça aucun moyen de dire à l’utilisateur « attend un peu car le système n’est pas encore prêt ».

Faudrait que je trouve un peu de temps pour regarder ce que fait HA pour HassOS ( buildroot ) car c’est du docker aussi


Edit: j’ai pas pu m’empecher de jeter un oeil tout de suite --’

Ils font un pull pendant le build, a priori buildroot le permet ( Docker in Docker )

1 Like

Ok ! Effectivement le temps de latence peut être un peu long. Si il n’y a pas de solution technique pour le moment, il faudrait peut-être ajouter une note dans le tuto pour préciser que la maj peut prendre jusqu’à 24h.
Sinon, ça coûterait quoi de réduire la fréquence de maj ?

Je regarderai en rentrant ce soir si la maj est bien effective.

Une autre possibilité, c’est de proposer après installation de lancer une mise à jour « maintenant ».

2 choses:

  • Docker hub a rajouté des restrictions très basses pour les comptes non authentifiés, qui font qu’on ne peut pas faire des demandes fréquentes.
  • Le fait que les instances ne check les mises à jour que toutes les 24h, ça permet de distribuer progressivement les mises à jour, car tout le monde check à l’heure à laquelle il a lancé son instance, et ainsi si la distribution est plus ou moins homogène, ça fait qu’en cas de mise à jour défectueuse, si on s’en rend compte dans la première heure, seule 1/24 des instances ont été affectées (si on s’en rend compte au bout de 2h, seulement 2/24, etc…) et on peut corriger le tir (rollback, push un fix, etc…).

Après je pense pas que réduire ce temps ne résolve le problème.

La piste de @VonOx , ou alors de proposer un bouton « mettre à jour maintenant » après installation, me paraissent plus prometteuse !

ah génial ça! du coup ils ont une image ou quand tu boot tu es direct sur la dernière version de HA, même sans internet? et sans attente?

Home Assistant Operating System uses Docker as Container engine.
It by default deploys the Home Assistant Supervisor as a container.
Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers.

Sur le readme, par défaut que le supervisor ( qui est lui même un conteneur ).

Faut que j’aille à la pêche aux infos.

Le script est en fait exécuté au démarrage.

Pendant le pull etc, une landing page informe l’utilisateur que le système est en préparation.

Donc le système est vierge au départ.

C’est un peu ce que j’avais fait sauf que l’utilisateur a une info :sweat_smile:

ok ! et ils font comment pour afficher la landing page?

C’est une app go qui est pull au démarrage ( 28Mb l’image donc relativement rapide )

Ils font un build par machine - arch

https://hub.docker.com/layers/homeassistant/raspberrypi3-64-homeassistant/landingpage/images/sha256-f87e6a68d5aac53ac28dfd82989904690f24c23d9ef2a7385198ed90288a6ae8?context=explore


Donc en fait tant que l’utilisateur est informé peu importe le temps que prends la préparation.
Pas besoin de build une image ( OS ) souvent. L’applicatif est toujours en dernière version.

De ce que je vois aussi, buildroot permet de build en x86 / x64 et spécifiquement par modèle de raspy.

Ok pas bête!

On peut faire le même résultat avec une nginx-alpine (9Mo, Docker Hub ), et un simple index.html, ça sera encore moins lourd :stuck_out_tongue:

Effectivement ça me tente mieux comme process si l’utilisateur sait ce qu’il passe !

Si en plus ça peut nous permettre de build l’image automatiquement franchement je suis preneur :heart_eyes:

On reprend le poc? ^^

J’ai update mon repo et préparer le CI

image

Y’a plus qu’à

On continue la discussion ici :

Je fais remonter le sujet pur savoir s’il y a eu des avancés.
Je serais un peu frustrer en installant Gladys et voyant que je n’ai pas la dernière version (pour un nouvel utilisateur).
J’ai du effectivement attendre 24h pour que Gladys soit à jour.

Est ce que cela serait possible d’avoir un historique des versions sur le site?
V4.0.0
V4.0.1

Afin de pouvoir télécharger la dernière ou l’avant dernière.

En soit la mise à jour est pas compliquée à faire manuellement en SSH (source) :

  1. Télécharger la nouvelle image docker :
docker pull gladysassistant/gladys:v4
  1. Stopper et supprimer le conteneur actuel :
docker stop gladys ; docker rm -f gladys
  1. Relancer Gladys avec la mise à jour :
docker run -d \
--log-opt max-size=10m \
--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 \
gladysassistant/gladys:v4

Mais évidemment, automatiser tout ça depuis l’interface web c’est clair que c’est plus agréable :slight_smile:
Tu peux créer une feature request sur le forum !

Il y a déjà un post pour ça
https://community.gladysassistant.com/t/build-automatique-de-limage-raspberry-pi-os/6124

1 Like