100% des modules complémentaires considérés comme arrêtés!

Bonjour à tous,

voilà suite à un plantage de HA sur mon raspberry pi 4 cette nuit, j’en ai profité pour restaurer mon dernier backup automatique datant justement de cette nuit sauf que voila, il y a un léger bug après restauration concernant les modules complémentaires…

Home assistant considère l’ensemble des modules comme arrétés alors qu’ils sont en cours d’execution. Par exemple deconz est considéré comme arrêté alors qu’il est fonctionnel vu que j’ai l’ensemble de mes capteurs ainsi que les automations pour mes lumières qui fonctionne sans soucis.

Hormis ça tout fonctionne parfaitement !

Une idée ?

Je vais restaurer un backup plus ancien pour voir (la nuit précédente), je vous tiendrai au courant !

Voilà le problème :

Exemple avec DECONZ :

Quand je clique sur DECONZ de la barre latérale :

  • image

Quel est ton mode d’installation HA ?
As-tu rajouter ses choses particulières sur HA ou sur le pi ces derniers jours ?

Oups j’ai zapé de décrire mon installation et l’historique, désolé surtout que cela a son importance !!!

J’étais sur Raspberry Pi 4 - 4Go avec HA supervised, aucun signe avant coureur d’un quelconque soucis, de plus nous étions absent lors du plantage, personne à la maison. Du coup en rentrant cette après-midi j’ai constaté le plantage et j’ai donc restauré en urgence la dernière sauvegarde sur une VM proxmox avec HA OS.

Pour information j’ai créé la VM proxmox avec le script de https://github.com/tteck/Proxmox

Voici la commande de création de la VM :

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/vm/haos-vm-v4.sh)"

Pour information la restauration d’un backup plus ancien ne change rien et encore plus étrange, si j’installe un nouveau plugin, que j’ai jamais installé, le comportement est identique.

Salut

C’est « chaud » quand même. Parce que en plus de faire une restauration (alors que peut-être un restart suffit) tu changes de plateforme (arm → I686, Supervised → haos, IP etc). Dans le genre rapide/urgent, je suis pas certain que ce soit le meilleur choix.
Si les images sont restaurées avec une base d’arm … c’est normale qu’elle ne démarrent pas…

Salut @Pulpy,

En fait j’ai commencé par essayer de me connecté en ssh mais connexion impossible. J’ai du coup rebooter le raspberry mais malheureusement il ne redémarrait pas. Du coup soit je formattais le ssd avec une image fraîche de HA puis j’y collé ma sauvegarde, soit j’en profitait pour migrer sous proxmox.

Visiblement les modules tournes en regardant les log.

Exemple avec fileditor :

Non les images commencent le démarrage, c’est pas tout à faire pareil qu’aller jusqu’au bout de la séquence et fonctionner. La preuve avec le dernier message comme quoi c’est pas lancé

J’ai pas tester mais la migration comme ça je n’y crois pas
EDIT
Tu peux faire un test facile. Supprime l’éditeur, redémarre, réinstalle l’éditeur.
Comme il n’y a pas de config, ça veut dire que tout est lié à la version d’image si ça fonctionne

Tu ferai la migration comment du coup ?

Sinon j’ai essayé d’installer un nouveau module que je n’avais pas lors de la sauvegarde, celui-ci a le même comportement que les autres. Pourtant il devrait s’installer correctement vu que je suis sous la nouvelle architecture.

OK mais comment tu expliques que mon zigbee soit opérationnel du coup ? Par exemple mon détecteur dans ma buanderie allumé bien mon ampoule alors que l’automation est dans HA via Deconz.

Dans ce cas, je fais une migration manuelle. Récupération des fichiers yaml, recopie des config. C’est à peine plus loin, mais au moins…

Zigbee via ZHA ? donc core, donc issue de l’installation HAOS qui elle est correcte.
Un exemple d’images par exemple :

root@homeassistant:/hassio# more addons.json |grep image
      "image": "homeassistant/{arch}-addon-ssh",
      "image": "ghcr.io/hassio-addons/spotify/{arch}",
      "image": "ghcr.io/hassio-addons/node-red/{arch}",
      "image": "sabeechen/hassio-google-drive-backup-{arch}",
      "image": "ghcr.io/hassio-addons/appdaemon/{arch}",
      "image": "homeassistant/{arch}-addon-zwave_js",
      "image": "ghcr.io/hassio-addons/sqlite-web/{arch}",
      "image": "helto4real/hassio-better-presence-{arch}",
      "image": "ghcr.io/esphome/esphome-hassio-{arch}",
      "image": "zigbee2mqtt/zigbee2mqtt-{arch}",
      "image": "ghcr.io/hassio-addons/vscode/{arch}",
      "image": "homeassistant/{arch}-addon-mosquitto",
      "image": "homeassistant/amd64-addon-ssh",
      "image": "ghcr.io/hassio-addons/spotify/amd64",
      "image": "ghcr.io/hassio-addons/node-red/amd64",
      "image": "sabeechen/hassio-google-drive-backup-amd64",
      "image": "ghcr.io/hassio-addons/appdaemon/amd64",
      "image": "homeassistant/amd64-addon-zwave_js",
      "image": "ghcr.io/hassio-addons/sqlite-web/amd64",
      "image": "helto4real/hassio-better-presence-amd64",
      "image": "ghcr.io/esphome/esphome-hassio-amd64",
      "image": "zigbee2mqtt/zigbee2mqtt-amd64",
      "image": "ccab4aaf/amd64-addon-frigate-proxy",
      "image": "ghcr.io/hassio-addons/vscode/amd64",
      "image": "homeassistant/amd64-addon-mosquitto",

Elles sont toutes typées plus ou moins en dur… Les {arch} marcheront en changeant de plateforme mais pas les amd64

Zigbee via Deconz pour ma part.

Merci de la précision ! Je pensais que HA s’appuyait sur des containers justement pour s’affranchir du matériel, mais si les images sont typées… Visiblement je ne maîtrise pas assez ! :slight_smile:

En regardant de plus près les log, visiblement certains bloque sur le démarrage de nginx.
SQLite Web :

Alors que deCONZ semble bien passer :

Oui, là c’est quand même un peu plus que le matériel. C’est l’architecture cpu

SQL Web ET mariadb ? Tu as la base classique plus du mariadb ?

j’ai mariadb mais il semble être dans le mal aussi

Je vais restaurer mon Raspberry pour voir si cela résous bien le problème puis je ferai une migration propre manuelle car là je suis obliger de me taper archive après archives et je ne maitrise pas ce que je fais donc…

1 « J'aime »

Bon visiblement c’était la config de la VM proxmox qui posait problème car après avoir décoché la case « Use USB 3 » j’ai retrouvé l’ensemble des modules fonctionnels. Hasard ou pas je n’en sais absolument rien !

J’ai eu le même problème, il y a 3 semaines quand j’ai installer un ssd et restaurer une sauvegarde.
La solution, est d’arrêter le RPi et débrancher l’alimentation du secteur. Relancer HA et vider le cache du navigateur. Suffit de ce connecter a HA et de s’identifier et tout rentre dans l’ordre.

Merci pour ton partage, cool de savoir que je ne suis pas le seul. Pour ma part la restauration sur le PI a fonctionné sans soucis par contre le PI a de nouveau planté quelques minutes suivant la restauration…

Du coup j’ai fait la manip de config des ports USB sur ma machine virtuelle dans proxmox et tout est rentrée dans l’ordre. Je suis donc depuis hier soir sur Proxmox, pas de plantage pour autant, le soucis semble provenir de mon raspberry !