El modelo de datos del hogar inteligente

Las casas inteligentes solían estar estrictamente en el futuro; ahora son una realidad. La mayoría de nosotros hemos oído hablar de ellos, pero no están tan extendidos como lo estarán en un futuro próximo. Administrar su hogar de manera "inteligente" definitivamente producirá una gran cantidad de datos. Hoy, analizaremos un modelo de datos que podríamos usar para almacenar datos de hogares inteligentes.

El modelo de datos

Cuando piensa en una casa inteligente, probablemente piense en abrir y cerrar su casa de forma remota, activar alarmas, luces o cámaras desde su teléfono, tener termómetros que controlen automáticamente su calefacción y aire acondicionado, etc. Pero las casas inteligentes pueden hacer mucho más. Puede conectar varios dispositivos y controladores inteligentes para lograr muchas funcionalidades complejas. Puedes enviar instrucciones a los dispositivos o leer sus estados desde donde estés.

Echemos un vistazo a un modelo de datos que nos permitiría implementar tales funcionalidades. Además de ese modelo de datos, podríamos crear una aplicación web y una aplicación móvil que permitirían a los usuarios registrados administrar sus cuentas, enviar instrucciones y realizar un seguimiento de los estados.

El modelo consta de tres áreas temáticas:

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

Describiré cada una de estas áreas temáticas en el orden en que aparecen. Sin embargo, antes que nada, describiré la user_account mesa.

La tabla User_Account

Empezamos con la user_account porque se usa en las tres áreas temáticas. Almacena una lista de todos los usuarios registrados de nuestra aplicación.

La user_account la tabla contiene todos los atributos estándar que esperaría, incluidos:

• first_name y last_name – El nombre y apellido del usuario.
• user_name – Un nombre de usuario ÚNICO elegido por el usuario.
• password – Un valor hash de la contraseña del usuario.
• email – La dirección de correo electrónico proporcionada por el usuario durante el proceso de registro.
• confirmation_code – El código generado durante el proceso de registro.
• confirmation_time – La marca de tiempo cuando el usuario confirmó su cuenta y completó el proceso de registro.
• ts – La marca de tiempo cuando se insertó este registro en la base de datos.

Sección 1:Patrimonios y dispositivos

Toda la motivación detrás de la creación de esta base de datos es monitorear lo que está sucediendo con nuestros estados (es decir, casas o propiedades). Estos pueden ser propiedades privadas, como apartamentos o casas, o pueden ser propiedades comerciales, como oficinas, almacenes, etc. Si realmente queremos llevar nuestro sistema al límite, también podemos usarlo para vehículos.

La tabla central en esta área temática es el real_estate mesa. Aquí es donde almacenaremos todas las diferentes fincas o propiedades conectadas a nuestra aplicación de hogar inteligente. Para cada patrimonio, almacenaremos:

• real_estate_name – Un nombre, elegido por el usuario, que hace referencia a una propiedad específica.
• user_account_id – El ID del usuario con el que está relacionado este patrimonio. Junto con el atributo real_estate_name, esto forma la clave ÚNICA (alternativa) de esta tabla.
• real_estate_type – Indica el tipo de bien inmueble que es esta propiedad.
• address – La dirección real de esa finca. Esto es anulable porque podríamos usar este sistema para otros tipos de propiedad (es decir, vehículos).
• details – Todos los detalles adicionales en formato de texto.

Ya hemos mencionado los tipos de bienes raíces. Una lista completa de posibles tipos se almacena en el real_estate_type diccionario. Contiene solo un valor ÚNICO, el type_name . Podríamos esperar valores como "apartamento", "casa" o "garaje" aquí.

Una pieza de bienes raíces se puede dividir en varias áreas. Esto podría ser habitaciones de un apartamento o una casa; tal vez queramos agrupar algunas estancias o queremos todo lo relacionado con el patio o jardín en un solo grupo, etc. O tal vez tenemos un polígono industrial o complejo con varias oficinas; si nuestra propiedad es realmente grande, tener áreas específicas puede ser muy útil. Para lograrlo, usaremos el area mesa. Contiene el par ÚNICO de real_estate_id y el area_name elegido por el usuario.

Las dos últimas tablas de esta área temática están relacionadas con los dispositivos.

En el device_type tabla, almacenaremos una lista completa de todos los tipos de dispositivos distintos. Para cada tipo, usaremos un type_name ÚNICO e inserte una description adicional si es necesario. Los tipos de dispositivos pueden ser diferentes sensores (temperatura, gas), cerraduras de puertas o ventanas, luces, sistemas de aire acondicionado y calefacción, etc.

Ahora estamos listos para la parte divertida. Usaremos el device tabla para almacenar una lista de todos los dispositivos incluidos en varios hogares inteligentes. Estos dispositivos son agregados por el usuario, ya sea de forma manual o automática si el dispositivo tiene esa opción. Para cada dispositivo, necesitaremos almacenar:

• real_estate_id – El DNI del inmueble donde está instalado este dispositivo.
• area_id – Hace referencia al area donde está instalado este dispositivo. Este es un valor opcional porque un patrimonio podría dividirse en áreas, pero tampoco puede dividirse.
• device_type_id – El ID del device_type pertenece este dispositivo.
• device_parameters – Usaremos este atributo para almacenar todos los parámetros posibles del dispositivo (por ejemplo, intervalos para almacenar datos) en un formato de texto estructurado. Estos parámetros pueden ser configurados por el usuario o como parte de la función regular del dispositivo (por ejemplo, diferentes medidas).
• current_status – El estado actual de los parámetros del dispositivo.
• time_activated y time_deactivated – Indique el intervalo cuando este dispositivo estuvo activo. Si time_deactivated no está configurado, entonces el dispositivo está activo y is_active el atributo también se establece en True.

Sección 2:Usuarios y perfiles

Ya hemos mencionado la user_account mesa. En nuestra aplicación, los usuarios deberían poder crear diferentes perfiles y compartirlos con otros usuarios si así lo desean.

Los perfiles son básicamente subconjuntos de dispositivos instalados en cada propiedad inmobiliaria del usuario. Cada usuario puede tener uno o más perfiles. La idea es permitir que un usuario agrupe sus dispositivos domésticos inteligentes de una manera adecuada. Si bien el usuario puede tener un perfil con todos sus dispositivos, también puede tener un perfil que muestre solo las cámaras de la puerta de entrada para todas sus propiedades. O tal vez un perfil solo para los termómetros instalados en todas las habitaciones de su apartamento.

Todos los perfiles creados por los usuarios se almacenan en el profile mesa. Para cada registro, tendremos:

• profile_name – El nombre del perfil, elegido por el usuario.
• user_account_id – Hace referencia al usuario que creó este perfil. Este atributo y el profile_name atributo forma la clave ÚNICA de la tabla.
• allow_others – Una bandera que indica si este perfil se comparte con otros usuarios.
• is_public – Una bandera que indica si este perfil es visible públicamente. Aunque podemos esperar que esto se establezca en Falso la mayor parte del tiempo, podría haber casos en los que queramos compartir un perfil con todos.
• is_active – Una bandera que indica si este perfil está activo o no.
• ts – Una marca de tiempo de cuándo se insertó este registro.

Para cada perfil, definiremos una lista de todos los dispositivos incluidos en él. Esta lista se almacena en profile_device_list y contiene una lista de profile_id ÚNICOS – device_id pares Este par de claves foráneas forma la clave principal de nuestra tabla.

La última tabla de este tema permite a los usuarios compartir sus perfiles con otros usuarios registrados. Esto podría ser muy útil, p. si una persona administra todo y otros usuarios registrados (por ejemplo, miembros de la familia) desean ver los perfiles creados por el propietario. En el shared_with tabla, almacenaremos una lista de todos los pares ÚNICOS de profile_id – user_account_id . Una vez más, este par de claves externas es la clave principal de la tabla. Tenga en cuenta que compartir solo funcionará si profile.allow_others el atributo se establece en Verdadero.

Sección 3:Comandos y datos

Usaremos tablas de esta última área temática para almacenar comunicaciones entre usuarios y dispositivos. Esta será una comunicación bidireccional. Los dispositivos generarán los datos durante sus operaciones y nuestra base de datos los almacenará, así como cualquier mensaje generado por el sistema (o los dispositivos). Los usuarios querrán ver estos mensajes y los datos enviados por sus dispositivos. Con base en estos datos, los usuarios podrían crear programas para su hogar inteligente. Estos programas son comandos generados manual o automáticamente o incluso una serie de comandos que harán exactamente lo que cada usuario quiere.

Comenzaremos con los datos que nos dan los dispositivos. En el device_data tabla, almacenaremos una descripción de los datos generados por el dispositivo y la(s) ubicación(es) de los datos. Nuevamente, los datos son generados automáticamente por los dispositivos. Puede ser una serie de medidas, estados (datos textuales) o datos audiovisuales. Para cada registro de esta tabla, almacenaremos:

