Add support for Snooz BLE devices

[AustinBrunkhorst]

Proposed change

Add support for Snooz BLE devices.

Thoroughly tested on multiple generations of the White Noise Machine model.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request: Add snooz integration home-assistant.io#24181

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[bdraco]

Ideally the user knows nothing about the connected state of the device.

I'm not sure how these devices work as I don't have one, but since the esphome devices have low connection limits and most bluetooth dongles start to fail with > 3-4 usually we don't stay connected to the device unless we know we are going to send commands.

At least for switchbots we disconnect after 20s if they haven't sent any more commands https://github.com/Danielhiversen/pySwitchbot/blob/36b03594762311942558c364ccb6b9aa6731d84a/switchbot/devices/device.py#L207

I haven't checked the lib to see if you are holding the connection for a long time or not but given the disconnect call I expect it is.

If you can't get the state from the advertisements, you are probably stuck with an always connected state like led_ble

[AustinBrunkhorst]

Ideally the user knows nothing about the connected state of the device.

I'm not sure how these devices work as I don't have one, but since the esphome devices have low connection limits and most bluetooth dongles start to fail with > 3-4 usually we don't stay connected to the device unless we know we are going to send commands.

At least for switchbots we disconnect after 20s if they haven't sent any more commands https://github.com/Danielhiversen/pySwitchbot/blob/36b03594762311942558c364ccb6b9aa6731d84a/switchbot/devices/device.py#L207

I haven't checked the lib to see if you are holding the connection for a long time or not but given the disconnect call I expect it is.

If you can't get the state from the advertisements, you are probably stuck with an always connected state like led_ble

@bdraco Unfortunately, the state isn't included in the advertisements. The lib does hold a connection for a long time - how about a config setting "use persistent connection"? When disabled, it would disconnect devices after a specified command timeout like you mentioned for switchbot.

I originally spent a good amount of time adding connection resilience to the lib since in testing it was somewhat painful for a 5-6 second command delay for "cold start" connections. I understand that not all users may want to have a persistent connection especially if the hardware is limited.

[bdraco]

If the device pushes updates via notify it is ok to hold the connection. If it doesn't it might be better to poll every so often instead.

It looks like it gets push updates https://github.com/AustinBrunkhorst/pysnooz/blob/61d5ffe1a115acd567781d22664e9998bf3fbf77/src/pysnooz/api.py#L98

I wouldn't add an option to disable the connection since it will make the integration more complex and probably not the best UX. Instead, maybe document that it needs a persistent connection

[bdraco]

I think the code may pass all the mypy checks or is really close to it so you could add it to .strict-typing

[bdraco]

Retested with library bump 👍

[MartinHjelmare]

Please address the comments in a new PR. Thanks!