Le modèle de données de la maison intelligente

Les maisons intelligentes étaient strictement dans le futur ; maintenant ils sont une réalité. La plupart d'entre nous en ont entendu parler, mais ils ne sont pas aussi répandus qu'ils le seront dans un proche avenir. Gérer votre maison de manière « intelligente » produira certainement beaucoup de données. Aujourd'hui, nous allons analyser un modèle de données que nous pourrions utiliser pour stocker les données de la maison intelligente.

Le modèle de données

Lorsque vous pensez à une maison intelligente, vous pensez probablement à verrouiller et déverrouiller votre maison à distance, à activer des alarmes, des lumières ou des caméras depuis votre téléphone, à avoir des thermomètres qui gèrent automatiquement votre chauffage et votre climatisation, etc. Mais les maisons intelligentes peuvent faire bien plus. Vous pouvez connecter un certain nombre d'appareils intelligents et de contrôleurs pour obtenir de nombreuses fonctionnalités complexes. Vous pouvez envoyer des instructions aux appareils ou lire leurs statuts où que vous soyez.

Examinons un modèle de données qui nous permettrait d'implémenter de telles fonctionnalités. En plus de ce modèle de données, nous pourrions créer une application Web et une application mobile qui permettraient aux utilisateurs enregistrés d'administrer leurs comptes, d'envoyer des instructions et de suivre les statuts.

Le modèle se compose de trois domaines :

Estates & devices
Users & profiles
Commands & data

Je décrirai chacun de ces domaines dans l'ordre dans lequel ils sont énumérés. Avant toute chose, cependant, je vais décrire le user_account tableau.

Le tableau User_Account

Nous commençons avec le user_account tableau car il est utilisé dans les trois domaines. Il stocke une liste de tous les utilisateurs enregistrés de notre application.

Le user_account table contient tous les attributs standard auxquels vous vous attendez, y compris :

first_name et last_name – Le prénom et le nom de l'utilisateur.
user_name – Un nom d'utilisateur UNIQUE choisi par l'utilisateur.
password – Une valeur de hachage du mot de passe de l'utilisateur.
email – L'adresse e-mail fournie par l'utilisateur lors du processus d'inscription.
confirmation_code – Le code généré lors du processus d'inscription.
confirmation_time – L'horodatage auquel l'utilisateur a confirmé son compte et terminé le processus d'inscription.
ts – L'horodatage auquel cet enregistrement a été inséré dans la base de données.

Section 1 :Domaines et appareils

