Sync sensor enabled state with core 2022.6+ #2547
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Change sensor 'registered' to indicate not registered, registered as disabled or registered as enabled - When a sensor is disabled, set it's status as such on core 2022.6 servers - In the sensor registration, use the basic sensor details in case there is no info in the database that can be used
- Now that there is a standard function to get the version, re-use it
- Update database migration to reset registration state on db upgrade to make sure the information is correct for all sensors - Only sync sensors that are actually available on the device - Fix registering all sensors on core <2022.6 on app/core version change - Fix unnecessary sensor updates due to location sensors which are never registered always triggering update on core >=2022.6
- After pushing app enabled changes to core, if on core 2022.6 check if the enabled state for any of the sensors is different from what is registered in the app and try to update the sensors. This is done by reading the entire config, because otherwise we wouldn't know about sensors that have been enabled and the app already updates all sensors at the same time so no need for tracking individual updates in the sensor update response. - Restore getting config using webhooks, because only the webhook config contains information about entity enabled state - Add support for opening a specific sensor's settings page, used for the notification when trying to enable a sensor that requires granting (additional) permissions
# Conflicts: # common/schemas/io.homeassistant.companion.android.database.AppDatabase/27.json # common/src/main/java/io/homeassistant/companion/android/database/AppDatabase.kt
JBassett
approved these changes
May 29, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
home-assistant/core#71561 and home-assistant/core#71562 added support for enabling/disabling entities and getting the current state of entities registered by the app, to allow apps and core to stay in sync. This PR implements these features for the sensors in the Android app.
The change should be seamless; when using core <2022.6 nothing changes, starting with core 2022.6 all sensors from the app will be registered with core and changing the enabled state in one place should also change it in another (unless additional permissions are required, in that case you have to enable the sensor in the app).
Screenshots
The only UI for this not in the frontend is the notification the app will post when a sensor is enabled in core, but the app doesn't have the required permissions:
Opening the notification links to the specific sensor settings screen.
This also technically works on Wear OS (except for the link to the settings screen), although it will never happen with the existing battery sensors:
Link to pull request in Documentation repository
I don't think this is necessary, there is currently no documentation on this behavior and the new behavior matches what is expected / other integrations
Any other notes
Is 1 device with 79 entities a new record for highest number of entities per device?