Envoi de downlinks

Un downlink est une trame envoyée du réseau vers un appareil : par exemple, un nouvel intervalle de remontée pour un capteur, ou « open » pour une vanne. Dans Hermetry, vous envoyez un downlink applicatif sous forme de commande avec la méthode lora.downlink. Vous fournissez vous-même les octets, tels que le constructeur de l’appareil les documente ; Hermetry ne les construit pas à partir de commandes nommées.

La commande lora.downlink

Paramètre	Obligatoire	Signification
`fPort`	Oui	Le port applicatif, de 1 à 223, tel que spécifié par le constructeur de l’appareil
`data`	Oui	La charge utile en hexadécimal (`"0100003C"`) ou en base64 (`"AQAAPA=="`) ; les deux donnent les mêmes octets. 1 024 caractères au maximum.
`confirmed`	Non	`true` demande à l’appareil d’accuser réception. Valeur par défaut : `false`.

{
  "method": "lora.downlink",
  "params": { "fPort": 10, "data": "0100003C", "confirmed": false }
}

Une commande dont les paramètres sont absents ou erronés n’est pas envoyée ; elle quitte la file avec le statut expirée.

Envoi

lora.downlink est une commande comme les autres : les règles générales de Envoi de commandes aux appareils s’appliquent.

Depuis la page de l’appareil : ajoutez lora.downlink au catalogue Commandes du profil LoRaWAN de l’appareil, avec des paramètres fixes ou modifiables et un niveau qui détermine qui peut l’envoyer. Envoyez-la ensuite depuis l’onglet Commandes de l’appareil. Une entrée de catalogue par action (par exemple « Remonter toutes les 10 minutes » avec ses octets fixes) est plus simple pour votre équipe que des octets bruts.

En méthode brute : sans entrée de catalogue, seuls les propriétaires peuvent l’envoyer.

Via l’API :

POST /tenant/<tenantId>/api/iot/devices/<deviceId>/rpc
Content-Type: application/json

{ "method": "lora.downlink", "params": { "fPort": 10, "data": "0100003C" }, "oneway": true, "persistent": true, "expiresInS": 86400 }

Depuis un flux : le bloc Envoyer une commande envoie une commande du catalogue à l’appareil du message.

Options recommandées :

Sens unique : un appareil LoRaWAN ne répond pas à une commande ; une commande bidirectionnelle attendrait une réponse qui n’arrive jamais et se terminerait en TIMEOUT.
Persistante, avec une expiration : un appareil de classe A peut ne pas émettre pendant un certain temps, et la commande doit alors attendre dans la file.

Moment de l’envoi

Classe	Moment
A	Lors de la prochaine remontée de l’appareil, dans sa fenêtre RX1 ou RX2. Un appareil qui remonte toutes les heures la reçoit jusqu’à une heure plus tard.
C	Immédiatement, sur le canal RX2, via la passerelle qui a entendu l’appareil en dernier, tant que sa dernière remontée a moins de 15 minutes. Sinon, à sa prochaine remontée.

Un seul downlink applicatif est envoyé par remontée d’un appareil de classe A. Lorsque d’autres sont en file, le serveur réseau positionne le drapeau « more data pending », qui demande à de nombreux appareils de réémettre rapidement. Voir Classes d’appareils A et C.

Taille

La charge utile doit tenir dans le débit de données de la fenêtre d’envoi, avec les éventuelles commandes MAC en attente pour l’appareil :

Débit de données	Charge utile max.
DR0–DR2	51 octets
DR3	115 octets
DR4–DR7	222 octets

Classe A : si elle ne tient pas cette fois, elle attend une remontée à un débit plus élevé. Une charge utile de plus de 222 octets ne pourra jamais être envoyée et quitte la file avec le statut expirée (payload_too_large).
Classe C : envoyée au débit de la RX2 (DR0 par défaut), donc 51 octets au maximum. Une charge plus grande quitte la file avec le statut expirée.

Downlinks confirmés

Avec "confirmed": true, l’appareil accuse réception lors de sa prochaine remontée.

Classe A : le serveur réseau la renvoie aux remontées suivantes jusqu’à réception de l’accusé, avec au total 3 envois maximum (paramètre de profil maxRetries).
Classe C : elle attend le délai du profil Downlink confirmé : attendre l’accusé de réception (secondes) (60 s par défaut), puis est renvoyée avec un nouveau compteur de trames, avec au total 3 envois maximum.
Sans accusé de réception après le dernier envoi, la commande quitte la file avec le statut expirée (no_ack).

Utilisez les downlinks confirmés uniquement pour les actions importantes. Chaque envoi utilise le duty cycle de la passerelle.

Résultats

Ce qui s’est passé	État de la commande
Une passerelle a émis le downlink	DELIVERED ; une commande à sens unique passe ensuite à SUCCESSFUL
L’expiration de la commande est passée avant son envoi	EXPIRED
Paramètres erronés ou charge utile trop grande, avant tout envoi	EXPIRED

Pour un downlink confirmé, l’état de la commande suit la première émission. L’accusé lui-même et les éventuels renvois apparaissent dans le journal des trames.

Le journal des trames affiche chaque downlink sous la forme Downlink, Envoyé via passerelle avec sa fenêtre (RX1, RX2 ou RXC) et son FPort. Une passerelle Basics Station ne signale pas les émissions échouées ; le compteur lora.gw.dn_unknown de la passerelle indique les downlinks sans résultat.

Downlinks que vous n’envoyez pas vous-même

Le serveur réseau envoie aussi les accusés de réception des uplinks confirmés, les join accept et les commandes MAC (ADR et paramètres radio). Ceux-ci n’apparaissent pas comme des commandes. Voir ADR, débits de données et commandes MAC.