Hello j’ai trouvé qu’un blueprint de ce type existe déja:
j’ai pas encore essayé mais bon @Argonaute si tu veux y jeter un coup d’oeil 
Oui, j’ai testé cette implémentation, et la solution est tout à fait valable pour les entités z2m. Par contre, elle oblige à générer et utiliser les entités last_seen. C’est un choix.
Je finalise un blueprint plus générique, fonctionnant pour toutes les entités (zigbee avec ZHA ou Z2M, zwave, RF433…).
L’idée est de sélectionner les entités à surveiller en appliquant un filtre sur leur nom avec des wildcard (genre sensor.*_temperature_* pour surveiller les capteurs de température). On indique ensuite les entités à exclure dans ce sous-ensemble.
Le blueprint teste ensuite si les entités sont « available » ou non.
Cela suppose avoir bien géré le nom de ses entités.
2 « J'aime »
Hello,
Perso j’aurai aussi ajouté comment activer les entités dans le topic, parce que tout le monde ne sait pas forcément que ça peut-être facile ( moi le premier 
) et je n’ai pas cru le voir
Edit: Pour le reste je l’ai suivi, ça me semble carrément bien
cdt
1 « J'aime »
Ca m intéresserai aussi ce blueprint.
Merci pour l’intérêt. J’avais effectivement développé un blueprint qui marche bien et il est dispo sur mon github.
J’essaie de publier un article à ce sujet tout prochainement.
Le blueprint a été publie : un bon complément à l’article sur Zigbee2mqtt pour surveiller ses entités…
1 « J'aime »
du coup je me demande si ca peut pas résoudre mon souci sur mes ampoule zigbee. j’ai des interrupter connectés d’un coté qui commande des ampoules connectées de l’autre… bien sur quand mon interrupteur est off, mes ampoules apparaissent en erreur sur mon dashboard… et bien sur, ma femme en rajoute une couche avec des remarques du style « tu vois bien que ca marche jamais »… ca fonctionne bien sur, mais c’est moche sur le tableau de bord.
vous pensez que ca peux résoudre le probleme ?
Pour moi il s’ait de faire « croire » a MQTT que les ampoules sont toujours fonctionnelles, meme si elle sont eteintes… pour l’instant j’ai ceci :
ou on peut voir les 2 états que j’ai aléatoirement sur les ampoules.
et qunad j’allume, j’ai ca : selon les etats :
Hello,
Drôle de démarche 
Si tu convertis tes inters en light et que tu fais des groupes de lights ( inter converti + ampoule) , tu auras une entité qui gère à la fois ton inter et l’ampoule. C’est cette entité « groupe » qu’il faut alors mettre sur ton dashboard
exemple d’un groupe constitué de 2 rubans led et un switch zigbee:
Comme tu peux le voir en bas, ça renvoi simplement le statut éteint pour une entité strip_sam alors que mes rubans led ne sont plus alimentés par le switch… C’est cette entité que j’utilise sur mon dashboard
1 « J'aime »
ah oui, bonne idée… mais comment faire reconnaitre l’entité a assembler… et si l’entité disparait comme on voit dans mon Dashboard est-ce l’entité créée ne va pas faire une erreur?
Non, tu vas essayer d’allumer la lumière, mais elle va revenir sur la position off.
Perso, j’ai une carte avec les dispositifs indisponibles. Et tu peux aussi créer une automatisation qui t’envoie une notification.
Mais au moins ton dashboard est propre.
2 « J'aime »
ok dashboard propre, ce fonctionne… maintenant comment faire en sorte que la lumiere soit de nouveau visible par MQTT quand j’allume le switch… quand le switch est eteint, l’ampouele est soucvent oubliée par le systeme et je dois la réapairer ( elle apparait alors avec son nom… mais je ne peux pas refaire une synchro a chaque fois que je dois allumer la lumiere…
autre detail je voudrais bien avoir acces via le dashbooard au fait de pouvoir baisser l’intensité etc
mais si je fait une tuile, ca marque la lumiere comme allumé alors que l’interupteur est eteint…
bon ben c’est résolu, j’ai simplement inversé l’ordre des entités dans le groupe. apparement ca a suffit a résoudre le probleme. un question d’ordre dans le groupe?
Super article !!!
Par contre, je ne sais pas pourquoi, mais avant j’avais des prises Ikéa qui ne communiquées pas souvent (toutes les 4H)… Et depuis que j’ai activé la disponibilité, hé bien il est rare de les voir ne pas communiquer pendant plus d’1H.
1 « J'aime »
Salut
J’ai eu un peu de temps pour lire l’article et commencer à mettre en place ce qu’il décrit.
J’ai constaté une petite erreur, enfin un oubli, qui n’était peut-être pas nécessaire avant…
Lors de l’étape de la configuration de la disponibilité; il manque enabled: true pour que la colonne s’affiche dans Z2M :
# Optional: Availability feature
availability:
# Enable the feature (default: false)
enabled: true
active:
# Time after which an active device will be marked as offline in
# minutes (default = 10 minutes)
timeout: 20
passive:
# Time after which a passive device will be marked as offline in
# minutes (default = 1500 minutes aka 25 hours)
timeout: 240
Sans cette ligne, point de colonne Availability.
Bon, je prendrais plus de temps pour finir la lecture et la mise en oeuvre
Bonne journée
edit : je vois aussi une autrre coquille :
Dans cette partie, vous dites que le timeout est mis à 360 min (6h) , or dans le code qui précède, c’est 240 min.image|624x500
Bonjour,
c’est option est nouvelle, depuis Z2M v2. L’option n’existait pas a la création de l’article.
@Argonaute il faudra le mettre a jour
1 « J'aime »
C’est bien ce que je pensais, vu que je suis en Z2M v2
Merci pour le retour ! J’ai mis à jour l’article.
2 « J'aime »