[ninux-Firenze] Incontro del 12 Settembre presso ExFila

[Marco Taiuti]

Provo a rispondere alle domande:

   - *MQTT vs HTTP:* a questo link
   <https://hackerstribe.com/wp-content/uploads/2016/04/Tesi-Rocco-Musolino.pdf>
puoi
   trovare una tesi in cui sono spiegate molto bene le differenze tra MQTT e
   HTTP. Personalmente MQTT lo utilizzerei nel progetto finale mentre non
   escluderei di utilizzare HTTP in questa prima fase visto che sia crate.io
   che influxdb supportano HTTP nativamente e ci permetterebbe in breve tempo
   di iniziare a raccogliere i dati.
   - *Node-Red:* andrebbe utilizzato nel caso si utilizzasse MQTT ma niente
   vieta di utilizzare altri strumenti come http://storm.apache.*org/*
   <http://storm.apache.org/>
   - *Separazione DB*: anche io sarei per dividere il DB anagrafico da
   quello della raccolta dei dati. C'e' pero' da tenere presente che
   nell'interrogazione dei dati ci sara' bisogno di tutte informazioni. Per
   questo aspetto  CRATE.IO permette di effettuare query SQL LIKE
   preformanti gestendo anche la geo-localizzazione vedi (
   https://crate.io/docs/reference/sql/joins.html
   https://crate.io/docs/reference/sql/scalar.html#geo-functions
   - *Grafana*: sinceramente non ho approfondito la parte di presentazione.
   A me piacerebbe geolocalizzare i dati in tempo reale e magari l'evoluzione
   nel tempo. Qui puoi trovare un esempio
   http://apps.socib.es/Leaflet.TimeDimension/examples/example12.html



Il giorno dom 18 set 2016 alle ore 17:35 Gabriel <gabriel at autistici.org> ha
scritto:

>
>
> On 17/09/2016 12:12, salvatore moretti wrote:
> > Ciao Marco,
> >
> > l'architettura proposta è sicuramente la più natura e ti invito a fare
> > una sezione a casa mia per installare il tutto
> > cominciare a collegare la tua e la mia centralina. E' ovvio che l'invito
> > è esteso a tutti.
> > Vorrei  però capire alcune cose:
> >
> > Il 14/09/2016 23:58, Marco Taiuti ha scritto:
> >> E' stata una bella serata e secondo me ci sono le premesse per fare un
> >> ottimo lavoro.
> >>
> >> L'idea di infrastruttura che avevo in mente e' questa:
> >>
> >>  1. *Centraline*: Sensore + NodeMcu che invia i dati  al server
> >>     tramite il protocollo MQTT (vedi link
> >>
> >> <
> http://jeanbrito.com/2016/02/24/saving-data-received-from-mqtt-to-influxdb-using-node-red/
> >)
> >>
> >>
> > Va bene nodemcu però teniamo presente che non in tutti i casi potrebbe
> > essere sufficiente (non ha tantissima memoria) e che la portata del Wifi
> > non è eccezionale: al massimo passa un muro.
> >
> >>  1. *MQTT*: server che veicola i dati a Node-Red
> >>
> > E' vero mqtt è specifico per la comunicazione di dati seriali, però
> > perchè no http che è più generale  e tutte le basi
> > (Raspberry, nodemcu, arduino) ce l'hanno nativo nel SO ?
>
> Concordo, ho dato un occhio al protocollo MQTT e non sembra molto adatto
> al nostro caso d'uso.
> >>
> >>  1. *Node-Red*: applicazione nodejs che elaborai dati e li inserisce
> >>     nel DB
> >>
> > Mi spieghi a cosa serve visto che infliuxdb ed anche carte.io accettano
> > query htpp  (get o post).
> Quoto.
>
> >>
> >>  1. *InfluxDB*: database ottimizzato per l'elaborazione delle serie
> >>     temporali
> >>
> > Ok va bene , vorrei sottolineare che  sarà necessario avere una
> > "tabella" dove sono catalogate tutte le centraline dalla quale attingere
> > per conoscere  posizione , stato, responsabile , data di installazione
> >  ed altre informazioni che possono aiutare a tenere una anagrafica e a
> > costruire un  portale di accesso generale.
> > Mi pare che con influxdb sia sconsogliato (se non impossibile) gestire
> > tabelle.
> > Come risolviamo questa cosa. ?
> Io penso che dovremmo tenere separate le due cose:
> Raccolta e immagazzinamento dati.
> Sito web, anagrafica, pagina di amministrazione, registrazione
> centraline, etc
>
> La prima è gestibile interamente con InfluxDB
> Per la seconda dovremmo fare un portale a parte con un suo database
> (magari SQL).
> >>
> >>  1. *Grafana*: applicazione per la visualizzazione grafica dei dati
> >>
> >   Garfana o altro va bene però non rimaniamo concetrati solo sui grafici
> > perchè alle persone
> >  dovremmo offrire una informazione rapida e comprensibile (tipo: "Oggi
> > va Bene" "Ieri è stato un dramma: non si respirava").
> >  Per capire cosa intendo vi invito a dare una occhaita qu
> > <http://salvatorehost.no-ip.org/aria/pm.php>i
> >  Poi ci sono i nostri amici tecnio-scentifici che vorrebbero scaricare i
> > dati in un formato adatto ad un foglio di calcolo per fare
> >  i loro grafici e le loro correllazioni e magari contestualizzare i dati
> > di inquinamento con quelli metereologici proenienti da altri servizi.
> > Quello che voglio dire e che comunque ci sarà da sbattersi un pochino
> > per fornire questi servizi.
>
> Grafana supporta già l'esportazione di dati in csv.
>
> Ho messo su grafana i dati dei miei sensori di temp, umidità e pressone.
> Qua puoi dare un occhio a come funziona:
>
> http://home.unname.eu:3000/dashboard/db/weather
> user: guest
> pwd: guest
>
> Se qualcuno avesse voglia di iniziare a pubblicare dati qua, sarebbe
> utile per capire come monitorare più centraline su Grafana.
>
>
>
> Gabriel
>
> _______________________________________________
> Firenze mailing list
> Firenze at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/firenze
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/firenze/attachments/20160919/7bdc989b/attachment-0002.html>