Assistente Personale e Centro Notifiche

---

---

AGGIORNAMENTO!!!  Nuovo Centro Notifiche con AppDaemon 

Nuove guide – AppDaemon: automazioni al massimo e Centro notifiche (AppDaemon notifier)

    

---

---

Con questa guida, provo a spiegare come crearsi il proprio Assistente Personale ed un centro di smistamento messaggi, per lo più quelli inerenti il servizio TTS, tramite l’uso di macro e script concatenati tra loro.

Ormai, è più di un anno che utilizzo questo sistema. Sicuramente potrebbe essere più performante con l’uso di AppDaemon, NodeRed o di Python Script, e vedremo il perchè più avanti,  ma attualmente non sento la necessità di migrare questo progetto in altri programmi.

Le mie fonti di ispirazione sono contenute nei link presenti all’inizio del package.

Sostanzialmente sono partito da Janet! (The Good Place) un progetto sul forum ufficiale di Home Assistant.

Vediamo come è organizzato il flusso dei dati, con un semplice diagramma.

Il messaggio di notifica, viene inoltrato allo script my_notify (Il primo script della catena). Questo elabora le variabili che gli passiamo (title, message, notify, mute, no_show, volume, link, o altro) tramite un modello (Template) e restituisce un messaggio pre-compilato allo script notification_hub (il cuore della centrale notifiche). Da qui, tramite opportune condizioni, il messaggio da notificare, viene:

• salvato, per poterlo riascoltare o rileggere
• riprodotto sul Media Player se non diversamente impostato (es. mute on, non annunciare, mute: 1)
• inviato sul notificatore o gruppi notificatori che abbiamo scelto (es. notify: telegram, notify: pushover…)
• Crea una notifica persistente se non diversamente impostato (es. no_show on, non mostrare, no_show: 1)

Applichiamo subito il settaggio preliminare per il package! Scaricate il pkg_centro_notifiche_220419

IMPOSTAZIONI

Copiare la cartella centro_notifiche (o il relativo contenuto) nel percorso \config\packages\.

Copiare il file (di esempio) motore_notifica_hp nella cartella config\include\. (o a scelta, ma l’importante è ricordarsi di modificare il percorso nell’ “!include:” presente nel package.

Aprire il file pkg_centro_notifiche.yaml e modificare o aggiungere i seguenti dati:

inserire i propri dispositivi da tracciare o il vostro gruppo se già lo avete. Serve per le condizioni, per escludere il tts quando si è fuori casa.

Creare un gruppo per i dispositivi google (il gruppo media player dall’applicazione Google Home ha ancora dei problemi tecnici)

inserire i propri Media Player Google, Alexa o se li avete, entrambi. (Importante: mettere il corrispettivo “friendly_name” come opzione di scelta).

Inserire uno o più servizi di notifica, questo servirà per impostarne uno di default, quello che si userà più spesso, così non sarà necessario chiamarlo dalle notifiche.

Per finire, nello script text_processing, adattare il codice con le proprie notifiche da utilizzare.

Ora che abbiamo settato tutti i parametri possiamo fare un controllo della configurazione e riavviare.

Una volta riavviato Hassio, possiamo impostare il nome del nostro Assistente Personale, l’orario di inizo e fine di Non disturbare (DND – Do Not Disturb) e il servizio di notifica per default.

Scheda Impostazioni Assistente

 

Continuare con le impostazioni per i Media Player. Scheda Impostazioni Google e Scheda Impostazioni Alexa.

Faccio presente, che nel mio caso, utilizzo sia il servizio Google Say che l’add-on Google Assistant Web Server per il TTS Google, mentre per Alexa, il Costum Component alexa_media_player.

Disattiva Google. Permette di disattivare i servizi TTS Google.

Google Say / Google assistant. Serve per scegliere quale servizio TTS di Google far funzionare. (di default google_say.tts)

Sorgente Google. Selettore dei media player Google.

Volume Google. Il volume per le notifiche dei madia player Google.

Disattiva Alexa. Permette di disattivare i servizi Alexa.

Sorgente Alexa. Selettore dei media player Alexa

Volume Alexa. Il volume per le notifiche dei madia player Alexa.

Tipo Predefinito Alexa. Con il custom Component ci sono tre tipi di invii per il messaggio: Announce, TTS e Push. Con Announce, il messaggio è preceduto da un suono. Con TTS, il messaggio NON è preceduto da alcun suono. Con Push, il messaggio sarà mostrato sul dispositivo mobile a cui è collegato l’account, come notifica “push”.

Metodo Predefinito Alexa. Si può scegliere se inviare la notifica a tutti i dispositivi, o in particolare su uno soltanto.

Nella scheda Modalità, troviamo altre cose utili:

Ultimo Messaggio. Permette, attivandolo, di riascoltare, inviare e notificare su Hassio l’ultimo messaggio eseguito.

Modo Ospite. Utilissimo, se abbiamo ospiti a casa. Attivandolo, il sistema funzionerà senza tener conto dei nostri dispositivi tracciati. Utile per fare anche dei test con il cellulare spento, o anche per disattivare certe automazioni, che in caso di nostra assenza si attivano, come potrebbe essere ad esempio lo spegnersi di tutte le luci… immaginate la suocera, quando voi uscite di casa la sera, e si spengono tutte le luci :0)

