Geekly articles weekly

Cloud Smart Home. Partie 2: Service cloud

image

Je continue la série de trois articles sur la maison intelligente cloud.

Dans un article précédent , l'équipement pour détecter une maison intelligente a été examiné, ainsi que des algorithmes pour convertir les données sensorielles en commandes de contrôle pour les appareils exécutifs. Le composant principal d'une maison intelligente est un contrôleur qui, la plupart du temps, fonctionne de manière autonome conformément à la logique définie lors de la configuration. Divers appareils (caméras IP, capteurs, actionneurs) sont connectés au contrôleur, qui envoie les données reçues de ces appareils vers le cloud.

Parlons maintenant de l'architecture d'un service cloud pour le stockage et le traitement des informations des capteurs et des caméras.

Avantages du service cloud


Un service cloud de maison intelligente offre un moyen simple, flexible et peu coûteux de stocker et d'accéder aux données reçues des appareils de la maison intelligente. L'utilisateur du service cloud n'a pas à se soucier de la sécurité de ses données. Les capacités d'un serveur multimédia multiprocesseur, équipé d'un panier de disques avec une matrice RAID de plusieurs disques de 10 à 12 To, dépassent de loin la capacité d'une carte SD ou Flash à l'intérieur d'un contrôleur domestique intelligent. De plus, les cartes mémoire ne sont pas fiables car elles ont un nombre limité de cycles de réécriture et échouent souvent. La profondeur de stockage des données dans le cloud est déterminée par le tarif de l'utilisateur et est facilement configurable dans son compte personnel.

De plus, pour accéder aux données, il n'est pas nécessaire de «rediriger les ports» sur le routeur de l'utilisateur lorsque les appareils domestiques intelligents sont cachés des réseaux externes par le protocole NAT. Dans votre compte personnel, accessible depuis des appareils mobiles, vous pouvez facilement configurer la configuration et la logique de la maison intelligente.

Il est pratique non seulement de stocker des données dans le cloud, mais aussi de les traiter, fournissant à l'utilisateur des statistiques pour différentes périodes. Ci-dessous, nous considérerons un exemple de calcul de la température ambiante moyenne par semaine sur la base de mesures multicapteurs.

Architecture de service cloud


Dans un article précédent, nous avons parlé d'un contrôleur de maison intelligente installé côté utilisateur et interagissant avec un service cloud à l'aide de plusieurs protocoles:

  • MQTT est utilisé pour échanger des messages JSON entre le contrôleur et le serveur de logique métier;
  • HTTP pour obtenir l'adresse IP du serveur multimédia le moins chargé à partir de l'équilibreur de charge du cluster de serveurs multimédia;
  • RTMP pour transférer le flux H.264 + AAC vers le serveur multimédia.

Nous allons maintenant examiner le service cloud d'une maison intelligente - les principaux composants qui le composent, et comment l'interaction avec le contrôleur de maison intelligente se produit.


(cliquez sur l'image pour l'ouvrir en plus haute résolution)

Le serveur de logique métier est un élément clé de l'ensemble du système d'échange d'informations au sein du service cloud. Son objectif principal est de gérer divers sous-systèmes de serveur via les interfaces API RESTful. Il implémente la logique du service cloud basée sur le modèle utilisateur : enregistrement d'une archive vidéo et mesures de capteurs en fonction du tarif sélectionné, interaction entre l'utilisateur et le contrôleur de maison intelligente, etc.

Le courtier MQTT est nécessaire pour échanger des messages JSON entre des contrôleurs de maison intelligente installés côté client et le serveur de logique métier. Les clients s'abonnent aux sujets du courtier qui servent de canaux de messages. En tant que courtier MQTT, Eclipse Mosquitto est utilisé .

Un cluster de serveurs multimédias est un système distribué de stockage, de traitement, de recherche et de lecture d'informations vidéo pour les caméras IP d'une maison intelligente nuageuse. Un équilibreur de charge spécial collecte des informations sur les performances actuelles de chaque serveur du cluster, calcule le moins chargé et communique son adresse IP au contrôleur de maison intelligente, qui lui transfère la vidéo des caméras.

