Les groupes de notifications

Salut à tous,

Je vous propose aujourd’hui une vidéo sur la gestion des notifications, plus précisément, les groupes de notifications.

J’y aborde les avantages d’utiliser des groupes de notifications dans vos automatisations.

Merci pour votre visionnage,
Domotech

5 « J'aime »

Pas mal ! Merci.
Si on veut, on peut donc faire un groupe pour chaque device et du coup si on change de téléphone, ou d’assistant vocal), on le remplace juste dans le yaml et non dans chaque automatisation/script etc … ?
(Je parle dans la situation où on n’utilise la notification que vers un seul appareil en fonction de l’automatisation/script).
Ex de groupe: notify my telephone (même si j’y mets qu’un device dedans)
Ou encore un groupe de téléphones, un groupe d’assistant vocaux ?
On les changera probablement un jour, ou on en ajoutera d’autres plus facilement. ex : achat d’un téléphone pour les enfants, ajout d’assistant vocaux …
Ai-je bien compris ?

Salut,
Personnellement je ne suis pas convaincu que ce soit un avantage de faire 1 groupe pour 1 appareil (ça me rappelle les encapsulations dans les virtuels de jeedom et certains se souviennent plus des inconvénients que des avantages que ça générerait … ).
Tu peux intégrer ton téléphone samsung, et lui donner un ID monsupertéléphone. Quand tu changes pour un iphone, tu supprimes monsupertéléphone, tu intégres le nouvel appareil et tu lui donne le même id qu’avant : monsupertéléphone
Pas besoin de corriger nul part.
Par contre faire un groupe avec X appareils, ça a du sens (c’est plus simple et plus rapide de notifier un groupe que plusieurs appareils séquentiellement), et si tu appliques la méthode de conservation de l’ID, tu n’as même pas besoin de corriger le groupe

2 « J'aime »

ok noté. Cela serait pas mal alors qu’on ait la possibilité de le faire en « entrées »/« Groupes » directement sans passer par le yaml. Ce sera peut-être implémenté un jour.

Possible que ça arrive un jour effectivement.
C’est pas le plus difficile du yaml en attendant :sweat_smile:

Hello @Domotech
Alors vidéo intéressante, dommage que tu n’ailles pas au bout des choses avec une mise en situation réel de ce que tu viens de mettre en place comme le fait @MakerNix dans ces vidéos. Merci pour ta vidéo.

Merci pour la démonstration du groupe c’est intéressant.

Mais ce qui manque c’est comment le rendre « dynamique » ce groupe ?

Exemple du ‹ centre de notification › quand je suis présent et que la TV est allumée faire apparaître le message que sur la TV si je suis absent recevoir un SMS / notification et enfin si la TV est éteinte le jouer sur le Google mini.

S’il y a du monde a l’étage et au RDC le faire sur tous les Google home

Le tout étant de ne pas le faire pour chaque automatisation. Parceque sinon on se retrouve avec des groupes ‹ unitaires › au final si on veut faire un truc fin et on perd tout l’intérêt de la démonstration que tu as voulu mettre.

Les groupes ne peuvent pas servir à ça (il y a rien de dynamique dans un groupe)

Tu as besoin d’une partie ‹ logique › pour déterminer la/les bonnes catégories à notifier, c’est typiquement une automatisation.
Tu n’as finalement besoin que d’une liste temporaire (les groupes sont stockés, persistants, là on parle plus de namespace dans une automatisation/script) , dans laquelle tu va pousser la notification. A la fin de l’execution, la liste n’a plus besoin d’exister
Tu peux par contre préparer les catégories avec les groupes : par ex, les TV, les GH etc… qui eux serviront à construire ta liste. Quand tu ajoutes un nouvel équipement dans ta maison, tu le mets dans les groupes adéquats, et la liste sera à jour lors du prochain appel

Bonjour,

Du coup l’exemple de la vidéo n’est peut être pas un bon exemple (du moins pour moi)
si je passe par une automatisation ‹ centralisée › comment faire ensuite pour l’appeler a partir d’un autre automatisme avec un texte en « paramètre »
( désolé si vous pensez que je sors du sujet de la vidéo )

La notion de paramètre s’applique à plein de mécanismes, par ex:

Une automatisation qui construit ton texte dans une entité input_text et appelle un service genre automation.trigger (Tu faisais sans doute pareil avec jeedom et les scénarios qui s’appellent mutuellement, éventuellement avec des tags ou des variables)
Ton automatisation centralisée qui notifie le contenu input_text et qui l’efface à la fin.
Tu pourrais même utiliser le trigger suivant : input_text est rempli sur l’automatisation centralisée

et rebelotte.
Evidement ça engendre d’autres effets (plusieurs automatisations qui veulent ajouter les infos en même temps au même endroit), mais sur le principe c’est fonctionnel.

1 « J'aime »