write_request_characteristic not detected in event pointer loop
11/328/2020 | 08:49 PM
Hello:
I have a custom app with a custom board which started from Thermometer Example.
I have a characteristic called digital from the automation I/O generic service. Using the Microsoft Bluetooth LE Explorer client I can write and read this characteristic r, but if I put a breakpoint on this code in the event pointer loop it never gets there:
if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_digital) {
int data[3];
// Save data in to Pointer to show which data type (acetone, co2,etc..)
Pointer_Data = evt->data.evt_gatt_server_attribute_value.value.data[0]; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< breakpoint
/* Send response to Write Request */
gecko_cmd_gatt_server_send_user_write_response(
evt->data.evt_gatt_server_user_write_request.connection,
gattdb_digital,
bg_err_success);
}
Here is the GATT configurator for this characteristic:
Therefore if it never gets there and I can't write into the variable Pointer_Data.
Thanks for your help!
Marcelo
Bluetooth Low Energy
Discussion Forums
Unanswered
If I try the empty_example with the same charateristic added, same result: no write_request_characteristic detected.
Indicates that a remote GATT client is attempting to write a value of an attribute into the local GATT database, where the attribute was defined in the GATT database XML file to have the type="user".
You are using type hex, the stack does all transactions automatically, it doesn't raise up for the application to handle.
0
Yes. I did change the type to user which worked for the first transaction. However, the following user_write_request transactions were not detected in the event loop, and after some seconds the device disconnected. The client sends the request and gets a response back but nothing on server event loop.
I have no idea what's going on.
Thank you for any help
Marcelo
0
Have you tried with a GATT client other than Microsoft Bluetooth LE Explorer? Try with a smartphone and EFR Connect and see if the results is the same. If it is then please upload a simple project that shows the issue and steps on how to replicate.
0
In order to replicate I took the soc_empty project and did the following procedure and result:
1. Added the service automation io from the generic services, and added the Digital characteristic. Removed the Analog and Aggregate characteristic. I am including the project file.
2. I downloaded the EFR Connect app (on android phone) and tried to write into this characteristic.
3. Wrote a "Output-state" value (which is a 3) into the characteristic, and got a good response back
4. After about 30 seconds the device disconnected.
5. I write another value (say active=1)before the disconnection, and I DO NOT get a user_write_request.characteristic event (before disconnection). It appears that the GATT stack gets lost after the first write.
6. This is what happens in my application that I described above.
Please see if you can duplicate and find what's wrong. We have been stuck for a while
I think the issue is that you are only handling the write requests but you're not handling the read requests. The mobile app might be reading the characteristic and since you are not handling that you get the GATT timeout after 30 seconds.
0
Thanks. That was it. If I don't have a read property on the characteristic do I still need to handle a read_request ?
0
You shouldn't have to but on your project you have Read property as True. If you put that to false and you are still getting the read requests then that is a bug, let us know if that is the case.
write_request_characteristic not detected in event pointer loop
Hello:
I have a custom app with a custom board which started from Thermometer Example.
I have a characteristic called digital from the automation I/O generic service. Using the Microsoft Bluetooth LE Explorer client I can write and read this characteristic r, but if I put a breakpoint on this code in the event pointer loop it never gets there:
if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_digital) {
int data[3];
// Save data in to Pointer to show which data type (acetone, co2,etc..)
Pointer_Data = evt->data.evt_gatt_server_attribute_value.value.data[0]; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< breakpoint
/* Send response to Write Request */
gecko_cmd_gatt_server_send_user_write_response(
evt->data.evt_gatt_server_user_write_request.connection,
gattdb_digital,
bg_err_success);
}
Here is the GATT configurator for this characteristic:
Therefore if it never gets there and I can't write into the variable Pointer_Data.
Thanks for your help!
Marcelo
The answer is in the documentation: https://docs.silabs.com/bluetooth/latest/gatt-server#evt_gatt_server_user_write_request
You are using type hex, the stack does all transactions automatically, it doesn't raise up for the application to handle.
Yes. I did change the type to user which worked for the first transaction. However, the following user_write_request transactions were not detected in the event loop, and after some seconds the device disconnected. The client sends the request and gets a response back but nothing on server event loop.
I have no idea what's going on.
Thank you for any help
Marcelo
In order to replicate I took the soc_empty project and did the following procedure and result:
1. Added the service automation io from the generic services, and added the Digital characteristic. Removed the Analog and Aggregate characteristic. I am including the project file.
2. I downloaded the EFR Connect app (on android phone) and tried to write into this characteristic.
3. Wrote a "Output-state" value (which is a 3) into the characteristic, and got a good response back
4. After about 30 seconds the device disconnected.
5. I write another value (say active=1)before the disconnection, and I DO NOT get a user_write_request.characteristic event (before disconnection). It appears that the GATT stack gets lost after the first write.
6. This is what happens in my application that I described above.
Please see if you can duplicate and find what's wrong. We have been stuck for a while
Much appreciate it!
Marcelo