Client without Notifications bricking device

RE: Client without Notifications bricking device

Edvin — Mon, 18 May 2020 08:35:11 GMT

My colleague Daniel Veilleux is right. Your transmit_samples() function never lets go. If this called from an interrupt, it will block other interrupts, because you never exit this interrupt. You should definitely consider calling this from your main loop.

I don't know what interrupt you are calling transmit_samples() from, but for the arguments sake, let's say it is a button press. How about something like this:

volatile bool transmit_samples_flag = false;

void button_press_handler()
{
    transmit_samples_flag = true;
}


...
int main(void)
{
    ...
    while (true)
    {
        if (transmit_samples_flag)
        {
            transmit_samples_flag = false;
            transmit_samples();
        }
        pwr_management_function();
    }
}

I believe you mentioned that you didn't want this kind of implementations because of current consumption. If current consumption is a concern, you should definitely break out of the:

while((err_code != NRF_ERROR_RESOURCES) && (requested_samples > transmitted_samples)){

if err_code = NRF_INVALID_STATE, because if you don't, the application will just spin through this while loop, actually never going to sleep at all.

    while((err_code != NRF_ERROR_RESOURCES) && (requested_samples > transmitted_samples)){
        
        /*FORM THE PACKET*/

        //send the packet!
        err_code = ble_ctcws_send_data(m_conn_handle, &m_ctcws, ble_packet, &packet_bytes_to_tx);
    
        //if we didn't get an error, and we're not done: incriment the number of samples and packets
        if (err_code == NRF_SUCCESS){
          transmitted_samples += (bytes_to_tx/2);
          packet_number ++;
        }
        else if (err_code != NRF_ERROR_RESOURCES)
        {
            break;  // you might as well break out of the while loop here, because if 
                    // err_code is not NRF_SUCCESS or NRF_ERROR_RESOURCES, it will not
                    // be the next time you call it either (until notifications are enabled).
        }
      }//while != NRF_ERROR_RESOURCES

BR,

Edvin

RE: Client without Notifications bricking device

Adam Gerken — Fri, 15 May 2020 18:31:22 GMT

I'm not convinced that's the right solution. Everything is event driven in my app, all main does is go to low power mode to wait for an event. This device has to operate for a couple years on a pair of coin cells so I have no extra power to spare.

This thread has gone way off into left field as I grasp at straws. The right solution is for my app to know if the client has notifications enabled. Edvin kept talking about it but I still have no idea how to do that.

RE: Client without Notifications bricking device

Daniel Veilleux — Fri, 15 May 2020 18:17:46 GMT

OK, so then your final ADC reading calls transmit_samples and gets stuck in an infinite loop at interrupt priority 5 -- the end result is the same. I think a lot of your problems would go away if you stopped calling transmit_samples from an interrupt context / callback and only called it from main.

RE: Client without Notifications bricking device

Adam Gerken — Fri, 15 May 2020 18:05:43 GMT

[quote userid="4528" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/250267"]OK, the adc_callback is probably getting executed at interrupt priority 6 in your firmware (usually defined as NRFX_SAADC_CONFIG_IRQ_PRIORITY in your sdk_config.h)[/quote]

The SAADC is actually priority 5, since when it's running it's the most important thing happening. It's also only the last ADC reading that triggers the transmit_samples routine. The ADC is timing critical so I write all the samples into a buffer, then transmit_samples reads the buffer memory, forms packets and send them out.

So it basically:

Gets a read request
Turns on a PPI to start taking readings
Triggers an ADC event that the ADC buffer is full, put these readings into an external QSPI memory
Turn off the PPI channel to stop the ADC readings then call transmit_samples to compile and send the first packet
BLE_GATTS_EVT_HVN_TX_COMPLETE then calls the remaining iterations of transmit_samples
Once it's done, I send a confirmation, disconnect and advertise.

[quote userid="4528" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/250267"]You should check for NRF_ERROR_INVALID_STATE when you call ble_ctcws_send_status. Then you can either wait for the peer device to enable the notification, as described by Edvin above, or disconnect[/quote]

This is exactly what I was trying to do at the bottom of my transmit_samples routine and it wasn't working. When I try to disconnect after getting NRF_ERROR_INVALID_STATE back from ble_ctcws_send_data nothing works. Nothing. sd_ble_gap_disconnect doesn't work, interrupts are gone, etc.

[quote userid="4528" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/250267"]If you disconnect then I'd recommend calling sd_ble_gap_disconnect and then waiting for the BLE_GAP_EVT_DISCONNECTED before restarting advertising (or simply calling NVIC_SystemReset).[/quote]

This is exactly what I do... send the sd_ble_gap_disconnect then wait for the BLE_GAP_EVT_DISCONNECTED event, which triggers the hardware to go into low power mode, and start advertising again.

As I said above, I'm totally lost with the soft device functionality for the most part, and I have no idea whats going on for most of it... I'm a consultant and have like 100 projects going at the same time so this isn't a full time thing trying to understand all the tiny details of this. I guess that's an issue but there's not much I can do about it. I just need to get this tiny thing done so my customer can start shipping these.

RE: Client without Notifications bricking device

Daniel Veilleux — Fri, 15 May 2020 17:19:25 GMT

Hello Adam,

OK, the adc_callback is probably getting executed at interrupt priority 6 in your firmware (usually defined as NRFX_SAADC_CONFIG_IRQ_PRIORITY in your sdk_config.h). The events from the SoftDevice are also delivered in interrupt priority 6 for the S140. So it sounds like you end up in an infinite while loop in transmit_samples --executing at interrupt priority 6-- because you aren't exiting when you see NRF_ERROR_INVALID_STATE. This will effectively block you from receiving further SoftDevice or SAADC events.

You should check for NRF_ERROR_INVALID_STATE when you call ble_ctcws_send_status. Then you can either wait for the peer device to enable the notification, as described by Edvin above, or disconnect. If you disconnect then I'd recommend calling sd_ble_gap_disconnect and then waiting for the BLE_GAP_EVT_DISCONNECTED before restarting advertising (or simply calling NVIC_SystemReset).

RE: Client without Notifications bricking device

Adam Gerken — Fri, 15 May 2020 15:38:45 GMT

[quote userid="4528" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/250058"]Is your transmit_samples function called in an interrupt context? If so, no other interrupts can preempt it unless they are a strictly greater priority (lower number).[/quote]

Um, I don't think so? It gets called initially from the final adc_callback, then from there on it gets called from the BLE_GATTS_EVT_HVN_TX_COMPLETE event, as the softdevice buffer empties. So I guess maybe?

I have absolutely no issues with interrupts if the client device has notifications enabled, the whole thing works perfectly and reliably. As soon as it gets tripped up with a client that doesn't have notifications enabled everything stops. I don't really need to "handle" this other than just disconnecting the connection... not using notifications isn't supported, the only issue is if a customer messes this up somehow the device hangs forever.

[quote userid="4528" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/250058"]f sd_ble_gap_disconnect is returning NRF_ERROR_INVALID_STATE then "Disconnection in progress or link has not been established." Not sure how you debugged it but maybe the first call to sd_ble_gap_disconnect succeeded and then the second call reported an error and got your attention?[/quote]

This really confused me... I can't find the logic in why this is the error that sd_ble_gap_disconnect is returning. I'm only calling it once and it fails, even though the connection is still up. This goes back to the issue of the whole thing just locking up once I try to send a packet to a client without notifications. I just can't get my hands around what it's doing.

RE: Client without Notifications bricking device

Daniel Veilleux — Thu, 14 May 2020 20:17:09 GMT

Is your transmit_samples function called in an interrupt context? If so, no other interrupts can preempt it unless they are a strictly greater priority (lower number).

If sd_ble_gap_disconnect is returning NRF_ERROR_INVALID_STATE then "Disconnection in progress or link has not been established." Not sure how you debugged it but maybe the first call to sd_ble_gap_disconnect succeeded and then the second call reported an error and got your attention?

RE: Client without Notifications bricking device

Adam Gerken — Thu, 14 May 2020 19:38:06 GMT

I don't believe so. My preprocessor defines are just:

CONFIG_GPIO_AS_PINRESET

CONFIG_NFCT_PINS_AS_GPIOS

FLOAT_ABI_HARD

INITIALIZE_USER_SECTIONS

NO_VTOR_CONFIG

NRF52840_XXAA

NRF_SD_BLE_API_VERSION=6

S140

SOFTDEVICE_PRESENT

SWI_DISABLE0

I do believe that I'm getting NRF_ERROR_INVALID_STATE back after I call my send_data, which does call sd_ble_gatts_hvx. The issue I'm running into now, is what do I do then? If I call sd_ble_gap_disconnect I also just get NRF_ERROR_INVALID_STATE back. I think this is where it's all hung up.

I don't do an error check after calling my send data routine though, so I'm not sure why it would be getting hung up to the point of disabling all the interrupts. I only look for SUCCESS, or ERROR_RESOURCES for program logic stuff.

Here's the routine that's calling my "send_data"

void transmit_samples(void){

    ret_code_t            err_code;
    uint16_t              bytes_to_tx, packet_bytes_to_tx;
    uint8_t               ble_packet[DEFAULT_MAX_MTU_SIZE];
    uint8_t               checksum;

    //send packets until we've filled the buffer, or we're done.
    if (requested_samples > transmitted_samples){

      while((err_code != NRF_ERROR_RESOURCES) && (requested_samples > transmitted_samples)){
        
        /*FORM THE PACKET*/

        //send the packet!
        err_code = ble_ctcws_send_data(m_conn_handle, &m_ctcws, ble_packet, &packet_bytes_to_tx);
    
        //if we didn't get an error, and we're not done: incriment the number of samples and packets
        if (err_code == NRF_SUCCESS){
          transmitted_samples += (bytes_to_tx/2);
          packet_number ++;
        }
      }//while != NRF_ERROR_RESOURCES

    }//if (requested_samples > transmitted_samples)

    //if we're done, let the device know
    else {
        send_application_status(TRANSFER_DONE);
        #ifdef DEBUG
        printf("Transmission done, sent %d samples in %d packets\r\n",transmitted_samples, packet_number);
        #endif
        rtc_set(DEFAULT_TIMEOUT);
        requested_samples = 0;
    }

}//transmit_samples

Here's my "send_data":

uint32_t ble_ctcws_send_status(uint16_t conn_handle, ble_ctcws_t * p_ctcws, uint8_t * p_data, uint16_t * p_length)
{
    ble_gatts_hvx_params_t params;

    memset(&params, 0, sizeof(params));
    params.type   = BLE_GATT_HVX_NOTIFICATION;
    params.handle = p_ctcws->status_char_handles.value_handle;
    params.p_data = p_data;
    params.p_len  = p_length;

    return sd_ble_gatts_hvx(conn_handle, &params);
}

RE: Client without Notifications bricking device

Daniel Veilleux — Thu, 14 May 2020 19:03:05 GMT

Hello Adam,

Do you have "DEBUG" in the preprocessor symbols for your project? I suspect that your project is calling sd_ble_gatts_hvx and then asserting when it receives the NRF_ERROR_INVALID_STATE error code. If DEBUG was defined then this can put you into an infinite loop at the bottom of the default app_error_fault_handler, with all of your application's interrupts disabled. If you remove the DEBUG symbol then the assert handler will initiate a system reset instead.

RE: Client without Notifications bricking device

Adam Gerken — Thu, 14 May 2020 18:22:36 GMT

[quote userid="26071" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/249829"]Perhaps this is because the ble_nus_data_send() returns != 0?[/quote]

I'm not using nus, it's a custom service but is probably similar. I'm only processing two error codes right now, NRF_SUCCESS and NRF_ERROR_RESOURCES. If the "send_data" service returns success, I compile another packet and send it to the SD until I get an NRF_ERROR_RESOURCES, then I wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE event, and do the whole process again.

I just tried looking for other error codes and quitting the transmission if "send_data" returns something other than SUCCESS or ERROR_RESOURCES but it still hangs up before I can even look at what the code is.

[quote userid="26071" url="~/f/nordic-q-a/61011/client-without-notifications-bricking-device/249829"]

Are you able to see from your application when the notification is enabled?

[/quote]

No. This is the whole point of this whole thread. I don't know how to do this. This is exactly what I want to do.

RE: Client without Notifications bricking device

Edvin — Thu, 14 May 2020 06:34:01 GMT

I think you are rushing ahead:

[quote user="Adam Gerken"]When my application sends data to a client that doesn't have notifications enabled, the program hangs up and no interrupts work any more.[/quote]

Perhaps this is because the ble_nus_data_send() returns != 0?

[quote user="Edvin Holmseth"]Are you able to see from your application when the notification is enabled?[/quote]

RE: Client without Notifications bricking device

Adam Gerken — Wed, 13 May 2020 13:58:48 GMT

Yes, I'm talking about interrupts. When my application sends data to a client that doesn't have notifications enabled, the program hangs up and no interrupts work any more. I'm trying to use a timer to reset the connection and go back to advertising when this happens, but it doesn't work because interrupts don't work. No interrupts work when this happens.... My SPI hangs up, Timer hangs up, RTC hangs up, everything.

No, I can not see in my application when notifications are enabled. That's exactly what I said I can't get to work.

How does a timer help me check for an event when notifications are enabled? I'm not following you at all here, I think we're talking about very different things. Are you suggesting using a timer to poll the notification status? I asked a while ago if I can just check the status of notifications, because then I can just do that before trying to transmit on that characteristic, and just not transmit if notifications aren't enabled. That would be the ideal situation, but I thought you said you can't query the notification status.

The basic flow of the program:

Server = Nordic device, Client = PC

Server advertises
Client connects
Client requests x number of data samples
Server collects samples
Server transmits samples

It's the last step that's getting hung up if the client doesn't have notifications enabled. The Server needs to transmit a large amount of data but just locks up.

RE: Client without Notifications bricking device

Edvin — Wed, 13 May 2020 07:42:40 GMT

[quote user="Adam Gerken"]I set my RTC interrupt to 0 to try and over ride whatever the SD is doing. I'm totally lost now... I get that some SD events are priority 0, but I don't know how/why writing to a characteristic that doesn't have notifications set on the other side would trigger a priority 0 interrupt.[/quote]

Are you talking about the interrupt priorities now? If so, don't change them. It shouldn't be needed in this case. Setting the RTC interrupt IRQ priority to 0 will damage the softdevice functionality.

Set the RTC priority back to 6.

Are you able to see from your application when the notification is enabled? If yes, I suggest you look into using the app_timer as your timer to check whether notifications are enabled. Check out the ble_app_hrs example, which uses an app_timer to generate simulated battery measurements.

Best regards,

Edvin

RE: Client without Notifications bricking device

Adam Gerken — Tue, 12 May 2020 17:40:53 GMT

So I can't get that to work, no other coder here, just me. I'm a pretty competent C coder but this SDK is so hard to follow (very common complaint around the internet.) I was going to implement a time out, since that's pretty easy... if the program gets stuck, force a timeout and go back to advertising. However, when I hit this snag it seems to be disabling all other interrupts. My SPIM gets hung up waiting for an event end interrupt, and my RTC interrupt to reset everything doesn't trigger.

I set my RTC interrupt to 0 to try and over ride whatever the SD is doing. I'm totally lost now... I get that some SD events are priority 0, but I don't know how/why writing to a characteristic that doesn't have notifications set on the other side would trigger a priority 0 interrupt.

Any thoughts? I'm beating my head against the wall here.

RE: Client without Notifications bricking device

Edvin — Thu, 07 May 2020 12:40:51 GMT

Do you have anyone with more software experience that can have a look?

If you look at the ble_app_uart example, in the same event handler:

    if ((p_evt_write->handle == p_nus->tx_handles.cccd_handle) &&
        (p_evt_write->len == 2))
    {
        if (p_client != NULL)
        {
            if (ble_srv_is_notification_enabled(p_evt_write->data))
            {
                p_client->is_notification_enabled = true;
                evt.type                          = BLE_NUS_EVT_COMM_STARTED;
            }
            else
            {
                p_client->is_notification_enabled = false;
                evt.type                          = BLE_NUS_EVT_COMM_STOPPED;
            }

            if (p_nus->data_handler != NULL)
            {
                p_nus->data_handler(&evt);
            }

        }

The line:

evt.type = BLE_NUS_EVT_COMM_STARTED;

and

p_nus->data_handler(&evt); You don't see this event in the event handler in main.c, but that is only because it is not checked.

If you add this event in the nus_data_handler() event handler in main.c you can see it:

static void nus_data_handler(ble_nus_evt_t * p_evt)
{

    if (p_evt->type == BLE_NUS_EVT_RX_DATA)
    {
        uint32_t err_code;

        NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
        NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);

        for (uint32_t i = 0; i < p_evt->params.rx_data.length; i++)
        {
            do
            {
                err_code = app_uart_put(p_evt->params.rx_data.p_data[i]);
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
                {
                    NRF_LOG_ERROR("Failed receiving NUS message. Error 0x%x. ", err_code);
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_BUSY);
        }
        if (p_evt->params.rx_data.p_data[p_evt->params.rx_data.length - 1] == '\r')
        {
            while (app_uart_put('\n') == NRF_ERROR_BUSY);
        }
    }
    else if (p_evt->type == BLE_NUS_EVT_COMM_STARTED)
    {
        NRF_LOG_INFO("notifications started");
    }

}

will forward the event to the event handler that is passed on in ble_nus_init(). But in your custom project, I am not sure whether you have implemented this kind of event handler. But it is possible.

This characteristic (the TX characteristic) is not a write characteristic either, but since it is possible to enable notifications on it, it is possible to write to the CCCD of the characteristic. This will appear as an BLE_GATTS_EVT_WRITE event.

I don't know anything about how your characteristic is set up. Are notifications supported?

If you want a getting started guide, you can check out this github guide:

https://github.com/edvinand/custom_ble_service_example

However, I believe that you have already made a working application, so this guide may not suit very well.

This is at least how you can check whether the notifications are enabled, but how to forward this to main.c, is not Nordic SDK specific, but this is one way to do it in C.

Best regards,

Edvin

RE: Client without Notifications bricking device

Adam Gerken — Wed, 06 May 2020 19:42:20 GMT

Alright, I'm totally lost... this sdk is so hard to follow for hardware guy like me.

Right now my "on_write" function is:

static void on_write(ble_ctcws_t * p_ctcws, ble_evt_t const * p_ble_evt)
{
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    //take care of a write to config
    if (p_evt_write->handle == p_ctcws->config_char_handles.value_handle)
    {
        p_ctcws->config_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);
    }

    //take care of a write to samples
    else if (p_evt_write->handle == p_ctcws->samples_char_handles.value_handle)
    {
        p_ctcws->samples_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);
    }

    //take care of a write to status
    else if (p_evt_write->handle == p_ctcws->status_char_handles.value_handle)
    {
        p_ctcws->status_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);
    }
}

One of those (status) is one that I need to check notifications on, would I just add the cccd stuff like so (line 22+):

static void on_write(ble_ctcws_t * p_ctcws, ble_evt_t const * p_ble_evt)
{
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    //take care of a write to config
    if (p_evt_write->handle == p_ctcws->config_char_handles.value_handle)
    {
        p_ctcws->config_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);
    }

    //take care of a write to samples
    else if (p_evt_write->handle == p_ctcws->samples_char_handles.value_handle)
    {
        p_ctcws->samples_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);
    }

    //take care of a write to status
    else if (p_evt_write->handle == p_ctcws->status_char_handles.value_handle)
    {
        p_ctcws->status_write_handler(p_ctcws, p_evt_write->data, p_evt_write->len);

        if ((p_evt_write->handle == p_ctcws->status_char_handles.cccd_handle) && (p_evt_write->len == 2)){
            if (ble_srv_is_notification_enabled(p_evt_write->data)){
            //notifications are on
            }
            else{
            //notifications are off
            }
        }
}

The other characteristic doesn't have a write event because it's data is transmit only, I would just create a new write handle and all that for that one then implement similar to the status one above?

Also, how does this status get back to the main program?.. this service thing is the one part of the code I never really got my head around... it all just looks like an enormous web of data structures and things I can't follow.

Also, just thinking out loud, what happens if the notifications are on by default, will this ever get called? Is there a way I can just check notification status in my main.c? That would be way easier, if I could just check before sending a packet.

RE: Client without Notifications bricking device

Edvin — Wed, 06 May 2020 12:42:38 GMT

Looking at the ble_app_uart example, the BLE_GATTS_EVT_WRITE event in ble_nus.c is triggered whenever someone write something to a characteristic, including the CCCD (for enabling notifications). In SDK16, it looks like this:

static void on_write(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                    err_code;
    ble_nus_evt_t                 evt;
    ble_nus_client_context_t    * p_client;
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gatts_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gatts_evt.conn_handle);
    }

    memset(&evt, 0, sizeof(ble_nus_evt_t));
    evt.p_nus       = p_nus;
    evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
    evt.p_link_ctx  = p_client;

    if ((p_evt_write->handle == p_nus->tx_handles.cccd_handle) &&
        (p_evt_write->len == 2))
    {
    ...

The last if-check in this snippet checks whether this event is caused by a notification change. If the value is 0x0001 then notifications are enabled.

You can do this with a central that enables notifications to see what it looks like.

RE: Client without Notifications bricking device

Adam Gerken — Tue, 05 May 2020 15:06:48 GMT

Seems like a reasonable idea. How would I see if the connected device enables notifications? I could also just check when the client requests that I send data (part of our application) and just deny the request if they don't have notifications enabled.

RE: Client without Notifications bricking device

Edvin — Tue, 05 May 2020 15:02:40 GMT

Oh, I see. Well. There is no event for something that never occurs in this case, unfortunately. Since it isn't mandatory to enable notifications, there will be no timeout from the SoftDevice.

I suggest that you try to add an app_timer to the device that you start in the connected event. If the connected device enables notifications on this characteristic, stop the timer, but if the timer times out, you would disconnect from the connected device, and it should start advertising again.

Does that seem like a viable solution?

BR,

Edvin

RE: Client without Notifications bricking device

Adam Gerken — Tue, 05 May 2020 13:57:40 GMT

This is a production device that a customer is having this issue with when trying to integrate into their software ecosystem, no debug available. Like I said, there's no hardware reset, and the device disappears.

"My suspicion is that the device is trying to send a notification, but this isn't possible since it isn't enabled by the central(client)."

Yes, exactly what's happening. I need to detect when this happens, and instead of sitting there waiting forever, I need to disconnect and advertise. I just can't find the notification that says the client hasn't responded or whatever to trigger the disconnect and advertise.

RE: Client without Notifications bricking device

Edvin — Tue, 05 May 2020 13:45:09 GMT

Hello,

What do you mean by "bricking device"?

[quote user=""]This causes the unit to seemingly wait indefinitely waiting to get the thumbs up from the client that it received the packet, which never comes.[/quote]

What device is waiting? Central or peripheral? And is this "thumbs up" supposed to be delivered via a notification, perhaps?

Have you/they tried to debug the "bricked device" while this is happening? Does the log say anything?

My suspicion is that the device is trying to send a notification, but this isn't possible since it isn't enabled by the central(client). But you/they would need to debug to see why the thumbs up is not working. Remember that we don't know anything about the logic in your application.

Best regards,

Edvin