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
Adjust locking to avoid data errors #97
Conversation
Codecov Report
@@ Coverage Diff @@
## main #97 +/- ##
==========================================
- Coverage 68.18% 66.62% -1.56%
==========================================
Files 67 67
Lines 5264 5397 +133
==========================================
+ Hits 3589 3596 +7
- Misses 1675 1801 +126
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Getting the MTU doesn't seem to work https://github.com/hbldh/bleak/blob/master/examples/mtu_size.py
|
Seems to be mostly working now the config num needs to be figured out since when you pair it has to sync 3 times now because we don't remember that |
while not self.client.is_connected: | ||
logger.debug("Connecting to %s", self.device) | ||
try: | ||
await self.client.connect() | ||
break | ||
except BleakError as e: | ||
logger.debug( | ||
"Failed to connect to %s: %s", self.client.address, str(e) | ||
) | ||
|
||
if self.description.address != self.client.address: | ||
self.client = BleakClient(self.description.address) | ||
|
||
await asyncio.sleep(5) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably shouldn't try forever
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it blocks shutdown
2022-07-15 02:54:59.770 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /homeassistant/restart request
2022-07-15 02:55:06.038 DEBUG (MainThread) [aiohomekit.controller.ble.pairing] Failed to connect to FB:EC:42:A9:79:F9: Device with address FB:EC:42:A9:79:F9 was not found.
2022-07-15 02:55:11.040 DEBUG (MainThread) [aiohomekit.controller.ble.pairing] FB:EC:42:A9:79:F9: Connecting
2022-07-15 02:55:21.137 DEBUG (MainThread) [aiohomekit.controller.ble.pairing] Failed to connect to FB:EC:42:A9:79:F9: Device with address FB:EC:42:A9:79:F9 was not found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened an issue so we don't forget #98
) | ||
|
||
async def _establish_connection(self): | ||
address = self.address | ||
while not self.client or not self.client.is_connected: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably shouldn't try forever
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened an issue so we don't forget #98
We also need to avoid this line for BLE devices and use the local name for the name so we don't read all the chars 2x |
I've seen local name be too vague quite often. Eg for my own Eve devices their local name seems to be "Eve" (most of the time). Think we should just make sure to only read the gatt database once and then retrieve the name from our cached copy so we don't even do a char read. |
👍 I'll make getting the cache working a priority in the next PR |
CharacteristicsTypes.PAIR_VERIFY, | ||
get_session_keys(self.pairing_data, self._session_id, self._derive), | ||
) | ||
# FIXME: this should not be a broad except handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the obvious bug in resume_m3, so I don't think we need this try/except block any more.
The resume handshake is supposed to be graceful in that if a device doesn't support resume or resume fails, the device will act as though we are already doing a full pair verify. So we should just be able to code defensively and fall through into a normal pair resume. There is logic to do that, but i wasn't handling the case where the method field wasn't present at all, which I do now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will adjust in the next run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No description provided.