Skip to content
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

feat: iOS / iPhone / Private BLE Device / IRK Support! #140

Merged
merged 6 commits into from
Mar 24, 2024
Merged

Conversation

agittins
Copy link
Owner

@agittins agittins commented Mar 24, 2024

  • 🚀 feat: iOS / iPhone Support with IRK Integrate with Private BLE Device to support iOS / iPhone tracking with IRK #135

    • Integrated with the Private BLE Device integration. Any devices set up in Private BLE will automatically be configured as Bermuda trackers as well.

    • 🐛 Fixed error if no devices are saved for setup (ie, CONF_DEVICES is empty) as may happen if one uses only Private BLE Devices.

    • Added refresh calls to device registry listener

    • Improved some mac_format calls by forcing .lower(), since some "addresses" like private ble will not match a MAC-based pattern.

    • Fixed new_device signal dispatcher to use full list of devices and check for create_sensor rather than scanning CONF_DEVICES

    • Added Private BLE Devices to the iBeacon code, so both are treated as "meta-devices" in that they have data that is provided via the MAC address, but is not "of" the mac address.

    • Fixed case when _refresh_scanners gathers addresses.

    • Updated device_info in entity.py to ensure entities tied to private_ble devices get linked to those device_registry entries.

  • fix: typedef for device_new callback

  • 🚤 feat: Update areas in realtime if scanners are moved improves Changing Area of a scanner does not get reflected in Bermuda #137 fix.

    • If an esphome or other scanner/proxy device has its "area" modified, we immediately update the Areas without requiring a reload or restart.

    • A little comment-linting.

  • 🐛 fix: matching of scanner IDs loaded from data (stuck area) fixes Changing Area of a scanner does not get reflected in Bermuda #137

    • scanner entries were being saved in data with "our default lower-case" form, but when loading was comparing them to uppercased. This was causing the data stored values to prevent correct loading, so changing the area of a scanner never got applied.
  • 📯 chore: Downgraged ibeacon stale source msg to debug

- was set to warning, and #138 shows people are getting this on their systems. I'm not sure why, so adding extra params to log but downgrading to debug since it's spamming people's logs.
- scanner entries were being saved in data with "our default lower-case" form, but when loading was comparing them to uppercased. This was causing the data stored values to prevent correct loading, so changing the area of a scanner never got applied.
- If an esphome or other scanner/proxy device has its "area" modified, we immediately update the Areas without requiring a reload or restart.

- A little comment-linting.
- Integrated with the `Private BLE Device` integration. Any devices set up in Private BLE will automatically be configured as Bermuda trackers as well.

- Fixed error if no devices are saved for setup (ie, CONF_DEVICES is empty) as may happen if one uses *only* Private BLE Devices.

- Added refresh calls to device registry listener

- Improved some mac_format calls by forcing .lower(), since some "addresses" like private ble will not match a MAC-based pattern.

- Fixed new_device signal dispatcher to use full list of devices and check for create_sensor rather than scanning CONF_DEVICES

- Added Private BLE Devices to the iBeacon code, so both are treated as "meta-devices" in that they have data that is provided via the MAC address, but is not "of" the mac address.

- Fixed case when _refresh_scanners gathers addresses.

- Updated device_info in entity.py to ensure entities tied to private_ble devices get linked to those device_registry entries.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant