Lire les transactions

Lire la transaction

L'un des premiers cas d'utilisation en cas d'interaction avec des nœuds dans Matter est la lecture d'un attribut à partir d'un autre nœud, comme une valeur de température à partir d'un capteur. Dans de telles interactions, la première action à effectuer est l'action de demande de lecture.

Séquence des opérations d'une transaction de lecture
Figure 1: Transaction de lecture

Action de demande de lecture

Direction: initiant -> Target

Dans cette action, l'initiateur interroge une cible en fournissant:

  • Requêtes d'attribut: liste de zéro, un ou plusieurs attributs de la cible. Cette liste est composée de zéro, un ou plusieurs chemins d'accès aux attributs demandés par la cible.
  • Requêtes d'événement: liste de zéro, un ou plusieurs chemins d'accès aux événements demandés par la cible.

Une fois que la cible a reçu l'action de demande de lecture, elle assemble une action de données de rapport avec les informations demandées.

Action sur les données de rapport

Direction: Cible -> Déclencheur

Dans cette action, la cible répond avec:

  • Rapports sur les attributs: une liste de zéro, un ou plusieurs attributs signalés demandés dans la requête d'action de lecture.
  • Rapports sur les événements: liste de zéro ou plusieurs événements enregistrés.
  • Supprimer la réponse: indicateur déterminant si la réponse d'état à cette action doit être supprimée.
  • ID d'abonnement: si ce rapport fait partie d'une transaction d'abonnement, il doit inclure un entier permettant d'identifier la transaction.

Action de réponse d'état

Direction: Target -> initator (Initiateur) -> Target (Cible)

Une fois que l'initiateur a reçu les données demandées, il doit générer par défaut une action de réponse d'état. Cette action est envoyée par l'initiateur, accusant réception des données signalées. Si l'option Suppress Status Response est définie, l'initiateur ne doit pas envoyer l'action de réponse d'état.

Une fois que l'initiateur de la requête d'état envoie l'action de réponse d'état ou qu'il reçoit une action de données de rapport avec l'indicateur de suppression de réponse activé, la requête de lecture/de rapport est terminée.

L'action de réponse d'état contient simplement un champ status qui confirmera la réussite de l'opération ou présentera un code d'échec.

Restrictions de lecture

L'action de requête de lecture et l'action de données de rapport sont des actions de type Unicast uniquement. De plus, les chemins d'accès de ces requêtes ne peuvent pas cibler un groupe de nœuds.

L'action de réponse d'état est de type Unicast uniquement et ne peut pas être générée en tant que réponse à un enregistrement de groupe.

Transaction d'abonnement

Séquence des opérations d'une transaction d'abonnement
Figure 2: Transaction d'abonnement

Action de demande d'abonnement

Direction: initiant -> Target

En plus d'une action de requête de lecture unique, un créateur peut également s'abonner aux mises à jour périodiques d'un attribut ou d'un événement. Ainsi, la même action de données de rapport peut être générée à la suite de mises à jour périodiques de données qui suivent une transaction d'abonnement.

Une interaction d'abonnement crée une relation entre deux nœuds, dans lequel la cible génère périodiquement des actions dans les données de rapport à l'initiateur de la demande. L'initiateur est l'abonné et la cible est l'éditeur.

Une action de demande d'abonnement contient:

  • Min Interval Floor (Intervalle minimal entre les rapports) : intervalle minimal entre les rapports.
  • Intervalle maximal entre les rapports: intervalle maximal entre les rapports.
  • Rapports sur les attributs: une liste de zéro, un ou plusieurs attributs signalés demandés dans la requête d'action de lecture.
  • Rapports sur les événements: liste de zéro ou plusieurs événements signalés.

Après la requête d'abonnement, la cible répond à l'initiateur avec une action de données de rapport contenant le premier lot de données signalées: les données publiées préparées.

L'initiateur confirme ensuite l'action concernant les données de rapport et envoie une action de réponse d'état à la cible. Une fois que la cible reçoit une action de réponse d'état ne signalant aucune erreur, elle envoie une action de réponse d'abonnement.

La cible enverra ensuite régulièrement l'action de données de rapport à l'intervalle négocié, et l'initiateur de la réponse répondra à ces actions jusqu'à ce que l'abonnement soit perdu ou résilié.

Action de réponse "S'abonner"

Direction: Cible -> Déclencheur

Il s'agit de la dernière action de la transaction d'abonnement et le processus conclut. Voici les sujets abordés :

  • ID d'abonnement: entier qui identifie l'abonnement.
  • Min Interval (Intervalle minimal) : intervalle minimal final, déterminé entre les rapports.
  • Max Interval (Intervalle maximal) : intervalle maximal final, déterminé entre les rapports.

Restrictions relatives à l'abonnement

  • Les actions de requête d'abonnement et de réponse d'abonnement sont des actions de type Unicast uniquement.
  • Toutes les actions liées aux données de rapport dans une interaction d'abonnement doivent avoir le même ID d'abonnement.
  • Si l'abonné ne reçoit pas d'action de données de rapport dans l'intervalle maximal négocié entre les actions, l'abonnement est résilié.
  • En raison de la règle précédente, l'Éditeur peut mettre fin à une interaction d'abonnement en arrêtant simplement d'envoyer des actions périodiques liées aux données de rapport.
  • L'abonné peut mettre fin à l'interaction avec l'abonnement en répondant à une action de données de rapport avec un code d'état INACTIVE_SUBSCRIPTION.