Une base de données cloud est nécessaire pour stocker le modèle utilisateur du service cloud, la configuration et l'état actuel de son équipement, ainsi que des méta-informations sur les entrées d'archives vidéo. En tant qu'implémentation de la base de données cloud, le SGBD MySQL est utilisé.

Touch Database est une base de données NoSQL non relationnelle. Il stocke les événements et les mesures des capteurs de maison intelligente, classés par heure. L'utilisation du SGBD InfluxDB , optimisé pour travailler avec ce type de données, améliore considérablement les performances du service cloud.

Le backend d'application client est une application serveur dont la fonction principale est de fournir des données reçues du cloud et des bases de données tactiles dans un format pratique pour un affichage ultérieur par l'application client sur l'appareil de l'utilisateur. Le backend génère également des commandes de contrôle au format JSON pour le contrôleur de maison intelligente. Le backend est basé sur le framework PHP Laravel . Il sera discuté plus en détail dans le prochain article sur une application client pour interagir avec une maison intelligente cloud.

Le fournisseur de notifications push envoie des messages sur les événements de la maison intelligente à l'appareil mobile de l'utilisateur afin qu'il puisse intervenir rapidement dans la situation (par exemple, lorsqu'une fuite d'eau ou de la fumée apparaît, appelez les services de réponse appropriés). Le service OneSignal a été choisi comme fournisseur de notifications push, qui possède une interface API RESTful pratique et la fonction d'identification des appareils mobiles, qui est nécessaire pour le bon fonctionnement des notifications dans le compte personnel de l'utilisateur.

Serveur de logique métier


