🧚 🛏️ 👨‍👩‍👦 Nuvem Smart Home. Parte 2: Serviço em nuvem 👩🏿 😜 🍈

Eu continuo a série de três artigos sobre a nuvem casa inteligente.

Em um artigo anterior , foram considerados equipamentos para detectar uma casa inteligente, bem como algoritmos para converter dados sensoriais em comandos de controle para dispositivos executivos. O principal componente de uma casa inteligente é um controlador, que na maioria das vezes funciona de forma autônoma, de acordo com a lógica estabelecida na fase de configuração. Vários dispositivos (câmeras IP, sensores, atuadores) estão conectados ao controlador, que envia os dados recebidos desses dispositivos para a nuvem.

Agora, vamos falar sobre a arquitetura de um serviço de nuvem para armazenar e processar informações de sensores e câmeras.

Benefícios do serviço em nuvem

Um serviço de nuvem doméstica inteligente oferece uma maneira simples, flexível e barata de armazenar e acessar dados recebidos de dispositivos domésticos inteligentes. O usuário do serviço em nuvem não precisa se preocupar com a segurança de seus dados. Os recursos de um servidor de mídia multiprocessador, equipado com uma cesta de discos com uma matriz RAID de várias unidades de 10 a 12 TB, excedem em muito a capacidade de um cartão SD ou Flash dentro de um controlador doméstico inteligente. Além disso, os cartões de memória não são confiáveis porque possuem um número limitado de ciclos de reescrita e geralmente falham. A profundidade do armazenamento de dados na nuvem é determinada pela tarifa do usuário e é facilmente configurada em sua conta pessoal.

Além disso, para acessar os dados, não há necessidade de "encaminhamento de porta" no roteador do usuário quando dispositivos domésticos inteligentes estão ocultos das redes externas pelo protocolo NAT. Na sua conta pessoal, acessível a partir de dispositivos móveis, você pode configurar facilmente a configuração e a lógica da casa inteligente.

É conveniente não apenas armazenar dados na nuvem, mas também processá-los, fornecendo ao usuário estatísticas por vários períodos de tempo. Abaixo, consideraremos um exemplo de cálculo da temperatura ambiente média por semana com base em medições multisensores.

Arquitetura de serviço em nuvem

Em um artigo anterior, falamos sobre um controlador doméstico inteligente instalado no lado do usuário e interage com um serviço de nuvem usando vários protocolos:

MQTT é usado para trocar mensagens JSON entre o controlador e o servidor de lógica de negócios;
HTTP para obter o endereço IP do servidor de mídia menos carregado do balanceador de carga do cluster de servidores de mídia;
RTMP para transferir o fluxo H.264 + AAC para o servidor de mídia.

Agora, consideraremos o serviço de nuvem de uma casa inteligente - os principais componentes dos quais consiste e como ocorre a interação com o controlador de casa inteligente.

(clique na imagem para abrir em resolução maior)

O servidor de lógica de negócios é um elemento-chave em todo o esquema de troca de informações no serviço em nuvem. Seu principal objetivo é gerenciar vários subsistemas de servidores por meio das interfaces da API RESTful. Ele implementa a lógica do serviço em nuvem com base no modelo do usuário : gravando um arquivo de vídeo e medições de sensor, dependendo da tarifa selecionada, interação entre o usuário e o controlador doméstico inteligente, etc.

O broker MQTT é necessário para a troca de mensagens JSON entre controladores domésticos inteligentes instalados no lado do cliente e o servidor de lógica de negócios. Os clientes assinam tópicos no broker que servem como canais de mensagens. Como um broker do MQTT, o Eclipse Mosquitto é usado .

Um cluster de servidor de mídia é um sistema distribuído para armazenar, processar, pesquisar e reproduzir informações de vídeo para câmeras IP de uma casa inteligente nublada. Um balanceador de carga especial coleta informações sobre o desempenho atual de cada servidor no cluster, calcula o menos carregado e relata seu endereço IP para o controlador doméstico inteligente, que transfere o vídeo das câmeras para ele.

