Développement image Raspbian Gladys 4 - Réflexion

Salut à tous!

Comme j’indiquais dans ma dernière newsletter, une de mes priorités en ce moment est de créer une image Raspbian officielle pour Gladys 4.

Les spécifications sont les suivantes :

  • Doit être fonctionnelle pour toutes les versions du Raspberry Pi (1, 2, 3, 4, Zero, Zero W, etc… )
  • Gladys 4 installée via Docker
  • Doit pouvoir se mettre à jour toute seul, sans avoir à se connecter en CLI.
  • Donnée Gladys (DB, etc…) stockée dans /var/lib/gladysassistant
  • Ports USB gérée et exposée dans Docker
  • Hostname “gladys”

Mon problème actuel

Au vu de ce que j’ai trouvé, il y a pour l’instant un problème avec les dernières versions de Docker sur les périphériques ARMv6 (Donc Raspberry Pi 1 et W). Les builds ne tournent pas sur ces Rasps.

Cf =>


Une possibilité est de repasser à une version plus ancienne de Docker, MAIS sans passer à Raspbian Buster, car ces versions n’ont été buildée que sur Stretch.

Au vu de mes tests, il semblerait qu’il n’y ait pas milles solutions :

  1. Créer 2 images différentes: une pour Raspberry Pi ARMv6 (Rpi 1 et W) et une pour les autres (2, 3, 4 ). L’image pour Raspberry Pi ARMv6 serait basée sur Stretch. (C’est beaucoup de travail)
  2. Ne faire qu’une image sous Buster, et dire que Gladys n’est plus compatible Raspberry Pi 1/W (je ne suis pas fan de cette solution)
  3. Utiliser la dernière version de HypriotOS, un OS basé sur Raspbian Buster avec Docker dans sa dernière version pré-installé. Je n’ai pas encore testé mais HypriotOS me semble être une bonne solution !
  4. Utiliser HypriotOS + flash + cloud-init ! Là ça serait le combo ultime, l’objectif serait de créer l’image en CLI de mon côté grâce à un fichier YAML cloud-init ( Exemple ), puis sans jamais la démarrer la publier comme ça sur le site. Ainsi, l’image est hyper clean (car je ne l’ai jamais booté de mon côté) et au premier démarrage l’image télécharge + lance l’image Docker Gladys 4 dans sa dernière version. L’avantage, c’est que l’image est toujours à jour. L’inconvénient, c’est qu’il faut que le Raspberry Pi soit connecté à internet au premier démarrage de Gladys, et que le téléchargement peut prendre un petit temps sur les connexions lentes.

Bref, ça bosse, je suis preneur de retour, si vous avez des remarques/tuyaux ça m’intéresse :slight_smile:

@VonOx ?

Clairement la solution 4, l’inconvénient n’en est pas vraiment un, je penses que la plupart des rpi ont accès à internet, les rpi complètement offline sont des cas isolés et les utilisateurs en questions sont dans la catégorie “expert” et sauront faire face :grin:.

La solution 5 serai de build une image rpi avec qemu.

Je suis d’accord que la solution 5 est la solution “parfaite”, mais c’est aussi la plus chronophage ^^ Pas simple de tout mettre en place et de comprendre tout!

Je pense que j’ai plus de plus value en ce moment à bosser sur les services :slight_smile:

Je viens de tester la méthode 4 sur un Raspberry Pi 1, l’équivalent d’un Pi Zero W, certes pas super représentatif du parc, mais autant tester dans les pires conditions pour savoir à quoi s’attendre.

Le temps de mise en place est quand même assez long… C’est pas très rapide pour l’utilisateur. Le docker pull prend une plombe (en fibre pourtant, mais bon le port ethernet est lent + le CPU a du mal à décompresser les archives des layers)

Je pense que la bonne solution pour l’instant, c’est de faire un mix de la solution 3 et 4:

  • Je créé l’image avec cloud-init de mon côté
  • Puis je la lance une fois sur un Pi 1 pour que le pull + le start se fasse une fois (la DB s’initialise comme ça)

Au premier démarrage, l’utilisateur aura une instance Gladys qui tourne quasi direct, c’est sûrement plus fluide pour l’utilisateur final… On est pas encore à l’automatisation complète du build de l’image, mais pour moi la priorité n°1 c’est l’expérience utilisateur!

C’est quoi une plombe pour toi ?

Parce que perso, ça me dérange pas de laisser tourner le truc 30-60 minutes… :stuck_out_tongue:

20 minutes :smiley:

En fait c’est pas que c’est long qui est pas clair pour l’utilisateur, ce qui est pas clair c’est qu’il n’y a aucun feedback externe. On branche le Pi et on attend, et si ça ne marche pas on ne sait pas ce qui n’a pas marché… Et surtout si il y a une erreur, tout est foutu et à part si on va chercher dans les logs de cloud-init on saura jamais vraiment ce qui a foiré.

Exemple: j’ai eu des soucis de résolution DNS du docker hub lors du docker pull (soucis vraiment tout con, il suffisait de relancer la commande), et du coup bah rien ne marchait ^^

Si on veut que le produit soit utilisable sans CLI, il faut que le process d’install soit sans faille. Le moins on fait de chose chez le client, le plus on est sûr que tout ira bien.

Bon dans un premier temps j’ai fais l’approche hybride, buildée sur Raspberry Pi 1 avec:

  • Un container Docker Gladys 4 qui écoute sur le port 80, accessible en gladys.local
  • Un container Watchtower

Les deux en restart=always, donc ça devrait toujours être bon.

Je test l’image sous un Pi plus récent pour voir si tout fonctionne!

Je dis quand même un des inconvénients de cette méthode:

Lors du premier démarrage de l’utilisateur, si sa version de Gladys n’est pas à jour, Watchtower va la mettre à jour automatiquement. Hors du coup, l"utilisateur sera probablement entrain de setup son Gladys et le serveur va se faire restart alors que l’utilisateur est en pleine configuration! Pas super propre non plus.

Testé sur Raspberry Pi 4, quel plaisir !

Et hop, une première image Raspbian Gladys 4 assez basique:

https://mirror-fr-2.gladysassistant.com/releases/gladys-4-alpha-1.img.zip

  • Testée sur Raspberry Pi 1 et 4
  • Basée sur HypriotOS 1.11.1 (Docker 19.03.0 CE + Raspbian Buster)
  • Ports USB fonctionels (testé avec une clé Zwave.me)
  • Mise à jour automatique avec Watchtower

Dites moi si vous avez des retours :slight_smile:

Bonjour à tous,

Je me permets de donner mon avis sur la question car j’ai pas mal développé sur RPi avec Docker et sur tous les modèles.

Les soucis sur les modèles armv6 (Pi1 et 0) sont récurrents mais l’OS d’Hypriot n’est à mon avis pas la solution ultime car il peut être limitant :
Pour ma part, j’aime bien faire plusieurs choses avec les Raspberry. Aussi, sur HypriotOS, il n’est pas possible de travailler avec toutes les interfaces matérielles (je n’ai jamais réussi à intégrer un simple capteur de température OneWire). De même, il est très compliqué d’utiliser un écran branché sur HDMI sur cet OS.
Du coup, en utilisant HypriotOS, l’utilisation de la Pi sera limitée à Gladys et il faudra bien vérifier que les périphériques USB sont bien tous reconnus.

Pour moi, il serait donc bien de rester sur Raspbian (mais c’est mon simple avis et le premier que je donne sur le forum :wink:).
Aussi, vus les posts d’hier, j’ai regardé les issues Docker :
docker-ce segmentation fault on Raspbian

J’ai ainsi réussi à installer Docker 19.03.2 sur Raspbian Buster sur une RPi0W.
Je peux détailler si ça vous est utile.

Merci @Reno pour ton retour!

Si tu peux détailler la procédure, ça m’intéresse :slight_smile:

Je n’ai pas d’expérience avec HypriotOS, je pensais que c’était un simple Raspbian Buster avec Docker d’installé, mais effectivement ça peut être mieux d’avoir un Raspbian Buster classique si on peut le faire

Avec plaisir, si ça peut servir :+1:

Apparemment le problème vient du binaire ‘containerd’ (v1.2.6-3) qui n’est pas compilé pour armv6 et comme le projet container.io n’est pas “encore” libre d’après ce que j’ai compris, on ne peut se le compiler nous même…
Par contre, Hypriot propose une version un peu infèrieure (v1.2.6-1) sur ses serveurs qui fonctionne sur armv6 mais je n’ai pas saisi comment elle avait été réalisée.
Il suffit donc de récupérer un paquet debian et l’installer à la main :
curl -s https://packagecloud.io/install/repositories/Hypriot/rpi/script.deb.sh | sudo bash
wget --content-disposition https://packagecloud.io/Hypriot/rpi/packages/raspbian/buster/containerd.io_1.2.6-1_armhf.deb/download.deb
sudo dpkg -i containerd.io_1.2.6-1_armhf.deb
Je ne suis pas sûr que la première ligne soit obligatoire. A tester

Puis d’installer Docker :
curl -sSL https://get.docker.com | sh

Pour en revenir à Hypriot, j’avais testé ça il y a plus d’un an voire même 2 (le temps passe vite…) avant de repasser sur Raspbian. D’après ce que j’avais pu lire, l’accès au matériel n’était pas dans les préoccupations du projet mais cela a peut-être changé depuis ?

Ok je comprend mieux l’histoire! :slight_smile:

Je garde ça sous le coude et dès que je test je mettrais un message ici, c’est clair que c’est sûrement mieux d’avoir un Raspbian classique si on veut garder d’autres programmes autour de Gladys.

1 Like

Bonjour,

je voulais savoir avant d’utiliser galdys V4 est-il toujours possible d’installer des modules sonoff, xiaomi etc…

Car de ce que j’ai compris il n’y aura plus de module.

il y aura que du z-wave ?

merci d’avance

La gestion serait différente, tout sera inclus dès le départ dedans. :wink:

D’accord merci de ta réponse.

Donc pour le moment il y a que Z-wave, MQTT.

Exactement :slight_smile: Pour l’instant il n’y a que Z-Wave, MQTT, RTSP Camera, Telegram & DarkSky.

Il y a pas mal de services en cours de migration (Xiaomi, Philips Hue, Sonos, …), ça bosse !

Bonjour @pierre-gilles

Merci pour ta réponse et merci pour tout le travail que vous effectuer j’ai hâte de pouvoir utiliser Gladys V4.

Est ce qu’il aura toujours le module sonoff ?
Pourrons nous parler à Gladys via un Google home autre que en ifttt?

Bonne journée

L’objectif est de migrer tous les modules y compris sonoff. Il est actuellement en pull request (un dev est en train de développer le module). Il devrait donc arriver d’ici quelque temps tout dépend de l’avancement du développement.

@damalgos +1, effectivement le service Sonoff est en cours de migration par @AlexTrovato. La PR sur le MQTT a été migrée récemment donc ça devrait pouvoir débloquer ce service.

Pour l’instant l’intégration Google Home en direct n’est pas dans mes développements prévus à court terme (il y a déjà beaucoup de boulot sur la migration des services!), après sur le long terme oui pourquoi pas. Comme toujours, toute PR est la bienvenue :slight_smile: