Maintenant que vous connaissez les principaux composants de Weave, examinons comment certaines de ses fonctionnalités sont gérées dans les grandes lignes.
La quasi-totalité des fonctionnalités de l'écosystème Nest pour un fonctionnement quotidien est mappée aux ressources et aux caractéristiques du schéma Weave. Le profil de gestion des données business_center gère toutes les requêtes de caractéristiques à l'aide d'un modèle publish-subscribe. Il s'agit de messages spécifiques au profil de gestion des données.
Dans ce type de modèle, un éditeur fait la promotion des caractéristiques (données à regarder) et un abonné réagit aux évolutions de ces caractéristiques publiées (données regardées).
Cette fonction est appelée gestion des caractéristiques en temps réel .
Le profil de gestion des données est la base de Weave. Il est généralement appelé "Wave Data Management" (WDM).
Requêtes
Les requêtes settings_backup_restore sont un élément clé de la gestion des caractéristiques en temps réel de WDM. Les requêtes sont des requêtes d'action standards d'une caractéristique, avec une réponse attendue. Elles sont différentes des commandes d'une caractéristique car elles ne sont pas et ne peuvent pas être définies dans un schéma, et ne sont pas spécifiques à une caractéristique.
Il existe trois types de requêtes standards:
Informez flare la requête standard qui informe un abonné de l'état d'une propriété de attribut ou d'un événement spécifique lié à cette caractéristique.Mettre à jour filter_center_focus La requête standard permet de modifier l'état d'une propriété de caractéristique.View filter_tilt_shift Requête standard pour afficher les propriétés d'une caractéristique.
Remarque :Les deux propriétés adjust et les événements control_camera du schéma sont fournies dans le cadre d'une requête not .
Rôles du protocole
Il existe deux types de rôles pour le protocole WDM: l'éditeur et l'abonné. Ces rôles sont attribués au niveau des caractéristiques.
Point clé :Un éditeur est la source de vérité pour les données pour une caractéristique particulière et est déterminé par un schéma de ressources. Éditeur
Le rôle Publisher WDM produit et diffuse des instances gérées pour un ou plusieurs schémas à un ou plusieurs abonnés, et envoie des notifications sur les modifications apportées au schéma aux abonnés intéressés. Ces notifications sont des notifications standards.
Par exemple, supposons que le circuit A soit publié par la ressource 1 et abonné à la ressource 2. Comme illustré dans la Figure 1 , si la priorité A change:
WDM envoie une requête notify (flare ) de la ressource 1 à tous les abonnés de la piste A, pour les informer de ce changement.
Chaque abonné met à jour son instance de la piste A en conséquence.
Figure 1 : Demandes des éditeurs WDM
Sur les schémas Openweave.io, les éditeurs de caractéristiques sont représentés par des blocs surélevés en gris clair.
Il en va de même pour les autres caractéristiques du schéma. Par exemple, si la ressource 2 publie la ligne B, la ressource 1 s'abonne à la session B et cette modification:
WDM envoie une requête notify (flare ) de la ressource 2 à tous les abonnés du Trait B pour les informer de la modification.
Chaque abonné met à jour son instance de la Trait B en conséquence.
Abonné
Le rôle subscriber de WDM affiche et utilise les instances multiversions d'un ou de plusieurs schémas publiés en externe. Elle peut modifier l'instance multiversion d'un schéma publié avec une requête update ou exécuter une commande spécifique à l'application.
Remarque : Une commande est utilisée pour les requêtes qui ne peuvent pas être réalisées par une requête standard. Par exemple, supposons que la ressource 2 souhaite modifier le circuit A, publié par la ressource 1. Comme illustré dans la Figure 2 , pour modifier le circuit A:
WDM envoie une mise à jour filter_center_focus de la ressource 2 à la ressource 1 pour demander une modification de la ligne A.
La ligne A de la ressource 1 a été modifiée.
WDM envoie une requête notify (flare ) de la ressource 1 à tous les abonnés de la piste A, pour les informer de ce changement.
Chaque abonné met à jour son instance de la piste A en conséquence.
Figure 2 : Demandes d'abonnés WDM
Les abonnés peuvent également envoyer une requête view filter_tilt_shift à un éditeur de attribut, pour afficher les propriétés adjust de ce trait et garder leurs propres instances des caractéristiques synchronisées avec l'éditeur.
Types d'abonnements
Il existe deux types d'abonnements WDM. Les abonnements sont établis à l'aide d'une requête bookmark_border subscribe .
La figure 3 illustre le flux de messages de base pour établir un abonnement à sens unique.
Figure 3 : abonnement unidirectionnel à WDM
Aller simple
Les abonnements à sens unique impliquent une requête envoyée par un abonné à un éditeur pour une ou plusieurs instances de caractéristiques. Par exemple, un appareil mobile peut récupérer l'état de la maison (structure) à partir d'un service.
Mutuel
On parle d'abonnements mutuels lorsque des ressources s'abonnent, et qu'elles servent à la fois d'éditeur et d'abonné. Nest Guard et Nest Detect font partie de ce système. Un abonnement mutuel permet de gérer le schéma publié, et de préserver l'état et la vivacité de l'abonnement de manière plus efficace que deux abonnements à sens unique.
Exemple
Voyons comment WDM traite une modification des paramètres régionaux d'un appareil à l'aide d'une application mobile.
Cet exemple montre trois ressources et deux caractéristiques, comme le montre la figure 4 :
Appareil all_out (abonné)
Service all_out (éditeur)
Application mobile all_out (abonné)
Fonctionnalité grain Les paramètres régionaux
adjust La propriété des paramètres régionaux disponibles
grain Attribut de paramètres régionaux
adjust Propriété Active Local
Remarque :Des modèles de données spécifiques aux applications peuvent être appliqués aux caractéristiques. Les modèles de données des produits Nest incluent les fonctionnalités, les paramètres et l'état. Les deux caractéristiques sont publiées par la ressource "Service" et auxquelles elles sont abonnées par les ressources "Appareil" et "Application mobile". Chaque abonné fonctionne comme un abonnement unidirectionnel aux éditeurs de fonctionnalités sur la ressource Service.
Toutes les ressources de cet exemple font partie de la même toile Weave texture .
Figure 4 – Exemple WDM
Procédure de mise à jour
Imaginons que l'utilisateur utilise son application mobile pour modifier les paramètres régionaux de l'appareil de en_US à fr_FR en utilisant une application mobile connectée. Comme illustré dans la Figure 5 , le flux de mise à jour dans WDM est:
La ressource d'application mobile (abonné) envoie une requête update à filter_center_focus la ressource de service (éditeur) pour modifier la propriété "Locale" du paramètre "Paramètres régionaux" sur "fr_FR, l'une des valeurs valides de la propriété "Paramètres régionaux" disponible de la propriété "Locales".
La ressource de service modifie la propriété "Locale" active de la caractéristique "Paramètres régionaux" dans sa copie du schéma.
La ressource de service envoie une requête de notification flare à propos de la modification à tous les abonnés de la caractéristique Paramètres régionaux.
Les ressources de l'appareil et de l'application mobile (abonnés) reçoivent toutes les deux la requête notée flare et mettent à jour la propriété "Locale" du paramètre "Locale Settings" dans leurs copies du schéma.
Figure 5 : Flux de mise à jour de WDM
Avantages de WDM
Cela peut s'avérer très compliqué lorsque vous souhaitez simplement modifier les paramètres régionaux de votre appareil à partir d'une application mobile. Mais en encapsulant le schéma avec versions gérées, le schéma "publish-subscribe" et les requêtes dans le profil WDM, Weave assure l'intégrité des données sur toutes les ressources.
Elle assure également l'activité. Ainsi, lorsqu'un appareil est redémarré, il en informe immédiatement tous les abonnés de l'état de ses caractéristiques publiées, observe l'état des caractéristiques abonnées et reflète tous ces états dans sa copie du schéma sans perte de fonctionnalité.
Au-delà des abonnements
Si une ressource se désabonne d'une caractéristique, elle conserve une copie de la dernière version connue de cette caractéristique. Il ne reçoit plus les requêtes notify flare de l'éditeur pour cette caractéristique, mais il peut toujours envoyer des requêtes update à cet éditeur.
Même les ressources qui n'ont jamais été abonnées à un éditeur de caractéristiques peuvent leur envoyer des requêtes. Par exemple, il est possible qu'une ressource n'ait pas besoin de connaître l'état d'une caractéristique en particulier, mais qu'elle souhaite envoyer des requêtes update pour modifier l'état de cette caractéristique en réponse à un événement externe.
Récapitulatif
Dans cet atelier, vous avez appris à effectuer les opérations suivantes :
Weave Data Management (WDM) business_center est le profil Weave pour la gestion des caractéristiques en temps réel qui garantit l'activité et l'intégrité des données sur toutes les ressources
Les requêtes settings_backup_restore sont des requêtes standards pour une action sur une caractéristique, avec une réponse attendue
WDM possède deux rôles de protocole :
Éditeur : la source d'informations pour une caractéristique spécifique envoie des requêtes à flare
Abonné : observe le schéma publié, envoie des requêtes filter_tilt_shift update filter_center_focus ou command center_focus_weak
WDM propose deux modèles d'abonnement :
Sens unique : flux de requêtes entre les abonnés et l'éditeur
Mutuel : les appareils s'abonnent
Les abonnements sont établis par les demandes d'abonnement
bookmark_border
Les ressources peuvent envoyer des messages WDM à des caractéristiques même si elles ne sont pas abonnées à ces caractéristiques.
Pour en savoir plus:
