Versione delle 18:35, 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	Temperatura PIR Finecorsa Proximity Livello Rele` Termostato Valvola Motore ...

Descrizione	Breve (?) descrizione del segnale

TipoIO	I (Input/Ingresso) O (Output/Uscita)

Segnale	Analogico Digitale Testo I2C SPI ...

PosizioneC	Casa Garage Giardino ...

PosizioneP	Piano0 Piano1 ...

PosizioneS	Cucina1 Camera2 Bagno1 ...

ID (Identificatore, Utenza/ITEM)	(solo esempi, tutta da definire) 1 2 3 .. Up Down Left Right (altro ?) ...

AreaAllarme	(solo esempi, tutta da definire) P2Ext int ext numero lettera ...

Valori	TipoIO:Tipo:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori

UM (Unita` di Misura)	°C V (tensione) A (assorbimento) ...

TempoRitardo (secondi)	0.000 1.002 ... 99.000 (max impostabile)

RangeValori	0-100 0,1

ValoreMin	10 (temperatura) 0 (binari/digitali)

ValoreMax	40 (temperatura) 1 (binari/digitali)

ValoreOn	1

Allarme	0 1 Min Max Min,Max off((oppure casella vuota ?)) ...

TipoIO:PosizioneC:PosizioneP:PosizioneS:Tipo:ID:Valori

Data (e ora)	2016/03/13 20:40:08

Valore	0 1 13 ...

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	sets

Tipo	alarms graph ...

ID (Identificatore)	(definito da utente, esempi:) TemperatureBagno TemperaturePianoTerra luigi ...

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" ?

Differenze tra le versioni di "Centralina livello 1"