É necessário um banco de dados em nuvem para armazenar o modelo de usuário do serviço em nuvem, a configuração e o status atual de seus equipamentos, além de meta-informações sobre as entradas do arquivo de vídeo. Como uma implementação do banco de dados em nuvem, o MySQL DBMS é usado.

O Touch Database é um banco de dados NoSQL não relacional. Ele armazena eventos e medições de sensores residenciais inteligentes, ordenados por tempo. O uso do InfluxDB DBMS, otimizado para trabalhar com esse tipo de dados, melhora significativamente o desempenho do serviço em nuvem.

O back - end do aplicativo cliente é um aplicativo de servidor cuja função principal é fornecer dados recebidos da nuvem e tocar em bancos de dados em um formato conveniente para exibição subsequente pelo aplicativo cliente no dispositivo do usuário. O back-end também gera comandos de controle no formato JSON para o controlador doméstico inteligente. O back-end é baseado na estrutura PHP do Laravel . Será discutido em mais detalhes no próximo artigo sobre um aplicativo cliente para interagir com uma casa inteligente na nuvem.

O provedor de notificação por push entrega mensagens sobre os eventos da casa inteligente ao dispositivo móvel do usuário para que ele possa intervir rapidamente na situação (por exemplo, quando um vazamento ou fumaça de água aparecer, ligue para os serviços de resposta apropriados). O serviço OneSignal foi escolhido como o provedor de notificações push, que possui uma interface API RESTful conveniente e a função de identificação de dispositivos móveis, necessária para a operação correta das notificações na conta pessoal do usuário.

Servidor de lógica de negócios

Como mencionado anteriormente, o servidor de lógica de negócios é um componente essencial da nuvem em casa inteligente. Com base no modelo do usuário (descrição informativa do usuário do sistema, que inclui recursos do sistema, pessoais, financeiros e lógicos), ele gerencia uma variedade de serviços na nuvem que possuem implementações e funcionalidades diferentes e se comunicam por meio de interfaces de API RESTful.

O módulo de lógica de negócios dentro do servidor é responsável pelas seguintes operações:

gerenciamento de armazenamento de medições de sensores e eventos de detectores de movimento de câmeras IP de uma casa inteligente dentro de um banco de dados de toque;
gerenciar a gravação do fluxo de mídia da câmera IP transmitida pelo controlador de casa inteligente no arquivo do servidor de mídia (constante / por detector de movimento);
tradução de comandos do aplicativo cliente para o controlador doméstico inteligente;
transmitir a configuração do controlador doméstico inteligente (dispositivos conectados, regras de lógica de produção definidas pelo usuário);
enviando notificações push sobre o status do controlador doméstico inteligente e dos dispositivos conectados ao aplicativo cliente.

Um recurso do servidor de lógica de negócios é a comunicação entre processos entre aplicativos remotos em execução em vários servidores na Internet. Na maioria das vezes, o aplicativo do servidor de lógica de negócios fica ocioso nos bloqueios de E / S; portanto, ele é projetado com base em uma arquitetura multithread e consiste em um conjunto de subtarefas finitas.

Para garantir a máxima eficiência, a implementação interna do servidor de lógica de negócios deve ser a mais simples ( princípio do KISS ). Como o modelo do usuário é completamente determinístico e não contém relacionamentos alterados entre os recursos, não há necessidade de um mecanismo de inferência flexível (como em um controlador doméstico inteligente, onde a lógica do usuário é configurada pelo usuário). Portanto, a operação do módulo de lógica de negócios dentro do servidor pode ser descrita por um diagrama de blocos algorítmico convencional com transições condicionais.

(clique na imagem para abrir em resolução maior)

Imediatamente após a inicialização, o servidor de lógica de negócios entra no estado de espera por mensagens usando os protocolos MQTT (dos controladores domésticos inteligentes) e HTTP (do back-end do aplicativo cliente). Caso a mensagem chegue via HTTP, isso significa que o usuário interage com o aplicativo cliente e envia comandos para o controlador doméstico inteligente ou atualiza sua configuração. Para que a mensagem do cliente caia no controlador de casa inteligente, ela é transmitida pelo servidor de lógica de negócios para o tópico correspondente do broker MQTT, no qual o controlador está inscrito ( subtarefa SendGatewayMessage ).

