Das Smart-Home-Datenmodell

Smart Homes waren früher streng in der Zukunft; jetzt sind sie Realität. Die meisten von uns haben davon gehört, aber sie sind nicht so weit verbreitet, wie sie es in naher Zukunft sein werden. Die „intelligente“ Verwaltung Ihres Zuhauses wird definitiv viele Daten produzieren. Heute analysieren wir ein Datenmodell, mit dem wir Smart-Home-Daten speichern könnten.

Das Datenmodell

Wenn Sie an ein Smart Home denken, denken Sie wahrscheinlich daran, Ihr Zuhause aus der Ferne zu sperren und zu entsperren, Alarme, Lichter oder Kameras von Ihrem Telefon aus zu aktivieren, Thermometer zu haben, die Ihre Heizung und Kühlung automatisch steuern usw. Aber Smart Homes können noch viel mehr. Sie können eine Reihe von intelligenten Geräten und Controllern anschließen, um viele komplexe Funktionen zu erreichen. Sie können von überall aus Anweisungen an Geräte senden oder deren Status ablesen.

Werfen wir einen Blick auf ein Datenmodell, das es uns ermöglichen würde, solche Funktionalitäten zu implementieren. Zusätzlich zu diesem Datenmodell könnten wir eine Webanwendung und eine mobile Anwendung erstellen, die es registrierten Benutzern ermöglichen würden, ihre Konten zu verwalten, Anweisungen zu senden und den Status zu verfolgen.

Das Modell besteht aus drei Themenbereichen:

• Estates & devices
• Users & profiles
• Commands & data

Ich werde jeden dieser Themenbereiche in der Reihenfolge beschreiben, in der sie aufgeführt sind. Vor allem aber beschreibe ich das user_account Tabelle.

Die User_Account-Tabelle

Wir beginnen mit dem user_account Tabelle, weil sie in allen drei Fachgebieten verwendet wird. Es speichert eine Liste aller registrierten Benutzer unserer Anwendung.

Das user_account Die Tabelle enthält alle Standardattribute, die Sie erwarten würden, einschließlich:

• first_name und last_name – Vor- und Nachname des Benutzers.
• user_name – Ein EINZIGARTIGER Benutzername, der vom Benutzer gewählt wird.
• password – Ein Hashwert des Passworts des Benutzers.
• email – Die E-Mail-Adresse, die der Nutzer während des Registrierungsprozesses angegeben hat.
• confirmation_code – Der während des Registrierungsprozesses generierte Code.
• confirmation_time – Der Zeitstempel, zu dem der Benutzer sein Konto bestätigt und den Registrierungsprozess abgeschlossen hat.
• ts – Der Zeitstempel, wann dieser Datensatz in die Datenbank eingefügt wurde.

Abschnitt 1:Nachlässe und Geräte

Die ganze Motivation hinter der Erstellung dieser Datenbank besteht darin, zu überwachen, was mit unseren Immobilien (d. H. Häusern oder Grundstücken) passiert. Dies können Privatgrundstücke wie Wohnungen oder Häuser oder Geschäftsobjekte wie Büros, Lagerhäuser usw. sein. Wenn wir unser System wirklich an seine Grenzen bringen wollen, könnten wir es auch für Fahrzeuge verwenden.

Die zentrale Tabelle in diesem Themenbereich ist die real_estate Tisch. Hier speichern wir alle verschiedenen Grundstücke oder Immobilien, die mit unserer Smart-Home-App verbunden sind. Für jeden Nachlass speichern wir:

• real_estate_name – Ein vom Benutzer gewählter Name, der auf eine bestimmte Eigenschaft verweist.
• user_account_id – Die ID des Benutzers, auf den sich dieser Nachlass bezieht. Zusammen mit dem Attribut real_estate_name bildet dies den EINZIGARTIGEN (alternativen) Schlüssel dieser Tabelle.
• real_estate_type – Bezeichnet die Art der Immobilie, um die es sich bei dieser Immobilie handelt.
• address – Die tatsächliche Adresse dieses Anwesens. Dies ist nullable, da wir dieses System möglicherweise für andere Arten von Eigentum (z. B. Fahrzeuge) verwenden.
• details – Alle weiteren Angaben im Textformat.

Wir haben bereits Immobilientypen erwähnt. Eine vollständige Liste möglicher Typen ist im real_estate_type Wörterbuch. Es enthält nur einen UNIQUE-Wert, den type_name . Wir könnten hier Werte wie „Wohnung“, „Haus“ oder „Garage“ erwarten.

Eine Immobilie kann in mehrere Bereiche aufgeteilt werden. Das können Räume einer Wohnung oder eines Hauses sein; vielleicht wollen wir ein paar Räume zusammenfassen oder wir wollen alles rund um den Hof oder Garten in einer Gruppe zusammenfassen usw. Oder vielleicht haben wir ein Gewerbegebiet oder einen Komplex mit mehreren Büros; Wenn unser Eigentum wirklich groß ist, kann es sehr nützlich sein, bestimmte Bereiche zu haben. Um dies zu erreichen, verwenden wir den area Tisch. Es enthält das EINZIGARTIGE Paar der real_estate_id und der area_name vom Benutzer ausgewählt.

Die letzten beiden Tabellen in diesem Themenbereich beziehen sich auf Geräte.

Im device_type Tabelle speichern wir eine vollständige Liste aller unterschiedlichen Gerätetypen. Für jeden Typ verwenden wir einen EINZIGARTIGEN type_name und fügen Sie eine zusätzliche description ein wenn benötigt. Gerätetypen können verschiedene Sensoren (Temperatur, Gas), Tür- oder Fensterschlösser, Beleuchtung, Klima- und Heizungssysteme usw. sein.

Jetzt sind wir bereit für den lustigen Teil. Wir verwenden das device Tabelle zum Speichern einer Liste aller Geräte, die in verschiedenen Smart Homes enthalten sind. Diese Geräte werden vom Benutzer entweder manuell oder automatisch hinzugefügt, wenn das Gerät über diese Option verfügt. Für jedes Gerät müssen wir Folgendes speichern:

• real_estate_id – Die ID der Immobilie, in der dieses Gerät installiert ist.
• area_id – Referenziert den area wo dieses Gerät installiert ist. Dies ist ein optionaler Wert, weil ein Nachlass könnte kann in Bereiche eingeteilt werden, darf aber auch nicht eingeteilt werden.
• device_type_id – Die ID des device_type dieses Gerät gehört.
• device_parameters – Wir verwenden dieses Attribut, um alle möglichen Geräteparameter (z. B. Intervalle zum Speichern von Daten) in einem strukturierten Textformat zu speichern. Diese Parameter können vom Benutzer eingestellt werden oder Teil der regulären Funktion des Geräts sein (z. B. verschiedene Maßnahmen).
• current_status – Der aktuelle Status der Geräteparameter.
• time_activated und time_deactivated – Geben Sie das Intervall an, in dem dieses Gerät aktiv war. Wenn time_deactivated nicht gesetzt ist, dann ist das Gerät aktiv und der is_active Attribut ist ebenfalls auf True gesetzt.

Abschnitt 2:Benutzer und Profile

Wir haben bereits den user_account Tisch. In unserer Anwendung sollten Benutzer verschiedene Profile erstellen und diese mit anderen Benutzern teilen können, wenn sie möchten.

Profile sind im Grunde Teilmengen von Geräten, die in jedem Grundstück des Benutzers installiert sind. Jeder Benutzer kann ein oder mehrere Profile haben. Die Idee ist, dass ein Benutzer seine Smart-Home-Geräte auf geeignete Weise gruppieren kann. Während der Benutzer ein Profil mit all seinen Geräten haben könnte, könnte er auch ein Profil haben, das nur die Haustürkameras für alle seine Eigenschaften zeigt. Oder vielleicht ein Profil nur für die Thermometer, die in allen Räumen ihrer Wohnung installiert sind.

Alle von Benutzern erstellten Profile werden im profile Tisch. Für jeden Datensatz haben wir:

