-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a difference between readValue and subscribing to characteristUpdatePublisher when reading a single value from a characteristic? #64
Comments
In a project I'm working on I'm using a similar pattern (although I call setNotify before subscribing, and never do explicit reads) and don't seem to be losing notifications from the peripheral. There's a couple of things I think are worth mentionig:
|
Is it possible that the issue is due to how Combine works? In my example above I've created the stream but I'm not actually subscribed to it until after I call My Is there maybe a better way to structure this sequence of calls so that I'm for sure subscribed to the publisher before the |
Hi, @tylerjames yes, any value sent before subscribing to do {
let values = await characteristicValueUpdatedPublisher
.filter { $0.characteristic.uuid == MyService.commandCharacteristicId }
.compactMap {
$0.value
}
.compactMap { String(data: $0, encoding: .utf8) }
.buffer(size: 10, prefetch: .keepFull, whenFull: .dropOldest)
.values
.eraseToStream()
// This 👇🏼
async let response = gatherMultipartResponse(fromStream: values)
try await setNotifyValue(
true,
forCharacteristicWithCBUUID: MyService.commandCharacteristicId,
ofServiceWithCBUUID: MyService.serviceId
)
try await writeValue(
request,
forCharacteristicWithCBUUID: MyService.commandCharacteristicId,
ofServiceWithCBUUID: MyService.serviceId
)
// Use the response
return await response
// ... Let me know if that works! |
Sorry, this is more of a question and maybe a problem.
I have a scenario where I first write to a characteristic with a request. My firmware interprets the request and posts a response to the same characteristic. Some of our hardware is more memory constrained than others so sometimes the response will be a single message and sometimes it will be broken up into multiple messages.
When the peripheral posts multiple messages I can usually receive them all by subscribing to the
characteristicUpdatePublisher
but if it posts only a single message then the update publisher does not seem to receive it.In the past, to combat this, I've had to add a
readValue
after mywriteValue
to see if the whole response has been posted to the characteristic. But I feel like this shouldn't really be necessary. Maybe the value is written before my line thatawait
s the response and then the response is missed?Is this how things should be working and is this the right way to deal with it?
If it helps my general structure is like this:
Thanks.
The text was updated successfully, but these errors were encountered: