Les notifications ! Par écrit, par la voix…

Rédaction le 04/03/2019

L’intérêt de cet article est de vous expliquer comme je gère les notifications de tout type par Jeedom. Comme tout le monde, j’ai commencé par faire des appels unitaires à l’email, à Telegram, Pushbullet ou TTS dans mes scénarios…

Puis après plusieurs tentatives, essais, j’ai stabilisé une version de scénario qui me sert à tout faire et qui simplifie mon utilisation des notifications dans Jeedom. C’est l’objectif de cet article !

Je vous expliquerai alors le principe du tag dans le scénario qui est un peu le pendant d’une variable que l’on passe à un scénario plus générique qui va se lancer et avoir un comportement différent en fonction des entrées données.

Pré-requis :

  • un plugin de notifications SMS : pourquoi ? En cas de coupure internet ou quand je veux avoir une lecture audio par Bluetooth de certaines notifications en voiture, je passe par JPI pour l’envoi de SMS (relire l’article pour JPI et l’envoi des SMS) ;
  • un plugin de notifications par Internet : email, Telegram, Pushbullet, etc … pour ma part, ce sera Telegram. Chiffré, pratique car l’envoi d’image etc.
  • un plugin de notifications TTS : par JPI, par SNIPS ou tout autre moyen. Pour ma part, c’est SNIPS avec mes 4 satellites audio dans la maison. J’en profiterai pour partager mon scénario de gestion de l’audio à la maison en fonction des horaires …

Les tags et leurs utilisations

Mais il y a plusieurs critères pour notifier : l’importance, le moyen et qui doit l’être. Pour cela les tags !

Quand je souhaite utiliser mon scénario de notifications, je lance ce scénario dans le scénario père avec des options présentes ou non. Il convient alors de définir un comportement type pour mon scénario si j’ai l’absence de définition du paramètre. Hein, il raconte quoi ?

Je vous explique :

Exemple d’un scénario qui appelle mon scénario de notification

Ce bout de scénario ne fait que définir une phrase à “lire” ou “envoyer” en fonction d’une présence et lance le scénario de notifications. Premier point, je lance le scénario en mode start(sync). Cela veut dire que le scénario père ne pourra continuer que lorsque le scénario enfant (celui de notifications) sera fini !

Ensuite vous pouvez observer sur l’appel du scénario de notifications des paramètres tags suivants :

tts=1 message=variable(message_TTS) important=1 qui=Tous

Dans l’ordre :

  • tts=1 veut dire que je veux de la lecture audio dans la maison,
  • message=variable(message_TTS) indique le message qui doit lu ou écrit,
  • important=1 veut dire que je double la notification orale par une voie écrite (Télégram ou à défaut SMS),
  • qui=Tous signifie tous les utilisateurs “Jeedomiens” doivent savoir.

Plus clair ? On voit clairement les possibilités en fonction des appels !

Qu’ai-je donc prévu dans mon scénario ?

  • #tts# : notification par TTS par SNIPS ou autre lecteur TTS audio (JPI, Google etc),
  • #sms# : force l’envoi par SMS en priorité au lieu de Telegram,
  • #message# : le message à envoyer,
  • #important# : double le TTS par Telegram et si Internet n’est pas disponible par SMS,
  • #qui# : envoie à moi, madame ou tout le monde

Je dois donc gérer dans mon scénario aussi si je ne passe pas le tag par défaut pour y mettre un comportement par défaut. En tête de votre scénario de notifications, il faut donc tester les différents tags par le biais de la commande SI avec comme test :

tag(nomdutag) == ""

Une optimisation est possible en utilisant directement les tags et non pas les variables mais par souci de clarté surtout en mise au point, j’ai préféré cette approche. Je teste donc les différents tags avec comme principe s’il est défini je reporte l’appel d’origine sinon j’affecte une valeur par défaut.

Très simple pour TTS et message :

  • le tag TTS est toujours à 1. Suivant l’heure le message est passé par ce scénario en Telegram par le biais de la variable autre_cas_tts. Je teste l’heure, les conditions de présence, l’alarme et je fais parler des satellites audio avec un volume réglé sinon je passe sur Telegram …
  • le tag message doit être défini sinon j’indiquerai une erreur.
Gestion du tag TTS et message

La suite est un peu plus sympa :

  • si ce n’est pas défini comme important (=1) alors cela ne l’est pas et si le destinataire (qui) n’est pas défini, ce sera moi par défaut (logique le mâle prédomine :D). De même si le SMS n’est pas défini, il n’est pas nécessaire, on passera par Telegram.
  • plus simple, si c’est important, je regarde juste qui est le destinataire, sinon c’est moi !
Gestion du tag important, qui, sms

Vous noterez la dernière ligne qui met à zéro une variable autre_cas_tts à 0. Elle me sert justement si les conditions de lecture audio ne sont pas remplies pour passer sur un envoi en Telegram ou SMS…

