Respond with a downlink
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
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.
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.
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:
- The contract is not bidirectional. Nothing else matters if this is wrong.
- The callback is not the bidirectional kind. A plain
DATA_UPLINKhas no reply channel. - The rule did not match. Check the conditions, and whether an earlier rule with Stop ran first.
- The value is not 16 hex characters. Check the field the rule reads.
- The bridge sink timed out, or answered without the named field.