• profile_name – Der vom Benutzer gewählte Name des Profils.
• user_account_id – Verweist auf den Benutzer, der dieses Profil erstellt hat. Dieses Attribut und der profile_name Attribut bilden den UNIQUE-Schlüssel der Tabelle.
• allow_others – Ein Flag, das angibt, ob dieses Profil mit anderen Benutzern geteilt wird.
• is_public – Ein Flag, das angibt, ob dieses Profil öffentlich sichtbar ist. Obwohl wir davon ausgehen können, dass dies die meiste Zeit auf "False" gesetzt ist, kann es Fälle geben, in denen wir ein Profil mit allen teilen möchten.
• is_active – Ein Flag, das angibt, ob dieses Profil aktiv ist oder nicht.
• ts – Ein Zeitstempel, wann dieser Datensatz eingefügt wurde.

Für jedes Profil definieren wir eine Liste aller darin enthaltenen Geräte. Diese Liste wird in der profile_device_list Tabelle und enthält eine Liste von UNIQUE profile_id – device_id Paare. Dieses Fremdschlüsselpaar bildet den Primärschlüssel unserer Tabelle.

Die letzte Tabelle in diesem Thema ermöglicht es Benutzern, ihre Profile mit anderen registrierten Benutzern zu teilen. Dies kann sehr nützlich sein, z. wenn eine Person alles verwaltet und andere registrierte Benutzer (z. B. Familienmitglieder) vom Eigentümer erstellte Profile einsehen möchten. Im shared_with Tabelle speichern wir eine Liste aller EINZIGARTIGEN Paare von profile_id – user_account_id . Auch dieses Fremdschlüsselpaar ist der Primärschlüssel der Tabelle. Bitte beachten Sie, dass das Teilen nur funktioniert, wenn profile.allow_others -Attribut auf True gesetzt ist.

Abschnitt 3:Befehle und Daten

Wir verwenden Tabellen aus diesem letzten Themenbereich, um die Kommunikation zwischen Benutzern und Geräten zu speichern. Dies wird eine Zwei-Wege-Kommunikation sein. Die Geräte generieren die Daten während ihres Betriebs und unsere Datenbank speichert sie sowie alle vom System (oder den Geräten) generierten Nachrichten. Benutzer möchten diese Nachrichten und die von ihren Geräten gesendeten Daten sehen. Basierend auf diesen Daten könnten Nutzer Programme für ihr Smart Home erstellen. Diese Programme sind manuell oder automatisch generierte Befehle oder sogar eine Reihe von Befehlen, die genau das tun, was jeder Benutzer will.

Wir beginnen mit den Daten, die uns die Geräte geben. In den device_data Tabelle speichern wir eine Beschreibung der vom Gerät generierten Daten und den Ort/die Orte der Daten. Auch hier werden Daten automatisch von Geräten generiert. Dies können eine Reihe von Messungen, Status (Textdaten) oder audiovisuelle Daten sein. Für jeden Datensatz in dieser Tabelle speichern wir:

• device_id – Die ID des Geräts, das diese Daten generiert hat.
• data_description – Die Beschreibung der gespeicherten Daten, z. was gespeichert wird, wann die Daten in unserem System gespeichert wurden und in welchem ​​Format.
• data_location – Der vollständige Pfad zum Speicherort dieser Daten.
• ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.

Gerätedaten werden unabhängig davon gespeichert, ob das Gerät ordnungsgemäß funktioniert oder ob die Daten außerhalb des erwarteten Bereichs liegen. Dies ist im Grunde ein Protokoll von allem, was von den Geräten aufgezeichnet wurde. Wir können davon ausgehen, dass wir eine Strategie zum Löschen alter Gerätedatendateien haben, aber das geht über den Rahmen dieses Artikels hinaus.

Im Gegensatz zu Gerätedaten können wir davon ausgehen, dass Nachrichten nur dann generiert werden, wenn etwas Unerwartetes passiert – z. B. wenn eine Gerätemessung außerhalb des normalen Bereichs liegt, wenn ein Sensor eine Bewegung erkannt hat usw. In solchen Fällen generiert das Gerät die Meldungen. Alle diese Nachrichten werden in auto_message Tisch. In jedem Datensatz haben wir:

• device_id – Die ID des Geräts, das diese Nachricht generiert hat.
• message_text – Der vom Gerät generierte Text. Dies kann ein vordefinierter Text, ein Wert außerhalb des erwarteten Bereichs oder eine Kombination aus beidem sein.
• ts – Ein Zeitstempel, wann dieser Datensatz gespeichert wurde.
• read – Ein Flag, das angibt, ob die Nachricht vom Benutzer gelesen wurde.

Die verbleibenden drei Tabellen werden verwendet, um Benutzerbefehle zu speichern. Befehle ermöglichen es Benutzern, die Kontrolle über ihre steuerbaren Geräte zu übernehmen und eine bidirektionale Kommunikation mit ihrem Smart Home herzustellen.

Zuerst definieren wir eine Liste aller möglichen Befehlstypen. Das können Werte sein wie „ein-/ausschalten“, „Temperatur erhöhen/verringern“ usw. Wir könnten auch bedingte Befehle haben, d. h. Befehle, die nur erfüllt werden, wenn eine bestimmte Bedingung wahr ist. Eine Liste aller unterschiedlichen Befehlstypen ist in command_type Wörterbuch. Für jeden Typ speichern wir einen EINZIGARTIGEN type_name . Wir speichern auch eine Liste aller Parameter, die für diesen Befehlstyp definiert werden sollten. Dies wird in einem strukturierten Textformat mit eingefügten Standardwerten sein. Der Benutzer legt diese Werte fest, wenn er seine neuen Befehle einfügt.

Ein Benutzer könnte auch alle recurring_commands vorne. Vielleicht möchten wir jeden Tag um 7 Uhr morgens heißes Wasser oder das Heiz-/Kühlsystem jeden Tag um 16 Uhr aktivieren. In dieser Tabelle sind der Regelsatz und alle erforderlichen Attribute gespeichert, um wiederkehrende Befehle auszuführen. Wir haben:

• user_account_id – Die ID des Benutzers, der diesen wiederkehrenden Befehl eingefügt hat.
• device_id – Die ID des Geräts, das für diesen wiederkehrenden Befehl relevant ist.
• command_type_id – Ein Verweis auf den command_type Wörterbuch.
• parameters – Alle Parameter, die für diesen Befehlstyp definiert werden sollten, zusammen mit ihren gewünschten Werten.
• interval_definition – Das Intervall zwischen zwei Wiederholungen dieses Befehls. Wie bei Befehlsparametern ist dies ein strukturiertes Textfeld.
• active_from und active_to – Das Intervall, in dem dieser Befehl wiederholt werden soll. Der active_to Das Attribut kann NULL sein, wenn wir möchten, dass dieser Befehl für immer wiederholt wird (oder bis wir active_to definieren Datum).
• ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.

Die letzte Tabelle in unserem Modell enthält eine Liste einzelner Befehle. Diese Befehle könnten vom Benutzer manuell eingefügt oder automatisch generiert werden (d. h. als Teil wiederkehrender Befehle). Für jeden Befehl speichern wir:

• recurring_command_id – Die ID des wiederkehrenden Befehls, der diesen Befehl auslöst, falls vorhanden.
• user_account_id – Die ID des Benutzers, der diesen Befehl eingefügt hat.
• device_id – Die ID des betreffenden Geräts.
• command_type_id – Referenziert den command_type Wörterbuch.
• parameters – Alle für diesen Befehl relevanten Parameter.
• executed – Ein Flag, das angibt, ob dieser Befehl ausgeführt wurde.
• ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.

Was halten Sie vom Smart-Home-Datenmodell?

In diesem Artikel haben wir versucht, die wichtigsten Aspekte der Verwaltung eines Smart Homes abzudecken. Eine davon ist definitiv die bidirektionale Kommunikation zwischen dem Benutzer und dem System. Die meisten „echten“ Aktionen werden als Textparameter gespeichert, und diese Werte sollten analysiert werden, wenn bestimmte Aktionen ausgeführt werden. Dies wurde getan, damit wir genügend Flexibilität haben, um mit vielen verschiedenen Gerätetypen zu arbeiten.

Haben Sie Vorschläge zur Ergänzung unseres Smart-Home-Modells? Was würden Sie ändern oder entfernen? Bitte teilen Sie uns dies in den Kommentaren unten mit.