Gestion du TTS audio

Comme s’assurer que l’on ne va pas avoir une belle notification audio en plein milieu de la nuit ! En testant. Le principe, on ne peut avoir une notification audio (dans mon cas) que si :

  • le TTS a été demandé =1,
  • qu’il y a quelqu’un à la maison ! (logique),
  • que l’alarme n’est pas armée,
  • ou que l’alarme en mode nuit a été récemment mise (ici j’ai le droit de parler en TTS dans les 2 minutes après l’avoir mise) :
variable(tts) == 1 ET #[Personnes][Maison][Presence]# == 1 ET (#[Sécurité][Gestion Alarme][Alarme Armée ?]# == 0 OU (#[Sécurité][Gestion Alarme][Mode]# == "Alarme mode Nuit" AND #[Sécurité][Gestion Alarme][Alarme Armée ?]# == 1 AND lastChangeStateDuration(#[Sécurité][Gestion Alarme][Alarme Armée ?]#,1) < 120))

Ensuite, je regarde si nous sommes en week-end/jour férié ou en semaine car en fonction je n’applique pas les mêmes conditions horaires pour les volumes et les satellites SNIPS qui me font le TTS. Je teste si nous sommes en journée entre 9h et 20h en prenant l’inverse (par !) de la condition de la nuit :

