Differenze tra le versioni di "Centralina livello 1"
Riga 124: | Riga 124: | ||
* SPI | * SPI | ||
* ... | * ... | ||
+ | | | ||
+ | Al momento l'ho soppresso, il tipo di segnale e` praticamente definito dal valore in entrata (per ora) | ||
|} | |} | ||
Riga 155: | Riga 157: | ||
! ID (Identificatore, Utenza/ITEM) | ! ID (Identificatore, Utenza/ITEM) | ||
| | | | ||
− | |||
* 1 | * 1 | ||
* 2 | * 2 | ||
Riga 166: | Riga 167: | ||
* (altro ?) | * (altro ?) | ||
* ... | * ... | ||
− | |||
− | |||
− | |||
− | |||
| | | | ||
− | + | Definito dall'utente che programma i "remote", ma meglio definire una struttura di base .. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|} | |} | ||
Riga 183: | Riga 174: | ||
! Valori | ! Valori | ||
| | | | ||
− | * TipoIO | + | * TipoIO:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori |
+ | | | ||
+ | Assegnato automaticamente dal programma | ||
|} | |} | ||
Riga 193: | Riga 186: | ||
* A (assorbimento) | * A (assorbimento) | ||
* ... | * ... | ||
+ | | | ||
+ | Questo e` previsto solo per le segnalazioni/avvisi/allarmi .. | ||
|} | |} | ||
Riga 202: | Riga 197: | ||
* ... | * ... | ||
* 99.000 (max impostabile) | * 99.000 (max impostabile) | ||
+ | | | ||
+ | Al momento non previsto, teoricamente i segnali dovrebbero arrivare gia` "filtrati" dai "remote" | ||
|} | |} | ||
Riga 209: | Riga 206: | ||
* 0-100 | * 0-100 | ||
* 0,1 | * 0,1 | ||
+ | | | ||
+ | Da utilizzarsi per definire l'errore e generare una segnalazione di sonda guasta | ||
|} | |} | ||
Riga 216: | Riga 215: | ||
* 10 (temperatura) | * 10 (temperatura) | ||
* 0 (binari/digitali) | * 0 (binari/digitali) | ||
+ | | | ||
+ | Sotto a questo valore dev'essere generato un'allarme | ||
|} | |} | ||
Riga 223: | Riga 224: | ||
* 40 (temperatura) | * 40 (temperatura) | ||
* 1 (binari/digitali) | * 1 (binari/digitali) | ||
+ | | | ||
+ | Sopra a questo valore dev'essere generato un'allarme | ||
|} | |} | ||
Riga 228: | Riga 231: | ||
! ValoreOn | ! ValoreOn | ||
| | | | ||
− | * 1 | + | * 1 (o vuoto quando segnale normale) |
+ | * 0 (quando attivo a segnale off) | ||
+ | | | ||
+ | Utile per sapere se si tratta di un segnale negato e trattarlo di conseguenza | ||
|} | |} | ||
Riga 241: | Riga 247: | ||
* off((oppure casella vuota ?)) | * off((oppure casella vuota ?)) | ||
* ... | * ... | ||
+ | | | ||
+ | Da definire, perche` tutto e`/o potrebbe essere allarme ... | ||
|} | |} | ||
Versione delle 19:00, 7 apr 2016
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 |
|
Al momento l'ho soppresso, il tipo di segnale e` praticamente definito dal valore in entrata (per ora) |
---|
PosizioneC |
|
---|
PosizioneP |
|
---|
PosizioneS |
|
---|
ID (Identificatore, Utenza/ITEM) |
|
Definito dall'utente che programma i "remote", ma meglio definire una struttura di base .. |
---|
Valori |
|
Assegnato automaticamente dal programma |
---|
UM (Unita` di Misura) |
|
Questo e` previsto solo per le segnalazioni/avvisi/allarmi .. |
---|
TempoRitardo (secondi) |
|
Al momento non previsto, teoricamente i segnali dovrebbero arrivare gia` "filtrati" dai "remote" |
---|
RangeValori |
|
Da utilizzarsi per definire l'errore e generare una segnalazione di sonda guasta |
---|
ValoreMin |
|
Sotto a questo valore dev'essere generato un'allarme |
---|
ValoreMax |
|
Sopra a questo valore dev'essere generato un'allarme |
---|
ValoreOn |
|
Utile per sapere se si tratta di un segnale negato e trattarlo di conseguenza |
---|
Allarme |
|
Da definire, perche` tutto e`/o potrebbe essere 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:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori
Autogenerata dal programma che legge i dati in arrivo (mqtt2redis_d.py)
Gruppi
Per realizzare i raggruppamenti ho utilizzato le chiavi Redis di tipo "sets".
Al momento ho pensato ai soli gruppi riguardanti gli allarmi e i grafici (per esempio quelli di due o piu`, sonde di temperatura).
Al solito, ho pensato ad una chiave univoca d'inserimento dei dati in Redis sets:type:ID
Gruppo |
|
---|
Tipo |
|
---|
ID (Identificatore) |
(definito da utente, esempi:)
|
---|
I gruppi sono definiti dall'utente, ed ogni volta che viene creato un nuovo gruppo (deve avere almeno un'utenza altrimenti si autoelimina), viene gia` creato il "Timer" di "campionamento" sets:type:ID:Timer, preimpostato a 5 minuti (sono previsto valori da 1 a 60 minuti).
In effetti la pagina d'inserimento permette di inserire una chiave con un nome qualsiasi, non ho ancora "bloccato" e/o previsto un controllo sull'identificazione.
Esempio "graph"
La chiave per questi gruppi e` previsto che sia: sets:graph:ID
La chiave per il timer di campionamento e` previsto che sia: sets:graph:ID:Timer (ora e` generata automaticamente)
La chiave per i dati campionati e la generazione del grafico (che sara` in formato csv) e` previsto che sia: sets:graph:ID:Valori (sara` creata ed aggiornata autonomamente, da un programma in python)
Esempio "alarms"
Al momento come sopra, tranne che il Timer non servira` (o forse si, perche` sono previsti anche grafici dei PIR).
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 ..
Caso 1
Invio da remoto ad MQTT, alla posizione:
"I/C/P/S/Type"
questa stringa:
{ "ID" : "TEMProv1", "Valore" : "18.5" }
La centralina legge, manipola (aggiungendo "DataOra" : "2016-03-20 09:45:11"), e modifica/aggiunge il sensore a Redis ..
Vengono create due chiavi:
"I:C:P:S:Type:ID" e "I:C:P:S:Type:ID:Valori"
Nelle successive letture sara` solo inserito il valore nella lista "Valori" (l'utenza e` gia` inserita, non e` piu` necessario)
Tramite apposita pagina sara` poi possibile manipolare il resto dei dati, come la descrizione ed altre informazioni (un paio ancora al vaglio).
?
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" ?