Archivi categoria: Uncategorized

L’HomeLab di LombaX – seconda puntata

Home-assistant – telecamere e automazioni

Ed eccoci arrivati al secondo appuntamento della serie #LombaXHomeLab , potete trovare gli altri articoli semplicemente cliccando sull’hashtag.

Iniziamo ad analizzare più nel dettaglio le varie componenti del mio HomeLab, ho deciso di partire da Home Assistant (o Hass, in breve), che forse è un po’ il “cuore” del progetto. Tutto è iniziato da Home Assistant, inizialmente installato su un piccolo Raspberry Pi.

Raspberry

Poi, col tempo, le mie esigenze sono cambiate e ho dovuto potenziare il tutto con un Intel Nuc, ma questa è un’altra storia.

Cos’è Home Assistant? 

Dal sito ufficiale:

> “Open source home automation that puts local control and privacy first.“

Quindi, in poche parole, un Hub per tutti i dispositivi IoT di casa nostra, con un forte focus su controllo locale e privacy.

In questo articolo però non mi voglio focalizzare su cos’è Home Assistant o su informazioni “base” per installarlo, quindi non prendetelo come un tutorial, ma piuttosto uno stimolo alla vostra creatività. Non esitate, però, a commentare e chiedere chiarimenti qualora qualcosa non fosse chiaro.

Infine, dato che con Hass faccio tante cose, l’articolo sarebbe un po’ troppo “corposo” quindi lo spezzerò in varie puntate.

Questa è la schermata principale del mio Home Assistant:

Hass

É totalmente personalizzabile nel mood grafico, cosa che però non ho fatto e non penso che farò, perchè sono totalmente incapace in tutto ciò che ha a che fare con grafica e UX 🙂 quindi mi sono concentrato più su quello che c’è sotto il cofano.

Bando alle ciance, un breve indice e poi si parte.

Di cosa parleremo in questa serie di articoli?

  • Videosorveglianza: collegare e gestire telecamere, accenderle e spegnerle quando necessario
  • Controllo luci: gestione di luci di vari generi e vendor, automazioni per gestirle in base agli orari o a determinate condizioni
  • Comandi vocali: utilizziamo Siri per gestire luci, e magari anche la TV
  • Controllo temperature e alert: fa freddo? fa caldo? E se fa troppo caldo, ti avviso.
  • Tempi di viaggio previsti: a che ora parto per andare a lavoro?
  • Teniamo d’occhio i consumi di corrente: Engage Efergy

Videosorveglianza

In alto a sinistra vediamo le Telecamere, i primi componenti che ho iniziato a controllare con Home Assistant, che in questa immagine sono spente. Why?

La prima esigenza è nata proprio così: ho 2 telecamere D-Link (vecchiotte), che supportano 2 funzionalità importanti, motion detection e alert via e-mail. Purtroppo però non sono programmabili gli orari di attivazione, senza contare che questi orari non sono sempre prevedibili. Come attivare la videosorveglianza ma evitare di ricevere alert quando io o mia moglie siamo in casa? E come rispettare la nostra privacy?

Ho sfruttato alcune componenti di Home Assistant e un po’ di hardware “di riciclo”, che avevo in casa.

Perchè il bello di Home Assistant è proprio questo: 
oggi supporta circa 1.200 componenti, quindi è altamente probabile 
che il vecchio device IoT che avete comprato 2 anni fa, e che ora è 
chiuso in una scatola perchè non si integra con nulla, possa essere 
gestito con Home Assistant

Hardware:

  • Per l’accensione/spegnimento delle telecamere, ho usato due Belkin Wemo switch
  • Ovviamente le telecamere 🙂 , due D-Link di cui non ricordo il modello e forse poco importa

Wemo

Dlink