• device_id – El ID del dispositivo que generó estos datos.
• data_description – La descripción de los datos almacenados, p. qué se almacena, cuándo se almacenaron los datos en nuestro sistema y en qué formato.
• data_location – La ruta completa a la ubicación donde se almacenan estos datos.
• ts – La marca de tiempo cuando se insertó este registro.

Los datos del dispositivo se almacenarán independientemente de si el dispositivo funciona correctamente o si los datos están fuera del rango esperado. Esto es básicamente un registro de todo lo que fue registrado por los dispositivos. Podemos esperar tener una estrategia para eliminar archivos de datos de dispositivos antiguos, pero eso está fuera del alcance de este artículo.

A diferencia de los datos del dispositivo, podemos esperar que los mensajes solo se generen cuando suceda algo inesperado, p. si la medición de un dispositivo está fuera del rango normal, si un sensor detectó movimiento, etc. En tales casos, el dispositivo genera los mensajes. Todos estos mensajes se almacenan en el auto_message mesa. En cada registro, tendremos:

• device_id – El ID del dispositivo que generó este mensaje.
• message_text – El texto generado por el dispositivo. Esto podría ser un texto predefinido, un valor que está fuera del rango esperado o una combinación de estos dos.
• ts – Una marca de tiempo de cuándo se almacenó este registro.
• read – Una bandera que indica si el mensaje ha sido leído por el usuario.

Las tres tablas restantes se utilizan para almacenar los comandos de los usuarios. Los comandos permiten a los usuarios tomar el control de sus dispositivos controlables y establecer una comunicación bidireccional con su hogar inteligente.

Primero, definiremos una lista de todos los tipos de comandos posibles. Estos podrían ser valores como “encender/apagar”, “aumentar/disminuir la temperatura”, etc. También podríamos tener comandos condicionales, es decir, comandos que solo se cumplen si una condición específica es verdadera. Una lista de todos los tipos de comandos distintos se almacena en el command_type diccionario. Para cada tipo, almacenaremos un type_name ÚNICO . También almacenaremos una lista de todos los parámetros que deben definirse para ese tipo de comando. Esto estará en un formato de texto estructurado con valores predeterminados insertados. El usuario establecerá estos valores al insertar sus nuevos comandos.

Un usuario también podría definir todos los recurring_commands en la delantera. Tal vez queremos agua caliente todos los días a las 7 a.m. o activar el sistema de calefacción/refrigeración todos los días a las 4 p.m. El conjunto de reglas y todos los atributos necesarios para que se ejecuten los comandos recurrentes se almacenan en esta tabla. Tendremos:

• user_account_id – El ID del usuario que insertó este comando recurrente.
• device_id – El ID del dispositivo relevante para este comando recurrente.
• command_type_id – Una referencia al command_type diccionario.
• parameters – Todos los parámetros que deben definirse para ese tipo de comando, junto con sus valores deseados.
• interval_definition – El intervalo entre dos recurrencias de este comando. Al igual que con los parámetros de comando, este será un campo de texto estructurado.
• active_from y active_to – El intervalo durante el cual se debe repetir este comando. El active_to El atributo puede ser NULL si queremos que ese comando se repita para siempre (o hasta que definamos el active_to fecha).
• ts – La marca de tiempo cuando se insertó este registro.

La última tabla de nuestro modelo contiene una lista de comandos individuales. Estos comandos pueden ser insertados manualmente por el usuario o generados automáticamente (es decir, como parte de comandos recurrentes). Para cada comando, almacenaremos:

• recurring_command_id – El ID del comando recurrente que activa este comando, si lo hay.
• user_account_id – El ID del usuario que insertó este comando.
• device_id – El ID del dispositivo relevante.
• command_type_id – Hace referencia al command_type diccionario.
• parameters – Todos los parámetros relevantes para este comando.
• executed – Una bandera que indica si este comando se ha ejecutado.
• ts – La marca de tiempo cuando se insertó este registro.

¿Qué opinas del modelo de datos de hogar inteligente?

En este artículo, hemos tratado de cubrir los aspectos más importantes de la gestión de una casa inteligente. Uno de ellos es definitivamente la comunicación bidireccional entre el usuario y el sistema. La mayoría de las acciones "reales" se almacenan como parámetros textuales y estos valores deben analizarse al realizar acciones específicas. Esto se hizo para que pudiéramos tener suficiente flexibilidad para trabajar con muchos tipos de dispositivos diferentes.

¿Tiene alguna sugerencia para agregar a nuestro modelo de casa inteligente? ¿Qué cambiarías o quitarías? Cuéntanos en los comentarios a continuación.