Comme mentionné précédemment, le serveur de logique métier est un composant clé de la maison intelligente cloud. Sur la base du modèle utilisateur (description informative de l'utilisateur du système, qui comprend les fonctionnalités système, personnelles, financières et logiques), il gère une variété de services dans le cloud qui ont différentes implémentations et fonctionnalités et communiquent entre eux via des interfaces API RESTful.



Le module de logique métier à l'intérieur du serveur est responsable des opérations suivantes:

  1. gérer le stockage des mesures des capteurs et des événements des détecteurs de mouvement des caméras IP d'une maison intelligente à l'intérieur d'une base de données tactile;
  2. gérer l'enregistrement du flux multimédia de la caméra IP diffusé par le contrôleur de maison intelligente dans l'archive du serveur multimédia (constant / par détecteur de mouvement);
  3. traduction des commandes de l'application client vers le contrôleur de maison intelligente;
  4. diffuser la configuration du contrôleur de maison intelligente (appareils connectés, règles de logique de production définies par l'utilisateur);
  5. envoyer des notifications push sur l'état du contrôleur de maison intelligente et des appareils connectés à l'application cliente.

Une caractéristique du serveur de logique métier est la communication interprocessus avec des applications distantes exécutées sur plusieurs serveurs sur Internet. La plupart du temps, l'application serveur de logique métier est inactive sur les verrous d'E / S, elle est donc conçue sur la base d'une architecture multithread et se compose d'un ensemble de sous-tâches finies.

Pour garantir une efficacité maximale, l'implémentation interne du serveur de logique métier doit être la plus simple ( principe KISS ). Étant donné que le modèle utilisateur est complètement déterministe et ne contient pas de relations changeantes entre les fonctionnalités, il n'est pas nécessaire d'avoir un mécanisme d'inférence flexible (comme dans un contrôleur de maison intelligente, où la logique utilisateur est configurée par l'utilisateur). Par conséquent, le fonctionnement du module de logique métier à l'intérieur du serveur peut être décrit par un schéma fonctionnel algorithmique classique avec des transitions conditionnelles.


(cliquez sur l'image pour l'ouvrir en plus haute résolution)

Immédiatement après le démarrage, le serveur de logique métier passe en état d'attente pour les messages à l'aide des protocoles MQTT (des contrôleurs de maison intelligente) et HTTP (du serveur principal de l'application client). Dans le cas où le message arrive via HTTP, cela signifie que l'utilisateur interagit avec l'application cliente et envoie des commandes au contrôleur de maison intelligente ou met à jour sa configuration. Pour que le message du client tombe dans le contrôleur de maison intelligente, il est transmis par le serveur de logique métier au sujet correspondant du courtier MQTT, auquel le contrôleur est abonné (sous- tâche SendGatewayMessage ).

Au stade de l'initialisation, le contrôleur de maison intelligente attend que l'utilisateur l'enregistre dans son compte personnel. Par conséquent, la sous-tâche CheckGatewayExistance est effectuée , qui vérifie l'état correspondant dans la base de données cloud MySQL. Pour vous inscrire dans votre compte personnel, le contrôleur envoie sa configuration complète au serveur de logique métier, qui à son tour diffuse son backend à l'application cliente (sous- tâche SendBackend ), qui crée et met à jour les enregistrements de configuration dans le cloud et les bases de données tactiles.

Lorsque le contrôleur domestique intelligent est enregistré avec succès dans le compte personnel de l'utilisateur, le serveur de logique métier charge le modèle utilisateur de la base de données cloud dans sa RAM et commence à traiter les messages des caméras IP et des capteurs Z-Wave conformément à l'algorithme de logique métier suivant.

Message JSON du capteur Z-Wave avec champs d'information:

{ "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-************" }

Lorsqu'un message du capteur Z-Wave arrive via le protocole MQTT, les sous-tâches suivantes sont effectuées:

  • StoreSensorDataMySQL met à jour (UPDATE) un enregistrement existant dans la base de données cloud MySQL, où les informations sur l'état actuel et les mesures du capteur sont stockées. Cela est nécessaire pour une application client qui affiche l'état actuel de la maison intelligente pour l'utilisateur;
  • StoreSensorDataInfluxDB ajoute (INSÉRER) un nouvel enregistrement à la base de données tactile InfluxDB, où l'historique des mesures du capteur est stocké. Ces informations sont utilisées dans le calcul des données statistiques pour différentes périodes (par exemple, la consommation d'énergie par jour, mois ou année) et affichées dans l'application client sous forme de graphiques et de tableaux;
  • SendPushNotification génère un message JSON contenant un horodatage, un nom de capteur, une description textuelle de l'événement, l'identifiant du smartphone de l'utilisateur avec lequel il est entré dans son compte personnel, l'identifiant interne de l'application dans le système du fournisseur OneSignal. De plus, ce message est envoyé au fournisseur de notifications push via l'API RESTful https://onesignal.com/api/v1/notifications , qui le transmet au smartphone de l'utilisateur.

Un exemple de message JSON d'une caméra IP avec des champs d'informations:

 { "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-************" }

Lorsqu'un message arrive de la caméra IP à l'aide du protocole MQTT, le serveur de logique métier extrait son type du champ messageType . Selon la valeur de ce champ, les actions suivantes sont effectuées:

  • "MessageType": "deviceState" - le message contient des informations sur le changement d'état de la caméra IP. La sous-tâche UpdateCameraState est effectuée , mettant à jour les informations dans la base de données cloud. Si le champ deviceState est streamingOn ou streamingOff (la caméra IP envoie / arrête le flux de données au serveur multimédia), la sous-tâche RecordMediaStream est exécutée , qui génère une commande pour activer / désactiver le mode d'enregistrement d'archive et l'envoie au serveur multimédia;
  • "MessageType": "sensorData" - informations sur le fonctionnement du détecteur de mouvement sur la caméra IP. Si dans le modèle utilisateur le mode d'enregistrement d'archive est réglé sur «par détecteur de mouvement», la sous-tâche RecordMediaStream est exécutée . Ensuite, les sous-tâches StoreSensorDataInfluxDB (sauvegarde de l'historique du détecteur dans la base de données tactile) et SendPushNotification (envoi de notifications push via le fournisseur) sont effectuées;
  • "MessageType": "aperçu" - le message contient un cadre d'une image miniature de la caméra IP, qui est périodiquement envoyée au cloud. La sous-tâche StorePreview l' enregistre dans une base de données cloud. Il est ensuite utilisé dans l'application client lors de l'affichage d'une liste de caméras;
  • "MessageType": "commande" - une commande envoyée par le contrôleur de maison intelligente lorsque l'utilisateur modifie ses paramètres via l'interface Web. La sous-tâche RecordMediaStream est exécutée , ce qui, selon le modèle utilisateur, active / désactive le mode d'enregistrement sur le serveur multimédia.


(cliquez sur l'image pour l'ouvrir en plus haute résolution)

À la suite du travail du module de logique métier, une file d'attente de tâches est formée - une séquence de sections minimales de code qui sont exécutées indépendamment les unes des autres. La file d'attente des tâches est transférée au pool de threads , qui répartit les tâches entre les cœurs libres du processeur central. Lorsqu'un verrouillage d'E / S se produit pendant l'exécution, le thread se met en pause et entre dans l'état inactif et libère le cœur du processeur central, ce qui permet au pool de threads de démarrer immédiatement la tâche suivante à partir de la file d'attente. Au moment où le verrou d'E / S est libéré, le thread bloqué passe à son état de fonctionnement et continue son exécution dès que l'un des cœurs du processeur central est libéré.

Ainsi, en décomposant la tâche de logique métier en de nombreuses sous-tâches distinctes qui sont exécutées simultanément, les performances du serveur de logique métier sont augmentées. La mise à l'échelle du système est obtenue en augmentant le nombre de cœurs du processeur central et en augmentant le nombre de serveurs de logique métier dans le système.

L'application serveur de logique métier est développée en C ++ et fonctionne comme le service systemd du système d'exploitation Linux Debian Sarge. Pour une surveillance supplémentaire des performances, le système de surveillance des ressources Monit est utilisé, ce qui redémarre le service en cas de problèmes de performances.

Actuellement, le service cloud exécute un serveur de logique métier s'exécutant sur la machine virtuelle cloud Yandex. Paramètres de la machine virtuelle - 4 cœurs vCPU avec une part garantie de 20%, 2 Go de RAM, 100 Go de disque dur. Selon les calculs, ces performances sont suffisantes pour traiter les messages de ~ 1000 contrôleurs de maison intelligente avec 3 caméras IP et 5 capteurs Z-Wave chacun (les calculs seront clarifiés pendant le fonctionnement du système).

Serveur multimédia


Un serveur multimédia est un serveur dédié sur lequel un logiciel spécial est installé pour:

  • recevoir des flux de données vidéo et audio à partir de dispositifs d'encodage en utilisant des protocoles réseau spécialisés;
  • stocker des données sous forme de fichiers d'archives dans son système de fichiers;
  • Diffusez des informations à partir de fichiers d'archives dans un format de streaming standard pour la lecture sur les appareils clients.

Le moteur de streaming Wowza 4.7.2 avec des modules supplémentaires développés en Java est utilisé comme serveur multimédia dans le système de maison intelligente cloud pour enregistrer des données de streaming dans une archive de fichiers et pour travailler avec une base de données cloud.


(cliquez sur l'image pour l'ouvrir en plus haute résolution)

Le flux multimédia du contrôleur de maison intelligente au format RTMP entre dans le serveur multimédia et est aligné avec les horodatages dans le tampon de gigue . Cela est nécessaire pour compenser l'effet des retards de paquets réseau lors de la transmission du flux de données sur Internet.

Pour enregistrer le flux vidéo sur le système de fichiers du serveur multimédia en tant que fichier MP4, le serveur de logique métier envoie la commande suivante au serveur multimédia via l'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" }

Le nom du flux vidéo (l'identifiant de la caméra IP sur le contrôleur de maison intelligente) est indiqué dans le champ recorderName , dans le champ fileVersionDelegateName est le nom de la classe héritée pour déterminer le chemin d'accès au dossier et le nom de fichier. Le code de classe Java est indiqué dans la liste suivante:

 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; } }

Dans la classe CustomFileVersionDelegate , la fonction virtuelle getFilename de la classe de base IStreamRecorderFileVersionDelegate est surchargée , qui est appelée par le serveur de médias avant que le flux ne commence à écrire dans le fichier. La fonction crée un dossier sur le disque avec le chemin d'accès sDirPath et renvoie le chemin d'accès complet au fichier sFullFilePath .

Le volume des données multimédias étant très important, le système de fichiers comprend plusieurs disques physiques de gros volume (8 à 12 To) montés en sous-répertoires. Le disque avec la plus grande quantité d'espace libre est sélectionné comme disque de destination pendant l'enregistrement. Pour un fonctionnement optimal du système de fichiers lors de l'accès au fichier, le chemin d'accès au dossier cible est formé comme suit:

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

où diskId est l'identifiant du disque (dossier monté),
cameraIdDivideBy200 - le résultat d'une division entière de l'identifiant de la caméra par 200,
streamUuid - identifiant de flux multimédia,
année, mois, jour - année, mois et jour d'enregistrement, respectivement.

Cela évite un grand nombre de sous-dossiers dans un dossier et, par conséquent, une baisse spectaculaire des performances de l'ensemble du système de fichiers avec une augmentation du nombre de caméras IP dans les maisons intelligentes nuageuses.

Les informations sur l'adresse IP du serveur multimédia, le chemin d'accès au fichier contenant les données multimédias, l'heure de début et de fin d'écriture dans le fichier sont stockées dans la base de données cloud, puis utilisées par l'application cliente pour afficher la chronologie d'archivage sur laquelle la vidéo peut être sélectionnée et lue.

Pour obtenir le flux vidéo, le frontal de l'application client accède au serveur multimédia, en envoyant les commandes suivantes via le protocole HTTP. Pour un flux vidéo "en direct":

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

Pour le flux vidéo archivé:

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

où fileName est le nom du fichier d'archive sur le disque,
offsetMs - décalage de lecture par rapport au début du fichier en millisecondes,
durationMs - durée de lecture en millisecondes.

Le serveur multimédia envoie un flux au format HLS , qui vous permet d'afficher la vidéo H.264 + AAC dans tous les navigateurs et appareils mobiles modernes avec les systèmes d'exploitation iOS et Android. Le packetizer HLS code le flux sous la forme de blocs séparés et l'envoie sur HTTP en réponse à une demande d'une application mobile.

Pour optimiser les coûts de stockage et l'accès aux fichiers d'archives, le serveur multimédia domestique intelligent cloud a été développé sur la plate-forme matérielle Supermicro CSE-825TQ, carte mère X8DT6, 2xCPU Intel Xeon E5645 2,4 GHz, 32 Go de RAM, 44 To HDD Adaptec AAC-RAID. Le serveur multimédia est installé en tant que serveur dédié sur le site d'hébergement et se connecte au canal Internet avec une largeur garantie de 400 Mbps. Les performances d'un serveur multimédia sont suffisantes pour traiter les flux multimédias de ~ 400 caméras IP avec le codec H.264, la résolution de trame 720p et le débit binaire de 1 Mbps.



En conséquence, afin de pouvoir traiter les flux de 1000 caméras IP, il est nécessaire d'installer 3 serveurs multimédias et de répartir uniformément la charge entre eux. Pour cela, un équilibreur de charge est utilisé, qui est connecté au serveur de médias Wowza Streaming Engine en tant que plug-in AddOn d'équilibrage de charge dynamique distinct. Cela distingue, en fait, l'équilibreur de charge (ou serveur d'origine ), qui reçoit périodiquement les métriques de performance des serveurs de médias finaux (ou serveurs de périphérie ) et, sur la base de ces informations, trouve le serveur le moins chargé dans le cluster.

Le contrôleur de maison intelligente accède à l'équilibreur via HTTP et reçoit en réponse l'adresse IP de ce serveur, à laquelle le contrôleur transmet le flux multimédia de la caméra IP via RTMP. La mesure des performances comprend le nombre de connexions établies avec les sources et les consommateurs de flux multimédias et la bande passante actuelle du canal Internet sur le serveur. Dans les paramètres de l'équilibreur, vous pouvez également spécifier le choix du serveur Edge, en tenant compte de sa position géospatiale, ce qui vous permet d'héberger des serveurs dans différentes villes et pays pour créer un réseau distribué pour la livraison de contenu CDN .

Base de données tactile


Comme mentionné précédemment dans l'article précédent, les lectures des capteurs Z-Wave, ainsi que l'état actuel et les événements des caméras IP sont envoyés au format JSON par le contrôleur de maison intelligente vers le cloud en utilisant le protocole MQTT. Le serveur de logique métier décode ces messages et exécute la sous-tâche StoreSensorDataInfluxDB , qui transmet les données à la base de données tactile via HTTP.


(cliquez sur l'image pour l'ouvrir en plus haute résolution)

La base de données des capteurs de la maison intelligente cloud est développée sur la base d' InfluxDB 1.7.x - un système de gestion de base de données open source pour travailler avec des séquences temporelles, qui est utilisé dans de nombreux projets de l'Internet des objets pour stocker des données provenant de capteurs et d'analyses. Les requêtes vers la base de données tactile sont générées dans le langage InfluxQL similaire au SQL traditionnel.

La durée de stockage des données dans la maison intelligente cloud est déterminée par le tarif sélectionné en fonction du modèle utilisateur. En raison de la différence significative dans la quantité de données vidéo et de données de capteur, leur durée de stockage sera différente. La taille de l'archive vidéo est mesurée en jours (7, 14, 30 jours à des taux différents) et la taille de l'archive de capteurs est mesurée en années (3, 5, 7 ans, respectivement). Par conséquent, pour chaque contrôleur de maison intelligente, lorsqu'il est enregistré dans le compte personnel de l'utilisateur, 2 bases de données distinctes avec différentes politiques de rétention sont créées dans la base de données tactile:

 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;

Le backend de l'application cliente est responsable de la création, de l'édition et de la suppression de la base de données à l'intérieur de la base de données tactile. Par exemple, si un utilisateur du cloud smart home modifie le tarif, le backend envoie les commandes suivantes pour apporter des modifications à la politique de stockage:

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

Lors de la suppression du contrôleur de maison intelligente du compte personnel de l'utilisateur, le backend supprime les bases de données correspondantes:

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

À la réception d'un message d'information du contrôleur de maison intelligente, le serveur de logique métier exécute une demande d'insertion de données dans la base de données tactile:

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

Un exemple de tableau avec les données des capteurs Z-Wave pour un contrôleur domestique intelligent:



L'une des fonctionnalités les plus utiles d'une maison cloud est le calcul de statistiques sur la base des données reçues. L'utilisateur doit connaître la température moyenne de la pièce ou la quantité d'électricité qu'il a dépensée par mois.

Le langage InfluxQL vous permet d'effectuer des requêtes à l'aide de fonctions analytiques . Par exemple, pour calculer la température moyenne d'une semaine, vous devez exécuter la requête suivante:

 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);

Les résultats de cette requête sont présentés dans le tableau:



Dans le prochain article, entièrement consacré à l'application client, nous examinerons en détail le calcul des statistiques pour différents paramètres et la construction de tableaux et de graphiques basés sur celui-ci.

Dans le système domestique intelligent cloud, le SGBD InfluxDB est déployé sur une machine virtuelle cloud Yandex avec les paramètres suivants: 4 cœurs vCPU avec une part garantie de 20%, 2 Go de RAM, 100 Go de disque dur. Selon les calculs de cette configuration, il suffit de stocker les données des capteurs de 3 000 caméras IP et 5 000 capteurs Z-Wave pendant 7 ans.

Conclusion


L'article a examiné l'architecture d'un service cloud pour une maison intelligente, l'algorithme d'un serveur de logique métier, l'architecture d'un serveur multimédia pour l'enregistrement, le stockage et la lecture de flux multimédias à partir de caméras IP, ainsi que l'architecture d'une base de données tactile pour stocker et analyser les données de capteurs de maison intelligente. Le système de service cloud fonctionne à la fois sur des serveurs dédiés et virtuels, pour une plus grande stabilité située sur différents sites d'hébergement. Le système est actuellement en cours d'essai.

Plus les données stockées dans le cloud sont anciennes, moins l'utilisateur y accède. Dans la prochaine version du service cloud, il est proposé d'utiliser le mécanisme d'amincissement (ou de suréchantillonnage) des données à l'aide d' InfluxDB Continuous Queries pour réduire la quantité de données stockées à l'aide de fonctions d'agrégation et, ainsi, augmenter la capacité de la base de données tactile.



De plus, dans la prochaine version du service cloud, un cluster de serveurs de logique métier sera implémenté selon le principe d'un cluster de serveurs de médias, discuté dans cet article. La figure montre l'architecture d'un tel cluster, où plusieurs serveurs de périphérie (dont chacun a un courtier MQTT distinct et un logiciel de serveur de logique métier) envoient des métriques de performances au serveur d'origine, qui calcule l'adresse IP du serveur le moins chargé. Cela vous permettra de faire évoluer le système dans une plus large mesure et de dépasser la limite actuelle de 1 000 maisons intelligentes.

Source: https://habr.com/ru/post/fr474700/

More articles:


All Articles