alp_received_unsolicited_data_cb does not get called anymore about sub-iot-stack HOT 5 CLOSED

Yes indeed, you are correct this callback is not called anymore and the gateway code should be adapted, I will fix this.
The alp_command_result_callback alp_command_result_cb; replaces this in a more generic way: not only unsolicited file data will be passed in this way, but also responses to request commands. The full command is passed as parameter and can be parsed for example like in https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/blob/b2fcb3fb789cc2c1dc7d8216e210ff350452e37b/stack/framework/hal/chips/oss7_modem/modem.c#L63 . It is important to note that in order to receive responses in the application code you should the use_serial_interface parameter of alp_layer_init() to false. The gateway sets this to true which results in all ALP command responses being transmitted over the serial interface to the host which for example parses this and sends this to an IoT backend platform.
Is it possible to give some more insight in your application, to better understand what you want to achieve?

from sub-iot-stack.

Thanks for the explanation. I first noticed it because the led wasn't blinking anymore on the gateway after updating.

We're building our own gateway now. Which consists of the Murata LoRa module, a Raspberry Pi Zero W and a 4G module.

The first stage is to connect the gateway through the Pi, with python, mqtt to a backend. But later we think we don't need the Pi anymore and we can connect the 4G module directly to the microcontroller.

So for now we need to use use_serial_interface = true, and later we should set it to 'false' when we implement the gateway logic in the firmware app.

I still think it might be nice to be able to at least blink a led in the modem_only gateway application to quickly see if things are working.

from sub-iot-stack.

I see, thanks for the information. When disabling the serial console the on_alp_command_result_cb() callback will be called so you can toggle the LED (and probably sned the data over the 4G connection) there. On thing to keep in mind when integrating the 4G module on the same MCU is that the stack is timing sensitive, so if you have other tasks running for a longer time this might interfere with timings. One solution might be to keep a separate modem MCU and application MCU, where the latter could run the 4G and mqtt logic etc

from sub-iot-stack.

I will close this issue then, you can reopen if necessary

from sub-iot-stack.

Good point, we should definitely keep that in mind. Thanks!

from sub-iot-stack.