O modelo de dados da casa inteligente

Casas inteligentes costumavam ser estritamente no futuro; agora são uma realidade. A maioria de nós já ouviu falar deles, mas eles não são tão difundidos como serão no futuro próximo. Gerenciar sua casa de maneira “inteligente” definitivamente produzirá muitos dados. Hoje, analisaremos um modelo de dados que poderíamos usar para armazenar dados de casa inteligente.

O modelo de dados

Quando você pensa em uma casa inteligente, provavelmente pensa em bloquear e desbloquear remotamente sua casa, ativar alarmes, luzes ou câmeras do seu telefone, ter termômetros que gerenciam automaticamente seu aquecimento e resfriamento etc. Mas as casas inteligentes podem fazer muito mais. Você pode conectar vários dispositivos e controladores inteligentes para obter muitas funcionalidades complexas. Você pode enviar instruções para dispositivos ou ler seus status de onde estiver.

Vamos dar uma olhada em um modelo de dados que nos permitiria implementar tais funcionalidades. Em cima desse modelo de dados, poderíamos construir um aplicativo da web e um aplicativo móvel que permitiria aos usuários registrados administrar suas contas, enviar instruções e rastrear status.

O modelo consiste em três áreas temáticas:

Estates & devices
Users & profiles
Commands & data

Descreverei cada uma dessas áreas de assunto na ordem em que estão listadas. Antes de mais nada, descreverei a user_account tabela.

A tabela User_Account

Estamos começando com a user_account tabela porque é usado em todas as três áreas de assunto. Ele armazena uma lista de todos os usuários registrados do nosso aplicativo.

A user_account table contém todos os atributos padrão que você esperaria, incluindo:

first_name e last_name – O nome e sobrenome do usuário.
user_name – Um nome de usuário ÚNICO escolhido pelo usuário.
password – Um valor de hash da senha do usuário.
email – O endereço de e-mail fornecido pelo usuário durante o processo de registro.
confirmation_code – O código gerado durante o processo de registro.
confirmation_time – O carimbo de data/hora em que o usuário confirmou sua conta e concluiu o processo de registro.
ts – O carimbo de data/hora em que este registro foi inserido no banco de dados.

Seção 1:Propriedades e dispositivos

Toda a motivação por trás da criação deste banco de dados é monitorar o que está acontecendo com nossas propriedades (ou seja, casas ou propriedades). Podem ser propriedades particulares, como apartamentos ou casas, ou podem ser propriedades comerciais, como escritórios, armazéns, etc. Se realmente queremos levar nosso sistema ao limite, também podemos usá-lo para veículos.

A tabela central nesta área de assunto é o real_estate tabela. É aqui que armazenaremos todas as diferentes propriedades ou propriedades conectadas ao nosso aplicativo de casa inteligente. Para cada propriedade, armazenaremos:

real_estate_name – Um nome, escolhido pelo usuário, que se refere a uma propriedade específica.
user_account_id – O ID do usuário ao qual esta propriedade está relacionada. Juntamente com o atributo real_estate_name, isso forma a chave UNIQUE (alternativa) desta tabela.
real_estate_type – Indica o tipo de imóvel que esta propriedade é.
address – O endereço real dessa propriedade. Isso é anulável porque podemos usar esse sistema para outros tipos de propriedade (ou seja, veículos).
details – Todos os detalhes adicionais em formato textual.

Já mencionamos os tipos de imóveis. Uma lista completa de tipos possíveis é armazenada em real_estate_type dicionário. Ele contém apenas um valor UNIQUE, o type_name . Poderíamos esperar valores como “apartamento”, “casa” ou “garagem” aqui.

Um pedaço de imóvel pode ser dividido em várias áreas. Podem ser cômodos de um apartamento ou de uma casa; talvez queiramos agrupar alguns quartos ou queremos tudo relacionado ao quintal ou jardim em um grupo, etc. Ou talvez tenhamos um parque ou complexo industrial com vários escritórios; se a nossa propriedade for muito grande, ter áreas específicas pode ser muito útil. Para isso, usaremos a area tabela. Ele contém o par ÚNICO do real_estate_id e o area_name escolhido pelo usuário.

As duas últimas tabelas nesta área de assunto estão relacionadas a dispositivos.

No device_type tabela, armazenaremos uma lista completa de todos os tipos de dispositivos distintos. Para cada tipo, usaremos um type_name ÚNICO e insira uma description adicional se necessário. Os tipos de dispositivos podem ser sensores diferentes (temperatura, gás), fechaduras de portas ou janelas, luzes, sistemas de ar condicionado e aquecimento, etc.

Agora estamos prontos para a parte divertida. Usaremos o device table para armazenar uma lista de todos os dispositivos incluídos em várias casas inteligentes. Esses dispositivos são adicionados pelo usuário, manualmente ou automaticamente, se o dispositivo tiver essa opção. Para cada dispositivo, precisaremos armazenar:

real_estate_id – O ID do imóvel onde este dispositivo está instalado.
area_id – Faz referência à area onde este dispositivo está instalado. Este é um valor opcional porque uma propriedade poderia ser dividido em áreas, mas também não pode ser dividido.
device_type_id – O ID do device_type este dispositivo pertence.
device_parameters – Usaremos este atributo para armazenar todos os parâmetros possíveis do dispositivo (por exemplo, intervalos para armazenamento de dados) em um formato textual estruturado. Esses parâmetros podem ser definidos pelo usuário ou parte da função normal do dispositivo (por exemplo, medidas diferentes).
current_status – O status atual dos parâmetros do dispositivo.
time_activated e time_deactivated – Indica o intervalo em que este dispositivo estava ativo. Se time_deactivated não estiver definido, o dispositivo estará ativo e o is_active atributo também está definido como True.

Seção 2:usuários e perfis

Já mencionamos a user_account tabela. Em nosso aplicativo, os usuários devem poder criar perfis diferentes e compartilhá-los com outros usuários, se quiserem.

Perfis são basicamente subconjuntos de dispositivos instalados em cada pedaço de propriedade do usuário. Cada usuário pode ter um ou mais perfis. A ideia é permitir que um usuário agrupe seus dispositivos domésticos inteligentes de maneira adequada. Embora o usuário possa ter um perfil com todos os seus dispositivos, ele também pode ter um perfil mostrando apenas as câmeras da porta frontal para todas as suas propriedades. Ou talvez um perfil apenas para os termômetros instalados em todos os cômodos do apartamento.

Todos os perfis criados pelos usuários são armazenados no profile tabela. Para cada registro, teremos:

profile_name – O nome do perfil, escolhido pelo usuário.
user_account_id – Refere-se ao usuário que criou este perfil. Este atributo e o profile_name atributo da chave UNIQUE da tabela.
allow_others – Um sinalizador indicando se este perfil é compartilhado com outros usuários.
is_public – Um sinalizador indicando se este perfil é visível publicamente. Embora possamos esperar que isso seja definido como False na maioria das vezes, pode haver casos em que queremos compartilhar um perfil com todos.
is_active – Um sinalizador indicando se este perfil está ativo ou não.
ts – Um carimbo de data/hora de quando este registro foi inserido.

Para cada perfil, definiremos uma lista de todos os dispositivos incluídos nele. Esta lista é armazenada em profile_device_list tabela e contém uma lista de profile_id ÚNICO – device_id pares. Este par de chaves estrangeiras forma a chave primária da nossa tabela.

A última tabela deste assunto permite que os usuários compartilhem seus perfis com outros usuários cadastrados. Isso pode ser muito útil, por exemplo. se uma pessoa gerencia tudo e outros usuários registrados (por exemplo, membros da família) desejam visualizar os perfis criados pelo proprietário. No shared_with tabela, armazenaremos uma lista de todos os pares ÚNICOS de profile_id – user_account_id . Mais uma vez, esse par de chaves estrangeiras é a chave primária da tabela. Observe que o compartilhamento só funcionará se o profile.allow_others atributo está definido como Verdadeiro.

Seção 3:Comandos e Dados

Usaremos tabelas desta última área de assunto para armazenar comunicações entre usuários e dispositivos. Esta será uma comunicação de duas vias. Os dispositivos gerarão os dados durante suas operações e nosso banco de dados os armazenará, bem como quaisquer mensagens geradas pelo sistema (ou pelos dispositivos). Os usuários vão querer ver essas mensagens e os dados enviados por seus dispositivos. Com base nesses dados, os usuários podem criar programas para sua casa inteligente. Esses programas são comandos gerados manualmente ou automaticamente ou até mesmo uma série de comandos que farão exatamente o que cada usuário deseja.

Começaremos com os dispositivos de dados que nos dão. No device_data tabela, armazenaremos uma descrição dos dados gerados pelo dispositivo e os locais dos dados. Novamente, os dados são gerados automaticamente pelos dispositivos. Pode ser uma série de medições, status (dados textuais) ou dados audiovisuais. Para cada registro nesta tabela, armazenaremos:

device_id – O ID do dispositivo que gerou esses dados.
data_description – A descrição dos dados armazenados, por ex. o que é armazenado, quando os dados foram armazenados em nosso sistema e em que formato.
data_location – O caminho completo para o local onde esses dados estão armazenados.
ts – O carimbo de data/hora em que este registro foi inserido.

Os dados do dispositivo serão armazenados independentemente de o dispositivo estar funcionando corretamente ou se os dados estiverem fora do intervalo esperado. Este é basicamente um log de tudo que foi gravado pelos dispositivos. Podemos esperar ter uma estratégia para excluir arquivos de dados de dispositivos antigos, mas isso está fora do escopo deste artigo.

Ao contrário dos dados do dispositivo, podemos esperar que as mensagens sejam geradas apenas quando algo inesperado acontecer – por exemplo, se uma medição do dispositivo estiver fora da faixa normal, se um sensor detectar movimento, etc. Nesses casos, o dispositivo gera as mensagens. Todas essas mensagens são armazenadas no auto_message tabela. Em cada registro, teremos:

device_id – O ID do dispositivo que gerou esta mensagem.
message_text – O texto gerado pelo dispositivo. Pode ser um texto predefinido, um valor fora do intervalo esperado ou uma combinação desses dois.
ts – Um carimbo de data/hora de quando este registro foi armazenado.
read – Um sinalizador indicando se a mensagem foi lida pelo usuário.

As três tabelas restantes são usadas para armazenar os comandos dos usuários. Os comandos permitem que os usuários assumam o controle de seus dispositivos controláveis e estabeleçam comunicação bidirecional com sua casa inteligente.

Primeiro, vamos definir uma lista de todos os tipos de comando possíveis. Estes podem ser valores como “ligar/desligar”, “aumentar/diminuir temperatura”, etc. Também poderíamos ter comandos condicionais, ou seja, comandos que só são atendidos se uma condição específica for verdadeira. Uma lista de todos os tipos de comandos distintos é armazenada no command_type dicionário. Para cada tipo, armazenaremos um type_name ÚNICO . Também armazenaremos uma lista de todos os parâmetros que devem ser definidos para esse tipo de comando. Isso estará em um formato de texto estruturado com valores padrão inseridos. O usuário definirá esses valores ao inserir seus novos comandos.

Um usuário também pode definir todos os recurring_commands na frente. Talvez queiramos água quente todos os dias às 7h ou para ativar o sistema de aquecimento/resfriamento todos os dias às 16h. O conjunto de regras e todos os atributos necessários para que os comandos recorrentes aconteçam são armazenados nesta tabela. Nós teremos:

user_account_id – O ID do usuário que inseriu este comando recorrente.
device_id – O ID do dispositivo relevante para este comando recorrente.
command_type_id – Uma referência ao command_type dicionário.
parameters – Todos os parâmetros que devem ser definidos para esse tipo de comando, juntamente com seus valores desejados.
interval_definition – O intervalo entre duas recorrências deste comando. Tal como acontece com os parâmetros de comando, este será um campo de texto estruturado.
active_from e active_to – O intervalo durante o qual este comando deve ser repetido. O active_to pode ser NULL se quisermos que esse comando se repita para sempre (ou até definirmos o active_to data).
ts – O carimbo de data/hora em que este registro foi inserido.

A última tabela em nosso modelo contém uma lista de comandos únicos. Esses comandos podem ser inseridos manualmente pelo usuário ou gerados automaticamente (ou seja, como parte de comandos recorrentes). Para cada comando, armazenaremos:

recurring_command_id – O ID do comando recorrente que aciona este comando, se houver.
user_account_id – O ID do usuário que inseriu este comando.
device_id – O ID do dispositivo relevante.
command_type_id – Refere-se ao command_type dicionário.
parameters – Todos os parâmetros relevantes para este comando.
executed – Um sinalizador indicando se este comando foi executado.
ts – O carimbo de data/hora em que este registro foi inserido.

O que você acha do modelo de dados de casa inteligente?

Neste artigo, tentamos abordar os aspectos mais importantes do gerenciamento de uma casa inteligente. Uma delas é definitivamente a comunicação bidirecional entre o usuário e o sistema. A maioria das ações “reais” são armazenadas como parâmetros textuais e esses valores devem ser analisados ao executar ações específicas. Isso foi feito para que pudéssemos ter flexibilidade suficiente para trabalhar com muitos tipos de dispositivos diferentes.

Você tem alguma sugestão para adicionar ao nosso modelo de casa inteligente? O que você mudaria ou removeria? Por favor, conte-nos nos comentários abaixo.