Datamodellen för smarta hem

Smarta hem brukade vara strikt i framtiden; nu är de verklighet. De flesta av oss har hört talas om dem, men de är inte så utbredda som de kommer att vara inom en snar framtid. Att hantera ditt hem på det "smarta" sättet kommer definitivt att producera mycket data. Idag ska vi analysera en datamodell som vi kan använda för att lagra smarta hemdata.

Datamodellen

När du tänker på ett smart hem tänker du förmodligen på att fjärrlåsa och låsa upp ditt hem, aktivera larm, lampor eller kameror från din telefon, ha termometrar som automatiskt hanterar din uppvärmning och kyla, etc. Men smarta hem kan göra mycket mer. Du kan ansluta ett antal smarta enheter och kontroller för att uppnå många komplexa funktioner. Du kan skicka instruktioner till enheter eller läsa deras status var du än befinner dig.

Låt oss ta en titt på en datamodell som skulle tillåta oss att implementera sådana funktioner. Utöver den datamodellen kunde vi bygga en webbapplikation och en mobilapplikation som skulle tillåta registrerade användare att administrera sina konton, skicka instruktioner och spåra status.

Modellen består av tre ämnesområden:

Estates & devices
Users & profiles
Commands & data

Jag kommer att beskriva vart och ett av dessa ämnesområden i den ordning de är listade. Före allt annat kommer jag dock att beskriva user_account bord.

Användarkontotabellen

Vi börjar med user_account tabellen eftersom den används i alla tre ämnesområdena. Den lagrar en lista över alla registrerade användare av vår applikation.

user_account tabellen innehåller alla standardattribut du kan förvänta dig, inklusive:

first_name och last_name – Användarens för- och efternamn.
user_name – ETT UNIKT användarnamn valt av användaren.
password – Ett hashvärde för användarens lösenord.
email – E-postadressen som användaren angav under registreringsprocessen.
confirmation_code – Koden som genererades under registreringsprocessen.
confirmation_time – Tidsstämpeln när användaren bekräftade sitt konto och slutförde registreringsprocessen.
ts – Tidsstämpeln när denna post infogades i databasen.

Avsnitt 1:Estates and Devices

Hela motivationen bakom att skapa denna databas är att övervaka vad som händer med våra fastigheter (dvs. hem eller fastigheter). Dessa kan vara privata fastigheter, som lägenheter eller hus, eller de kan vara affärsfastigheter, som kontor, lager, etc. Om vi verkligen vill pressa vårt system till det yttersta kan vi också använda det för fordon.

Den centrala tabellen i detta ämnesområde är real_estate tabell. Det är här vi kommer att lagra alla olika fastigheter eller fastigheter som är kopplade till vår smarta hem-app. För varje dödsbo lagrar vi:

real_estate_name – Ett namn, valt av användaren, som refererar till en specifik egenskap.
user_account_id – ID för användaren som denna dödsbo är relaterad till. Tillsammans med attributet real_estate_name bildar detta den UNIKA (alternativa) nyckeln för denna tabell.
real_estate_type – Anger vilken typ av fastighet denna fastighet är.
address – Den faktiska adressen till dödsboet. Detta är nullbart eftersom vi kan använda det här systemet för andra typer av egendom (t.ex. fordon).
details – Alla ytterligare detaljer i textformat.

Vi har redan nämnt fastighetstyper. En komplett lista över möjliga typer lagras i real_estate_type lexikon. Den innehåller bara ett UNIKT värde, type_name . Vi kan förvänta oss värden som "lägenhet", "hus" eller "garage" här.

En fastighet kan delas in i flera områden. Detta kan vara rum i en lägenhet eller ett hus; kanske vill vi gruppera några rum eller så vill vi ha allt som har med gården eller trädgården att göra i en grupp etc. Eller så kanske vi har ett industriområde eller komplex med flera kontor; om vår fastighet är riktigt stor kan det vara mycket användbart att ha specifika ytor. För att uppnå det använder vi area tabell. Den innehåller det UNIKA paret av real_estate_id och area_name vald av användaren.

De två sista tabellerna i detta ämnesområde är relaterade till enheter.

I device_type tabell lagrar vi en komplett lista över alla distinkta enhetstyper. För varje typ använder vi ett UNIKT type_name och infoga en ytterligare description om det behövs. Enhetstyper kan vara olika sensorer (temperatur, gas), dörr- eller fönsterlås, lampor, luftkonditionering och värmesystem, etc.

