Guides

Respond with a downlink

Answer a device in the same exchange that carried its uplink.

Most traffic flows left to right. A downlink goes back: the device asks a question with its uplink, and the answer travels home in the reply to that same callback.

This is the one place the pipeline runs backwards, and it is time-critical — the device is waiting.

What has to be true first

The device must be on a bidirectional contract
On Sigfox, a device type whose contract is not bidirectional cannot carry downlinks at all. The contract is fixed when the device type is created and cannot be changed afterwards. Check this before debugging anything else — no amount of correct configuration works around it.

You also need the uplink to be the kind that expects an answer. For Sigfox that is a DATA_BIDIR callback.

Set up the rule

Flow → Rules → New rule. Match the uplinks that should be answered — usually on messageType — and choose Respond with downlink.

Then pick where the answer comes from.

Where the answer comes from

The Center computes it

The Center returns a downlink you define: either a constant, or a value read from a field on the message.

Constant hex
The same 8-byte answer every time. Right for an acknowledgement or a fixed command.
From a field
A dot-path into the message, e.g. decoded.cmdHex. Lets a decoder work out the answer from what the device sent.

Reading from a field is the more useful of the two: your decoder can inspect the uplink and produce the correct response, and the rule just forwards it.

Bridge to a sink

The Center forwards the uplink to a sink you choose, waits for its JSON reply, and returns the hex from a named field in that reply.

This is for when your own system decides the answer — a server that knows the meter's schedule, or holds a pending command queue.

It comes with a timeout. If the sink does not answer in time, no downlink is returned and the device gets nothing.

Keep the bridge fast
The device is holding its receive window open. A bridge sink that takes seconds to think will miss it. Set the timeout to something the device can actually wait for, and make sure the sink answers well inside it.

The format

A Sigfox downlink is 16 hex characters — 8 bytes. Not more, not less.

Whether it is a constant, read from a field, or returned by a bridge sink, that is what has to come out. A field holding the wrong length is a common cause of "the rule matched but nothing arrived".

First match wins

If several rules could produce a downlink, the first one that matches provides it. Later downlink rules are ignored for that message.

So order downlink rules from most specific to most general, exactly as with any other rule.

Delivery still happens

Answering with a downlink does not stop the uplink being delivered to your sinks. The two are independent: the device gets its answer, and your systems still get the reading.

If you want a downlink instead of delivery, add a rule that drops the message after the downlink rule has run.

When nothing comes back

In order of likelihood:

  1. The contract is not bidirectional. Nothing else matters if this is wrong.
  2. The callback is not the bidirectional kind. A plain DATA_UPLINK has no reply channel.
  3. The rule did not match. Check the conditions, and whether an earlier rule with Stop ran first.
  4. The value is not 16 hex characters. Check the field the rule reads.
  5. The bridge sink timed out, or answered without the named field.

Next

Filter with rules
Rule ordering, stop-on-match and the other actions.
When delivery fails
Diagnosing the outbound side.
Copyright © 2026