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.
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):
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.
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?