Messaggio Prioritario. È l’input booleano che ci permette di eseguire il messaggio, anche se è attivata l’opzione non disturbare. Potrebbe essere non mostrata in questa scheda, ma ho scelto di inserirla, perchè, se volessi inviare un testo, tramite l’interfono, nelle ore inibite, basta attivare l’interruttore, scrivere il testo e premere invio!

Questo interruttore è molto comodo. Prendiamo ad esempio, il caso di un’automazione di “allarme”, e si vuole inviare un messaggio del tipo, “Attenzione! Pericolo allagamento”, anche nelle ore notturne, basta ricordarsi di attivarlo nell’automazione stessa.

Notifiche Vocali. Attiva/Disattiva l’invio di messaggi tramite Media Player.

Notifiche di testo. Attiva/Disattiva le notifiche di tipo notify.telegram, notify.family, notify.pushbullet.

Notifiche Persistenti. Attiva/Disattiva le notifiche persistenti sulla web-UI di Hassio.

Interfono. L’interruttore per l’invio automatico del messaggio. Nell’input test sottostante basterà scrivere la propria frase e premere invio.

TEST

Possiamo testare il nostro Assistente Personale, scrivendo una frase nella sezione interfono, o attivando e disattivando la modalità ospite, o direttamente in dev-tool (Strumenti per gli sviluppatori) scegliendo lo strumento Services, ecco alcuni esempi:

Scegliere come servizio: script.my_notify

In Service Data (JSON, optional) inserire questo esempio e premere CALL SERVICE

Se tutto è andato a buon fine, dovremmo aver ascoltato il messaggio, ricevuto la notifica sul cellulare e leggere il tutto nelle notifiche persistenti.

Proviamo ora ad aggiungere altro, copiando e incollando nella dev-service, il seguente codice:

 

 

Che cosa è successo?

In definitiva, abbiamo inviato al modello, per l’elaborazione della notifica,  il titolo “*–Hassio Start!–*”, chiamato le macro introduzione (call_introduzione) e informare (call_informare), seguito dal nostro messaggio “Il sistema è operativo!” (message).

Il modello, è composto essenzialmente da tre parti:

1. nella prima si imposta il media player
2. nella seconda ci sono tutte le macro pronte per essere richiamate all’occorrenza, un po’ come le routine di Google Assistant ed Alexa
3. ed infine, in maniera sequenziale, ci sono le condizioni, che richiamano le routine (nel nostro caso Macro) e pian piano si crea il messaggio

Il “template”, fa un ciclo su tutti i Media Player che trova nel sistema,  e in base all’input che gli abbiamo fornito, lo imposta come sorgente su cui riprodurre il testo, e lo conserva nella variabile {{media_player}}.

Poi inizia la costruzione del messaggio build_message: e come prima operazione imposta il nome del nostro Assistente Personale che potrà essere richiamato nelle varie macro (funzioni) quando lo vogliamo, aggiungendo la variabile ~nome~ come potete notare nel file di esempio centro_notifiche_hp.yaml, o più sotto nel codice.

Ogni macro, sarà inserita nel messaggio, solo se la condizione con cui la chiamiamo sarà soddisfatta.

La prima condizione che incontriamo è

Quindi, ci restituirà ad ogni messaggio il saluto Buon… giorno/pomeriggo/sera a seconda dell’orario, al contrario, se impostiamo nella nostra notifica call_no_annuncio: 1 verrà saltata questa condizione, e non verrà aggiunto il saluto.

Se volessimo fare il contrario, ci basterà mettere call_no_annuncio == 1 nel nostro modello, e richiamarlo con call_no_annuncio: 1 nella nostra notifica, ovviamente, per comodità, lo potremmo chiamare anche chiama_annuncio, o semplicemente annuncio.

Il “template” prosegue, e incontra la seguente condizione:

Poiché, è vera, si sposta nella sezione macro introduzione

Dove prende una frase a caso, e prosegue ancora fino ad incontrare:

e allo stesso modo, prende una frase a caso e continua, dove incontra {{ message }}, il  nostro messaggio. Non ci sono altre richieste e/o chiamate, e conserva il tutto nelle variabili dedicate. {{ title }} {{ link }} {{ mute }} {{ no_show }} {{ notify }} {{ volume }} {{ alexa_type }} {{ alexa_method }}...

Il modello è sequenziale, questo non dimentichiamolo mai, ed inizia a costruire il messaggio completo da inviare ai vari dispositivi, appunto in maniera sequenziale! Se invertissimo l’ordine delle chiamate, il risultato sarebbe sempre lo stesso, ovvero, prima c’è il messaggio per l’introduzione e poi segue quello di informazione.

Nel nostro caso, quello che verrà riportato potrebbe, per ipotesi, essere:

1. build_message = Buona sera. Io sono Hassio, Sto ancora imparando, ma molto più rapidamente di quello stupido di Google… è mio dovere informarti… Il sistema è operativo!
2. Title = *–Hassio Start!–*
3. media_player = media_player.red, media_player.black, media_player.black2
4. media_player_alexa = media_player_sala
5. notify = notify.telegram (per default)

All’inizio, vi suggerisco di provare con dei test, nella dev-service, fare diverse chiamate, e una volta capito il concetto, possiamo passare all’atto pratico.

Esempio di restart Hassio:

Esempio nuovo dispositivo trovato:

Esempio modalità ospite:

Esempio di come utilizzare alcune variabili: [mute: 1]

[no_show: 1]

[mute: 1 e no_show: 1]

~~~

Ora proviamo a creare un’automazione per l’invio di una notifica, quando il sistema si avvia.

Come vedremo, l’unica cosa che cambierà, rispetto al normale uso del componente notify, è il servizio da richiamare, che sarà service: script.my_notify.

Nota. Nell’id: dell’automazione, alla fine del nome, ho aggiunto un suffisso “hub“, così da poter tenere traccia di tutte le automazioni che usano questo servizio. Infatti, nel package è presente un’automatismo che mi crea un gruppo di tutte le automazioni che hanno tale suffisso.

Qui di seguito, vi mostro come utilizzare le variabili da inserire nel motore di notifica, o strutturare il tutto direttamente nell’automazione stessa.

Si noti come cambia anche data: in data_template:, proprio perché si utilizzerà un template da passare al motore di notifica. ({{ trigger.to_state.attributes.friendly_name }})

BENTORNATO – Automazione di esempio per il classico bentornato a casa, con il codice inserito nel file motore_notifica_hp.yaml. Basta richiamare l’evento con call_bentornato: 1

BENVENUTO – Automazione di esempio per il benvenuto a casa, con il codice inserito direttamente all’interno dell’automazione, e aggiungendo solo la variabile di richiamo {{ benvenuto }} nel file motore_notifiche_hp.yaml

Altra cosa da tener presente e da notare, e forse è l’unico svantaggio che si può trovare in questo sistema di notifica, è:

- wait_template: "{{ is_state('script.my_notify', 'off') }}"

Infatti, voglio ricordare, che l’esecuzione di script multipli, può causare la perdita di notifiche, se avvengono nello stesso istante!

Vi sarà capitato spesso di trovare nel log di Hassio, un WARNING di tipo “Script script.esempio already running.”

Questo, succede perché lo script che si sta avviando è già in esecuzione, e verrà annullato. Non è un errore, ma una cattiva gestione degli script in Hassio. Non è concepita una coda di esecuzione. Infatti, ciò non accadrebbe, se si scrivesse un opportuno programma in python, o si creasse un AppDaemon, e se non erro (non ne ho conoscenza) anche tramite l’utilizzo di  NodeRed. Per il mio fine, per ora è più che sufficiente inserire un wait_template sullo script principale, ma se non si hanno numerose notifiche, per lo più audio, si può anche tralasciare.

Per adesso, mi fermerei qui, lo scopo di questa guida, è quello di comprendere un po’ l’uso di macro e come richiamare le variabili nel codice, e realizzare un proprio Assistente, capace di risponderci con frasi differenti. Non ripetere più volte codice sempre uguale e avere un pieno controllo su chi deve comunicarci le nostre amate notifiche.

In questo package, sono presenti pochi esempi di macro, per evitare di avere un file lunghissimo, in modo da evitare il più possibile confusioni nel codice. Se la cosa suscita interesse, si potrebbero continuare degli articoli con l’aggiunta di nuove macro, o magari, si potrebbe implementare il salvataggio del volume prima di una notifica, e ripristinarlo successivamente.

Per chi se la sente, e ha già nozioni in merito, vi invito nella discussione sul Forum, per ampliare o approfondire questo concetto di centro notifiche.

Una, ad esempio, potrebbe essere la segnalazione del passaggio della ISS, o quando c’è luna gibbosa calante, per avvisarci che è il momento buono per tagliarsi i capelli :0) per chi ne ha :0)

Scarica il package

Per commenti, idee o altro vi lascio il link alla discussione sul nostro Forum.

Update 11/2019 Nuovi file e spiegazioni le trovate sul forum Forum