Le case intelligenti erano rigorosamente nel futuro; ora sono una realtà. La maggior parte di noi ne ha sentito parlare, ma non sono così diffusi come lo saranno nel prossimo futuro. Gestire la tua casa in modo "intelligente" produrrà sicuramente molti dati. Oggi analizzeremo un modello di dati che potremmo utilizzare per archiviare i dati della casa intelligente.
Il modello dei dati
Quando pensi a una casa intelligente, probabilmente pensi a bloccare e sbloccare la tua casa da remoto, attivare allarmi, luci o telecamere dal tuo telefono, avere termometri che gestiscono automaticamente il riscaldamento e il raffreddamento, ecc. Ma le case intelligenti possono fare molto di più. È possibile collegare una serie di dispositivi e controller intelligenti per ottenere molte funzionalità complesse. Puoi inviare istruzioni ai dispositivi o leggere i loro stati ovunque ti trovi.
Diamo un'occhiata a un modello di dati che ci permetterebbe di implementare tali funzionalità. Oltre a questo modello di dati, potremmo creare un'applicazione Web e un'applicazione mobile che consenta agli utenti registrati di amministrare i propri account, inviare istruzioni e tenere traccia degli stati.
Il modello si compone di tre aree tematiche:
Estates & devices
Users & profiles
Commands & data
Descriverò ciascuna di queste aree tematiche nell'ordine in cui sono elencate. Prima di ogni altra cosa, però, descriverò il user_account
tabella.
La tabella User_Account
Iniziamo con il user_account
tabella perché è utilizzato in tutte e tre le aree tematiche. Memorizza un elenco di tutti gli utenti registrati della nostra applicazione.
Il user_account
la tabella contiene tutti gli attributi standard che ti aspetteresti, inclusi:
first_name
elast_name
– Il nome e il cognome dell'utente.user_name
– Un nome utente UNICO scelto dall'utente.password
– Un valore hash della password dell'utente.email
– L'indirizzo email fornito dall'utente durante il processo di registrazione.confirmation_code
– Il codice generato durante il processo di registrazione.confirmation_time
– Il timestamp in cui l'utente ha confermato il proprio account e completato il processo di registrazione.ts
– Il timestamp in cui questo record è stato inserito nel database.
Sezione 1:Proprietà e dispositivi
L'intera motivazione alla base della creazione di questo database è monitorare ciò che sta accadendo con le nostre proprietà (ad esempio case o proprietà). Potrebbero essere proprietà private, come appartamenti o case, o potrebbero essere proprietà commerciali, come uffici, magazzini, ecc. Se vogliamo davvero spingere il nostro sistema al limite, potremmo usarlo anche per i veicoli.
La tabella centrale in questa area tematica è il real_estate
tavolo. Qui è dove memorizzeremo tutte le diverse proprietà o proprietà collegate alla nostra app per la casa intelligente. Per ogni proprietà, memorizzeremo:
real_estate_name
– Un nome, scelto dall'utente, che fa riferimento a una specifica proprietà.user_account_id
– L'ID dell'utente a cui è correlata questa proprietà. Insieme all'attributo real_estate_name, questo costituisce la chiave UNICA (alternativa) di questa tabella.real_estate_type
– Indica il tipo di immobile in cui si trova questa proprietà.address
– L'indirizzo effettivo di tale eredità. Questo è nullable perché potremmo usare questo sistema per altri tipi di proprietà (es. veicoli).details
– Tutti i dettagli aggiuntivi in formato testuale.
Abbiamo già menzionato i tipi di immobili. Un elenco completo dei possibili tipi è memorizzato in real_estate_type
dizionario. Contiene solo un valore UNIQUE, il type_name
. Potremmo aspettarci valori come "appartamento", "casa" o "garage" qui.
Un immobile può essere suddiviso in più aree. Potrebbero essere le stanze di un appartamento o di una casa; forse vogliamo raggruppare alcune stanze insieme o vogliamo tutto ciò che riguarda il cortile o il giardino in un gruppo, ecc. O forse abbiamo una zona industriale o un complesso con più uffici; se la nostra proprietà è davvero grande, avere delle aree specifiche può essere molto utile. Per raggiungere questo obiettivo, utilizzeremo l'area
tavolo. Contiene la coppia UNICA di real_estate_id
e il area_name
scelto dall'utente.
Le ultime due tabelle in questa area tematica sono relative ai dispositivi.
Nel device_type
tabella, memorizzeremo un elenco completo di tutti i tipi di dispositivi distinti. Per ogni tipo, utilizzeremo un type_name
UNICO e inserisci un'ulteriore description
se necessario. I tipi di dispositivi possono essere diversi sensori (temperatura, gas), serrature di porte o finestre, luci, impianti di condizionamento e riscaldamento, ecc.
Ora siamo pronti per la parte divertente. Utilizzeremo il device
tabella per memorizzare un elenco di tutti i dispositivi inclusi nelle varie case intelligenti. Questi dispositivi vengono aggiunti dall'utente, manualmente o automaticamente se il dispositivo dispone di tale opzione. Per ogni dispositivo, dovremo memorizzare:
real_estate_id
– L'ID dell'immobile in cui è installato questo dispositivo.area_id
– Fa riferimento all'area
dove è installato questo dispositivo. Questo è un valore facoltativo perché una proprietà potrebbe essere diviso in aree, ma non può nemmeno essere diviso.device_type_id
– L'ID deldevice_type
a cui appartiene questo dispositivo.device_parameters
– Utilizzeremo questo attributo per memorizzare tutti i possibili parametri del dispositivo (ad es. intervalli per la memorizzazione dei dati) in un formato testuale strutturato. Questi parametri possono essere impostati dall'utente o da una parte del normale funzionamento del dispositivo (es. misure diverse).current_status
– Lo stato attuale dei parametri del dispositivo.time_activated
etime_deactivated
– Indica l'intervallo in cui questo dispositivo era attivo. Setime_deactivated
non è impostato, il dispositivo è attivo eis_active
anche l'attributo è impostato su True.
Sezione 2:Utenti e profili
Abbiamo già menzionato il user_account
tavolo. Nella nostra applicazione, gli utenti dovrebbero essere in grado di creare profili diversi e condividerli con altri utenti, se lo desiderano.
I profili sono fondamentalmente sottoinsiemi di dispositivi installati in ogni immobile di proprietà dell'utente. Ogni utente può avere uno o più profili. L'idea è quella di consentire a un utente di raggruppare i propri dispositivi domestici intelligenti in modo adeguato. Sebbene l'utente possa avere un profilo con tutti i suoi dispositivi, potrebbe anche avere un profilo che mostra solo le telecamere della porta principale per tutte le sue proprietà. O magari un profilo solo per i termometri installati in tutte le stanze del loro appartamento.
Tutti i profili creati dagli utenti sono memorizzati nel profile
tavolo. Per ogni record avremo:
profile_name
– Il nome del profilo, scelto dall'utente.user_account_id
– Fa riferimento all'utente che ha creato questo profilo. Questo attributo e ilprofile_name
attributo formano la chiave UNICA della tabella.allow_others
– Un flag che indica se questo profilo è condiviso con altri utenti.is_public
– Un flag che indica se questo profilo è visibile pubblicamente. Sebbene possiamo aspettarci che questo sarà impostato su False per la maggior parte del tempo, potrebbero esserci casi in cui vogliamo condividere un profilo con tutti.is_active
– Un flag che indica se questo profilo è attivo o meno.ts
– Un timestamp di quando questo record è stato inserito.
Per ogni profilo, definiremo un elenco di tutti i dispositivi inclusi in esso. Questo elenco è memorizzato nel profile_device_list
tabella e contiene un elenco di UNIQUE profile_id
– device_id
coppie. Questa coppia di chiavi esterne costituisce la chiave primaria della nostra tabella.
L'ultima tabella in questo argomento consente agli utenti di condividere i propri profili con altri utenti registrati. Questo potrebbe essere molto utile, ad es. se una persona gestisce tutto e altri utenti registrati (es. familiari) vogliono visualizzare i profili creati dal proprietario. Nel shared_with
tabella, memorizzeremo un elenco di tutte le coppie UNIQUE di profile_id
– user_account_id
. Ancora una volta, questa coppia di chiavi esterne è la chiave primaria della tabella. Tieni presente che la condivisione funzionerà solo se il profile.allow_others
l'attributo è impostato su True.
Sezione 3:Comandi e dati
Utilizzeremo le tabelle di quest'ultima area tematica per archiviare le comunicazioni tra utenti e dispositivi. Questa sarà una comunicazione bidirezionale. I dispositivi genereranno i dati durante le loro operazioni e il nostro database li memorizzerà così come tutti i messaggi generati dal sistema (o dai dispositivi). Gli utenti vorranno vedere questi messaggi e i dati inviati dai loro dispositivi. Sulla base di questi dati, gli utenti potrebbero creare programmi per la loro casa intelligente. Questi programmi sono comandi generati manualmente o automaticamente o anche una serie di comandi che faranno esattamente ciò che ogni utente desidera.
Inizieremo con i dati che i dispositivi ci forniscono. Nei device_data
tabella, memorizzeremo una descrizione dei dati generati dal dispositivo e le posizioni dei dati. Anche in questo caso, i dati vengono generati automaticamente dai dispositivi. Potrebbe essere una serie di misurazioni, stati (dati testuali) o dati audiovisivi. Per ogni record in questa tabella, memorizzeremo:
device_id
– L'ID del dispositivo che ha generato questi dati.data_description
– La descrizione dei dati memorizzati, ad es. cosa viene archiviato, quando i dati sono stati archiviati nel nostro sistema e in quale formato.data_location
– Il percorso completo della posizione in cui sono archiviati questi dati.ts
– Il timestamp in cui è stato inserito questo record.
I dati del dispositivo verranno archiviati indipendentemente dal fatto che il dispositivo funzioni correttamente o se i dati non rientrano nell'intervallo previsto. Questo è fondamentalmente un registro di tutto ciò che è stato registrato dai dispositivi. Possiamo aspettarci di avere una strategia per eliminare i vecchi file di dati del dispositivo, ma questo esula dallo scopo di questo articolo.
A differenza dei dati del dispositivo, possiamo aspettarci che i messaggi vengano generati solo quando accade qualcosa di imprevisto, ad es. se una misurazione del dispositivo è al di fuori del range normale, se un sensore ha rilevato un movimento, ecc. In questi casi, il dispositivo genera i messaggi. Tutti questi messaggi sono memorizzati nel auto_message
tavolo. In ogni record avremo:
device_id
– L'ID del dispositivo che ha generato questo messaggio.message_text
– Il testo generato dal dispositivo. Potrebbe trattarsi di un testo predefinito, un valore che non rientra nell'intervallo previsto o una combinazione di questi due.ts
– Un timestamp di quando questo record è stato archiviato.read
– Un flag che indica se il messaggio è stato letto dall'utente.
Le restanti tre tabelle vengono utilizzate per memorizzare i comandi degli utenti. I comandi consentono agli utenti di assumere il controllo dei propri dispositivi controllabili e di stabilire una comunicazione bidirezionale con la propria casa intelligente.
Innanzitutto, definiremo un elenco di tutti i possibili tipi di comando. Questi potrebbero essere valori come "accensione/spegnimento", "aumento/diminuzione della temperatura", ecc. Potremmo anche avere comandi condizionali, ad es. comandi che vengono soddisfatti solo se una condizione specifica è vera. Un elenco di tutti i tipi di comando distinti è archiviato in command_type
dizionario. Per ogni tipo, memorizzeremo un type_name
UNICO . Conserveremo anche un elenco di tutti i parametri che dovrebbero essere definiti per quel tipo di comando. Questo sarà in un formato di testo strutturato con valori predefiniti inseriti. L'utente imposterà questi valori durante l'inserimento dei nuovi comandi.
Un utente può anche definire tutti i recurring_commands
in anticipo. Forse vogliamo acqua calda ogni giorno alle 7:00 o per attivare il sistema di riscaldamento/raffreddamento ogni giorno alle 16:00. L'insieme di regole e tutti gli attributi necessari per eseguire i comandi ricorrenti sono archiviati in questa tabella. Avremo:
user_account_id
– L'ID dell'utente che ha inserito questo comando ricorrente.device_id
– L'ID del dispositivo rilevante per questo comando ricorrente.command_type_id
– Un riferimento alcommand_type
dizionario.parameters
– Tutti i parametri che dovrebbero essere definiti per quel tipo di comando, insieme ai loro valori desiderati.interval_definition
– L'intervallo tra due ricorrenze di questo comando. Come per i parametri di comando, questo sarà un campo di testo strutturato.active_from
eactive_to
– L'intervallo durante il quale questo comando deve essere ripetuto. Ilactive_to
l'attributo può essere NULL se vogliamo che il comando si ripeta per sempre (o finché non definiamo ilactive_to
data).ts
– Il timestamp in cui è stato inserito questo record.
L'ultima tabella del nostro modello contiene un elenco di singoli comandi. Questi comandi possono essere inseriti manualmente dall'utente o generati automaticamente (cioè come parte di comandi ricorrenti). Per ogni comando memorizzeremo:
recurring_command_id
– L'ID del comando ricorrente che attiva questo comando, se presente.user_account_id
– L'ID dell'utente che ha inserito questo comando.device_id
– L'ID del dispositivo in questione.command_type_id
– Fa riferimento alcommand_type
dizionario.parameters
– Tutti i parametri relativi a questo comando.executed
– Un flag che indica se questo comando è stato eseguito.ts
– Il timestamp in cui è stato inserito questo record.
Cosa ne pensi del modello di dati Smart Home?
In questo articolo abbiamo cercato di coprire gli aspetti più importanti della gestione di una casa intelligente. Uno di questi è sicuramente la comunicazione bidirezionale tra l'utente e il sistema. La maggior parte delle azioni "reali" vengono archiviate come parametri testuali e questi valori devono essere analizzati durante l'esecuzione di azioni specifiche. Questo è stato fatto in modo da poter avere abbastanza flessibilità per lavorare con molti tipi di dispositivi diversi.
Hai qualche suggerimento da aggiungere al nostro modello di casa intelligente? Cosa cambieresti o rimuoveresti? Per favore, dicci nei commenti qui sotto.