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.
Modificato il file "/etc/hosts", aggiunto il nome del pc, perche` i clients direttamente collegati possano utilizzare il nome e non l'indirizzo:
127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters #127.0.1.1 level1 # Ho dovuto eliminare il doppione 127.0.1.1 errorlevel 192.168.3.1 level1
Fra i clients il nome dovrebbe essere risolto automaticamente da "dnsmasq" (ricordarsi di verificare).
Rete
Al momento e` previsto che sia tutto sotto WiFi (quella onboard) del Raspberry Pi 3.
Comunque bastera` modificare il firewall per accettare dati dalla ethernet se si rendesse necessario.
Le centrali accessorie, tipo quella di allarme, che deve solo ricevere, non necessariamente dovranno trovarsi nella sottorete gestita da "livello 1".
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)
|
---|
Valori |
|
---|
UM (Unita` di Misura) |
|
---|
TempoRitardo (secondi) |
|
---|
RangeValori |
|
---|
ValoreMin |
|
---|
ValoreMax |
|
---|
ValoreOn |
|
---|
Allarme |
|
---|
TipoIO:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori
Data (e ora) |
|
---|
Valore |
|
---|
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:PosizioneC:PosizioneP:PosizioneS:Tipo:ID
Chiave primaria valori di livello 1
Mi riferisco alla chiave univoca d'inserimento dei valori in Redis.
Deve essere univoca, e sara` cosi` composta:
TipoIO:Tipo:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori
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" ?