Specific Lovense LUSH3 causing exception (and Hush and Lapis)
DavidNorman opened this issue · comments
Describe the bug
I have 2 Lovense Lush 3 devices. One works well with buttplug.io, but the other one causes an exception when it is scanned.
Sadly I cannot remember which I bought recently. One has the device string LVS-Lush, and the other LVS-Lush352.
The one with 352 works with your system, the other one does not.
the 352 one has one service, starting 53300001
the non working one has two services, one as above, and one starting 984227f3. this one still only advertises the 53300001 service, but that service is the second in the enumerated list of services if that makes any difference.
Expected behavior
Both should function identically.
Actual behavior
When scanning one, an exception occurs in some worker thread and the system stops.
Additional context
Add any other context about the problem here.
the one which doesn't work also has a couple of extra generic type characteristics, like the manufacturer name
the same issue happens with my relatively new Lapis toy. It has the same extra services and the same extra characteristics, although the error is very slightly different.
Maybe the "questionable assumptions" are not valid, although i don't know enough about Bluetooth to know:
fn check_discovered(&mut self) {
// It's time for QUESTIONABLE ASSUMPTIONS.
//
// For sake of being lazy, we don't want to fire device connection until
// we have all of our services and characteristics. We assume that
// set_characteristics should be called once for every entry in the
// service map. Once that's done, we're filled out enough and can send
// back a Connected reply to the waiting future with all of the
// characteristic info in it.
if !self.services.values().any(|service| !service.discovered) {
if self.connected_future_state.is_none() {
panic!("We should still have a future at this point!");
}
This is the log from before the error. This is actually the log from a relatively new Lovense Lapis.
I note that the required service is the right one (starting 553000001) and the characteristics that it finds are also the right ones.
Now i've seen a similar thing happen with the one that works. I am on a MacBook Air 7.2, running MacOS 10.15.7
It seems unlikely but could the machine be failing to service something in time?
nevertheless, the newer toys (including my Hush as well) all cause the problem during connection, while the older one does not.
I noticed the same issue for the Hush 2 on MacOS (11.7.10) on an old Macbook Air from (2013).
Intiface App Version 2.5.5.
Device Config Version 2.25
Seems to be MacOS specific, as it works on Windows.
Ok hmm. I guess we've got some sort of race issue down in btleplug. I'll try to check it out soon.
Not sure why this got closed? It's not fixed yet. I've at least made a followup on btleplug.