Centralina livello 1
Qui la foto |
---|
Centralina livello 1 |
Centralina generale (?) gestione segnali |
Repository: ancora no |
Centralina livello 1
Prima e sommaria descrizione
Centralina di controllo segnali.
Dove arrivano i segnali utenze e vengono smistati.
Come inizio si dovrebbe evolvere subito nella centralina di allarme (ma le idee sono ancora confuse --Dave4rp)
Hardware e Software
- Hardware
- Raspberry Pi 3, perche` completa di WiFi e Bluetooth
- Software
- MQTT Broker (Mosquitto), perche` in grado di dialogare con la maggior parte dei componenti (Arduino, ESP8266, eccetera)
- Redis, perche` servira` un database di appoggio e manipolazione per alcuni dati, e perche` servira` una struttura dati "manipolabile" (dovremo poter aggiungere e togliere "campi:valori" ad una "chiave", e aggiungere/togliere chiavi a delle liste, ecc. ecc.)
- Nginx, non si puo` fare senza web server
- ... e poi non so cos'altro
- Script cgi
- javascript
- ...
Access Point
Installato/configurato "Raspberry Pi Access Point WEP2", sfruttando il wifi integrato nel Raspberry Pi 3.
Descrizione
I 'segnali' arrivano sempre (?) a "MQTT broker", vengono manipolati se necessario, ed inseriti nel database Redis.
Dal database Redis sono di nuovo letti/scritti/modificati/manipolati ed inviati:
- e/o
- in report (testo, grafico, audio, video, ...)
- e/o
- alla centralina di allarme CentRed
- e/o
- reinviati a MQTT broker
- e/o
- inviati ad altre centraline livello 1
- e/o
- ...
Dati di livello 1 (bozza)
Tipo |
|
---|
Descrizione |
Breve (?) descrizione del segnale |
---|
TipoIO |
|
---|
Segnale |
|
---|
PosizioneC |
|
---|
PosizioneP |
|
---|
PosizioneS |
|
---|
ID (Identificatore, Utenza/ITEM) |
(solo esempi, tutta da definire)
|
---|
AreaAllarme |
(solo esempi, tutta da definire)
|
---|
Valore |
|
---|
UM (Unita` di Misura) |
|
---|
Data (e ora) |
|
---|
TempoRitardo (secondi) |
|
---|
RangeValori |
|
---|
ValoreMin |
|
---|
ValoreMax |
|
---|
ValoreOn |
|
---|
Allarme |
|
---|
Chiave primaria dati di livello 1
Mi riferisco alla chiave univoca d'inserimento dei dati in Redis.
Deve essere univoca, e sara` cosi` composta:
TipoIO:Tipo:PosizioneC:PosizioneP:PosizioneS:Tipo:ID
AreaAllarme
Con tutta probabilita`, sara` una "lista", generata da utente, dove inserire le utenze che faranno capo a quella determinata area di allarme, quindi, non sara` presente nel "record" di livello 1 (?)
Record da/per MQTT
Ancora tutta un'ipotesi
Percorso di ricevimento dato, dove una "centralina" remota scrive il valore:
- TipoIO(I)/PosizioneC/PosizioneP/PosizioneS/Tipo
Percorso d'invio comando, dove scrivere l'eventuale comando utenza che sia letto dalla "centralina" remota:
- TipoIO(O)/PosizioneC/PosizioneP/PosizioneS/Tipo
Il dato in arrivo avra` solo informazioni di base, esempio di input:
{ "ID" : "NomeUtenza", "Valore" : "1" }
Sono omesse { "TipoIO" : "I" , "PosizioneC" : "Casa", "PosizioneP" : "Piano0", "PosizioneS" : "Corridoio", "Tipo" : "PIR" }, perche` ricavabili da struttura directory.
Ho eliminato anche "DataOra" : "2016-03-16 09:46:01", perche` non sempre e` a disposizione, mentre lo sara` nella centralina, quindi si occupera` lei di inserirlo nella fase di manipolazione dati pre-inserimento in redis.
Il dato per 'comando' avra`, per esempio, queste informazioni:
{ "ID" : "NomeUtenza", "Valore" : "1" }
Anche qua, possono essere omesse le info ricavabili dal percorso di "scambio" dati.
Appunti sparsi
Caso PIR
Invio da remoto, alla posizione:
I/Casa/Piano1/Sala/Messaggi
questa stringa:
{ "ID" : "PIR0", "Valore" : "0" }
La centralina legge, eventualmente manipola (aggiungendo "DataOra" : "2016-03-20 09:45:11"), e modifica/aggiunge il sensore a Redis ..
Nel caso cambi il valore, stessa cosa, arriva la stringa:
{ "ID" : "PIRangoloTV", "Valore" : "1" }
La centralina legge, eventualmente manipola, e modifica/aggiunge il sensore a Redis ..
?
Ma se ci fosse una spia/lampada da accendere ?
Si potrebbe fare arrivare il feedback, ma come riconoscere che e` un'uscita ? Visto che arriverebbe come ingresso ?
Forse serve un TipoIO "F" ?