Nu är vi redo för det roliga. Vi använder device tabell för att lagra en lista över alla enheter som ingår i olika smarta hem. Dessa enheter läggs till av användaren, antingen manuellt eller automatiskt om enheten har det alternativet. För varje enhet måste vi lagra:

real_estate_id – ID för fastigheten där enheten är installerad.
area_id – Refererar till area där denna enhet är installerad. Detta är ett valfritt värde eftersom en egendom kan delas upp i områden, men det får inte heller delas upp.
device_type_id – ID för device_type den här enheten tillhör.
device_parameters – Vi kommer att använda det här attributet för att lagra alla möjliga enhetsparametrar (t.ex. intervall för lagring av data) i ett strukturerat textformat. Dessa parametrar kan ställas in av användaren eller en del av enhetens vanliga funktion (t.ex. olika åtgärder).
current_status – Aktuell status för enhetsparametrar.
time_activated och time_deactivated – Ange intervallet när denna enhet var aktiv. Om time_deactivated inte är inställd, är enheten aktiv och is_active attribut är också satt till True.

Avsnitt 2:Användare och profiler

Vi har redan nämnt user_account tabell. I vår applikation ska användare kunna skapa olika profiler och dela dem med andra användare om de vill.

Profiler är i princip delmängder av enheter installerade i varje fastighet som ägs av användaren. Varje användare kan ha en eller flera profiler. Tanken är att göra det möjligt för en användare att gruppera sina smarta hemenheter på ett lämpligt sätt. Även om användaren kan ha en profil med alla sina enheter, kan de också ha en profil som endast visar ytterdörrskamerorna för alla sina egenskaper. Eller kanske en profil bara för termometrarna installerade i alla rum i deras lägenhet.

Alla profiler som skapats av användare lagras i profile tabell. För varje post har vi:

profile_name – Profilens namn, valt av användaren.
user_account_id – Refererar till användaren som skapade den här profilen. Detta attribut och profile_name attribut från tabellens UNIKA nyckel.
allow_others – En flagga som anger om denna profil delas med andra användare.
is_public – En flagga som anger om denna profil är offentligt synlig. Även om vi kan förvänta oss att detta kommer att vara inställt på False för det mesta, kan det finnas fall då vi vill dela en profil med alla.
is_active – En flagga som anger om denna profil är aktiv eller inte.
ts – En tidsstämpel för när denna post infogades.

För varje profil kommer vi att definiera en lista över alla enheter som ingår i den. Den här listan lagras i profile_device_list tabell och innehåller en lista med UNIQUE profile_id – device_id par. Detta främmande nyckelpar utgör den primära nyckeln i vår tabell.

Den sista tabellen i detta ämne gör det möjligt för användare att dela sina profiler med andra registrerade användare. Detta kan vara mycket användbart, t.ex. om en person hanterar allt och andra registrerade användare (t.ex. familjemedlemmar) vill se profiler skapade av ägaren. I shared_with tabell lagrar vi en lista över alla UNIKA par av profile_id – user_account_id . Återigen är detta främmande nyckelpar den primära nyckeln i tabellen. Observera att delning endast fungerar om profile.allow_others attribut är satt till True.

Avsnitt 3:Kommandon och data

Vi kommer att använda tabeller från detta sista ämnesområde för att lagra kommunikation mellan användare och enheter. Detta kommer att vara en tvåvägskommunikation. Enheter kommer att generera data under sin verksamhet och vår databas kommer att lagra den såväl som alla meddelanden som genereras av systemet (eller enheterna). Användare kommer att vilja se dessa meddelanden och data som skickas av deras enheter. Baserat på dessa data kan användare skapa program för sitt smarta hem. Dessa program är manuellt eller automatiskt genererade kommandon eller till och med en serie kommandon som kommer att göra exakt vad varje användare vill ha.

Vi börjar med de dataenheter som ger oss. I device_data tabell lagrar vi en beskrivning av enhetsgenererad data och platsen/platserna för data. Återigen, data genereras automatiskt av enheter. Det kan vara en serie mätningar, statuser (textdata) eller audiovisuella data. För varje post i den här tabellen lagrar vi:

