Ein Downlink ist ein Frame vom Netzwerk zu einem Gerät, zum Beispiel ein neues Meldeintervall für einen Sensor oder „open“ für ein Ventil. In Hermetry senden Sie einen Application-Downlink als Command mit der Methode lora.downlink. Die Bytes geben Sie selbst an, so wie der Gerätehersteller sie dokumentiert; Hermetry erzeugt sie nicht aus benannten Commands.
Der Command lora.downlink
| Parameter | Pflichtfeld | Bedeutung |
|---|---|---|
fPort | Ja | Der Application-Port, 1–223, wie vom Gerätehersteller vorgegeben |
data | Ja | Die Nutzdaten als Hexadezimal ("0100003C") oder Base64 ("AQAAPA=="); beide ergeben dieselben Bytes. Höchstens 1.024 Zeichen. |
confirmed | Nein | true bittet das Gerät um eine Bestätigung. Standard false. |
{
"method": "lora.downlink",
"params": { "fPort": 10, "data": "0100003C", "confirmed": false }
}
Ein Command mit fehlenden oder falschen Parametern wird nicht gesendet; er verlässt die Warteschlange als abgelaufen.
Senden
lora.downlink ist ein Command wie jedes andere, daher gelten die allgemeinen Regeln unter Befehle an Geräte senden.
Von der Geräteseite: Fügen Sie lora.downlink dem Katalog Commands des LoRaWAN-Profils des Geräts hinzu, mit festen oder editierbaren Parametern und einer Stufe, die bestimmt, wer es senden darf. Senden Sie es dann über den Tab Commands des Geräts. Ein Katalogeintrag pro Aktion (zum Beispiel „Report every 10 minutes“ mit seinen festen Bytes) ist für Ihr Team einfacher als rohe Bytes.
Als reine Methode: Ohne Katalogeintrag dürfen nur Owner es senden.
Über die 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 }
Aus einem Flow: Der Block Send command sendet einen Katalog-Command an das Gerät der Nachricht.
Empfohlene Optionen:
- One-way: Ein LoRaWAN-Gerät antwortet nicht auf einen Command; ein Two-way-Command würde auf eine Antwort warten, die nie kommt, und mit TIMEOUT enden.
- Persistent, mit Ablaufzeit: Ein Class-A-Gerät sendet eine Zeit lang möglicherweise nicht, daher muss der Command in der Warteschlange warten.
Wann er gesendet wird
| Class | Zeitpunkt |
|---|---|
| A | Beim nächsten Uplink des Geräts, in seinem RX1- oder RX2-Fenster. Ein Gerät, das stündlich meldet, erhält ihn bis zu eine Stunde später. |
| C | Sofort, auf dem RX2-Kanal, über das Gateway, das das Gerät zuletzt gehört hat, sofern dessen letzter Uplink weniger als 15 Minuten alt ist. Andernfalls beim nächsten Uplink. |
Pro Uplink eines Class-A-Geräts wird nur ein Application-Downlink gesendet. Sind weitere in der Warteschlange, setzt der Network Server das Flag „more data pending“, das viele Geräte bittet, bald erneut zu senden. Siehe Geräteklassen A und C.
Größe
Die Nutzdaten müssen in die Datenrate des Fensters passen, in dem sie gesendet werden, zusammen mit allen MAC-Commands, die auf das Gerät warten:
| Datenrate | Maximale Nutzlast |
|---|---|
| DR0–DR2 | 51 Bytes |
| DR3 | 115 Bytes |
| DR4–DR7 | 222 Bytes |
- Class A: Passt es diesmal nicht, wartet es auf einen Uplink mit einer schnelleren Datenrate. Eine Nutzlast über 222 Bytes kann nie gesendet werden und verlässt die Warteschlange als abgelaufen (
payload_too_large). - Class C: Gesendet wird mit der RX2-Datenrate (standardmäßig DR0), also höchstens 51 Bytes. Eine größere verlässt die Warteschlange als abgelaufen.
Bestätigte Downlinks
Mit "confirmed": true bestätigt das Gerät im nächsten Uplink.
- Class A: Der Network Server sendet es bei den nächsten Uplinks erneut, bis die Bestätigung eintrifft, insgesamt bis zu 3 Sendungen (Profileinstellung
maxRetries). - Class C: Es wartet die im Profil eingestellte Zeit Confirmed downlink: wait for the acknowledgement (seconds) (standardmäßig 60 s) und sendet dann mit einem neuen Frame-Counter erneut, insgesamt bis zu 3 Sendungen.
- Bleibt nach der letzten Sendung eine Bestätigung aus, verlässt der Command die Warteschlange als abgelaufen (
no_ack).
Verwenden Sie bestätigte Downlinks nur für wichtige Aktionen. Jede Sendung belegt die Duty Cycle des Gateways.
Ergebnisse
| Was passiert ist | Command-Status |
|---|---|
| Ein Gateway hat den Downlink gesendet | DELIVERED; ein One-way-Command endet dann als SUCCESSFUL |
| Die Ablaufzeit des Commands ist verstrichen, bevor er gesendet werden konnte | EXPIRED |
| Falsche Parameter oder zu große Nutzlast, bevor er je gesendet wurde | EXPIRED |
Bei einem bestätigten Downlink folgt der Status des Commands der ersten Übertragung. Die Bestätigung selbst und alle erneuten Sendungen erscheinen im Frames-Log.
Das Frames-Log zeigt jeden Downlink als Downlink, Sent via gateway mit seinem Fenster (RX1, RX2 oder RXC) und seinem FPort. Ein Basics-Station-Gateway meldet fehlgeschlagene Übertragungen nicht; der Zähler lora.gw.dn_unknown des Gateways zeigt Downlinks ohne Ergebnis.
Downlinks, die Sie nicht selbst senden
Der Network Server sendet außerdem Bestätigungen bestätigter Uplinks, Join Accepts und MAC-Commands (ADR und Funkeinstellungen). Diese erscheinen nicht als Commands. Siehe ADR, Datenraten und MAC-Commands.

