Continúo la serie de tres artículos sobre el hogar inteligente en la nube.
En un
artículo anterior , se consideraron equipos para detectar un hogar inteligente, así como algoritmos para convertir datos sensoriales en comandos de control para dispositivos ejecutivos. El componente principal de una casa inteligente es un controlador, que la mayoría de las veces funciona de forma autónoma de acuerdo con la lógica establecida en la etapa de configuración. Varios dispositivos (cámaras IP, sensores, actuadores) están conectados al controlador, que envía los datos recibidos de estos dispositivos a la nube.
Ahora hablemos de la arquitectura de un servicio en la nube para almacenar y procesar información de sensores y cámaras.
Beneficios del servicio en la nube
Un servicio en la nube para el hogar inteligente ofrece una forma simple, flexible y económica de almacenar y acceder a los datos recibidos de los dispositivos domésticos inteligentes. El usuario del servicio en la nube no necesita preocuparse por la seguridad de sus datos. Las capacidades de un servidor de medios multiprocesador, equipado con una canasta de discos con una matriz RAID de varias unidades de 10-12 TB, superan con creces la capacidad de una tarjeta SD o Flash dentro de un controlador doméstico inteligente. Además, las tarjetas de memoria no son confiables porque tienen un número limitado de ciclos de reescritura y a menudo fallan. La profundidad del almacenamiento de datos en la nube está determinada por la tarifa del usuario y se configura fácilmente en su cuenta personal.
Además, para acceder a los datos no hay necesidad de "reenvío de puertos" en el enrutador del usuario cuando el protocolo NAT oculta los dispositivos domésticos inteligentes de las redes externas. En su cuenta personal, accesible desde dispositivos móviles, puede configurar fácilmente la configuración y la lógica del hogar inteligente.
Es conveniente no solo almacenar datos en la nube, sino también procesarlos, proporcionando al usuario estadísticas para varios períodos de tiempo. A continuación, consideraremos un ejemplo de cálculo de la temperatura ambiente promedio por semana basada en mediciones multisensor.
Arquitectura de servicio en la nube
En un artículo anterior, hablamos sobre un controlador doméstico inteligente que está instalado en el lado del usuario e interactúa con un servicio en la nube utilizando varios protocolos:
- MQTT se usa para intercambiar mensajes JSON entre el controlador y el servidor de lógica de negocios;
- HTTP para obtener la dirección IP del servidor de medios menos cargado del equilibrador de carga del clúster de servidores de medios;
- RTMP para transferir la secuencia H.264 + AAC al servidor de medios.
Ahora consideraremos el servicio en la nube de un hogar inteligente: los componentes principales en los que consiste y cómo se produce la interacción con el controlador del hogar inteligente.
(haga clic en la imagen para abrir en una resolución más alta)El servidor de lógica de negocios es un elemento clave en todo el esquema de intercambio de información dentro del servicio en la nube. Su objetivo principal es administrar varios subsistemas de servidor a través de las interfaces RESTful API. Implementa la lógica del servicio en la nube en función
del modelo del usuario : grabar un archivo de video y mediciones del sensor según la tarifa seleccionada, la interacción entre el usuario y el controlador del hogar inteligente, etc.
El intermediario MQTT es necesario para intercambiar mensajes JSON entre controladores domésticos inteligentes instalados en el lado del cliente y el servidor de lógica de negocios. Los clientes se suscriben a temas dentro del agente que sirven como canales de mensajes. Como corredor de MQTT,
se utiliza Eclipse Mosquitto .
Un clúster de servidores de medios es un sistema distribuido para almacenar, procesar, buscar y reproducir información de video para cámaras IP de un hogar inteligente nublado. Un equilibrador de carga especial recopila información sobre el rendimiento actual de cada servidor en el clúster, calcula el menos cargado e informa su dirección IP al controlador doméstico inteligente, que transfiere el video de las cámaras al mismo.
Se necesita
una base de datos en la nube para almacenar el modelo de usuario del servicio en la nube, la configuración y el estado actual de su equipo, así como la metainformación sobre las entradas del archivo de video. Como implementación de la base de datos en la nube, se utiliza MySQL DBMS.
Touch Database es una base de datos NoSQL no relacional. Almacena eventos y mediciones de sensores domésticos inteligentes, ordenados por tiempo. El uso de
InfluxDB DBMS, optimizado para trabajar con este tipo de datos, mejora significativamente el rendimiento del servicio en la nube.
El backend de la aplicación cliente es una aplicación de servidor cuya función principal es proporcionar los datos recibidos de la nube y las bases de datos táctiles en un formato conveniente para su posterior visualización por la aplicación cliente en el dispositivo del usuario. El backend también genera comandos de control en formato JSON para el controlador doméstico inteligente. El backend está basado en el framework PHP
Laravel . Se discutirá con más detalle en el próximo artículo sobre una aplicación cliente para interactuar con un hogar inteligente en la nube.
El proveedor de notificaciones push entrega mensajes sobre los eventos de la casa inteligente al dispositivo móvil del usuario para que pueda intervenir rápidamente en la situación (por ejemplo, cuando aparece una fuga de agua o humo, llame a los servicios de respuesta apropiados).
El servicio
OneSignal fue elegido como el proveedor de notificaciones Push, que tiene una interfaz API RESTful conveniente y la función de identificación de dispositivos móviles, que es necesaria para el correcto funcionamiento de las notificaciones dentro de la cuenta personal del usuario.
Servidor de lógica de negocios
Como se mencionó anteriormente, el servidor de lógica de negocios es un componente clave del hogar inteligente en la nube. Basado en
el modelo de usuario (descripción informativa del usuario del sistema, que incluye características del sistema, personales, financieras y lógicas), administra una variedad de servicios dentro de la nube que tienen diferentes implementaciones y funcionalidades y se comunican entre sí a través de interfaces API RESTful.
El módulo de lógica de negocios dentro del servidor es responsable de las siguientes operaciones:
- gestionar el almacenamiento de mediciones de sensores y eventos de detectores de movimiento de cámaras IP de una casa inteligente dentro de una base de datos táctil;
- gestionar la grabación de la transmisión de medios de la cámara IP transmitida por el controlador doméstico inteligente en el archivo del servidor de medios (constante / por detector de movimiento);
- traducción de comandos desde la aplicación del cliente al controlador del hogar inteligente;
- difundir la configuración del controlador doméstico inteligente (dispositivos conectados, reglas de lógica de producción definidas por el usuario);
- enviando notificaciones push sobre el estado del controlador doméstico inteligente y los dispositivos conectados a la aplicación cliente.
Una característica del servidor de lógica de negocios es la comunicación entre procesos con aplicaciones remotas que se ejecutan en varios servidores en Internet. La mayoría de las veces, la aplicación del servidor de lógica de negocios está inactiva en bloqueos de E / S, por lo que está diseñada en base a una arquitectura de subprocesos múltiples y consta de un conjunto de subtareas finitas.
Para garantizar la máxima eficiencia, la implementación interna del servidor de lógica de negocios debería ser la más simple (
principio KISS ). Dado que el modelo de usuario es completamente determinista y no contiene relaciones cambiantes entre las características, no hay necesidad de un mecanismo de inferencia flexible (como en un controlador doméstico inteligente, donde el usuario configura la lógica del usuario). Por lo tanto, la operación del módulo de lógica de negocios dentro del servidor puede describirse mediante un diagrama de bloques algorítmico convencional con transiciones condicionales.
(haga clic en la imagen para abrir en una resolución más alta)Inmediatamente después de iniciarse, el servidor de lógica de negocios pasa al estado de espera para recibir mensajes utilizando los protocolos MQTT (de los controladores domésticos inteligentes) y HTTP (desde el back-end de la aplicación cliente). En caso de que el mensaje llegue a través de HTTP, esto significa que el usuario interactúa con la aplicación cliente y envía comandos al controlador doméstico inteligente o actualiza su configuración. Para que el mensaje del cliente caiga en el controlador de inicio inteligente, el servidor de lógica de negocios lo transmite al tema correspondiente del agente MQTT, al que está suscrito el controlador (
subtarea SendGatewayMessage ).
En la etapa de inicialización, el controlador doméstico inteligente espera a que el usuario lo registre en su cuenta personal. Por lo tanto, se realiza la subtarea
CheckGatewayExistance , que verifica el estado correspondiente en la base de datos en la nube MySQL. Para registrarse en su cuenta personal, el controlador envía su configuración completa al servidor de lógica de negocios y, a su vez, transmite su backend a la aplicación cliente (
subtarea SendBackend ), que crea y actualiza los registros de configuración en la nube y las bases de datos táctiles.
Cuando el controlador doméstico inteligente se registra con éxito en la cuenta personal del usuario, el servidor de lógica de negocios carga el modelo de usuario de la base de datos en la nube en su RAM y comienza a procesar mensajes de cámaras IP y sensores Z-Wave de acuerdo con el siguiente algoritmo de lógica de negocios.
Mensaje JSON del sensor Z-Wave con campos de información:
{ "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-************" }
Cuando llega un mensaje del sensor Z-Wave a través del protocolo MQTT, se realizan las siguientes subtareas:
- StoreSensorDataMySQL actualiza (ACTUALIZA) un registro existente en la base de datos en la nube MySQL, donde se almacena la información sobre el estado actual y las mediciones del sensor. Esto es necesario para una aplicación cliente que muestra el estado actual de la casa inteligente para el usuario;
- StoreSensorDataInfluxDB agrega (INSERTAR) un nuevo registro a la base de datos táctil InfluxDB, donde se almacena el historial de mediciones del sensor. Esta información se utiliza en el cálculo de datos estadísticos para varios períodos de tiempo (por ejemplo, consumo de energía por día, mes o año) y se muestra en la aplicación del cliente en forma de gráficos y tablas;
- SendPushNotification genera un mensaje JSON que contiene una marca de tiempo, un nombre de sensor, una descripción de texto del evento, el identificador del teléfono inteligente del usuario con el que ingresó a su cuenta personal, el identificador interno de la aplicación en el sistema del proveedor OneSignal. Además, este mensaje se envía al proveedor de notificaciones push a través de la API RESTful https://onesignal.com/api/v1/notifications , que lo entrega al teléfono inteligente del usuario.
Un ejemplo de un mensaje JSON de una cámara IP con campos de información:
{ "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-************" }
Cuando llega un mensaje de la cámara IP utilizando el protocolo MQTT, el servidor de lógica de negocios extrae su tipo del campo
messageType . Dependiendo del valor de este campo, se realizan las siguientes acciones:
- "MessageType": "deviceState" : el mensaje contiene información sobre el cambio de estado de la cámara IP. Se realiza la subtarea UpdateCameraState , actualizando la información en la base de datos en la nube. Si el campo deviceState es streamingOn o streamingOff (la cámara IP envía / detiene el flujo de datos al servidor de medios), se ejecuta la subtarea RecordMediaStream , que genera un comando para habilitar / deshabilitar el modo de grabación de archivo y lo envía al servidor de medios;
- "MessageType": "sensorData" : información sobre el funcionamiento del detector de movimiento en la cámara IP. Si en el modelo de usuario el modo de grabación de archivo se establece en "por detector de movimiento", se ejecuta la subtarea RecordMediaStream . A continuación, se realizan las subtareas StoreSensorDataInfluxDB (guardar el historial del detector en la base de datos táctil) y SendPushNotification (enviar notificaciones push a través del proveedor);
- "MessageType": "vista previa" : el mensaje contiene un cuadro de una imagen en miniatura de la cámara IP, que se envía periódicamente a la nube. La subtarea StorePreview lo guarda en una base de datos en la nube. Luego se usa en la aplicación cliente cuando se muestra una lista de cámaras;
- "MessageType": "comando" : un comando enviado por el controlador del hogar inteligente cuando el usuario cambia su configuración a través de la interfaz web. Se realiza la subtarea RecordMediaStream , que, según el modelo de usuario, activa / desactiva el modo de grabación en el servidor de medios.
(haga clic en la imagen para abrir en una resolución más alta)Como resultado del trabajo del módulo de lógica de negocios, se forma una
cola de tareas , una secuencia de secciones mínimas de código que se ejecutan independientemente entre sí. La cola de tareas se transfiere al grupo de
subprocesos , que distribuye las tareas entre los núcleos libres del procesador central. Cuando se produce un bloqueo de E / S durante la ejecución, el subproceso se detiene y entra en el estado inactivo y libera el núcleo del procesador central, lo que permite que el grupo de subprocesos inicie la ejecución inmediata de la siguiente tarea desde la cola. En el momento en que se libera el bloqueo de E / S, el subproceso bloqueado cambia su estado a funcionamiento y continúa la ejecución tan pronto como se libera uno de los núcleos del procesador central.
Por lo tanto, al descomponer la tarea de lógica de negocios en muchas subtareas separadas que se ejecutan simultáneamente, aumenta el rendimiento del servidor de lógica de negocios. El escalado del sistema se logra aumentando el número de núcleos del procesador central y aumentando el número de servidores de lógica de negocios en el sistema.
La aplicación de servidor de lógica de negocios se desarrolla en C ++ y se ejecuta como el servicio
systemd del sistema operativo Linux Debian Sarge. Para la supervisión adicional del rendimiento, se utiliza el sistema de supervisión de recursos
monit , que reinicia el servicio en caso de problemas de rendimiento.
Actualmente, el servicio en la nube ejecuta un servidor de lógica de negocios que se ejecuta en la máquina virtual Yandex. Parámetros de la máquina virtual: 4 núcleos de vCPU con una cuota garantizada del 20%, 2 GB de RAM, 100 GB de disco duro. Según los cálculos, este rendimiento es suficiente para procesar mensajes de ~ 1000 controladores domésticos inteligentes con 3 cámaras IP y 5 sensores Z-Wave cada uno (los cálculos se aclararán durante el funcionamiento del sistema).
Servidor de medios
Un servidor de medios es un servidor dedicado en el que se instala un software especial para:
- recibir flujos de datos de video y audio desde dispositivos codificadores utilizando protocolos de red especializados;
- almacenar datos en forma de archivos en su sistema de archivos;
- Transmita información de archivos en un formato de transmisión estándar para reproducir en dispositivos cliente.
El
Wowza Streaming Engine 4.7.2 con módulos adicionales desarrollados en el lenguaje Java se usa como un servidor de medios en el sistema doméstico inteligente en la nube para grabar datos de transmisión en un archivo y para trabajar con una base de datos en la nube.
(haga clic en la imagen para abrir en una resolución más alta)El flujo de medios desde el controlador doméstico inteligente en formato RTMP ingresa al servidor de medios y se alinea con las marcas de tiempo en el
búfer de fluctuación . Esto es necesario para compensar el efecto de los retrasos en los paquetes de red al transmitir el flujo de datos a través de Internet.
Para grabar la transmisión de video en el sistema de archivos del servidor de medios como un archivo MP4, el servidor de lógica de negocios envía el siguiente comando al servidor de medios a través de la API RESTful HTTP:
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" }
En el campo
recorderName , el nombre de la transmisión de video (identificador de cámara IP en el controlador doméstico inteligente) se
indica , en el campo
fileVersionDelegateName , el nombre de la clase heredada para determinar la ruta de la carpeta y el nombre del archivo. El código de clase Java se muestra en la siguiente lista:
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; } }
En la clase
CustomFileVersionDelegate , la función virtual
getFilename de la clase base
IStreamRecorderFileVersionDelegate está
sobrecargada , que el servidor de medios llama antes de que la secuencia comience a escribir en el archivo. La función crea una carpeta en el disco con la ruta
sDirPath y devuelve la ruta completa al archivo
sFullFilePath .
Dado que el volumen de datos multimedia es muy grande, el sistema de archivos incluye varios discos físicos de gran volumen (8-12 TB) montados como subdirectorios. El disco con la mayor cantidad de espacio libre se selecciona como el disco de destino durante la grabación. Para un funcionamiento óptimo del sistema de archivos al acceder al archivo, la ruta a la carpeta de destino se forma de la siguiente manera:
/content/<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/
donde
diskId es el identificador del disco (carpeta montada),
cameraIdDivideBy200 : el resultado de una división entera del identificador de la cámara por 200,
streamUuid : identificador de flujo de medios,
año, mes, día : año, mes y día de grabación, respectivamente.
Esto evita una gran cantidad de subcarpetas dentro de una carpeta y, en consecuencia, una caída dramática en el rendimiento de todo el sistema de archivos con un aumento en el número de cámaras IP en hogares inteligentes nublados.
La información sobre la dirección IP del servidor de medios, la ruta al archivo con datos de medios, la hora de inicio y finalización de la escritura en el archivo se almacena en la base de datos en la nube y luego la aplicación cliente la utiliza para mostrar la línea de tiempo del archivo en el que se puede seleccionar y reproducir el video.
Para obtener la transmisión de video, el front-end de la aplicación cliente accede al servidor de medios, enviando los siguientes comandos a través del protocolo HTTP. Para una transmisión de video "en vivo":
https://<mediaserverIp>:<port>/rtp-live-iot/<streamUuid>/playlist.m3u8
Para la secuencia de video archivada:
https://<mediaserverIp>:<port>/vod/_definst_/mp4:<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/<fileName>/playlist.m3u8?wowzaplaystart=<offsetMs>&wowzaplayduration=<durationMs>
donde
fileName es el nombre del archivo en el disco,
offsetMs : desplazamiento de reproducción relativo al comienzo del archivo en milisegundos,
duraciónMs - duración de la reproducción en milisegundos.
El servidor de medios envía una transmisión en formato
HLS , que le permite mostrar video H.264 + AAC en todos los navegadores modernos y dispositivos móviles con sistemas operativos iOS y Android. El paquete de paquetes HLS codifica el flujo en forma de fragmentos separados y lo envía a través de HTTP como respuesta a una solicitud de una aplicación móvil.
Para optimizar los costos de almacenamiento y el acceso a los archivos de almacenamiento, el servidor de medios domésticos inteligentes en la nube se desarrolló en la plataforma de hardware Supermicro CSE-825TQ, placa base X8DT6, 2xCPU Intel Xeon E5645 2.4 GHz, 32 GB de RAM, 44 TB HDD Adaptec AAC-RAID. El servidor de medios se instala como un servidor dedicado en el sitio de alojamiento y se conecta al canal de Internet con un ancho garantizado de 400 Mbps. El rendimiento de un servidor de medios es suficiente para procesar transmisiones de medios de ~ 400 cámaras IP con el códec H.264, resolución de cuadro de 720p y velocidad de bits de 1 Mbps.
En consecuencia, para poder procesar transmisiones de 1000 cámaras IP, es necesario instalar 3 servidores de medios y distribuir uniformemente la carga entre ellos. Para esto, se utiliza un equilibrador de carga, que está conectado al servidor de medios Wowza Streaming Engine como un complemento
adicional de Dynamic Load Balancing AddOn . Esto distingue, de hecho, el equilibrador de carga (o
servidor de origen ), que recibe periódicamente las métricas de rendimiento de los servidores de medios finales (o
servidores perimetrales ) y, según esta información, encuentra el servidor menos cargado en el clúster.
El controlador doméstico inteligente accede al equilibrador a través de HTTP y, en respuesta, recibe la dirección IP de este servidor, a la cual el controlador transmite el flujo de medios desde la cámara IP a través de RTMP. La métrica de rendimiento incluye el número de conexiones establecidas con fuentes y consumidores de transmisiones de medios y el ancho de banda actual del canal de Internet en el servidor. En la configuración del equilibrador, también puede especificar la elección del servidor perimetral, teniendo en cuenta su posición geoespacial, que le permite alojar servidores en diferentes ciudades y países para crear una red distribuida para entregar contenido
CDN .
Base de datos táctil
Como se mencionó anteriormente en el artículo anterior, las lecturas de los sensores Z-Wave, así como el estado actual y los eventos de las cámaras IP, se envían en formato JSON a la nube mediante el protocolo MQTT. El servidor de lógica de negocios decodifica estos mensajes y ejecuta la subtarea
StoreSensorDataInfluxDB , que transmite datos a la base de datos táctil a través de HTTP.
(haga clic en la imagen para abrir en una resolución más alta)La base de datos de sensores del hogar inteligente en la nube se desarrolla sobre la base de
InfluxDB 1.7.x , un sistema de gestión de bases de datos de código abierto para trabajar con secuencias de tiempo, que se utiliza en muchos proyectos de Internet de las Cosas para almacenar datos de sensores y análisis. Las consultas a la base de datos táctil se generan en el lenguaje
InfluxQL similar al SQL tradicional.
El tiempo de almacenamiento de datos en el hogar inteligente en la nube está determinado por la tarifa seleccionada de acuerdo con el modelo de usuario. Debido a la diferencia significativa en la cantidad de datos de video y datos del sensor, su tiempo de almacenamiento será diferente. El tamaño del archivo de video se mide en días (7, 14, 30 días a diferentes velocidades), y el tamaño del archivo de sensores se mide en años (3, 5, 7 años, respectivamente). Por lo tanto, para cada controlador doméstico inteligente, cuando se registra en la cuenta personal del usuario, se crean 2 bases de datos separadas con diferentes políticas de retención dentro de la base de datos táctil:
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;
El backend de la aplicación cliente es responsable de crear, editar y eliminar la base de datos dentro de la base de datos táctil. Por ejemplo, si un usuario doméstico inteligente en la nube cambia la tarifa, el servidor envía los siguientes comandos para realizar cambios en la política de almacenamiento:
ALTER RETENTION POLICY "autogen" ON "gateway_6774f85a_0a5b_4059_9b68_************_cameras" DURATION 168h SHARD DURATION 1h;
Al eliminar el controlador de casa inteligente de la cuenta personal del usuario, el servidor elimina las bases de datos correspondientes:
DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras"; DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors";
Al recibir un mensaje informativo del controlador del hogar inteligente, el servidor de lógica de negocios realiza una solicitud para insertar datos en la base de datos táctil:
INSERT device_20873eb0_dd5e_4213_a175_************,class=METER,label=Energy,units=kWh value_float=0.05 1572194550125;
Un ejemplo de una tabla con datos de sensores Z-Wave para un controlador doméstico inteligente:
Una de las características más útiles de una casa en la nube es el cálculo de estadísticas basadas en los datos recibidos. El usuario necesita saber la temperatura promedio en la habitación o cuánta electricidad gastó por mes.
El lenguaje InfluxQL le permite realizar consultas utilizando
funciones analíticas . Por ejemplo, para calcular la temperatura promedio durante una semana, debe ejecutar la siguiente 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);
Los resultados de esta consulta se muestran en la tabla:
En el próximo artículo, que está dedicado por completo a la aplicación del cliente, consideraremos en detalle el cálculo de estadísticas para varios parámetros y la construcción de tablas y gráficos basados en él.
En el sistema de casa inteligente en la nube, el DBMS InfluxDB se implementa en una máquina virtual Yandex. Cloud con los siguientes parámetros: 4 núcleos de vCPU con una participación garantizada del 20%, 2 GB de RAM, 100 GB de disco duro. Según los cálculos de esta configuración, es suficiente almacenar datos de sensores de 3.000 cámaras IP y 5.000 sensores Z-Wave durante 7 años.
Conclusión
El artículo examinó la arquitectura de un servicio en la nube para un hogar inteligente, el algoritmo de un servidor de lógica de negocios, la arquitectura de un servidor de medios para grabar, almacenar y reproducir transmisiones de medios desde cámaras IP, así como la arquitectura de una base de datos táctil para almacenar y analizar datos de sensores de hogares inteligentes. El sistema de servicio en la nube funciona tanto en servidores dedicados como virtuales, para una mayor estabilidad ubicada en diferentes sitios de alojamiento. El sistema se encuentra actualmente en operación de prueba.
Mientras más antiguos sean los datos almacenados en la nube, con menos frecuencia el usuario accede a ellos. En la próxima versión del servicio en la nube, se propone utilizar el mecanismo de adelgazamiento (o sobremuestreo) de datos mediante
consultas continuas InfluxDB para reducir la cantidad de datos almacenados mediante funciones de agregación y, por lo tanto, aumentar la capacidad de la base de datos táctil.
Además, en la próxima versión del servicio en la nube, se implementará un grupo de servidores de lógica de negocios de acuerdo con el principio de un grupo de servidores de medios, discutido en este artículo. La figura muestra la arquitectura de dicho clúster, donde varios servidores perimetrales (cada uno de los cuales tiene un agente MQTT y un software de servidor de lógica de negocios) envían métricas de rendimiento al servidor de origen, que calcula la dirección IP del servidor menos cargado. Esto le permitirá escalar el sistema en mayor medida y superar el límite existente de 1000 hogares inteligentes.