Toute la motivation derrière la création de cette base de données est de surveiller ce qui se passe avec nos biens (c'est-à-dire les maisons ou les propriétés). Il peut s'agir de propriétés privées, comme des appartements ou des maisons, ou de propriétés commerciales, comme des bureaux, des entrepôts, etc. Si nous voulons vraiment pousser notre système à ses limites, nous pouvons également l'utiliser pour les véhicules.

La table centrale dans ce domaine est le real_estate table. C'est là que nous stockerons tous les différents domaines ou propriétés connectés à notre application de maison intelligente. Pour chaque domaine, nous stockerons :

real_estate_name – Un nom, choisi par l'utilisateur, qui fait référence à une propriété spécifique.
user_account_id – L'identifiant de l'utilisateur auquel ce domaine est lié. Avec l'attribut real_estate_name, cela forme la clé UNIQUE (alternative) de cette table.
real_estate_type – Indique le type de bien immobilier auquel appartient cette propriété.
address – L'adresse réelle de cette succession. Ceci est nullable, car nous pourrions utiliser ce système pour d'autres types de biens (par exemple, des véhicules).
details – Tous les détails supplémentaires au format textuel.

Nous avons déjà mentionné les types de biens immobiliers. Une liste complète des types possibles est stockée dans le real_estate_type dictionnaire. Il ne contient qu'une seule valeur UNIQUE, le type_name . Nous pourrions nous attendre à des valeurs telles que "appartement", "maison" ou "garage" ici.

Un bien immobilier peut être divisé en plusieurs zones. Il peut s'agir de pièces d'un appartement ou d'une maison ; peut-être voulons-nous regrouper quelques pièces ou nous voulons tout ce qui concerne la cour ou le jardin dans un seul groupe, etc. Ou peut-être avons-nous une zone industrielle ou un complexe avec plusieurs bureaux ; si notre propriété est vraiment grande, avoir des zones spécifiques peut être très utile. Pour ce faire, nous utiliserons la area table. Il contient la paire UNIQUE du real_estate_id et le area_name choisi par l'utilisateur.

Les deux derniers tableaux de ce domaine concernent les appareils.

Dans le device_type table, nous stockerons une liste complète de tous les types d'appareils distincts. Pour chaque type, nous utiliserons un type_name UNIQUE et insérez une description supplémentaire si besoin. Les types d'appareils peuvent être différents capteurs (température, gaz), serrures de porte ou de fenêtre, lumières, systèmes de climatisation et de chauffage, etc.

Nous sommes maintenant prêts pour la partie amusante. Nous utiliserons le device table pour stocker une liste de tous les appareils inclus dans diverses maisons intelligentes. Ces appareils sont ajoutés par l'utilisateur, manuellement ou automatiquement si l'appareil dispose de cette option. Pour chaque appareil, nous devrons stocker :

real_estate_id – L'identifiant du bien immobilier où cet appareil est installé.
area_id – Fait référence à la area où cet appareil est installé. Il s'agit d'une valeur facultative car une succession pourrait être divisé en zones, mais il ne peut pas être divisé non plus.
device_type_id – L'ID du device_type cet appareil appartient.
device_parameters – Nous utiliserons cet attribut pour stocker tous les paramètres possibles de l'appareil (par exemple, les intervalles de stockage des données) dans un format textuel structuré. Ces paramètres peuvent être définis par l'utilisateur ou faire partie du fonctionnement normal de l'appareil (par exemple, différentes mesures).
current_status – L'état actuel des paramètres de l'appareil.
time_activated et time_deactivated – Indiquez l'intervalle pendant lequel cet appareil était actif. Si time_deactivated n'est pas défini, alors l'appareil est actif et le is_active est également défini sur True.

Section 2 :Utilisateurs et profils

Nous avons déjà mentionné le user_account table. Dans notre application, les utilisateurs doivent pouvoir créer différents profils et les partager avec d'autres utilisateurs s'ils le souhaitent.

Les profils sont essentiellement des sous-ensembles d'appareils installés dans chaque bien immobilier appartenant à l'utilisateur. Chaque utilisateur peut avoir un ou plusieurs profils. L'idée est de permettre à un utilisateur de regrouper ses appareils domestiques intelligents de manière appropriée. Bien que l'utilisateur puisse avoir un profil avec tous ses appareils, il peut également avoir un profil affichant uniquement les caméras de la porte d'entrée pour toutes ses propriétés. Ou peut-être un seul profil pour les thermomètres installés dans toutes les pièces de leur appartement.

Tous les profils créés par les utilisateurs sont stockés dans le profile table. Pour chaque enregistrement, nous aurons :

profile_name – Le nom du profil, choisi par l'utilisateur.
user_account_id – Fait référence à l'utilisateur qui a créé ce profil. Cet attribut et le profile_name l'attribut forme la clé UNIQUE de la table.
allow_others – Un indicateur indiquant si ce profil est partagé avec d'autres utilisateurs.
is_public – Un indicateur indiquant si ce profil est visible publiquement. Bien que nous puissions nous attendre à ce que ce paramètre soit défini sur False la plupart du temps, il peut arriver que nous souhaitions partager un profil avec tout le monde.
is_active – Un indicateur indiquant si ce profil est actif ou non.
ts – Un horodatage du moment où cet enregistrement a été inséré.

Pour chaque profil, nous définirons une liste de tous les appareils qui y sont inclus. Cette liste est stockée dans le profile_device_list table et contient une liste de profile_id UNIQUE – device_id paires. Cette paire de clés étrangères constitue la clé primaire de notre table.

Le dernier tableau de ce sujet permet aux utilisateurs de partager leurs profils avec d'autres utilisateurs enregistrés. Cela pourrait être très utile, par ex. si une personne gère tout et que d'autres utilisateurs enregistrés (par exemple, les membres de la famille) souhaitent afficher les profils créés par le propriétaire. Dans le shared_with table, nous stockerons une liste de toutes les paires UNIQUES de profile_id – user_account_id . Encore une fois, cette paire de clés étrangères est la clé primaire de la table. Veuillez noter que le partage ne fonctionnera que si le profile.allow_others l'attribut est défini sur True.

Section 3 :Commandes et données

Nous utiliserons des tableaux de ce dernier domaine pour stocker les communications entre les utilisateurs et les appareils. Ce sera une communication bidirectionnelle. Les appareils généreront les données pendant leurs opérations et notre base de données les stockera ainsi que tous les messages générés par le système (ou les appareils). Les utilisateurs voudront voir ces messages et les données envoyées par leurs appareils. Sur la base de ces données, les utilisateurs pourraient créer des programmes pour leur maison intelligente. Ces programmes sont des commandes générées manuellement ou automatiquement ou même une série de commandes qui feront exactement ce que chaque utilisateur veut.

Nous allons commencer par les données que les appareils nous donnent. Dans le device_data table, nous stockerons une description des données générées par l'appareil et l'emplacement (s) des données. Encore une fois, les données sont automatiquement générées par les appareils. Il peut s'agir d'une série de mesures, d'états (données textuelles) ou de données audiovisuelles. Pour chaque enregistrement de cette table, nous stockerons :

device_id – L'identifiant de l'appareil qui a généré ces données.
data_description – La description des données stockées, par ex. ce qui est stocké, quand les données ont été stockées dans notre système et dans quel format.
data_location – Le chemin d'accès complet à l'emplacement où ces données sont stockées.
ts – L'horodatage auquel cet enregistrement a été inséré.

Les données de l'appareil seront stockées indépendamment du fait que l'appareil fonctionne correctement ou si les données sont hors de la plage attendue. Il s'agit essentiellement d'un journal de tout ce qui a été enregistré par les appareils. Nous pouvons nous attendre à avoir une stratégie pour supprimer les anciens fichiers de données de l'appareil, mais cela sort du cadre de cet article.

Contrairement aux données de l'appareil, nous pouvons nous attendre à ce que les messages ne soient générés que lorsque quelque chose d'inattendu se produit - par ex. si une mesure de l'appareil est en dehors de la plage normale, si un capteur a détecté un mouvement, etc. Dans de tels cas, l'appareil génère les messages. Tous ces messages sont stockés dans le auto_message table. Dans chaque enregistrement, nous aurons :

device_id – L'ID de l'appareil qui a généré ce message.
message_text – Le texte généré par l'appareil. Il peut s'agir d'un texte prédéfini, d'une valeur hors de la plage attendue ou d'une combinaison des deux.
ts – Un horodatage du moment où cet enregistrement a été stocké.
read – Un indicateur indiquant si le message a été lu par l'utilisateur.

Les trois tables restantes sont utilisées pour stocker les commandes des utilisateurs. Les commandes permettent aux utilisateurs de prendre le contrôle de leurs appareils contrôlables et d'établir une communication bidirectionnelle avec leur maison intelligente.

Tout d'abord, nous allons définir une liste de tous les types de commandes possibles. Il peut s'agir de valeurs telles que "allumer/éteindre", "augmenter/diminuer la température", etc. Nous pourrions également avoir des commandes conditionnelles, c'est-à-dire commandes qui ne sont remplies que si une condition spécifique est vraie. Une liste de tous les types de commandes distincts est stockée dans le command_type dictionnaire. Pour chaque type, nous stockerons un type_name UNIQUE . Nous stockerons également une liste de tous les paramètres qui doivent être définis pour ce type de commande. Ce sera dans un format de texte structuré avec des valeurs par défaut insérées. L'utilisateur définira ces valeurs lors de l'insertion de ses nouvelles commandes.

Un utilisateur peut également définir toutes les recurring_commands à l'avant. Peut-être voulons-nous de l'eau chaude chaque jour à 7h00 ou pour activer le système de chauffage/refroidissement chaque jour à 16h00. L'ensemble de règles et tous les attributs nécessaires pour que les commandes récurrentes se produisent sont stockés dans cette table. Nous aurons :

user_account_id – L'ID de l'utilisateur qui a inséré cette commande récurrente.
device_id – L'ID de l'appareil correspondant à cette commande récurrente.
command_type_id – Une référence au command_type dictionnaire.
parameters – Tous les paramètres qui doivent être définis pour ce type de commande, ainsi que leurs valeurs souhaitées.
interval_definition – L'intervalle entre deux récurrences de cette commande. Comme pour les paramètres de commande, ce sera un champ de texte structuré.
active_from et active_to – L'intervalle pendant lequel cette commande doit être répétée. Le active_to L'attribut peut être NULL si nous voulons que cette commande se répète indéfiniment (ou jusqu'à ce que nous définissions le active_to jour).
ts – L'horodatage auquel cet enregistrement a été inséré.

La dernière table de notre modèle contient une liste de commandes uniques. Ces commandes peuvent être insérées manuellement par l'utilisateur ou générées automatiquement (c'est-à-dire dans le cadre de commandes récurrentes). Pour chaque commande, nous stockerons :

recurring_command_id – L'ID de la commande récurrente déclenchant cette commande, le cas échéant.
user_account_id – L'ID de l'utilisateur qui a inséré cette commande.
device_id – L'identifiant de l'appareil concerné.
command_type_id – Fait référence au command_type dictionnaire.
parameters – Tous les paramètres relatifs à cette commande.
executed – Un indicateur indiquant si cette commande a été exécutée.
ts – L'horodatage auquel cet enregistrement a été inséré.

Que pensez-vous du modèle de données de la maison intelligente ?

Dans cet article, nous avons essayé de couvrir les aspects les plus importants de la gestion d'une maison intelligente. L'un d'eux est certainement la communication bidirectionnelle entre l'utilisateur et le système. La plupart des actions "réelles" sont stockées sous forme de paramètres textuels, et ces valeurs doivent être analysées lors de l'exécution d'actions spécifiques. Cela a été fait afin que nous puissions avoir suffisamment de flexibilité pour travailler avec de nombreux types d'appareils différents.

Avez-vous des suggestions à ajouter à notre modèle de maison intelligente ? Que changeriez-vous ou supprimeriez-vous ? Veuillez nous le dire dans les commentaires ci-dessous.