Software:

  • Hass gestisce nativamente gli switch Belkin Wemo, se sono sulla stessa rete locale li autorileva e può controllarli senza bisogno di far nulla. Tutti i device che possiedono un interruttore, sono chiamati “switch” su Hass, e vengono visualizzati con un semplice interruttore on-off nell’interfaccia.
  • Geolocalizzazione: un altro componente di Hass è il “device_tracker”, componente che rileva la posizione/presenza di un device (tipicamente un cellulare) in vari modi. Può eseguire scansioni temporizzate all’interno della rete con NMap per rilevare se il Mac Address del vostro cellulare è connesso, può basarsi sulla presenza rilevata tramite Bluetooth, oppure (come ho fatto io), sul GPS dei vostri cellulari.
  • Automazioni: un altro componente importante di Home Assistant è “automation”, che permette di eseguire automaticamente alcune attività solo se si presentano determinate condizioni.
  • OwnTracks: App disponibile su iOS e Android, traccia costantemente la posizione del vostro cellulare e la invia a un MQTT Broker di vostra scelta. Hass offre questa funzionalità anche con la sua App nativa, ma si tratta di una funzionalità implementata in un secondo momento, che non ho ancora testato.
  • MQTT: si tratta di un protocollo di messaging “machine to machine” molto leggero, lo useremo per “trasportare” le informazioni di localizzazione da OwnTracks a Hass. Necessità di un server MQTT, nel mio caso ho deciso di utilizzarne uno cloud e gratuito chiamato CloudMQTT. Hass dovrebbe avere un MQTT server integrato, ma anche in questo caso si tratta di una funzionalità aggiunta in seguito, che non ho ancora testato.

NB: Hass ha moltissimi “componenti”, ma un altro componente core che vale la pena citare anche se in questo caso non è stato utilizzato, si chiama “sensor”.
Un Sensor permette di rilevare lo stato di qualsiasi cosa. Esistono sensori fisici (es. un termometro digitale, un rilevatore di movimento, un rilevatore di gas), sensori “virtuali” (es che rilevano le previsioni del tempo, quando il sole sorgerà o tramonterà).

Ora che abbiamo tutti gli ingredienti, la ricetta:

Sorvolo sul collegamento di Switch Belkin Wemo e delle Telecamere, in pochi minuti sarete in grado di collegarli e fare in modo di accendere/spegnere le telecamere dall’interfaccia di Hass.

Una volta fatto ciò, dobbiamo collegare Hass al nostro MQTT Broker, in configuration.yaml andiamo a inserire i dati di CloudMQTT (dopo esservi iscritti, li trovate nella vostra area personale)

In configuration.yaml andiamo a inserire i seguenti dati (NB yaml è sensibile all’indentazione, quindi ricontrollatela bene perchè potrebbe essere “saltato” qualche spazio durante il copia e incolla)

mqtt:
  broker: xxx.cloudmqtt.com
  port: 10109
  username: “your_username”
  password: “your_password”

questi stessi dati andranno inseriti su OwnTracks, con l’aggiunta di un id che identifichi il cellulare (chiamato Topic nel gergo di MQTT). Nel mio caso avremo 2 topic, uno per il mio cellulare (es marito) e uno per mia moglie.

A questo punto, nel file known_devices.yaml di Hass andiamo a inserire 2 nuovi devices:

your_username_marito:
  name: MaritoiPhone
  track: yes
  hide_if_away: no

your_username_moglie:
  name: MoglieiPhone
  track: yes
  hide_if_away: no

Mancano ancora un paio di cose. Sempre in configuration.yaml dobbiamo inserire la posizione di casa

zone:
  name: home
  latitude: 11.12345
  longitude: 22.23456
  radius: 250

(NB ho scelto un raggio un po’ ampio, 250 metri, ma nulla vi vieta di modificarlo. Fate un po’ di prove, la scelta giusta dipende anche dalla precisione del vostro cellulare)

A questo punto, Hass dovrebbe essere in grado di rilevare se siete in casa o no:

Infine, dobbiamo creare un “gruppo” per la famiglia (per rilevare quando almeno un membro della famiglia è in casa), e uno con gli switch delle Telecamere (per accenderle/spegnerle entrambe contemporaneamente)

group:
  family:
    name: Famiglia
    view: yes
    entities:
      - device_tracker.your_username_moglie
      - device_tracker.your_username_marito
  telecamere:
    name: Telecamere
    entities:
      - switch.telecamera_sala
      - switch.telecamera_studio

A questo punto siamo pronti per creare la nostra automation