!((#time# >= 2000 AND #time# <= 2359) OU (#time# >= 0000 AND #time# <= 0900))

Et si nous sommes en journée, je regarde si notre fils est là et que c’est l’heure de la sieste par :

#[Personnes][Raphaël][Présence]# == 1 AND (#time# >= 1230 AND #time# <= 1700)

Je pilote alors le volume du satellite SNIPS (je détaillerai plus tard ce point) ainsi je fais parler le satellite que je souhaite suivant cette logique :

  • celui du garage parle s’il y a mouvement (capteur Xiaomi dédié) dans le garage,
  • celui de l’entrée parle s’il y a mouvement (capteur Xiaomi dédié + mouvement par JPI dans la tablette voir article dédié) – sauf si horaires de nuit ou sieste,
  • celui de la chambre parentale parle s’il y a mouvement (capteur Xiaomi dédié),
  • par défaut, celui de la salle à manger – salon parle.

Le détail pour cette première partie qui est lié au fait que l’alarme vient d’être activée en mode nuit (donc nous sommes dans la maison) ou que l’alarme n’est pas activée ou que c’est la vie quotidienne !

WE/JF – Gestion du TTS sur présence ou alarme nuit

Seconde partie, si nous n’avons pas encore mis l’alarme (par exemple nous avons du monde…), donc je ne teste que l’heure entre 20h et minuit ou le matin tôt ou bien …. je ne veux pas que le TTS parle !

WE/JF – Gestion du TTS sur horaires décalés

Dans ce cas, je teste l’heure soit :

  • entre (#time# >= 2000 AND #time# <= 2359) (cas du soir tard) :
  • entre (#time# >= 0500 AND #time# <= 0900) (cas du matin tôt – oui il m’arrive de me lever tôt…)
  • et par défaut si je suis en dehors de ces cas, j’active la variable autre_cas_tts qui me servira à passer par Telegram !

Là encore, je pilote mes satellites SNIPS en volume et j’active en fonction du mouvement.

La seconde partie est si nous sommes en semaine (pas week-end et jour férié), vous retrouverez exactement le même principe sauf que j’ai changé mes conditions horaires.

Semaine – Gestion du TTS sur présence ou alarme nuit
Semaine – Gestion du TTS sur horaires décalés

Là encore si je ne suis dans aucune des conditions pour faire parler mes satellites SNIPS, j’active la variable autre_cas_tts qui va me permettre d’envoyer la notification par Telegram.

Gestion de la notification écrite

Dans le même scénario, donc si j’ai fini de traiter la partie TTS audio, je passe à la partie des notifications écrites. Comme vu précédemment, elle s’activera de base si nous avons indiqué par la première partie du scénario que nous voulions une notification écrite par la variable autre_cas_tts à 1 mais il y a d’autres cas :

  • si c’est important (qu’on veut doubler le TTS) – variable important à 1,
  • s’il n’y a personne à la maison (le TTS est actif que s’il y a quelqu’un),
  • ou que l’alarme est activée en mode nuit depuis plus de 2 min (idem l’inverse que précédemment),
  • ou que autre_cas_tts est à 1 !

Ce qui donne :

variable(important) == 1 OU #[Personnes][Maison][Presence]# == 0 OU (#[Sécurité][Gestion Alarme][Mode]# == "Alarme mode Nuit" AND #[Sécurité][Gestion Alarme][Alarme Armée ?]# == 1 AND lastChangeStateDuration(#[Sécurité][Gestion Alarme][Alarme Armée ?]#,1) > 120) OU variable(autre_cas_tts) == 1

Petite astuce, utilisez le plugin networks ou ping pour tester la connexion Internet (par exemple à www.google.com ou 8.8.8.8) et vous pourrez utiliser ce virtuel pour activer l’envoi de SMS (par JPI) si Telegram n’est pas accessible (par Internet donc) :

Test de la présence Internet par le serveur Google

Si le SMS est demandé ou que Google n’est pas accessible, j’envoie un SMS par mon téléphone qui gère JPI en testant s’il y avait une condition à qui je devais l’envoyer (pour rappel, je me mets par défaut dans l’affectation tag/variable vu plus haut dans l’article).

A contrario si le SMS n’est pas demandé et que Google est accessible (SINON), je passe par Telegram sur le même principe. Je teste simplement la variable qui par le biais de la fonction matches :

variable(qui) matches "/Benjamin/"
Gestion de la notification écrite par SMS ou Telegram

La remise à zéro

Dernière partie du scénario de gestion des notifications est la remise à zéro des différentes variables :

  • du message qui est lu,
  • de la personne désignée,
  • de l’importance,
  • de la demande de SMS,
  • de la demande du TTS,
  • de la variable qui permet le basculement entre le TTS ou l’envoi de la notification.
Remise à zéro des variables internes du scénario

Un exemple d’utilisation

Un exemple (mais des articles sur le quotidien seront publiés) pour illustrer l’utilisation de ce scénario. Pour rappel, vous avez le principe au tout début de l’article.

Ce scénario est celui qui gère la VMC en mode automatique (voir l’article dédié) :

Exemple d’utilisation
  • je définis le message à envoyer/lire par la variable message_TTS,
  • j’indique que je veux une lecture TTS par tts=1,
  • et si nous ne sommes pas là ou que l’alarme est mise, ce message sera envoyé automatiquement par SMS (si internet n’est pas dispo) ou par Telegram (par défaut) à tout le monde car qui=Tous.
tts=1 message=variable(message_TTS) qui=Tous

Le cas particulier de SNIPS

La mise en place de SNIPS (reconnaissance vocale et TTS sur Raspberry) étant assez compliquée (je trouve !), j’ai prévu un article dédié. Pour ceux qui ont déjà sauté le pas, vous avez pu observer dans cet article que je pilote à la fois le volume de mes satellites audio (j’en ai 4 dans la maison). Vous avez aussi la possibilité de passer par le TTS de JPI. J’utilisais cette possibilité au début mais souhaitant du privé total (tout est en local sur mon réseau à la différence du TTS Google ou autre qui passe par les serveurs de Google, Amazon suivant votre utilisation), j’ai migré peu à peu sur SNIPS.

SNIPS ne permet pas de piloter le volume des satellites par défaut. Vous ne pouvez faire que de la lecture audio par la commande say respective de chaque satellite :

#[Snips-Intents][Snips-TTS-SATPI-SNIPS1][say]#
Définition des SNIPS devices

J’utilise alors le plugin SSH commander pour envoyer des commandes à mes Raspberry respectives :

Définition des équipements SSH par le plugin SSH Commander

Comme votre client SSH pour vous connecter sur votre Raspberry (voir l’article dédié), définissez l’IP, le login, mot de passe, port SSH etc

Paramétrage de votre équipement SSH

Cela sous-entend d’avoir installé le paquet alsa-utils par la commande :

sudo apt install -y alsa-utils
Pilotage du volume et des LED des satellites SNIPS

Les commandes respectives sont :

  • volume à 0 : sudo amixer -c 1 set PCM 0%
  • volume à 50 : sudo amixer -c 1 set PCM 50%
  • volume à 100 : sudo amixer -c 1 set PCM 100%

Vous pouvez vérifier le niveau du gain de votre partie lecture directement en SSH sur votre satellite en tapant :

sudo alsa-mixer

Puis choisissez la carte son de lecture (touche F6) :

Vérification du volume du satellite SNIPS

Concernant le matériel nécessaire pour monter un satellite SNIPS, je vous recommande les éléments suivants :

Bonne utilisation !

Un article qui est à la base de votre installation domotique. Il va vous permettre de gérer au mieux les notifications qu’elles soient écrites, verbales par le biais de plusieurs moyens : Telegram, SMS, TTS audio. Bien que présenté avec Telegram ou SNIPS, vous aurez compris que vous pouvez le transposer sur n’importe quelle synthèse vocale (Google TTS, Amazon Polly, Echo etc) ou n’importe quelle système de notification écrit : Pushbullet, Pushover, email etc. Les conditions d’horaire, de présence sont indicatives, à vous de les modifier en fonction de vos indicateurs présents !

La conclusion de cet article !

Si vous avez aimé cet article, remerciez-moi en considérant une petite donation financière par Paypal. Cela prend du temps de rédiger et de partager ce contenu, sans publicité !

Merci à vous !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *