Het Smart Home-gegevensmodel

Slimme huizen waren vroeger strikt in de toekomst; nu zijn ze een realiteit. De meesten van ons hebben ervan gehoord, maar ze zijn niet zo wijdverbreid als ze in de nabije toekomst zullen zijn. Het ‘slim’ beheren van je huis zal zeker veel data opleveren. Vandaag analyseren we een datamodel dat we zouden kunnen gebruiken om smart home-gegevens op te slaan.

Het gegevensmodel

Als je aan een smart home denkt, denk je waarschijnlijk aan het op afstand vergrendelen en ontgrendelen van je huis, het activeren van alarmen, lichten of camera's vanaf je telefoon, thermometers hebben die je verwarming en koeling automatisch regelen, enz. Maar slimme huizen kunnen veel meer. Je kunt een aantal slimme apparaten en controllers aansluiten om veel complexe functionaliteiten te realiseren. Je kunt instructies naar apparaten sturen of hun status lezen, waar je ook bent.

Laten we eens kijken naar een datamodel waarmee we dergelijke functionaliteiten kunnen implementeren. Bovenop dat datamodel zouden we een webapplicatie en een mobiele applicatie kunnen bouwen waarmee geregistreerde gebruikers hun accounts kunnen beheren, instructies kunnen sturen en statussen kunnen volgen.

Het model bestaat uit drie vakgebieden:

Estates & devices
Users & profiles
Commands & data

Ik zal elk van deze vakgebieden beschrijven in de volgorde waarin ze worden vermeld. Maar eerst zal ik het user_account tafel.

De User_Account-tabel

We beginnen met het user_account tabel omdat het in alle drie de vakgebieden wordt gebruikt. Het slaat een lijst op van alle geregistreerde gebruikers van onze applicatie.

Het user_account tabel bevat alle standaardkenmerken die u zou verwachten, waaronder:

first_name en last_name – De voor- en achternaam van de gebruiker.
user_name – Een UNIEKE gebruikersnaam gekozen door de gebruiker.
password – Een hash-waarde van het wachtwoord van de gebruiker.
email – Het e-mailadres dat door de gebruiker is opgegeven tijdens het registratieproces.
confirmation_code – De code gegenereerd tijdens het registratieproces.
confirmation_time – Het tijdstempel waarop de gebruiker zijn account heeft bevestigd en het registratieproces heeft voltooid.
ts – Het tijdstempel waarop dit record in de database werd ingevoegd.

Sectie 1:Landgoederen en apparaten

De hele motivatie achter het maken van deze database is om te volgen wat er gebeurt met onze landgoederen (d.w.z. huizen of eigendommen). Dit kunnen privéterreinen zijn, zoals appartementen of huizen, of het kunnen bedrijfseigendommen zijn, zoals kantoren, magazijnen, enz. Als we ons systeem echt tot het uiterste willen drijven, kunnen we het ook voor voertuigen gebruiken.

De centrale tabel in dit onderwerpgebied is de real_estate tafel. Hier slaan we alle verschillende landgoederen of eigendommen op die zijn verbonden met onze smart home-app. Voor elk landgoed slaan we op:

real_estate_name – Een naam, gekozen door de gebruiker, die verwijst naar een specifieke eigenschap.
user_account_id – De ID van de gebruiker waaraan deze estate is gerelateerd. Samen met het real_estate_name attribuut vormt dit de UNIEKE (alternatieve) sleutel van deze tabel.
real_estate_type – Geeft het type onroerend goed aan dat dit onroerend goed is.
address – Het werkelijke adres van die nalatenschap. Dit is nullable omdat we dit systeem voor andere soorten eigendommen (bijv. voertuigen) kunnen gebruiken.
details – Alle aanvullende details in tekstformaat.

We hebben al vastgoedtypes genoemd. Een volledige lijst met mogelijke typen is opgeslagen in de real_estate_type woordenboek. Het bevat slechts één UNIEKE waarde, de type_name . We kunnen hier waarden als 'appartement', 'huis' of 'garage' verwachten.

Een stuk onroerend goed kan worden onderverdeeld in verschillende gebieden. Dit kunnen kamers van een appartement of een huis zijn; misschien willen we een paar kamers groeperen of willen we alles wat met het erf of tuin te maken heeft in één groep, enz. Of misschien hebben we een industrieterrein of complex met meerdere kantoren; als ons eigendom erg groot is, kan het erg handig zijn om specifieke ruimtes te hebben. Om dat te bereiken, gebruiken we het area tafel. Het bevat het UNIEKE paar van de real_estate_id en de area_name gekozen door de gebruiker.

De laatste twee tabellen in dit onderwerp hebben betrekking op apparaten.

In de device_type tabel, slaan we een volledige lijst op van alle verschillende apparaattypen. Voor elk type gebruiken we een UNIEKE type_name en voeg een aanvullende description in indien nodig. Apparaattypes kunnen verschillende sensoren zijn (temperatuur, gas), deur- of raamsloten, lichten, airconditioning- en verwarmingssystemen, enz.

