Smart Home Data Model

Smarte hjem plejede at være strengt i fremtiden; nu er de en realitet. De fleste af os har hørt om dem, men de er ikke så udbredte, som de vil være i den nærmeste fremtid. At administrere dit hjem på den 'smarte' måde vil helt sikkert producere en masse data. I dag vil vi analysere en datamodel, vi kunne bruge til at gemme smart home-data.

Datamodellen

Når du tænker på et smart hjem, tænker du sikkert på at fjernlåse og låse dit hjem op, aktivere alarmer, lys eller kameraer fra din telefon, have termometre, der automatisk styrer din opvarmning og køling osv. Men smarte hjem kan meget mere. Du kan tilslutte en række smartenheder og controllere for at opnå mange komplekse funktionaliteter. Du kan sende instruktioner til enheder eller læse deres status, uanset hvor du er.

Lad os tage et kig på en datamodel, der ville give os mulighed for at implementere sådanne funktionaliteter. Oven i denne datamodel kunne vi bygge en webapplikation og en mobilapplikation, der ville give registrerede brugere mulighed for at administrere deres konti, sende instruktioner og spore statusser.

Modellen består af tre fagområder:

Estates & devices
Users & profiles
Commands & data

Jeg vil beskrive hvert af disse emneområder i den rækkefølge, de er anført. Før noget andet vil jeg dog beskrive user_account tabel.

Brugerkontotabellen

Vi starter med user_account tabel, fordi den bruges i alle tre fagområder. Den gemmer en liste over alle de registrerede brugere af vores applikation.

user_account tabel indeholder alle de standardattributter, du ville forvente, inklusive:

first_name og last_name – Brugerens for- og efternavn.
user_name – ET UNIKT brugernavn valgt af brugeren.
password – En hashværdi af brugerens adgangskode.
email – Den e-mailadresse, som brugeren har angivet under registreringsprocessen.
confirmation_code – Den kode, der blev genereret under registreringsprocessen.
confirmation_time – Tidsstemplet, når brugeren bekræftede sin konto og fuldførte registreringsprocessen.
ts – Tidsstemplet, da denne post blev indsat i databasen.

Afsnit 1:Ejendomme og enheder

Hele motivationen bag oprettelsen af denne database er at overvåge, hvad der sker med vores ejendom (dvs. huse eller ejendomme). Disse kunne være private ejendomsejendomme, såsom lejligheder eller huse, eller de kunne være forretningsejendomme, såsom kontorer, varehuse osv. Hvis vi virkelig ønsker at presse vores system til det yderste, kan vi også bruge det til køretøjer.

Den centrale tabel i dette emneområde er real_estate bord. Det er her, vi gemmer alle de forskellige ejendomme eller ejendomme, der er forbundet med vores smarthome-app. For hver ejendom gemmer vi:

real_estate_name – Et navn, valgt af brugeren, der refererer til en bestemt egenskab.
user_account_id – ID'et på den bruger, som denne ejendom er relateret til. Sammen med attributten real_estate_name danner dette den UNIKKE (alternative) nøgle i denne tabel.
real_estate_type – Angiver den type fast ejendom, denne ejendom er.
address – Boets faktiske adresse. Dette er nullbart, fordi vi muligvis bruger dette system til andre typer ejendom (f.eks. køretøjer).
details – Alle yderligere detaljer i tekstformat.

Vi har allerede nævnt ejendomstyper. En komplet liste over mulige typer er gemt i real_estate_type ordbog. Den indeholder kun én UNIK værdi, type_name . Vi kunne forvente værdier som "lejlighed", "hus" eller "garage" her.

Et stykke fast ejendom kan opdeles i flere områder. Dette kunne være værelser i en lejlighed eller et hus; måske vil vi samle et par værelser eller vi vil have alt relateret til gården eller haven i én gruppe osv. Eller måske har vi et industriområde eller kompleks med flere kontorer; hvis vores ejendom er virkelig stor, kan det være meget nyttigt at have specifikke områder. For at opnå det bruger vi area bord. Den indeholder det UNIKKE par af real_estate_id og area_name valgt af brugeren.

De sidste to tabeller i dette emneområde er relateret til enheder.

I device_type tabel, gemmer vi en komplet liste over alle forskellige enhedstyper. For hver type bruger vi et UNIKT type_name og indsæt en yderligere description hvis det er nødvendigt. Enhedstyper kan være forskellige sensorer (temperatur, gas), dør- eller vindueslåse, lys, aircondition- og varmesystemer osv.

