Hi,
I'm seeing an unexpected behaviour when doing a write without response on a characteristic. When writing something this same data is received on the stream property "value".
I have used some other BLE libraries on React native, Cordova, Go, Javascript... and never seen a behaviour like this. On all of these you never receive notifications with the same data you have just written on a characteristic, no matter if writing with or without response.
I have checked the code and seen that it is done on then write method:
if (type == CharacteristicWriteType.withoutResponse) {
_value.add(value);
return result;
}
If there is a use case for this strange behaviour, maybe could it be configured to work like on the rest of BLE libraries with some option on write?
Same here, latest update on "write without response" seems bizarre
same for me (write with response), with c.write(withoutResponse: false), i receive data on my listeners for c.value.listen()
The use case here is to assume that if the write platform call completed successfully, but was without response, to internally update the characteristic anyways, so that the example app showed the correct value in the UI. I do believe this is leading to a duplicate notification when the user writes with response.
I understand the case of the example app, the problem is that this behaviour breaks a more typical use of characteristic to send and receive messages to a BLE device.
The typical example of this is sending messages to a device (serialized as JSON, msgpack...) writing to some characteristic and receiving its responses listening for notifications on it. So you can be sure that everything you read on that characteristic comes from the device.
Right now the current behaviour makes this difficult.
Also, as I mentioned I haven't seen this behaviour on other BLE libs so maybe it's better for users to try to behave in the same way everyone else works.
As for the example app maybe this should be done on its own code rather than on the lib?
The typical example of this is sending messages to a device (serialized as JSON, msgpack...) writing to some characteristic and receiving its responses listening for notifications on it. So you can be sure that everything you read on that characteristic comes from the device.
+1
At least, it should be possible to distinguish, what the cause for the notification was (a write from within the app or a response from the device), maybe carry a sender attribute or something if you want to support both use cases.
I agree with @soyangel and @khainke here. I think that to avoid confusion this feature should be turned off by default, if it's kept at all. Filtering the data you receive in notifications to ensure that values you receive are actually what you receive and not trying to write feels backwards and not something that you would expect to do.
At the minimum there should be an easy way to distinguish which notifications that comes from the write operation and the device itself.
I agree with others. Currently I'm forced to do a fork of your library just to comment out this line. Because of a specific of a protocol I use, sometimes I get a response from a previous send operation because of a _value.add(value); line. And it makes me cry.
Yikes, sorry this has taken me so long, fix coming tonight!
Most helpful comment
I understand the case of the example app, the problem is that this behaviour breaks a more typical use of characteristic to send and receive messages to a BLE device.
The typical example of this is sending messages to a device (serialized as JSON, msgpack...) writing to some characteristic and receiving its responses listening for notifications on it. So you can be sure that everything you read on that characteristic comes from the device.
Right now the current behaviour makes this difficult.
Also, as I mentioned I haven't seen this behaviour on other BLE libs so maybe it's better for users to try to behave in the same way everyone else works.
As for the example app maybe this should be done on its own code rather than on the lib?