I have successfully used the gRPC API to send the LinkADRReq to the device, and I believe that some other MAC command can also be implemented.
However, ADR operation needs to dynamically adjust the device according to the current rate and power consumption of the device. However, When I actively issue MAC command, I can’t get the current device’s speed and power consumption as the judgment input of the ADR algorithm.
How to combine the logic of the two?
I don’t think it is a good idea to schedule custom mac-commands. The option is there for historical reasons (and maybe it should be removed?). The issue is that when you modify the state of a device yourself, the ChirpStack Network Server will not be aware of this and this can result in malfunctioning devices.
For custom ADR logic, I recommend that you look into the pluggable ADR engine option. This will allow you to return the desired state to the NS and let the NS issue the mac commands.
I don’t have custom MAC instructions, but those defined by LoRaWAN specifications like LinkADRReq and LinkCheckReq and So on.
Why the Network Server will not be aware of this? After all, I see that the MAC command is sent by the network server through the downlink message.
It’s not a good choice to delete the MAC command API because it will stimulate people’s creativity, and it also needs more operation space for scientific research.
Because mac-commands might be a result of a requested state-change by the NS. E.g. your device might not be aligned with the parameters in the configuration file. That will result in a mac-command sent by the NS to update the device config according to the config file.
If you send your own mac-commands, then you are basically taking a shortcut 
