Événements

Les événements sont asynchrones et gérés par Google Cloud Pub/Sub, dans un seul sujet, par Project. Les événements fournissent des mises à jour pour tous les appareils et toutes les structures. La réception des événements est assurée tant que le jeton d'accès n'est pas révoqué par l'utilisateur et que les messages d'événement n'ont pas expiré.

Activer les événements

Les événements sont une fonctionnalité facultative de l'API SDM. Consultez Activer les événements pour découvrir comment les activer pour votre Project.

Google Cloud Pub/Sub

Pour en savoir plus sur le fonctionnement de Pub/Sub, consultez la documentation de Google Cloud Pub/Sub. En particulier :

Abonnement à un événement

Lorsque les événements sont activés pour votre Project, un sujet spécifique à cet ID Project vous est fourni, sous la forme suivante:

projects/sdm-prod/topics/enterprise-project-id

Pour recevoir des événements, créez un abonnement pull ou push associé à ce sujet, selon votre cas d'utilisation. Vous pouvez souscrire plusieurs abonnements au sujet SDM. Pour en savoir plus, consultez Gérer les abonnements.

Lancer des événements

Pour lancer des événements pour la première fois une fois l'abonnement Pub/Sub créé, effectuez un appel d'API devices.list en tant que déclencheur unique. Les événements pour toutes les structures et tous les appareils seront publiés après cet appel.

Pour obtenir un exemple, consultez la page Autoriser du guide de démarrage rapide.

Ordre des événements

Pub/Sub ne garantit pas la diffusion ordonnée des événements, et l'ordre de réception des événements peut ne pas correspondre à l'ordre dans lequel ils se sont réellement produits. Utilisez le champ timestamp pour faciliter le rapprochement de l'ordre des événements. Les événements peuvent également arriver individuellement ou combinés dans un même message d'événement.

Pour en savoir plus, consultez la section Trier des messages.

ID utilisateur

Si votre implémentation est basée sur les utilisateurs (plutôt que sur la structure ou l'appareil), utilisez le champ userID de la charge utile de l'événement pour mettre en corrélation les ressources et les événements. Ce champ est un ID obscurci représentant un utilisateur spécifique.

userID est également disponible dans l'en-tête de réponse HTTP de chaque appel d'API.

Événements de relations

Les événements de relation représentent une mise à jour relationnelle d'une ressource. (par exemple, lorsqu'un appareil est ajouté à une structure ou qu'il est supprimé d'une structure).

Il existe trois types d'événements de relation:

  • CRÉÉ
  • DELETED
  • MISE À JOUR

La charge utile d'un événement de relation se présente comme suit:

Charge utile

{
  "eventId" : "3fc1d439-6822-4ce2-bec0-a67554629ceb",
  "timestamp" : "2019-01-01T00:00:01Z",
  "relationUpdate" : {
    "type" : "CREATED",
    "subject" : "enterprises/project-id/structures/structure-id",
    "object" : "enterprises/project-id/devices/device-id"
  },
  "userId": "AVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yi"
}

Dans un événement de relation, object est la ressource qui a déclenché l'événement, et subject est la ressource avec laquelle object est désormais en relation. Dans l'exemple ci-dessus, a user a accordé l'accès à cet appareil spécifique à un developer, et l'appareil autorisé de userest désormais associé à sa structure autorisée, ce qui déclenche l'événement.

Un élément subject ne peut être qu'une pièce ou une structure. Si a developer n'est pas autorisé à afficher la structure de user, subject est toujours vide.

Champs

Champ Description Type de données
eventId Identifiant unique de l'événement. string
Exemple: "42ed1dd5-94a1-4a35-a042-c49be24a1c69"
timestamp L'heure à laquelle l'événement s'est produit. string
Exemple: "2019-01-01T00:00:01Z"
relationUpdate Objet qui détaille des informations sur la mise à jour de la relation. object
userId Identifiant unique et obscurci qui représente l'utilisateur. string
Exemple: "AVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yi"

Consultez la page Événements pour en savoir plus sur les différents types d'événements et leur fonctionnement.

Exemples

Les charges utiles d'événement diffèrent pour chaque type d'événement de relation:

CREATED

Structure créée

"relationUpdate" : {
  "type" : "CREATED",
  "subject" : "",
  "object" : "enterprises/project-id/structures/structure-id"
}

Appareil créé

"relationUpdate" : {
  "type" : "CREATED",
  "subject" : "enterprises/project-id/structures/structure-id",
  "object" : "enterprises/project-id/devices/device-id"
}

Appareil créé

"relationUpdate" : {
  "type" : "CREATED",
  "subject" : "enterprises/project-id/structures/structure-id/rooms/room-id",
  "object" : "enterprises/project-id/devices/device-id"
}

MISE À JOUR

Appareil déplacé

"relationUpdate" : {
  "type" : "UPDATED",
  "subject" : "enterprises/project-id/structures/structure-id/rooms/room-id",
  "object" : "enterprises/project-id/devices/device-id"
}

DELETED

Structure supprimée

"relationUpdate" : {
  "type" : "DELETED",
  "subject" : "",
  "object" : "enterprises/project-id/structures/structure-id"
}

Appareil supprimé

"relationUpdate" : {
  "type" : "DELETED",
  "subject" : "enterprises/project-id/structures/structure-id",
  "object" : "enterprises/project-id/devices/device-id"
}

Appareil supprimé

"relationUpdate" : {
  "type" : "DELETED",
  "subject" : "enterprises/project-id/structures/structure-id/rooms/room-id",
  "object" : "enterprises/project-id/devices/device-id"
}

Les événements de relation ne sont pas envoyés dans les cas suivants:

  • Un salon est supprimé

Événements liés aux ressources

Un événement de ressource représente une mise à jour spécifique à une ressource. Elle peut intervenir en réponse à un changement de valeur d'un champ de caractéristique, comme un changement de mode d'un thermostat. Il peut également représenter une action de l'appareil qui ne modifie pas un champ de caractéristique, comme appuyer sur un bouton de l'appareil.

Un événement généré en réponse à une modification de la valeur du champ de caractéristique contient un objet traits, semblable à un appel GET d'appareil:

Charge utile

{
  "eventId" : "ca2ff605-9d12-43bd-8c9b-106739e7e777",
  "timestamp" : "2019-01-01T00:00:01Z",
  "resourceUpdate" : {
    "name" : "enterprises/project-id/devices/device-id",
    "traits" : {
      "sdm.devices.traits.ThermostatMode" : {
        "mode" : "COOL"
      }
    }
  },
  "userId": "AVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yi",
  "resourceGroup" : [
    "enterprises/project-id/devices/device-id"
  ]
}

Utilisez la documentation sur les caractéristiques individuelles pour comprendre le format de la charge utile pour tout événement de ressource de modification du champ de caractéristique.

Un événement généré en réponse à une action de l'appareil qui ne modifie pas de champ de caractéristique possède également une charge utile avec un objet resourceUpdate, mais avec un objet events au lieu d'un objet traits:

Charge utile

{
  "eventId" : "b1946dde-7383-4fc4-99c2-d35b1ed046ea",
  "timestamp" : "2019-01-01T00:00:01Z",
  "resourceUpdate" : {
    "name" : "enterprises/project-id/devices/device-id",
    "events" : {
      "sdm.devices.events.CameraMotion.Motion" : {
        "eventSessionId" : "CjY5Y3VKaTZwR3o4Y19YbTVfMF...",
        "eventId" : "k_LbjTNVqDgD4-p5iO6g2JSEYa...",
      }
    }
  }
  "userId" : "AVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yi",
  "eventThreadId" : "d67cd3f7-86a7-425e-8bb3-462f92ec9f59",
  "eventThreadState" : "STARTED",
  "resourceGroup" : [
    "enterprises/project-id/devices/device-id"
  ]
}

Ces types d'événements de ressource sont définis par des caractéristiques spécifiques. Par exemple, l'événement "Mouvement" est défini dans la caractéristique CameraMotion . Consultez la documentation de chaque caractéristique pour comprendre le format de la charge utile pour ces types d'événements de ressources.

Champs

Champ Description Type de données
eventId Identifiant unique de l'événement. string
Exemple: "b1946dde-7383-4fc4-99c2-d35b1ed046ea"
timestamp L'heure à laquelle l'événement s'est produit. string
Exemple: "2019-01-01T00:00:01Z"
resourceUpdate Objet qui détaille des informations sur la mise à jour de la ressource. object
userId Identifiant unique et obscurci qui représente l'utilisateur. string
Exemple: "AVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yi"
eventThreadId Identifiant unique du fil de discussion de l'événement. string
Exemple: "d67cd3f7-86a7-425e-8bb3-462f92ec9f59"
eventThreadState État du thread d'événement. string
Valeurs: "STARTED", "UPDATED", "ENDED"
resourceGroup Objet qui indique les ressources susceptibles d'avoir des mises à jour semblables à cet événement. La ressource de l'événement lui-même (à partir de l'objet resourceUpdate) sera toujours présente dans cet objet. object

Consultez la page Événements pour en savoir plus sur les différents types d'événements et leur fonctionnement.

Notifications pouvant être mises à jour

Les notifications basées sur des événements de ressources peuvent être implémentées dans une application, par exemple pour Android ou iOS. Pour réduire le nombre de notifications envoyées, vous pouvez implémenter une fonctionnalité appelée notifications pouvant être mises à jour. Elle permet de mettre à jour les notifications existantes avec de nouvelles informations basées sur les événements ultérieurs du même fil de discussion d'événements.

Certains événements sont compatibles avec les notifications pouvant être mises à jour et sont marqués comme Updateable  dans la documentation. Ces événements comportent un champ supplémentaire appelé eventThreadId dans leurs charges utiles. Utilisez ce champ pour associer des événements individuels afin de mettre à jour une notification existante qui s'affiche pour un utilisateur.

Un thread d'événement est différent d'une session d'événement. Le thread d'événement identifie l'état mis à jour d'un événement précédent dans le même thread. La session avec événement identifie des événements distincts liés les uns aux autres, et il peut y avoir plusieurs threads d'événements pour une session d'événement donnée.

À des fins de notification, différents types d'événements sont regroupés dans différents threads.

Cette logique de regroupement et de synchronisation des threads est gérée par Google et est susceptible d'être modifiée à tout moment. A developer doit mettre à jour les notifications en fonction des threads d'événements et des sessions fournis par l'API SDM.

État du thread

Les événements compatibles avec les notifications pouvant être mises à jour comportent également un champ eventThreadState qui indique l'état du thread d'événement à ce moment précis. Ce champ présente les valeurs suivantes:

  • DÉMARRÉ : premier événement d'un fil de discussion d'événement.
  • MISE À JOUR : événement dans un fil de discussion d'événement en cours. Il peut y avoir zéro ou plusieurs événements avec cet état dans un même thread.
  • ENDED : dernier événement d'un thread d'événement, qui peut être un doublon du dernier événement UPDATED, en fonction du type de thread.

Ce champ peut être utilisé pour suivre la progression d'un thread d'événement et sa date de fin.

Filtrage des événements

Dans certains cas, les événements détectés par un appareil peuvent être exclus de la publication dans un sujet Pub/Sub SDM. Ce comportement est appelé filtrage des événements. Le filtrage des événements vise à éviter de publier trop de messages d'événement similaires en peu de temps.

Par exemple, un message peut être publié dans un sujet SDM pour un événement "Motion" initial. Par la suite, les autres messages concernant Motion seront exclus de la publication jusqu'à ce qu'une période définie soit écoulée. Une fois ce délai écoulé, un message d'événement pour ce type d'événement peut être publié à nouveau.

Dans l'application Google Home, les événements filtrés continuent de s'afficher dans l'historique des événements de user. Toutefois, de tels événements ne génèrent pas de notification d'application (même si ce type de notification est activé).

Chaque type d'événement possède sa propre logique de filtrage des événements, définie par Google et susceptible d'être modifiée à tout moment. Cette logique de filtrage des événements est indépendante du thread d'événements et de la logique de session.

Comptes de service

Les comptes de service sont recommandés pour gérer les abonnements à l'API SDM et les messages d'événement. Un compte de service est utilisé par une application ou une machine virtuelle, et non par une personne, et possède sa propre clé de compte unique.

L'autorisation de compte de service pour l'API Pub/Sub utilise l'authentification OAuth à deux acteurs (2LO).

Dans le flux d'autorisation 2LO:

  • Le developer demande un jeton d'accès à l'aide d'une clé de service.
  • developer utilise le jeton d'accès avec des appels à l'API.

Pour en savoir plus sur Google 2LO et sur sa configuration, consultez la page Utiliser OAuth 2.0 pour les applications de serveur à serveur.

Autorisation

Le compte de service doit être autorisé à être utilisé avec l'API Pub/Sub:

  1. Activez l'API Cloud Pub/Sub dans Google Cloud.
  2. Créez un compte de service et une clé de compte de service comme décrit dans la section Créer un compte de service. Nous vous recommandons de ne lui attribuer que le rôle Abonné Pub/Sub. Veillez à télécharger la clé du compte de service sur la machine qui utilisera l'API Pub/Sub.
  3. Fournissez vos identifiants d'authentification (clé de compte de service) à votre code d'application en suivant les instructions de la page précédente, ou obtenez un jeton d'accès manuellement à l'aide de oauth2l si vous souhaitez tester rapidement l'accès à l'API.
  4. Utilisez les identifiants du compte de service ou le jeton d'accès avec l'API project.subscriptions Pub/Sub pour extraire et confirmer les messages.

OAuth2L

Google oauth2l est un outil de ligne de commande pour OAuth écrit en Go. Installez-le pour Mac ou Linux à l'aide de Go.

  1. Si vous n'avez pas installé Go sur votre système, téléchargez d'abord et installez-le.
  2. Une fois que Go est installé, installez oauth2l et ajoutez son emplacement à votre variable d'environnement PATH :
    go install github.com/google/oauth2l@latest
export PATH=$PATH:~/go/bin
  3. Utilisez oauth2l pour obtenir un jeton d'accès pour l'API, en utilisant le ou les champs d'application OAuth appropriés : 
    oauth2l fetch --credentials path-to-service-key.json --scope https://www.googleapis.com/auth/pubsub
https://www.googleapis.com/auth/cloud-platform
    Par exemple, si votre clé de service se trouve à l'emplacement ~/myServiceKey-eb0a5f900ee3.json : 
    oauth2l fetch --credentials ~/myServiceKey-eb0a5f900ee3.json --scope https://www.googleapis.com/auth/pubsub
https://www.googleapis.com/auth/cloud-platform
ya29.c.Elo4BmHXK5...

Pour en savoir plus sur son utilisation, consultez le fichier README oauth2l.

Bibliothèques clientes pour les API Google

Plusieurs bibliothèques clientes sont disponibles pour les API Google qui utilisent OAuth 2.0. Pour en savoir plus sur le langage de votre choix, consultez la page Bibliothèques clientes des API Google.

Lorsque vous utilisez ces bibliothèques avec Pub/Sub API, utilisez la ou les chaînes de champ d'application suivantes :

https://www.googleapis.com/auth/pubsub
https://www.googleapis.com/auth/cloud-platform

Erreurs

Le ou les codes d'erreur suivants peuvent être renvoyés en rapport avec ce guide:

Message d'erreur RPC Dépannage
L'image de l'appareil photo n'est plus disponible au téléchargement. DEADLINE_EXCEEDED Les images d'un événement expirent 30 secondes après leur publication. Veillez à télécharger l'image avant qu'elle n'expire.
L'ID d'événement n'appartient pas à la caméra. FAILED_PRECONDITION Utilisez le bon eventID renvoyé par l'événement enregistré.

Consultez la documentation de référence sur les codes d'erreur de l'API pour obtenir la liste complète des codes d'erreur de l'API.