Nu er vi klar til den sjove del. Vi bruger device tabel for at gemme en liste over alle de enheder, der er inkluderet i forskellige smarte hjem. Disse enheder tilføjes af brugeren, enten manuelt eller automatisk, hvis enheden har denne mulighed. For hver enhed skal vi gemme:

real_estate_id – ID'et for den ejendom, hvor denne enhed er installeret.
area_id – Refererer til area hvor denne enhed er installeret. Dette er en valgfri værdi, fordi en ejendom kunne være opdelt i områder, men det må heller ikke opdeles.
device_type_id – ID'et for device_type denne enhed tilhører.
device_parameters – Vi bruger denne attribut til at gemme alle mulige enhedsparametre (f.eks. intervaller for lagring af data) i et struktureret tekstformat. Disse parametre kan indstilles af brugeren eller en del af enhedens almindelige funktion (f.eks. forskellige mål).
current_status – Den aktuelle status for enhedsparametre.
time_activated og time_deactivated – Angiv intervallet, hvor denne enhed var aktiv. Hvis time_deactivated ikke er indstillet, så er enheden aktiv og is_active attribut er også sat til True.

Afsnit 2:Brugere og profiler

Vi har allerede nævnt user_account bord. I vores applikation skal brugere være i stand til at oprette forskellige profiler og dele dem med andre brugere, hvis de ønsker det.

Profiler er dybest set undersæt af enheder, der er installeret i hvert stykke fast ejendom, som ejes af brugeren. Hver bruger kan have en eller flere profiler. Ideen er at gøre det muligt for en bruger at gruppere deres smarte hjemmeenheder på en passende måde. Mens brugeren kunne have én profil med alle deres enheder, kunne de også have én profil, der kun viser frontdørskameraerne for alle deres egenskaber. Eller måske en profil kun til termometre installeret i alle værelser i deres lejlighed.

Alle profiler oprettet af brugere gemmes i profile bord. For hver post har vi:

profile_name – Profilens navn, valgt af brugeren.
user_account_id – Refererer til den bruger, der oprettede denne profil. Denne attribut og profile_name attribut fra tabellens UNIKKE nøgle.
allow_others – Et flag, der angiver, om denne profil er delt med andre brugere.
is_public – Et flag, der angiver, om denne profil er offentligt synlig. Selvom vi kan forvente, at dette vil være indstillet til Falsk det meste af tiden, kan der være tilfælde, hvor vi ønsker at dele en profil med alle.
is_active – Et flag, der angiver, om denne profil er aktiv eller ej.
ts – Et tidsstempel for, hvornår denne post blev indsat.

For hver profil definerer vi en liste over alle enheder, der er inkluderet i den. Denne liste er gemt i profile_device_list tabel og indeholder en liste over UNIQUE profile_id – device_id par. Dette fremmednøglepar danner den primære nøgle i vores tabel.

Den sidste tabel i dette emne gør det muligt for brugere at dele deres profiler med andre registrerede brugere. Dette kunne være meget nyttigt, f.eks. hvis én person administrerer alt og andre registrerede brugere (f.eks. familiemedlemmer) ønsker at se profiler oprettet af ejeren. I shared_with tabel, gemmer vi en liste over alle UNIKKE par af profile_id – user_account_id . Endnu en gang er dette fremmednøglepar den primære nøgle i tabellen. Bemærk, at deling kun fungerer, hvis profile.allow_others attribut er sat til True.

Afsnit 3:Kommandoer og data

Vi vil bruge tabeller fra dette sidste emneområde til at gemme kommunikation mellem brugere og enheder. Dette vil være en tovejskommunikation. Enheder vil generere dataene under deres operationer, og vores database gemmer dem såvel som alle meddelelser, der genereres af systemet (eller enhederne). Brugere vil gerne se disse beskeder og de data, der sendes af deres enheder. Baseret på disse data kunne brugerne oprette programmer til deres smarte hjem. Disse programmer er manuelt eller automatisk genererede kommandoer eller endda en række kommandoer, der vil gøre præcis, hvad hver bruger ønsker.

Vi starter med de dataenheder, vi giver os. I device_data tabel, gemmer vi en beskrivelse af enhedsgenererede data og placeringen af dataene. Igen genereres data automatisk af enheder. Det kan være en række målinger, statusser (tekstdata) eller audiovisuelle data. For hver post i denne tabel gemmer vi:

device_id – ID'et på den enhed, der genererede disse data.
data_description – Beskrivelsen af de lagrede data, f.eks. hvad der er gemt, hvornår dataene blev gemt i vores system, og i hvilket format.
data_location – Den fulde sti til det sted, hvor disse data er gemt.
ts – Tidsstemplet, da denne post blev indsat.

Enhedsdata vil blive gemt, uanset om enheden fungerer korrekt, eller om dataene er uden for det forventede område. Dette er dybest set en log over alt, hvad der blev registreret af enhederne. Vi kan forvente at have en strategi til at slette gamle enhedsdatafiler, men det er uden for denne artikels omfang.

I modsætning til enhedsdata kan vi forvente, at beskeder først bliver genereret, når der sker noget uventet – f.eks. hvis en enhedsmåling er uden for det normale område, hvis en sensor registrerer bevægelse osv. I sådanne tilfælde genererer enheden meddelelserne. Alle sådanne beskeder gemmes i auto_message bord. I hver post har vi:

device_id – ID'et på den enhed, der genererede denne besked.
message_text – Teksten genereret af enheden. Dette kan være en foruddefineret tekst, en værdi, der er uden for det forventede interval, eller en kombination af disse to.
ts – Et tidsstempel for, hvornår denne post blev gemt.
read – Et flag, der angiver, om meddelelsen er blevet læst af brugeren.

De resterende tre tabeller bruges til at gemme brugernes kommandoer. Kommandoer giver brugerne mulighed for at tage kontrol over deres kontrollerbare enheder og etablere tovejskommunikation med deres smarte hjem.

Først vil vi definere en liste over alle mulige kommandotyper. Det kunne være værdier som "tænd/sluk", "øg/sænk temperatur" osv. Vi kunne også have betingede kommandoer, dvs. kommandoer, der kun opfyldes, hvis en bestemt betingelse er sand. En liste over alle forskellige kommandotyper er gemt i command_type ordbog. For hver type gemmer vi et UNIKT type_name . Vi gemmer også en liste over alle parametre, der skal defineres for den type kommando. Dette vil være i et struktureret tekstformat med indsatte standardværdier. Brugeren vil indstille disse værdier, når de indsætter deres nye kommandoer.

En bruger kan også definere alle recurring_commands foran. Måske vil vi have varmt vand hver dag kl. 7.00 eller at aktivere varme-/kølesystemet hver dag kl. 16.00. Sættet af regler og alle nødvendige attributter for at få tilbagevendende kommandoer til at ske, er gemt i denne tabel. Vi har:

user_account_id – ID'et på den bruger, der indsatte denne tilbagevendende kommando.
device_id – ID'et for den enhed, der er relevant for denne tilbagevendende kommando.
command_type_id – En reference til command_type ordbog.
parameters – Alle de parametre, der skal defineres for den kommandotype, sammen med deres ønskede værdier.
interval_definition – Intervallet mellem to gentagelser af denne kommando. Som med kommandoparametre vil dette være et struktureret tekstfelt.
active_from og active_to – Det interval, hvor denne kommando skal gentages. active_to attribut kan være NULL, hvis vi ønsker, at kommandoen skal gentages for evigt (eller indtil vi definerer active_to dato).
ts – Tidsstemplet, da denne post blev indsat.

Den sidste tabel i vores model indeholder en liste over enkelte kommandoer. Disse kommandoer kan indsættes manuelt af brugeren eller genereres automatisk (dvs. som en del af tilbagevendende kommandoer). For hver kommando gemmer vi:

recurring_command_id – ID'et for den tilbagevendende kommando, der udløser denne kommando, hvis nogen.
user_account_id – ID'et på den bruger, der indsatte denne kommando.
device_id – ID'et for den relevante enhed.
command_type_id – Refererer til command_type ordbog.
parameters – Alle de parametre, der er relevante for denne kommando.
executed – Et flag, der angiver, om denne kommando er blevet udført.
ts – Tidsstemplet, da denne post blev indsat.

Hvad synes du om Smart Home Data Model?

I denne artikel har vi forsøgt at dække de vigtigste aspekter af at administrere et smart hjem. En af dem er helt klart tovejskommunikation mellem brugeren og systemet. De fleste "rigtige" handlinger gemmes som tekstparametre, og disse værdier bør analyseres, når der udføres specifikke handlinger. Dette blev gjort, så vi kunne have tilstrækkelig fleksibilitet til at arbejde med mange forskellige enhedstyper.

Har du nogle forslag til at tilføje til vores smarthusmodel? Hvad ville du ændre eller fjerne? Fortæl os venligst i kommentarerne nedenfor.