No estágio de inicialização, o controlador doméstico inteligente aguarda o usuário registrá-lo em sua conta pessoal. Portanto, é executada a subtarefa CheckGatewayExistance , que verifica o status correspondente no banco de dados em nuvem MySQL. Para registrar-se em sua conta pessoal, o controlador envia sua configuração completa ao servidor de lógica de negócios e, por sua vez, transmite seu back-end para o aplicativo cliente ( subtarefa SendBackend ), que cria e atualiza registros de configuração nos bancos de dados em nuvem e touch.

Quando o controlador doméstico inteligente é registrado com êxito na conta pessoal do usuário, o servidor de lógica de negócios carrega o modelo do usuário do banco de dados na nuvem em sua RAM e começa a processar mensagens de câmeras IP e sensores Z-Wave de acordo com o seguinte algoritmo de lógica de negócios.

Mensagem JSON do sensor Z-Wave com campos de informação:

{ "vendor": "*****", "version": "3.0.0", "timestampMs": "1571754749561", "clientType": "gateway", "deviceId": "c8e8de37-d301-45f4-ba01-************", "deviceType": "sensor", "protocol": "zwave", "messageType": "sensorData", "homeId": "0xefa0cfa7", "nodeId": "19", "sensorType": "SENSOR MULTILEVEL", "label": "Temperature", "sensorData": "26.1", "units": "C", "gatewayId": "6774f85a-0a5b-4059-9b68-************" }

Quando uma mensagem do sensor Z-Wave chega via protocolo MQTT, as seguintes subtarefas são executadas:

StoreSensorDataMySQL atualiza (UPDATE) um registro existente no banco de dados em nuvem MySQL, onde são armazenadas informações sobre o estado atual e as medidas do sensor. Isso é necessário para um aplicativo cliente que exibe o estado atual da casa inteligente para o usuário;
O StoreSensorDataInfluxDB adiciona (INSERT) um novo registro ao banco de dados de toque do InfluxDB, onde o histórico de medições do sensor é armazenado. Essas informações são usadas no cálculo de dados estatísticos para vários períodos de tempo (por exemplo, consumo de energia por dia, mês ou ano) e exibidas no aplicativo cliente na forma de gráficos e tabelas;
SendPushNotification gera uma mensagem JSON contendo um registro de data e hora, um nome de sensor, uma descrição em texto do evento, o identificador do smartphone do usuário com quem ele entrou em sua conta pessoal, o identificador interno do aplicativo no sistema de provedor OneSignal. Além disso, essa mensagem é enviada ao provedor de notificação por push por meio da API RESTful https://onesignal.com/api/v1/notifications , que a entrega ao smartphone do usuário.

Um exemplo de uma mensagem JSON de uma câmera IP com campos de informações:

 { "vendor": "*****", "version": "3.0.0", "timestampMs": "1571753150317", "clientType": "gateway", "deviceId": "1616453d-30cd-44b7-9bf0-************", "deviceType": "camera", "protocol": "onvif", "messageType": "deviceState", "deviceState": "streamingOn", "mediaserverIp": "***.***.***.***", "applicationName": "rtp-live-iot", "gatewayId": "6774f85a-0a5b-4059-9b68-************" }

Quando uma mensagem chega da câmera IP usando o protocolo MQTT, o servidor de lógica de negócios extrai seu tipo do campo messageType . Dependendo do valor desse campo, as seguintes ações são executadas:

"MessageType": "deviceState" - a mensagem contém informações sobre a alteração de status da câmera IP. A subtarefa UpdateCameraState é executada , atualizando as informações no banco de dados em nuvem. Se o campo deviceState for streamingOn ou streamingOff (a câmera IP envia / interrompe o fluxo de dados para o servidor de mídia), a subtarefa RecordMediaStream é executada , o que gera um comando para ativar / desativar o modo de gravação de arquivo morto e o envia ao servidor de mídia, levando em consideração o modelo do usuário;
"MessageType": "sensorData" - informações sobre a operação do detector de movimento na câmera IP. Se no modelo do usuário o modo de gravação de arquivo estiver definido como "por detector de movimento", a subtarefa RecordMediaStream será executada . Em seguida, são executadas as subtarefas StoreSensorDataInfluxDB (salvando o histórico do detector no banco de dados de toque) e SendPushNotification (enviando notificações push através do provedor);
"MessageType": "preview" - a mensagem contém um quadro de uma imagem em miniatura da câmera IP, que é enviada periodicamente para a nuvem. A subtarefa StorePreview o salva em um banco de dados em nuvem. Em seguida, é usado no aplicativo cliente ao exibir uma lista de câmeras;
"MessageType": "command" - um comando enviado pelo controlador doméstico inteligente quando o usuário altera suas configurações pela interface da Web. A subtarefa RecordMediaStream é executada , que, dependendo do modelo do usuário, liga / desliga o modo de gravação no servidor de mídia.

