Instabilité de l'interface HA?

pour quelle utilité ? puisque tu n’as plus de HA :roll_eyes:

tout ceci est dans le backup de HA :wink:

tous les éléments de HAos sont séparés ce sont tous des conteneurs dockers
le core est aussi un conteneur, tous les addons sont des conteneurs

Il y a plus de positifs que de négatifs à déporter z2m et mqtt ?

Je nourris quelques topics MQTT également depuis des scripts sur une autre machine :wink:

Sans avis, c’est vraiment une question de choix.
Je préfère avoir de « petites » entités séparées, qui peuvent certes planter individuellement et demandent des MAJ séparées, qu’un gros truc monolithique où si le point d’entrée plante tout est HS.

Mais c’est presque une question de religion à ce stade :wink:

justement HAos n’est pas une gros truc monolithique :wink:

c’est que je disais pour un usage standard ça n’a pas d’interet

Je pense comme @ddfdom

Et même si c’est un peu HS ici, je pense qu’il vaut mieux réfléchir proprement à faire du binding en zigbee qu’à avoir un Z2M indépendant de HA…

2 « J'aime »

Ce n’est pas forcément la bonne solution.

Si c’est bien pronote et sa gestion gourmande de la mémoire, tu peux très bien surveiller ça avec une automatisation et mettre en place les barrières qui vont bien, largement avant le crash de HA…

par exemple:

  • reset HA lorsque l’usage de la RAM devient > XX%
  • desactivation de pronote lorsque les entités deviennent indisponibles
  • notification dans les deux cas de figures pour aller jeter un oeil…

Si besoin je t’envoie les miennes…

Pour ça je m’appuie sur deux trucs:

  • le monitoring système (je me rappelle jamais du nom de l’intégration, ça doit être system_monitor, mais pas 100% sûr) pour récupérer la RAM
  • spook (dans HACS) pour désactiver l’integration pronote
2 « J'aime »

Ce sujet a été automatiquement fermé après 2 jours. Aucune réponse n’est permise dorénavant.