Sending a MAC Command to a device using 'ttnctl downlink'

TTN Network and Services v2 Backend
1

I’ve tried to send a MAC Command (Sample MAC Command for DevStatusReq : 0x06 ) using a ttnctl command as follows:

ttnctl downlink <my-dev-id> --fport 0  06

I thought by specifying the fport as ‘0’, 0x06 will be handled as a MAC command. But what shows on the device AT command window is the following:

>fport=1
>rxmsg=06

This means the device has received the downlink message as an ordinary data on ‘Fport 1’, not as a MAC command.

Is it expected to work this way? Or, should it be donwlinked as a MAC command?

2

I found this issue was filed as a bug and was reported as fixed on May 1st, 2017.

But, the result shows the bug hasn’t been fixed yet as of ttn v2.7.1. The ‘fport=0’ is still changed to ‘fport=1’ in the downlink message process.

See this posting for reference on filing this issue as a bug.

3

It is not possible to send MAC commands from the application layer. In the future we will add functionality to schedule (a subset of) MAC commands

4

What would be the time frame to implement this function? By the end of 2017? Or, earlier than that?

5

Are you going to add a possibility to send MAC commands in FOpt field?

6

It’s really hard to make estimates for release dates of new features. We already have a large backlog of backend features and as there are hardly any outside (community) contributions to our open source backend, all of these tasks fall on the shoulders of the core team. That’s not a problem for us, but it asks some patience from our users.

7

I see. It is very understandable. I always appreciate the good work of your team.

8

I am wondering if this is already fixed? I am trying to do downlink messages via the console, but it doesn’t respect the port settings. It will change it to something else when entering port = 0.

Furthermore I try to use it via the ttnctl, but I don’t manage to get the downlink to show up in the console at all. Here are my settings (.ttnctl.yml):

discovery-address: discover.thethingsnetwork.org:1900
auth-server: https://account.thethingsnetwork.org
router-id: ttn-router-asia-se
handler-id: ttn-handler-asia-se
mqtt-address: asia-se.thethings.network:1883

I am running the following command

ttnctl downlink <dev_id> --fport 0 0300ff0001

I also tried it via HTTP but didn’t manage to get any downlink through at all. I tried the following command:

curl -i -X POST --data '{"dev_id":"2604273B", "payload_raw":"AwD/AAE=", "port" : 0 }' https://integrations.thethingsnetwork.org/ttn-asia-se/api/v2/down/[app_id]/[process_id]?key=[app_key]

Response was a 202 success.

I know the device is able to receive the downlink messages as via the console they arrive, I just need to have the FPORT being set properly, which isn’t the case now.

Cheers

9

I guess you’re asking about sending MAC commands as per this topic’s title, but just to be sure: what “fix” are you expecting? As noted:

But if you’re referring to the (fixed) bug mentioned above: that was about ADR as generated by TTN (and limited to the case where no application downlink was included).

Application downlinks, like you can send using ttnctl downlink, should not use port 0.

When transmitted as a MAC command, 0x03 would decode to a LinkADRReq and the next 4 bytes would be the requested settings. However, I think that ADR changes should be controlled by the network operator only, so would probably not be part of the allowed subset mentioned in:

(Also, I don’t think the above has been implemented, which I guess is what you’re asking.)

So, TTN rightfully assumes your 0x0300ff0001 is an application-level downlink, which should not use port 0. One might argue if silently changing the port number should be changed into raising an error instead.

So: what are you trying to achieve? Do you feel that TTN should allow for ADR MAC commands to be created by the application?