device_id – ID för enheten som genererade dessa data.
data_description – Beskrivningen av de lagrade uppgifterna, t.ex. vad som lagras, när uppgifterna lagrades i vårt system och i vilket format.
data_location – Den fullständiga sökvägen till platsen där denna data lagras.
ts – Tidsstämpeln när denna post infogades.

Enhetsdata kommer att lagras oavsett om enheten fungerar korrekt eller om data ligger utanför det förväntade intervallet. Detta är i princip en logg över allt som har registrerats av enheterna. Vi kan förvänta oss att ha en strategi för att ta bort gamla enhetsdatafiler, men det ligger utanför den här artikelns omfattning.

Till skillnad från enhetsdata kan vi förvänta oss att meddelanden bara genereras när något oväntat händer – t.ex. om en enhetsmätning ligger utanför det normala intervallet, om en sensor upptäckt rörelse, etc. I sådana fall genererar enheten meddelandena. Alla sådana meddelanden lagras i auto_message tabell. I varje post kommer vi att ha:

device_id – ID för enheten som genererade detta meddelande.
message_text – Texten som genereras av enheten. Detta kan vara en fördefinierad text, ett värde som ligger utanför det förväntade intervallet eller en kombination av dessa två.
ts – En tidsstämpel för när denna post lagrades.
read – En flagga som anger om meddelandet hade lästs av användaren.

De återstående tre tabellerna används för att lagra användarnas kommandon. Kommandon låter användare ta kontroll över sina kontrollerbara enheter och etablera tvåvägskommunikation med sitt smarta hem.

Först kommer vi att definiera en lista över alla möjliga kommandotyper. Dessa kan vara värden som "slå på/av", "öka/minska temperaturen" etc. Vi skulle också kunna ha villkorliga kommandon, dvs. kommandon som endast uppfylls om ett specifikt villkor är sant. En lista över alla distinkta kommandotyper lagras i command_type lexikon. För varje typ lagrar vi ett UNIKT type_name . Vi kommer också att lagra en lista över alla parametrar som bör definieras för den typen av kommando. Detta kommer att vara i ett strukturerat textformat med infogade standardvärden. Användaren kommer att ställa in dessa värden när de infogar sina nya kommandon.

En användare kan också definiera alla recurring_commands framtill. Kanske vill vi ha varmvatten varje dag klockan 07.00 eller att aktivera värme-/kylasystemet varje dag klockan 16.00. Uppsättningen regler och alla nödvändiga attribut för att få återkommande kommandon att hända lagras i den här tabellen. Vi har:

user_account_id – ID för användaren som infogade detta återkommande kommando.
device_id – ID för enheten som är relevant för detta återkommande kommando.
command_type_id – En referens till command_type ordbok.
parameters – Alla parametrar som ska definieras för den kommandotypen, tillsammans med deras önskade värden.
interval_definition – Intervallet mellan två upprepningar av detta kommando. Precis som med kommandoparametrar kommer detta att vara ett strukturerat textfält.
active_from och active_to – Intervallet under vilket detta kommando ska upprepas. active_to attributet kan vara NULL om vi vill att kommandot ska upprepas för alltid (eller tills vi definierar active_to datum).
ts – Tidsstämpeln när denna post infogades.

Den sista tabellen i vår modell innehåller en lista med enstaka kommandon. Dessa kommandon kan infogas manuellt av användaren eller genereras automatiskt (dvs som en del av återkommande kommandon). För varje kommando lagrar vi:

recurring_command_id – ID för det återkommande kommandot som utlöser detta kommando, om något.
user_account_id – ID för användaren som infogade detta kommando.
device_id – ID för den relevanta enheten.
command_type_id – Refererar till command_type ordbok.
parameters – Alla parametrar som är relevanta för detta kommando.
executed – En flagga som anger om detta kommando har utförts.
ts – Tidsstämpeln när denna post infogades.

Vad tycker du om Smart Home Data Model?

I den här artikeln har vi försökt täcka de viktigaste aspekterna av att hantera ett smart hem. En av dem är definitivt tvåvägskommunikation mellan användaren och systemet. De flesta "riktiga" åtgärder lagras som textparametrar, och dessa värden bör analyseras när du utför specifika åtgärder. Detta gjordes för att vi skulle ha tillräckligt med flexibilitet för att arbeta med många olika enhetstyper.

Har du några förslag att lägga till vår smarta hemmodell? Vad skulle du ändra eller ta bort? Berätta för oss i kommentarerna nedan.