automation:
  - alias: Turn on camera when family outside
    trigger:
      platform: state
      entity_id: group.family
      from: 'home'
    action:
      - service: switch.turn_on
        entity_id: group.telecamere
      - service: notify.ios_iphone_di_lombax
        data:
          message: "Telecamere accese"
          data:
            push:
              badge: 0
              category: "DEFAULT_NOTIFICATION"
  - alias: Turn off camera when family inside
    trigger:
      platform: state
      entity_id: group.family
      to: 'home'
    action:
      - service: switch.turn_off
        entity_id: group.telecamere
      - service: notify.ios_iphone_di_lombax
        data:
          message: "Telecamere spente"
          data:
            push:
              badge: 0
              category: "DEFAULT_NOTIFICATION"

Molto semplice, come potete vedere.

Nella prima automation stiamo dicendo che quando lo “state” del gruppo “family” non è più “home” (ricordate come abbiamo chiamato la zona di casa nostra?), deve scattare una action “switch.turn_on” sul gruppo “telecamere”. Nel secondo, viceversa.

In questa configurazione vedete anche un “service” specifico per le notifiche. Si tratta di un tema che vedremo in uno dei prossimi articoli, vi basti sapere che…quando l’automazione si verifica, ricevo una notifica push sul mio cellulare.

Per oggi è tutto, alla prossima puntata!

L’HomeLab di LombaX – prima puntata

Da appassionato di tutto ciò che è il mondo informatico, ho sempre avuto voglia di “toccare con mano” le tecnologie che ritengo più interessanti. Un po’ come il garage è “la stanza dei giochi” per un appassionato di meccanica o bricolage, l’HomeLab è la stanza dei giochi dell’appassionato di informatica, qualcosa che nasce per hobby, e viene coltivato sempre per hobby. Poi, nel tempo, diventa utile…probabilmente (almeno nel mio caso) non indispensabile…perchè poter dire “ehi Siri, accendi il Natale” per far accendere l’albero e varie luci colorate è cool, ma si può vivere anche senza 🙂

Questa sarà l’intro di una serie di articoli più tecnici e hands on, penso che una premessa – prima di entrare nei dettagli dei singoli servizi e tecnologie utilizzate per realizzare il mio HomeLab – sia d’obbligo. Farà anche un po’ da indice per i prossimi articoli.

Quindi…com’è il mio HomeLab? Cosa fa? A che serve? Come è organizzato?

Intel Nuc

 

Postazione

​Io direi di partire dai servizi, principalmente domotica, automazione, monitoring e multimedia in casa:

– fa da hub per tutti i dispositivi domotici che ho in casa (lampadine Philips Hue, switch Belkin Wemo e Sonoff, termometri “artigianali” sviluppati su Raspberry Pi, TV), permettendomi di accenderli e spegnerli da remoto (pc o cellulare), di controllare le temperature ecc…

– si interfaccia con Siri e HomeKit di Apple, permettendo a me e mia moglie di controllare gli stessi dispositivi con comandi vocali ai nostri iPhone o Apple Watch. “Ehi Siri, accendi le luci della Sala”, “spegni le luci della Camera”, “imposta luci calde in Studio”, “dimmi che temperatura c’è in Soggiorno”.

– gestisce la TV (Samsung Smart TV), permettendoci di accenderla, spegnerla, gestire canali e volumi sempre tramite controllo vocale

– ci permette di memorizzare file (documenti, foto, video) in una condivisione di grandi dimensioni e al tempo stesso proteggerli (encryption + backup offsite – in  particolare su Amazon AWS S3), ci permette di vederli direttamente in tv condividendoli con il protocollo DLNA.

– gestisce il nostro “mini” impianto di videosorveglianza, la casa è piccola ma abbiamo un paio di telecamere, tuttavia per rispetto della nostra privacy preferiamo che si spegnano quando io o mia moglie siamo a casa. Quindi, tramite geolocalizzazione sul cellulare e protocollo MQTT, non appena uno dei due entra in casa, le telecamere si disattivano.

– ci avvisa, tramite notifiche sul cellulare, se qualcosa non va: temperature troppo alte, rilevato movimento dalle telecamere

– gestisce un minimo di automazione: se siamo fuori casa facciamo accendere le luci al crepuscolo, così da non lasciare il cane al buio

– permette di monitorare consumi elettrici, banda internet, temperature delle varie stanze, con grafici facilmente esplorabili

– protegge, filtra e monitora la navigazione internet (tramite Pi-hole e protocollo SNMP)

…e questa lista è in continua evoluzione 🙂

Il componenti principali, ad oggi, sono:

Software