(clique na imagem para abrir em resolução maior)

Como resultado do trabalho do módulo de lógica de negócios, uma fila de tarefas é formada - uma sequência de seções mínimas de código que são executadas independentemente uma da outra. A fila de tarefas é transferida para o conjunto de encadeamentos , que distribui tarefas entre os núcleos livres do processador central. Quando um bloqueio de E / S ocorre durante a execução, o encadeamento pausa e entra no estado inativo e libera o núcleo do processador central, o que permite ao conjunto de encadeamentos iniciar a execução imediata da próxima tarefa da fila. No momento em que o bloqueio de E / S é liberado, o encadeamento bloqueado muda seu estado para trabalho e continua a execução assim que um dos núcleos do processador central é liberado.

Assim, decompondo a tarefa de lógica de negócios em várias subtarefas separadas que são executadas simultaneamente, o desempenho do servidor de lógica de negócios aumenta. O dimensionamento do sistema é obtido aumentando o número de núcleos do processador central e o número de servidores de lógica de negócios no sistema.

O aplicativo do servidor de lógica de negócios é desenvolvido em C ++ e é executado como o serviço systemd do sistema operacional Linux Debian Sarge. Para monitoramento de desempenho adicional, é usado o sistema de monitoramento de recursos monit , que reinicia o serviço em caso de problemas de desempenho.

Atualmente, o serviço de nuvem executa um servidor de lógica de negócios em execução na máquina virtual Yandex. Parâmetros da máquina virtual - 4 núcleos de vCPU com participação garantida de 20%, 2 GB de RAM e 100 GB de HDD. De acordo com os cálculos, esse desempenho é suficiente para processar mensagens de ~ 1000 controladores domésticos inteligentes com 3 câmeras IP e 5 sensores Z-Wave cada (os cálculos serão esclarecidos durante a operação do sistema).

Servidor de mídia

Um servidor de mídia é um servidor dedicado no qual um software especial está instalado para:

receber fluxos de dados de vídeo e áudio de dispositivos codificadores usando protocolos de rede especializados;
armazenar dados na forma de arquivos compactados em seu sistema de arquivos;
Transmita informações de arquivos compactados em um formato de streaming padrão para reprodução em dispositivos clientes.

O Wowza Streaming Engine 4.7.2 com módulos adicionais desenvolvidos na linguagem Java é usado como servidor de mídia no sistema inteligente em nuvem para gravar dados de streaming em um arquivo morto e para trabalhar com um banco de dados em nuvem.

(clique na imagem para abrir em resolução maior)

O fluxo de mídia do controlador doméstico inteligente no formato RTMP entra no servidor de mídia e é alinhado com carimbos de data e hora no buffer de tremulação . Isso é necessário para compensar o efeito dos atrasos dos pacotes de rede ao transmitir o fluxo de dados pela Internet.

Para gravar o fluxo de vídeo no sistema de arquivos do servidor de mídia como um arquivo MP4, o servidor de lógica de negócios envia o seguinte comando ao servidor de mídia por meio da API HTTP RESTful:

 http://<mediaserverIp>:<port>/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/rtp-live-iot/instances/_definst_/streamrecorders/1616453d-30cd-44b7-9bf0-************ { "instanceName": "_definst_", "fileVersionDelegateName": "CustomFileVersionDelegate", "serverName": "", "recorderName": "1616453d-30cd-44b7-9bf0-************", "segmentSchedule": "", "outputPath": "", "currentFile": "", "applicationName": "rtp-live-iot", "fileTemplate": "", "segmentationType": "SegmentByDuration", "fileFormat": "MP4", "recorderState": "", "option": "", "currentSize": "0", "segmentSize": "0", "segmentDuration": "1800000", "backBufferTime": "0", "currentDuration": "0", "startOnKeyFrame": "true", "recordData": "false", "moveFirstVideoFrameToZero": "true", "defaultRecorder": "false", "splitOnTcDiscontinuity": "false" }

No campo recorderName , o nome do fluxo de vídeo (identificador da câmera IP no controlador doméstico inteligente) é indicado , no campo fileVersionDelegateName , o nome da classe herdada para determinar o caminho da pasta e o nome do arquivo. O código da classe Java é mostrado na seguinte listagem:

 import java.io.File; import java.util.Calendar; import java.util.TimeZone; import com.wowza.wms.livestreamrecord.manager.IStreamRecorder; import com.wowza.wms.livestreamrecord.manager.IStreamRecorderFileVersionDelegate; import com.wowza.wms.logging.WMSLoggerFactory; public class CustomFileVersionDelegate implements IStreamRecorderFileVersionDelegate { @Override public String getFilename(IStreamRecorder recorder) { String sDisk = GetDisk(); if(sDisk == null) { WMSLoggerFactory.getLogger(null).error("CustomFileVersionDelegate::getFilename(): No drive chosen"); return null; } String sStreamName = recorder.getStreamName(); int nCameraId = Integer.parseUnsignedInt(ServiceQueries.GetCameraId(sStreamName)); TimeZone tz = TimeZone.getTimeZone("Europe/Moscow"); Calendar now = Calendar.getInstance(tz); String sDirPath = ServerParams.m_sServerContentPath + "/" + sDisk + "/" + Integer.toString(nCameraId / 200) + "/" + sStreamName + "/" + String.format("%1$tY/%1$tm/%1$td", now); String sFullFilePath = sDirPath + "/" + sStreamName + "_" + String.format("%1$tH_%1$tM_%1$tS", now) + ".mp4"; File dirs = new File(sDirPath); dirs.setExecutable(true); dirs.setWritable(true); dirs.mkdirs(); WMSLoggerFactory.getLogger(null).info( "CustomFileVersionDelegate::getFilename(): Filename created: " + sFullFilePath); return sFullFilePath; } }

Na classe CustomFileVersionDelegate , a função virtual getFilename da classe base IStreamRecorderFileVersionDelegate está sobrecarregada , que é chamada pelo servidor de mídia antes que o fluxo comece a gravar no arquivo. A função cria uma pasta no disco com o caminho sDirPath e retorna o caminho completo para o arquivo sFullFilePath .

Como o volume de dados de mídia é muito grande, o sistema de arquivos inclui vários discos físicos de grande volume (8 - 12 TB) montados como subdiretórios. O disco com a maior quantidade de espaço livre é selecionado como o disco de destino durante a gravação. Para uma operação ideal do sistema de arquivos ao acessar o arquivo, o caminho para a pasta de destino é formado da seguinte maneira:

 /content/<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/

onde diskId é o identificador do disco (pasta montada),
cameraIdDivideBy200 - o resultado de uma divisão inteira do identificador da câmera em 200,
streamUuid - identificador de fluxo de mídia,
ano, mês, dia - ano, mês e dia da gravação, respectivamente.

Isso evita um grande número de subpastas em uma pasta e, consequentemente, uma queda drástica no desempenho de todo o sistema de arquivos, com um aumento no número de câmeras IP em casas inteligentes nubladas.

As informações sobre o endereço IP do servidor de mídia, o caminho para o arquivo com dados de mídia, o horário de início e término da gravação no arquivo são armazenadas no banco de dados em nuvem e, em seguida, usadas pelo aplicativo cliente para exibir a linha do tempo do arquivo na qual o vídeo pode ser selecionado e reproduzido.

Para obter o fluxo de vídeo, o front-end do aplicativo cliente acessa o servidor de mídia, enviando os seguintes comandos por meio do protocolo HTTP. Para uma transmissão de vídeo "ao vivo":

 https://<mediaserverIp>:<port>/rtp-live-iot/<streamUuid>/playlist.m3u8

Para fluxo de vídeo arquivado:

 https://<mediaserverIp>:<port>/vod/_definst_/mp4:<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/<fileName>/playlist.m3u8?wowzaplaystart=<offsetMs>&wowzaplayduration=<durationMs>

onde fileName é o nome do arquivo no disco,
offsetMs - deslocamento da reprodução em relação ao início do arquivo em milissegundos,
durationMs - duração da reprodução em milissegundos.

O servidor de mídia envia um fluxo no formato HLS , que permite exibir o vídeo H.264 + AAC em todos os navegadores e dispositivos móveis modernos com os sistemas operacionais iOS e Android. O empacotador HLS codifica o fluxo na forma de blocos separados e o envia por HTTP como resposta a uma solicitação de um aplicativo móvel.

Para otimizar os custos de armazenamento e o acesso a arquivos compactados, o servidor de mídia doméstica inteligente na nuvem foi desenvolvido na plataforma de hardware Supermicro CSE-825TQ, placa-mãe X8DT6, 2xCPU Intel Xeon E5645 de 2,4 GHz, 32 GB de RAM, 32 GB de RAM, HDD Adaptec AAC-RAID de 44 TB. O servidor de mídia é instalado como um servidor dedicado no site de hospedagem e se conecta ao canal da Internet com uma largura garantida de 400 Mbps. O desempenho de um servidor de mídia é suficiente para processar fluxos de mídia de ~ 400 câmeras IP com o codec H.264, resolução de quadro de 720p e taxa de bits de 1 Mbps.

Portanto, para poder processar fluxos de 1000 câmeras IP, é necessário instalar três servidores de mídia e distribuir uniformemente a carga entre eles. Para isso, é usado um balanceador de carga, conectado ao servidor de mídia Wowza Streaming Engine como um plug-in AddOn de balanceamento dinâmico de carga separado. Na verdade, isso distingue o balanceador de carga (ou servidor de origem ), que recebe periodicamente as métricas de desempenho dos servidores de mídia finais (ou servidores de borda ) e, com base nessas informações, encontra o servidor menos carregado no cluster.

O controlador doméstico inteligente acessa o balanceador via HTTP e, em resposta, recebe o endereço IP deste servidor, para o qual o controlador transmite o fluxo de mídia da câmera IP via RTMP. A métrica de desempenho inclui o número de conexões estabelecidas com fontes e consumidores de fluxos de mídia e a largura de banda atual do canal da Internet no servidor. Nas configurações do balanceador, você também pode especificar a escolha do servidor de borda, levando em consideração sua posição geoespacial, que permite hospedar servidores em diferentes cidades e países para criar uma rede distribuída para entrega de conteúdo CDN .

Touch database

Como mencionado anteriormente no artigo anterior, as leituras dos sensores Z-Wave, bem como o status e os eventos atuais das câmeras IP são enviados no formato JSON pelo controlador doméstico inteligente para a nuvem usando o protocolo MQTT. O servidor de lógica de negócios decodifica essas mensagens e executa a subtarefa StoreSensorDataInfluxDB , que transmite dados para o banco de dados touch via HTTP.

(clique na imagem para abrir em resolução maior)

O banco de dados em nuvem da casa inteligente é desenvolvido com base no InfluxDB 1.7.x - um sistema de gerenciamento de banco de dados de código aberto para trabalhar com seqüências de tempo, usado em muitos projetos da Internet das Coisas para armazenar dados de sensores e análises. As consultas ao banco de dados de toque são geradas na linguagem InfluxQL semelhante ao SQL tradicional.

O tempo de armazenamento de dados na nuvem smart home é determinado pela tarifa selecionada de acordo com o modelo do usuário. Devido à diferença significativa na quantidade de dados de vídeo e dados do sensor, o tempo de armazenamento será diferente. O tamanho do arquivo de vídeo é medido em dias (7, 14, 30 dias a taxas diferentes) e o tamanho do arquivo de sensores é medido em anos (3, 5, 7 anos, respectivamente). Portanto, para cada controlador doméstico inteligente, quando é registrado na conta pessoal do usuário, dois bancos de dados separados com diferentes políticas de retenção são criados dentro do banco de dados de toque:

 CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras" WITH DURATION 720h SHARD DURATION 1h; CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors" WITH DURATION 61320h SHARD DURATION 24h;

O back-end do aplicativo cliente é responsável por criar, editar e excluir o banco de dados dentro do banco de dados de toque. Por exemplo, se um usuário doméstico inteligente na nuvem alterar a tarifa, o back-end envia os seguintes comandos para fazer alterações na política de armazenamento:

 ALTER RETENTION POLICY "autogen" ON "gateway_6774f85a_0a5b_4059_9b68_************_cameras" DURATION 168h SHARD DURATION 1h;

Ao remover o controlador doméstico inteligente da conta pessoal do usuário, o back-end exclui os bancos de dados correspondentes:

 DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras"; DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors";

Após o recebimento de uma mensagem informativa do controlador doméstico inteligente, o servidor de lógica de negócios executa uma solicitação para inserir dados no banco de dados de toque:

 INSERT device_20873eb0_dd5e_4213_a175_************,class=METER,label=Energy,units=kWh value_float=0.05 1572194550125;

Um exemplo de uma tabela com dados dos sensores Z-Wave para um controlador doméstico inteligente:

Um dos recursos mais úteis de uma casa na nuvem é o cálculo das estatísticas com base nos dados recebidos. O usuário precisa saber a temperatura média na sala ou quanta eletricidade ele gasta por mês.

A linguagem InfluxQL permite realizar consultas usando funções analíticas . Por exemplo, para calcular a temperatura média de uma semana, você precisa executar a seguinte consulta:

 SELECT MEAN("value_float") FROM device_63c660da_f0e8_4eca_8d5f_************ WHERE label = 'Temperature' AND time >= '2019-10-21T00:00:00.000Z' AND time <= '2019-10-27T23:59:59.999Z' GROUP BY time(1d) fill(null);

Os resultados desta consulta são mostrados na tabela:

No próximo artigo, inteiramente dedicado ao aplicativo cliente, o cálculo das estatísticas para vários parâmetros e a construção de tabelas e gráficos baseados nele serão examinados em detalhes.

No sistema doméstico inteligente em nuvem, o InfluxDB DBMS é implantado em uma máquina virtual em Yandex: Cloud com os seguintes parâmetros: 4 núcleos de vCPU com uma parcela garantida de 20%, 2 GB de RAM e 100 GB de disco rígido. De acordo com os cálculos dessa configuração, é suficiente armazenar dados de sensores de 3.000 câmeras IP e 5.000 sensores Z-Wave por 7 anos.

Conclusão

O artigo examinou a arquitetura de um serviço de nuvem para uma casa inteligente, o algoritmo de um servidor de lógica de negócios, a arquitetura de um servidor de mídia para gravação, armazenamento e reprodução de fluxos de mídia de câmeras IP, bem como a arquitetura de um banco de dados de toque para armazenar e analisar dados de sensores domésticos inteligentes. O sistema de serviço em nuvem funciona em servidores dedicados e virtuais, para maior estabilidade localizada em diferentes sites de hospedagem. O sistema está atualmente em operação experimental.

Quanto mais antigos os dados armazenados na nuvem, menos frequentemente o usuário os acessa. Na próxima versão do serviço de nuvem, propõe-se usar o mecanismo de redução de dados (ou superamostragem ) usando as Consultas Contínuas do InfluxDB para reduzir a quantidade de dados armazenados usando funções de agregação e, assim, aumentar a capacidade do banco de dados de toque.

Além disso, na próxima versão do serviço em nuvem, um cluster de servidores de lógica de negócios será implementado de acordo com o princípio de um cluster de servidores de mídia, discutido neste artigo. A figura mostra a arquitetura desse cluster, em que vários servidores de borda (cada um com um broker MQTT e um software de servidor de lógica de negócios separados) enviam métricas de desempenho ao servidor de origem, que calcula o endereço IP do servidor menos carregado. Isso permitirá que você dimensione o sistema em maior medida e supere o limite existente de 1.000 residências inteligentes.