Nu zijn we klaar voor het leuke gedeelte. We gebruiken het device tabel om een lijst op te slaan van alle apparaten in verschillende slimme huizen. Deze apparaten worden door de gebruiker toegevoegd, handmatig of automatisch als het apparaat die optie heeft. Voor elk apparaat moeten we opslaan:

real_estate_id – De ID van het onroerend goed waar dit apparaat is geïnstalleerd.
area_id – Verwijst naar het area waar dit apparaat is geïnstalleerd. Dit is een optionele waarde omdat een landgoed zou worden verdeeld in gebieden, maar het mag ook niet worden verdeeld.
device_type_id – De ID van het device_type dit apparaat is van.
device_parameters – We gebruiken dit attribuut om alle mogelijke apparaatparameters (bijv. intervallen voor het opslaan van gegevens) in een gestructureerd tekstformaat op te slaan. Deze parameters kunnen worden ingesteld door de gebruiker of een deel van de normale functie van het apparaat (bijvoorbeeld verschillende maatregelen).
current_status – De huidige status van apparaatparameters.
time_activated en time_deactivated – Geef het interval aan waarin dit apparaat actief was. Indien time_deactivated niet is ingesteld, dan is het apparaat actief en de is_active kenmerk is ook ingesteld op True.

Sectie 2:Gebruikers en profielen

We hebben het user_account tafel. In onze applicatie moeten gebruikers verschillende profielen kunnen maken en deze kunnen delen met andere gebruikers als ze dat willen.

Profielen zijn in feite subsets van apparaten die zijn geïnstalleerd in elk stuk onroerend goed dat eigendom is van de gebruiker. Elke gebruiker kan een of meer profielen hebben. Het idee is om een gebruiker in staat te stellen zijn smart home-apparaten op een geschikte manier te groeperen. Hoewel de gebruiker één profiel met al zijn apparaten zou kunnen hebben, zou hij ook één profiel kunnen hebben met alleen de camera's aan de voordeur voor al zijn eigendommen. Of misschien één profiel voor de thermometers die in alle kamers van hun appartement zijn geïnstalleerd.

Alle profielen die door gebruikers zijn gemaakt, worden opgeslagen in het profile tafel. Voor elk record hebben we:

profile_name – De naam van het profiel, gekozen door de gebruiker.
user_account_id – Verwijst naar de gebruiker die dit profiel heeft gemaakt. Dit kenmerk en de profile_name attribuut vormen de UNIEKE sleutel van de tabel.
allow_others – Een vlag die aangeeft of dit profiel wordt gedeeld met andere gebruikers.
is_public – Een vlag die aangeeft of dit profiel openbaar zichtbaar is. Hoewel we kunnen verwachten dat dit meestal is ingesteld op False, kunnen er gevallen zijn waarin we een profiel met iedereen willen delen.
is_active – Een vlag die aangeeft of dit profiel actief is of niet.
ts – Een tijdstempel van wanneer deze record is ingevoegd.

Voor elk profiel definiëren we een lijst met alle apparaten die erin zijn opgenomen. Deze lijst wordt opgeslagen in de profile_device_list tabel en bevat een lijst van UNIEKE profile_id – device_id paren. Dit vreemde sleutelpaar vormt de primaire sleutel van onze tabel.

De laatste tabel in dit onderwerp stelt gebruikers in staat hun profielen te delen met andere geregistreerde gebruikers. Dit kan erg handig zijn, b.v. als één persoon alles beheert en andere geregistreerde gebruikers (bijvoorbeeld gezinsleden) profielen willen bekijken die door de eigenaar zijn gemaakt. In de shared_with tabel, slaan we een lijst op van alle UNIEKE paren van profile_id – user_account_id . Nogmaals, dit vreemde sleutelpaar is de primaire sleutel van de tabel. Houd er rekening mee dat delen alleen werkt als de profile.allow_others kenmerk is ingesteld op True.

Sectie 3:Opdrachten en gegevens

We gebruiken tabellen uit dit laatste onderwerpgebied om communicatie tussen gebruikers en apparaten op te slaan. Dit zal een tweerichtingscommunicatie zijn. Apparaten genereren de gegevens tijdens hun activiteiten en onze database slaat deze op, evenals alle berichten die door het systeem (of de apparaten) worden gegenereerd. Gebruikers zullen deze berichten en de gegevens die door hun apparaten zijn verzonden, willen zien. Op basis van deze gegevens konden gebruikers programma's maken voor hun slimme huis. Deze programma's zijn handmatig of automatisch gegenereerde opdrachten of zelfs een reeks opdrachten die precies doen wat elke gebruiker wil.

We beginnen met de gegevens die apparaten ons geven. In de device_data tabel, slaan we een beschrijving op van door het apparaat gegenereerde gegevens en de locatie(s) van de gegevens. Nogmaals, gegevens worden automatisch gegenereerd door apparaten. Het kan gaan om een reeks metingen, statussen (tekstuele gegevens) of audiovisuele gegevens. Voor elk record in deze tabel slaan we op:

device_id – De ID van het apparaat dat deze gegevens heeft gegenereerd.
data_description – De beschrijving van de opgeslagen gegevens, b.v. wat er wordt opgeslagen, wanneer de gegevens in ons systeem zijn opgeslagen en in welk formaat.
data_location – Het volledige pad naar de locatie waar deze gegevens zijn opgeslagen.
ts – Het tijdstempel waarop dit record is ingevoegd.

Apparaatgegevens worden opgeslagen, ongeacht of het apparaat goed werkt of dat de gegevens buiten het verwachte bereik vallen. Dit is in feite een logboek van alles wat door de apparaten is vastgelegd. We kunnen een strategie verwachten voor het verwijderen van oude apparaatgegevensbestanden, maar dat valt buiten het bestek van dit artikel.

In tegenstelling tot apparaatgegevens, kunnen we verwachten dat berichten alleen worden gegenereerd als er iets onverwachts gebeurt, bijv. als een apparaatmeting buiten het normale bereik valt, als een sensor beweging heeft gedetecteerd, enz. In dergelijke gevallen genereert het apparaat de berichten. Al dergelijke berichten worden opgeslagen in de auto_message tafel. In elk record hebben we:

device_id – De ID van het apparaat dat dit bericht heeft gegenereerd.
message_text – De tekst die door het apparaat wordt gegenereerd. Dit kan een vooraf gedefinieerde tekst zijn, een waarde die buiten het verwachte bereik ligt of een combinatie van deze twee.
ts – Een tijdstempel van wanneer deze record is opgeslagen.
read – Een vlag die aangeeft of het bericht door de gebruiker is gelezen.

De overige drie tabellen worden gebruikt om de opdrachten van gebruikers op te slaan. Met opdrachten kunnen gebruikers de controle over hun bestuurbare apparaten overnemen en tweerichtingscommunicatie tot stand brengen met hun slimme huis.

Eerst definiëren we een lijst met alle mogelijke commandotypes. Dit kunnen waarden zijn zoals "aan/uit", "temperatuur verhogen/verlagen", enz. We kunnen ook voorwaardelijke opdrachten hebben, d.w.z. opdrachten die alleen worden uitgevoerd als aan een specifieke voorwaarde wordt voldaan. Een lijst van alle verschillende commandotypes wordt opgeslagen in het command_type woordenboek. Voor elk type slaan we een UNIEKE type_name op . We slaan ook een lijst op met alle parameters die voor dat type commando moeten worden gedefinieerd. Dit is in een gestructureerde tekstindeling met ingevoegde standaardwaarden. De gebruiker zal deze waarden instellen bij het invoegen van hun nieuwe commando's.

Een gebruiker kan ook alle recurring_commands vooraan. Misschien willen we elke dag om 7.00 uur warm water of willen we het verwarmings-/koelsysteem elke dag om 16.00 uur activeren. De set regels en alle benodigde attributen om terugkerende opdrachten te laten plaatsvinden, worden in deze tabel opgeslagen. We hebben:

user_account_id – De ID van de gebruiker die deze terugkerende opdracht heeft ingevoegd.
device_id – De ID van het apparaat dat relevant is voor deze terugkerende opdracht.
command_type_id – Een verwijzing naar het command_type woordenboek.
parameters – Alle parameters die moeten worden gedefinieerd voor dat opdrachttype, samen met hun gewenste waarden.
interval_definition – Het interval tussen twee herhalingen van deze opdracht. Net als bij opdrachtparameters zal dit een gestructureerd tekstveld zijn.
active_from en active_to – De interval waarin dit commando moet worden herhaald. De active_to attribuut kan NULL zijn als we willen dat die opdracht voor altijd wordt herhaald (of totdat we de active_to definiëren datum).
ts – Het tijdstempel waarop dit record is ingevoegd.

De laatste tabel in ons model bevat een lijst met enkele commando's. Deze opdrachten kunnen handmatig door de gebruiker worden ingevoegd of automatisch worden gegenereerd (d.w.z. als onderdeel van terugkerende opdrachten). Voor elke opdracht slaan we op:

recurring_command_id – De ID van de terugkerende opdracht die deze opdracht activeert, indien van toepassing.
user_account_id – De ID van de gebruiker die deze opdracht heeft ingevoegd.
device_id – De ID van het betreffende apparaat.
command_type_id – Verwijst naar het command_type woordenboek.
parameters – Alle parameters die relevant zijn voor deze opdracht.
executed – Een vlag die aangeeft of dit commando is uitgevoerd.
ts – Het tijdstempel waarop dit record is ingevoegd.

Wat vindt u van het Smart Home-gegevensmodel?

In dit artikel hebben we geprobeerd de belangrijkste aspecten van het beheren van een smart home te bespreken. Een daarvan is zeker tweerichtingscommunicatie tussen de gebruiker en het systeem. De meeste "echte" acties worden opgeslagen als tekstuele parameters en deze waarden moeten worden geparseerd bij het uitvoeren van specifieke acties. Dit werd gedaan zodat we voldoende flexibiliteit hadden om met veel verschillende apparaattypes te werken.

Heb je suggesties om toe te voegen aan ons smart home-model? Wat zou je veranderen of verwijderen? Vertel het ons in de reacties hieronder.