Bug scheduling messages in the unsollicited response callback about sub-iot-stack HOT 8 OPEN

Example:

void scheduled_function()
{
d7ap_send(message); // Returns 0 in both cases
}

bool unsolicited_cb(args)
{
sched_post_task(&scheduled_function); // Doesn't work
timer_post_task_delay(&scheduled_function, delay); // Does work
return false;
}

from sub-iot-stack.

this is a bit of a weird use case to me, you want to transmit a message when getting an unsolicited message, but you don't want to answer it in the same dialog? I think now you're trying to start a new dialog while the previous one is still wrapping up, however it should indeed not return SUCCESS.

from sub-iot-stack.

I don't respond in the dialog because I'm switching access classes to go from background scanning to continious forground scanning.

from sub-iot-stack.

won't it be better to first answer and then switch classes? I think you still want to transmit to the same device?

from sub-iot-stack.

I do answer first. The scheduled function just sends the next message using the new access class.

from sub-iot-stack.

so you're scheduling two d7 messages at the same time? Sorry, just trying to get a grasp of the situation. alp never directly schedules an independent answer right after it got some unsollicited message

from sub-iot-stack.

Well the message gets send in a function thats called by the scheduler so it should be send outside the scope of the unsolicited callback. I think the message did end up in the message queue but it didn't get send. I could trigger the function by pressing a button on another board and after pressing it a couple of times the d7ap_send funciton would return an error code but the messages were never transmitted. (I think the error code was caused because the buffer was full)

from sub-iot-stack.

ok, weird, we'll have to look into that. We haven't seen this happen using alp above d7.

from sub-iot-stack.