– Home Assistant: è l’hub di automazione principale, in brevissimo, si connette a tutti i device IOT della casa e permette di interagirci da un’unica interfaccia, integrata con HomeKit (e anche con la concorrenza… 🙂 ). Scriverò un articolo specifico in proposito, ma nel frattempo potete informarvi meglio quì: Home Assistant

Home Assistant

– Grafana: software per creare dashboard come queste

Grafana

– InfluxDB, memorizza tutte le metriche da HomeAssistant e altri servizi, permettendo poi di visualizzarle su Grafana

– Pi-hole, dns server che blocca la maggior parte dei domini di advertising, phishing e malevoli, rendendo più sicura e anonima la navigazione internet

Pihole

– MiniDLNA per condividere in rete i file multimediali e vederli dalla tv

– Un po’ di software custom (linguaggi principali utilizzati: PHP, Javascript con Node.js, Python e un bel po’ di sano bash scripting) scritto per fare da “collante” dove necessario.

– VMWare ESXi 6.7 per virtualizzare il tutto

vmware 1

vmware 2

 

XSIBackup per il backup delle macchine virtuali

– OS: il mio OS principale è MacOS, ma adoro anche Linux e in casa mia non viene discriminato nemmeno Windows, in questo momento (tra portatili, fissi e virtuali) almeno una 15ina di macchine: 2 mac, 3 windows, il resto Linux (Ubuntu o Raspbian, in generale sono della squadra Debian) 🙂

– Apple Homekit per i comandi vocali

– OWNTracks su cellulare per la geolocalizzazione

– Altri servizi esterni: quando necessario, mi appoggio ad Amazon AWS (in questo momento S3 per i backup) e OVH (macchina virtuale su cui risiede questo sito e alcuni script di controllo). CloudMQTT come broker MQTT per geolocalizzazione e temperature

Hardware

– Intel NUC 7th gen. i3, NVMe Samsun Evo 970 da 500GB per le virtual, Seagate BarraCuda da 2TB per storage, 16GB di RAM

nuc

 

samsung evo nvmenvme speed

– Alcuni dischi USB esterni per i backup delle macchine virtuali

– Hub e luci Philips HUE

– Hub Engage Efergy per il controllo dei consumi elettrici

– Vari Belkin Wemo e Sonoff come smart switch

– Telecamere D-Link

– UPS

– 4 Raspberry Pi sparsi per casa per controllare temperature (sensori DHT-22) o fare da Thin Client verso le macchine virtuali

Raspberry

– 3 Monitor (Lenovo 27″ 4K, Samsung 24″ FullHD, Samsung 19″ “di servizio”)

I motivi di queste scelte saranno dettagliati negli articoli di approfondimento, ma è bene tener presente alcuni “constraints” che mi hanno portato a farle:

– come detto a inizio articolo, tutto nasce principalmente per hobby. Voglia di provare delle tecnologie, hype, voglia di imparare un particolare linguaggio o usare uno strumento…quindi non cercate troppa logica in quello che ho fatto. Sicuramente si poteva “ingegnerizzare” meglio, ma lo scopo principale era uno solo: intrattenermi, e vi assicuro che ad oggi lo scopo è raggiunto 😉

– spendere “il giusto”. Ognuno di noi ha un concetto, totalmente personale, di quanto sia “il giusto”, e non è sempre uguale in ogni momento della vita. Il mio HomeLab è nato un pezzo alla volta, in alcuni momenti si è evoluto più velocemente, in altri meno. Lo espando per “iterazioni”. Generalmente, se in 2-3 occasioni all’anno sono più libero e mi avanzano 200-300€, mi “coccolo” regalandomi qualche pezzo di hardware nuovo (telecamere, switch, dischi ecc ecc). Tranne questo Natale che ho fatto evaporare una parte consistente di 13esima…ma questa è un’altra storia che leggerete nell’approfondimento dedicato all’Intel NUC.

– limitare i consumi elettrici: l’HomeLab (monitor esclusi, quindi Intel Nuc, disco esterno, router Internet + Wifi, UPS e qualche Raspberry) consuma appena 40watt! Con i 2 monitor principali accesi, arrivo a 120watt!

Direi che per la premessa è tutto.

Ora ci dobbiamo concentrare sui dettagli tecnici – più divertenti – relativi ai vari punti. I prossimi articoli quindi andranno a esplorare nel dettaglio tutti i punti sopra riportati, uno alla volta (man mano aggiungerò link a questo articolo).

Se avete domande o preferenze su quale argomento trattare per primo non esitate a commentare.

Soluzioni per Live Streaming

NB: questo articolo è stato scritto velocemente, ma vuole riassumere diverse giornate di analisi delle tecnologie e del mercato.
Se non capite qualche parte o volete maggiori dettagli, contattatemi pure. Con il tempo aggiungerò dettagli.

Parliamo delle tecnologie di Live Streaming, sistemi per trasmettere live e a migliaia di persone, in tempo reale, un flusso video.

Ho effettuato questa analisi per esigenza aziendale.

Nel nostro caso l’esigenza era duplice: in alcuni casi, trasmettere un evento live a qualche migliaio di persone (troupe video presente). In altri casi, effettuare brevi trasmissioni da parte di singoli (responsabili dei ns clienti), non assistiti (quindi tecnologia *semplice*), a diverse centinaia di persone.

Prima di entrare nei dettagli, è bene analizzare le varie parti dello stack di cui un Live Streaming si compone


 

Fase di ripresa e acquisizione (transcoding):

Questa prima fase è, banalmente, il momento in cui effettuate le riprese. Dato che parliamo di “Live”, il flusso video deve essere catturato e trasmesso in tempo reale. Qualunque sia il vostro sistema video per le riprese (telecamere professionali, webcam, cellulari), il vostro scopo è quello di far arrivare un segnale video a un pc, che dovrà poi codificarlo secondo uno standard e trasmetterlo a un server.

Esistono inoltre delle App per cellulari che facilitano il compito: acquisiscono il segnale dalla telecamera on-board, lo impacchettano e spediscono direttamente secondo lo standard.
Per la fase di trasmissione, ci focalizziamo sullo standard RTMP ( https://it.wikipedia.org/wiki/Real_Time_Messaging_Protocol ). E’ possibile usare anche RTSP ( https://it.wikipedia.org/wiki/Real_Time_Streaming_Protocol ). Non ho analizzato altri standard.


 

Fase di creazione dello stream:

Questa fase viene effettuata da un server dedicato, quello a cui state inviando il flusso RTMP. Il server riceve il flusso video, lo transcodifica ulteriormente (producendo i chunk video a varie risoluzioni/bitrate e formati) e li rende disponibili per la fruizione.


 

Fase di distribuzione:

il server che crea lo stream non ha una banda sufficiente a servire tutti i vostri utenti. Per questo motivo non viene esposto direttamente su internet, viene piuttosto utilizzato un sistema di distribuzione (tipicamente una CDN https://it.wikipedia.org/wiki/Content_Delivery_Network ). Quindi il vostro server di encoding carica lo stream definitivo sulla CDN rendendolo disponibile agli utenti


 

Fase di fruizione:

i vostri utenti tipicamente (ma non necessariamente) si collegano al sito internet dove ospitate il video. In questo sito è inserito un player, che tipicamente è un’applicazione Flash o un player HTML5. All’avvio della fruizione, il player contatta l’url CDN e inizia a scaricare il video. Anche in questa fase, esistono diversi standard e tecnologie: quelle che ho analizzato sono sempre RTMP (può essere usato indipendentemente sia per la fase di upload che per quella di download), oppure HLS (standard più recente)
Una variabile importante, se lavorate su siti internet, è la possibilità di vedere il video direttamente dalla pagina che lo ospita (embed), senza farlo aprire in un popup. Altra variabile importante è la possibilità di scegliere diversi bitrate manualmente o in automatico (a seconda della banda disponibile lato client). In questo caso parleremo di JWPlayer ( https://www.jwplayer.com ) che gestisce tutte queste casistiche.


 

Ora che abbiamo parlato delle varie parti dello stack, passiamo a un po’ di nomi, tecnologie e consigli. Iniziamo con il fai da te, se volete dei servizi che coprono tutta questa parte in pieno outsourcing staltate pure questa parte. Anche se vi consiglio caldamente di leggerla per imparare qualcosa 😉

Per la fase di ripresa
possiamo utilizzare telecamere professionali con uscita analogica o digitale, acquisendo poi il segnale con una scheda di acquisizione tipo questa:

http://www.amazon.it/Blackmagic-Design-Intensity-Shuttle-Thunderbolt/dp/B007ZDHDRS

Oppure è possibile usare direttamente la webcam.
In questa fase vogliamo encodare il segnale in ingresso in un flusso RTMP da inviare al nostro server.
Esistono diversi software per questa fase, io personalmente consiglio Wirecast: http://www.telestream.net/wirecast/overview.htm

Il setup è semplice, una volta acquisito correttamente il segnale video dovrete impostare i dati del server RTMP che riceverà il flusso video. Tipicamente saranno un indirizzo ip, uno username e una password.

Se volete un setup più semplice per eseguire le prime prove, scaricate un’app all-in-one, su iPhone posso consigliare questa: https://itunes.apple.com/it/app/broadcast-me/id491982406?mt=8 (esiste anche una versione RTSP, ma in questo caso noi vogliamo usare la versione RTMP)

per la fase di creazione dello stream:
il nostro server riceverà lo stream RTMP e dovrà encodarlo secondo i diversi standard che vogliamo poi fornire al nostro player (passando per la CDN).
Gli strumenti consigliati in questa fase sono due:
*Apple Media Encoder e altri software a supporto (ostico ma sicuramente il più configurabile)
*Adobe Media Encoder (non l’ho usato personalmente)

In questa fase consiglio di creare uno stream HLS ( https://en.wikipedia.org/wiki/HTTP_Live_Streaming ), in particolare l’encoder prende il video live e lo segmenta in piccoli pezzi (da 10 secondi ciascuno), in tante risoluzioni diverse, e li carica sulla CDN. L’encoder mantiene aggiornato un file di index (file .m3u8) che viene usato dal player per referenziare correttamente i file man mano che vengono aggiunti.

per la fase di distribuzione:

in questa fase ci servirà appoggiarci a una CDN e depositare i file sullo storage ad essa associato. In alcuni casi sarà la CDN a recuperare i file (tramite una http request a un vostro server, anche direttamente al media server se volete).
Poco da dire, facciamo qualche nome:
• Akamai
• CDNetworks
• Edgecast
• Limelight

ce ne sono tante altre, ma queste hanno un particolare: possono ricevere (e poi redistribuire) uno stream RTMP direttamente, senza la necessità di un encoder intermedio come da punto due. In questa guida non copriamo questa casistica, ma è giusto saperlo. Io comunque vi sconsiglio questo setup, in quanto RTMP è superato per la parte di distribuzione, in favore del più recente e flessibile HLS.

per la fase di fruizione:

anche in questo caso poche parole, vi consiglio di usare JWPlayer che ha già il supporto nativo per HLS e un player HTML5 nativo (o flash in fallback nel caso il vostro device non supporti html5).
A questa pagina trovate dettagli per il setup: https://support.jwplayer.com/customer/portal/articles/1430218-using-hls-streaming


 

Una volta parlato del fai da te, è giusto dire che non è sempre corretto reinventare la ruota. Esistono servizi che, a fronte di un costo mensile, coprono in tutto o in parte le varie parti dello stack.

Il più completo che ho trovato è Ustream: copre l’intero stack. Fornisce un’interfaccia web per l’acquisizione, con la possibilità di acquisire dalla webcam direttamente all’interno del browser e, nella versione pro, fornisce il codice embed per il player. Insomma, copre tutte e 4 le fasi in maniera molto semplice.
Si possono utilizzare telecamere professionali ed effettuare lo streaming anche tramite un software dedicato, Ustream producer. Inoltre vi permette di inviare il vostro flusso RTMP direttamente (se volete usare un’app o uno streamer hardware).

Altri nomi di cui scriverò più avanti: DaCast, StreamZilla.


 

Vi lascio alcuni link utili:
Bibbia dello streaming video by Apple

Strumenti server Apple

Alcuni transcoder:
https://zencoder.com/en/hls
https://www.wowza.com/forums/content.php?304-How-to-set-up-and-run-Wowza-Transcoder-for-live-streaming#swReq
http://knowledge.kaltura.com/live-streaming-using-kaltura-live-streaming-hds-hls-dash

Alcune app per streaming da iPhone
http://www.dacast.com/blog/how-to-stream-live-from-iphone/
https://itunes.apple.com/it/app/broadcast-me/id491982406?mt=8
https://itunes.apple.com/it/app/os-broadcaster/id632458541?mt=8